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

David Cole david.cole at kitware.com
Tue Dec 22 10:52:54 EST 2009


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

>
> On 22. Dec, 2009, at 16:22 , David Cole wrote:
> <snip>
> >>
> >> 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.
>
> 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...)
>
> > 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.
>
>
> Yeah, kind of a chicken-egg problem...
>

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.

So: there is one approach that's sort of a hybrid here, that I'll mention
because it might be useful to consider.

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...

Something like this in CMakeLists.txt:
==================================================
option(MYPROJ_UBERBUILD "If ON, build all prereqs first, then build me..."
ON)
if(uberbuild)
  include(BuildAllViaExternalProject.cmake)
else()
  include(BuildJustMe.cmake)
endif()

And as the last thing inside BuildAllViaExternalProject.cmake:
==================================================
ExternalProject_Add(
  DOWNLOAD_COMMAND ""
  CMAKE_ARGS
    -DMYPROJ_UBERBUILD:BOOL=OFF
  SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}
  ...
)


The net effect is that a project can build itself as an ExternalProject with
the "clever (?)" use of a CMake option....


HTH,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20091222/fc82133d/attachment.htm>


More information about the CMake mailing list