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