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

[David Cole]

On Tue, Dec 22, 2009 at 10:12 AM, Michael Wild <themiwi at gmail.com> wrote:

>
> 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.
>
>
So first build boost and everything with a simple "build my prerequisites"
project that builds/installs all your prereqs in a nice, reasonable fashion.

Then your project can just find/include/import everything as your accustomed
to without any fuss.

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