On 05/16/2010 12:36 PM, Marcus D. Hanwell wrote: > On Sun, May 16, 2010 at 2:26 PM, Timothy M. Shead <[email protected] > <mailto:[email protected]>> wrote: > > On 05/16/2010 12:11 PM, Marcus D. Hanwell wrote: > > On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> 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
<<attachment: tshead.vcf>>
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
