<div class="gmail_quote">On Tue, Dec 22, 2009 at 10:12 AM, Michael Wild <span dir="ltr"><<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
On 22. Dec, 2009, at 15:50 , David Cole wrote:<br>
<br>
> On Tue, Dec 22, 2009 at 9:37 AM, Troy D. Straszheim <<a href="mailto:troy@resophonic.com">troy@resophonic.com</a>>wrote:<br>
><br>
>> David Cole <<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>> writes:<br>
>><br>
>>> On Tue, Dec 22, 2009 at 7:58 AM, David Wolfe <<a href="mailto:dwolfe@fifthsally.com">dwolfe@fifthsally.com</a>><br>
>> wrote:<br>
>>><br>
>>> On 12/22/2009 7:11 AM, David Wolfe wrote:<br>
>>><br>
>>> Most of our external<br>
>>> dependencies aren't even built using CMake, so 'CMake-ifying'<br>
>>> everything<br>
>>> under one big über-build hardly seems worth it...<br>
>>><br>
>>><br>
>>> On 12/22/2009 6:50 AM, David Cole wrote:<br>
>>><br>
>>> One way to overcome these things, but still build projects from<br>
>> source<br>
>>> code as needed is to use a new feature in CMake 2.8: the<br>
>>> ExternalProject<br>
>>> module...<br>
>>><br>
>>><br>
>>> Wow. That could be *really* useful---especially the fact that it<br>
>> allows<br>
>>> you to download sources from the web, CVS, svn, etc. It might be<br>
>> enough<br>
>>> to change my mind about maintaining a separate externals archive. :-)<br>
>>><br>
>>><br>
>>><br>
>>> If it's not enough to change your mind...... let me know what you think<br>
>> it's<br>
>>> missing.<br>
>>><br>
>><br>
>> Here's a use-case: boost-cmake exports buildspace targets to<br>
>> $CMAKE_BINARY_DIR/lib/Exports.cmake. So you'd want to download,<br>
>> extract, run cmake on the unpacked archive, and only then include() the<br>
>> exported targets... Does ExternalProject work this way?<br>
>><br>
><br>
> It does work that way if you set it up that way.<br>
><br>
> So you would have one ExternalProject_Add call to build and install<br>
> boost-cmake... and then a subsequent ExternalProject_Add call to build<br>
> something that depends on it. In this dependent project you would use<br>
> "DEPENDS boost-cmake-proj" to express this dependency. And pass whatever -D<br>
> or prefix information you need to the configure step of this dependent<br>
> project so that it knows where the boost-cmake build is.<br>
><br>
> An external project must configure, build and install all the way before any<br>
> of the projects that depend on it even run their first build step.<br>
><br>
> It's pretty flexible and customizable. If there's a build step that does not<br>
> do what you want it to by default, you can replace it with your own custom<br>
> step. And you can inject custom steps into the stream of steps that occur by<br>
> default, too.<br>
><br>
> HTH,<br>
> David<br>
><br>
<br>
</div></div>That's exactly my point: if the dependent project is the calling project (i.e. the one that calls ExternalProject_Add), you have to use error-prone ADD_LIBRARY(<name> <type> IMPORTED) calls with according invocations of SET_TARGET_PROPERTIES(<name> PROPERTIES IMPORTED_LOCATION <filepath>). In the case of Boost this is probably very difficult to get right, because from what I hear, the library names change almost randomly with operating system, compilation flags and what not. So what ExternalProject.cmake is missing, is a mechanism of "pulling" the targets of the external project into the calling project.<br>
<br></blockquote><div><br></div><div>So first build boost and everything with a simple "build my prerequisites" project that builds/installs all your prereqs in a nice, reasonable fashion.</div><div><br></div><div>
Then your project can just find/include/import everything as your accustomed to without any fuss.</div></div><br><div>There will never be an easy way to pull external projects directly into a calling project because the external things are not even guaranteed to be on disk yet at configure time of said calling project.</div>
<div><br></div><div><br></div>