[CMake] External projects and imported targets

[Marcus D. Hanwell]

On Sun, May 16, 2010 at 2:26 PM, Timothy M. Shead <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>> 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.

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