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