<div class="gmail_quote">On Sun, May 16, 2010 at 2:26 PM, Timothy M. Shead <span dir="ltr"><<a href="mailto:tshead@k-3d.com">tshead@k-3d.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 05/16/2010 12:11 PM, Marcus D. Hanwell wrote:<br>
> On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead <<a href="mailto:tshead@k-3d.com">tshead@k-3d.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:tshead@k-3d.com">tshead@k-3d.com</a>>> wrote:<br>
><br>
> I'd like to do the following:<br>
><br>
> # Build external project A<br>
> ExternalProject_Add(A ...)<br>
><br>
> # Import target B, which is exported by A in AConfig.cmake<br>
> ExternalProject_Get_Property(A, BINARY_DIR)<br>
> set(A_DIR ${BINARY_DIR})<br>
> find_package(A)<br>
><br>
> # Link with B<br>
> add_library(C ...)<br>
> target_link_libraries(C B)<br>
><br>
> Of course, this doesn't work because the external project hasn't been<br>
> built yet at configure-time, so AConfig.cmake doesn't exist. Which<br>
> leads me to the following:<br>
><br>
> Hi,<br>
><br>
> If I understand your question correctly, then adding DEPENDS A to your<br>
> ExternalProject_Add(B...) call will ensure that A has been built when B<br>
> is configured, thus satisfying your need to find A's exported targets.<br>
> Using the dependencies between external projects it is possible to<br>
> control the build order, so that A's config file will be present before<br>
> B attempts a configure step.<br>
<br>
</div>That wasn't quite what I was describing - "B" isn't another external<br>
project, it's a library that's built by external project "A". Because A<br>
hasn't been built (isn't even downloaded yet) at configure time, I can't<br>
use find_package to benefit from A's internal understanding of where<br>
its' outputs are located. Basically, I want the simplest possible<br>
add_library(... IMPORTED) call possible, one that doesn't end-up<br>
duplicating all of the platform-specific logic that CMake normally takes<br>
care of. Since my last post, I've switched to the following, which<br>
works on Linux and seems like it could work on Windows:<br>
<br>
ADD_LIBRARY(B SHARED IMPORTED)<br>
SET_TARGET_PROPERTIES(B PROPERTIES<br>
IMPORTED_LOCATION<br>
"${BINARY_DIR}/path/to/libB${CMAKE_SHARED_LIBRARY_SUFFIX}"<br>
IMPORTED_IMPLIB "${BINARY_DIR}/path/to/libB.lib"<br>
)<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Marcus</div></div>