<div class="gmail_quote">On Tue, Dec 22, 2009 at 10:35 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;">
<br>
On 22. Dec, 2009, at 16:22 , David Cole wrote:<br>
<snip><br>
<div class="im">>><br>
>> That's exactly my point: if the dependent project is the calling project<br>
>> (i.e. the one that calls ExternalProject_Add), you have to use error-prone<br>
>> ADD_LIBRARY(<name> <type> IMPORTED) calls with according invocations of<br>
>> SET_TARGET_PROPERTIES(<name> PROPERTIES IMPORTED_LOCATION <filepath>). In<br>
>> the case of Boost this is probably very difficult to get right, because from<br>
>> what I hear, the library names change almost randomly with operating system,<br>
>> compilation flags and what not. So what ExternalProject.cmake is missing, is<br>
>> a mechanism of "pulling" the targets of the external project into the<br>
>> calling project.<br>
>><br>
>><br>
> So first build boost and everything with a simple "build my prerequisites"<br>
> project that builds/installs all your prereqs in a nice, reasonable fashion.<br>
><br>
> Then your project can just find/include/import everything as your accustomed<br>
> to without any fuss.<br>
<br>
</div>That is a workable solution for "tech-savvy" users, I'm not so sure the average admin will appreciate it (remembering the heated and quite ridiculous discussions on KDE not providing a configure script anymore...)<br>
<div class="im"><br>
> There will never be an easy way to pull external projects directly into a<br>
> calling project because the external things are not even guaranteed to be on<br>
> disk yet at configure time of said calling project.<br>
<br>
<br>
</div>Yeah, kind of a chicken-egg problem...<br></blockquote><div><br></div><div>Exactly. That's why we didn't try to solve that problem. If you have a chicken-egg problem to solve, you have to choose starting with a chicken or an egg, thereby alienating approximately 50% of your audience, even if you have good reasons for your choice.</div>
<div><br></div><div>So: there is one approach that's sort of a hybrid here, that I'll mention because it might be useful to consider.</div><div><br></div><div>You could have a cmake option in your project that builds your project one of two ways: "as usual" or as the final link in a chain of ExternalProject_Add calls. I've done this and I know it works, but it's proprietary and I cannot point you to the source code. This technique, however, does make things hard to think about at times...</div>
<div><br></div><div>Something like this in CMakeLists.txt:</div><div>==================================================</div><div>option(MYPROJ_UBERBUILD "If ON, build all prereqs first, then build me..." ON)</div>
<div>if(uberbuild)</div><div> include(BuildAllViaExternalProject.cmake)</div><div>else()</div><div> include(BuildJustMe.cmake)</div><div>endif()</div><div><br></div><div>And as the last thing inside BuildAllViaExternalProject.cmake:<br>
</div><div>==================================================</div><div>ExternalProject_Add(</div><div> DOWNLOAD_COMMAND ""</div><div> CMAKE_ARGS</div><div> -DMYPROJ_UBERBUILD:BOOL=OFF</div><div> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}</div>
<div> ...</div><div>)</div><div><br></div><div><br></div><div>The net effect is that a project can build itself as an ExternalProject with the "clever (?)" use of a CMake option....</div><div><br></div><div><br>
</div><div>HTH,</div><div>David</div><div><br></div></div>