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

[David Cole]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20091222/202823e4/attachment.htm>