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

[Michael Wild]

On 22. Dec, 2009, at 16:52 , David Cole wrote:

> 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

Very cool idea, but probably not quite easy to maintain as you have to pass all the cache variables to your own external project... I'll certainly put this little jewel in my box of useful tricks ;-) But then I'd probably just always build the main project as an external project and orchestrate the whole thing from a "meta-project".


Michael