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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
