On 22. Dec, 2009, at 15:50 , David Cole wrote: > On Tue, Dec 22, 2009 at 9:37 AM, Troy D. Straszheim > <t...@resophonic.com>wrote: > >> David Cole <david.c...@kitware.com> writes: >> >>> On Tue, Dec 22, 2009 at 7:58 AM, David Wolfe <dwo...@fifthsally.com> >> wrote: >>> >>> On 12/22/2009 7:11 AM, David Wolfe wrote: >>> >>> Most of our external >>> dependencies aren't even built using CMake, so 'CMake-ifying' >>> everything >>> under one big über-build hardly seems worth it... >>> >>> >>> On 12/22/2009 6:50 AM, David Cole wrote: >>> >>> One way to overcome these things, but still build projects from >> source >>> code as needed is to use a new feature in CMake 2.8: the >>> ExternalProject >>> module... >>> >>> >>> Wow. That could be *really* useful---especially the fact that it >> allows >>> you to download sources from the web, CVS, svn, etc. It might be >> enough >>> to change my mind about maintaining a separate externals archive. :-) >>> >>> >>> >>> If it's not enough to change your mind...... let me know what you think >> it's >>> missing. >>> >> >> Here's a use-case: boost-cmake exports buildspace targets to >> $CMAKE_BINARY_DIR/lib/Exports.cmake. So you'd want to download, >> extract, run cmake on the unpacked archive, and only then include() the >> exported targets... Does ExternalProject work this way? >> > > It does work that way if you set it up that way. > > So you would have one ExternalProject_Add call to build and install > boost-cmake... and then a subsequent ExternalProject_Add call to build > something that depends on it. In this dependent project you would use > "DEPENDS boost-cmake-proj" to express this dependency. And pass whatever -D > or prefix information you need to the configure step of this dependent > project so that it knows where the boost-cmake build is. > > An external project must configure, build and install all the way before any > of the projects that depend on it even run their first build step. > > It's pretty flexible and customizable. If there's a build step that does not > do what you want it to by default, you can replace it with your own custom > step. And you can inject custom steps into the stream of steps that occur by > default, too. > > HTH, > David >
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. 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
