[CMake] External projects and imported targets

[Timothy M. Shead]

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.

Cheers,
Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tshead.vcf
Type: text/x-vcard
Size: 151 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100516/e36c9202/attachment.vcf>