[CMake] Subdirectories and FIND_LIBRARY routines

Michael Wild themiwi at gmail.com
Mon Jul 26 15:45:27 EDT 2010


On 26. Jul, 2010, at 19:51 , Rolf Eike Beer wrote:

> Am Monday 26 July 2010 schrieb Michael Wild:
> 
>> The build_thirdparty macro
> calls itself other macros, e.g. build_zlib. That
>> one "guesses" the output
> location of the zlib libraries, creates an
>> IMPORTED library target and
> sets XXX_LIBRARIES accordingly.
>> 
>> The problem of finding the output
> location of external projects has been
>> discussed quite a few times, and
> there is only one really clean, although
>> complex and confusing solution:
> There is one "master" project which only
>> makes calls to
> ExternalProject_Add, even the main project is build as such
>> an external
> project.
> 
> Which sucks at other places: we some such "master" projects that
> pull in a ton of other projects. But sometimes we just want to build one of
> these subprojects and not a monster which 500+ projects (takes about an hour
> to build on a recent DualCore with MSVC2008). So we have a macro
> ADD_SUBDIRECTORY_ONCE that works like ADD_SUBDIRECTORY but checks the cache
> if that directory has already been included. Now every subproject can
> A_S_ONCE all of it's dependencies so you can start at many places in the
> tree and get a correct build. Next problem is when the place where A_S_ONCE
> was called first (and which pushed it's absolute path into the cache) get's
> removed from the tree as noone then is including that needed dependency
> anymore. Nightmare again. Luckyly that doesn't happen too often...
> 
> Eike
> 

You shouldn't store such information in the cache, that's definitely the wrong place. Use a global property instead, which only lives during the CMake run. This way, when you remove a sub-project, another one will step in to fill the gap.

HTH

Michael



More information about the CMake mailing list