On Tue, Dec 22, 2009 at 10:12 AM, Michael Wild <them...@gmail.com> wrote:
> > 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. > > 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. 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.
_______________________________________________ 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
