[CMake] Build only what you need in third party libs

[Michael Wild]

On 22. Dec, 2009, at 15:50 , David Cole wrote:

> On Tue, Dec 22, 2009 at 9:37 AM, Troy D. Straszheim <troy at resophonic.com>wrote:
> 
>> David Cole <david.cole at kitware.com> writes:
>> 
>>> On Tue, Dec 22, 2009 at 7:58 AM, David Wolfe <dwolfe at fifthsally.com>
>> wrote:
>>> 
>>>    On 12/22/2009 7:11 AM, David Wolfe wrote:
>>> 
>>>                                                   Most of our external
>>>        dependencies aren't even built using CMake, so 'CMake-ifying'
>>>        everything
>>>        under one big über-build hardly seems worth it...
>>> 
>>> 
>>>    On 12/22/2009 6:50 AM, David Cole wrote:
>>> 
>>>        One way to overcome these things, but still build projects from
>> source
>>>        code as needed is to use a new feature in CMake 2.8: the
>>>        ExternalProject
>>>        module...
>>> 
>>> 
>>>    Wow. That could be *really* useful---especially the fact that it
>> allows
>>>    you to download sources from the web, CVS, svn, etc.  It might be
>> enough
>>>    to change my mind about maintaining a separate externals archive. :-)
>>> 
>>> 
>>> 
>>> If it's not enough to change your mind...... let me know what you think
>> it's
>>> missing.
>>> 
>> 
>> Here's a use-case: boost-cmake exports buildspace targets to
>> $CMAKE_BINARY_DIR/lib/Exports.cmake.  So you'd want to download,
>> extract, run cmake on the unpacked archive, and only then include() the
>> exported targets...  Does ExternalProject work this way?
>> 
> 
> It does work that way if you set it up that way.
> 
> So you would have one ExternalProject_Add call to build and install
> boost-cmake... and then a subsequent ExternalProject_Add call to build
> something that depends on it. In this dependent project you would use
> "DEPENDS boost-cmake-proj" to express this dependency. And pass whatever -D
> or prefix information you need to the configure step of this dependent
> project so that it knows where the boost-cmake build is.
> 
> An external project must configure, build and install all the way before any
> of the projects that depend on it even run their first build step.
> 
> It's pretty flexible and customizable. If there's a build step that does not
> do what you want it to by default, you can replace it with your own custom
> step. And you can inject custom steps into the stream of steps that occur by
> default, too.
> 
> HTH,
> David
> 

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.

Michael