[CMake] External projects and imported targets

[Marcus D. Hanwell]

On Sun, May 16, 2010 at 2:47 PM, Timothy M. Shead <tshead at k-3d.com> wrote:

> On 05/16/2010 12:36 PM, Marcus D. Hanwell wrote:
> > On Sun, May 16, 2010 at 2:26 PM, Timothy M. Shead <tshead at k-3d.com
> > <mailto:tshead at k-3d.com>> wrote:
> >
> >     On 05/16/2010 12:11 PM, Marcus D. Hanwell wrote:
> >     > On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead
> >     <tshead at k-3d.com <mailto:tshead at k-3d.com>
> >     > <mailto:tshead at k-3d.com <mailto:tshead at k-3d.com>>> wrote:
> >     >
> >     >     I'd like to do the following:
> >     >
> >     >      # Build external project A
> >     >      ExternalProject_Add(A ...)
> >     >
> >     >      # Import target B, which is exported by A in AConfig.cmake
> >     >      ExternalProject_Get_Property(A, BINARY_DIR)
> >     >      set(A_DIR ${BINARY_DIR})
> >     >      find_package(A)
> >     >
> >     >      # Link with B
> >     >      add_library(C ...)
> >     >      target_link_libraries(C B)
> >     >
> >     >     Of course, this doesn't work because the external project
> >     hasn't been
> >     >     built yet at configure-time, so AConfig.cmake doesn't exist.
> >      Which
> >     >     leads me to the following:
> >     >
> >     > Hi,
> >     >
> >     > If I understand your question correctly, then adding DEPENDS A to
> your
> >     > ExternalProject_Add(B...) call will ensure that A has been built
> >     when B
> >     > is configured, thus satisfying your need to find A's exported
> targets.
> >     > Using the dependencies between external projects it is possible to
> >     > control the build order, so that A's config file will be present
> >     before
> >     > B attempts a configure step.
> >
> >     That wasn't quite what I was describing - "B" isn't another external
> >     project, it's a library that's built by external project "A".
>  Because A
> >     hasn't been built (isn't even downloaded yet) at configure time, I
> can't
> >     use find_package to benefit from A's internal understanding of where
> >     its' outputs are located.  Basically, I want the simplest possible
> >     add_library(... IMPORTED) call possible, one that doesn't end-up
> >     duplicating all of the platform-specific logic that CMake normally
> takes
> >     care of.  Since my last post, I've switched to the following, which
> >     works on Linux and seems like it could work on Windows:
> >
> >      ADD_LIBRARY(B SHARED IMPORTED)
> >      SET_TARGET_PROPERTIES(B PROPERTIES
> >        IMPORTED_LOCATION
> >     "${BINARY_DIR}/path/to/libB${CMAKE_SHARED_LIBRARY_SUFFIX}"
> >       IMPORTED_IMPLIB "${BINARY_DIR}/path/to/libB.lib"
> >      )
> >
> >
> > Ah, I understand now. This is one of the major reasons to avoid mixing
> > external projects and traditional targets in the same build. I would
> > solve that by adding another external project in the build, that would
> > depend on A, and so A would be there at configure time and no guessing
> > would be necessary.
> >
> > Is there any particular reason why you cannot use that pattern in your
> > case? Otherwise you can quickly end up writing a lot of code to predict
> > where things will be, and that could be quite a fragile approach if the
> > targets changed in a new release.
>
> It's not impossible, but I had hoped to avoid the extra level of
> indirection.  I'm really just feeling-out the pros-and-cons of various
> approaches.
>
> OK, may be others on the list may have other experiences they will share.
After having spent quite a bit of time working on packaging for a Linux
distro, and using CMake's external projects I see many parallels.

The external project allows us to establish inter-package dependencies, and
from there build order. Traditional targets assume that project is building
everything, or that it was already built and found. So two levels are
necessary, and external projects allow us to do cross platform packaging for
our particular projects.

I would certainly be interested in what others who have been using external
project have found, but it seems to me that mixing external projects and
traditional targets is unlikely to work well, at least with what is
available to us right now.

Thanks,

Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100516/66d7d79a/attachment-0001.htm>