See below On Mon, Dec 7, 2009 at 1:26 PM, troy d. straszheim <t...@resophonic.com>wrote:
> Michael Jackson wrote: > >> >> >> On Dec 7, 2009, at 1:28 PM, troy d. straszheim wrote: >> >> Michael Jackson wrote: >>> >>>> So you are wanting to include the Boost sources in your project and you >>>> just want to build a specific subset of Boost to use with your project? >>>> >>> >>> Here's what I came up with: >>> >>> >>> http://sodium.resophonic.com/boost-cmake/current-docs/exported_targets.html#with-boost-source-in-a-subdirectory-of-your-source >>> >>> the EXCLUDE_FROM_ALL option to add_subdirectory makes things remarkably >>> easy... nice feature. >>> >>> -t >>> >> Yes this appears to be the closest thing to what I would like to do. > >> >> Nice, >> Couple of comments though: >> "Setting BUILD_PROJECTS, etc is unnecessary, but if all the extra boost >> targets bother you you can set it at the commandline as usual:" >> >> Why can't I set BUILD_PROJECTS in my own CMakeLists.txt file? Wouldn't >> this get rid of the need to pass this on the command line? Also what about >> those running CMake-GUI? They don't have a command line to work from? >> > > Yup, you can, it needs to be CACHE STRING FORCE. > > I am already taking advantage of CACHE STRING FORCE for multiple parameters to provide "checkout and build" automation with out having to specify these variables each time. I only wish I could do this for the text box "Where to build the Binaries" i.e. the ability to fill this in with a default as I build out of source, but within the checkout directory structure ( rootofcheckout/source and rootofcheckout/build). This way it would be a 3 step to development for developers 1) checkout tree and 2) point cmake to CMakeLists.txt and 3) press go. > > By using the name of the target (boost_filesystem-mt-shared in your >> example), will CMake automatically "do the right thing" with respect to >> Debug and release libraries? Will building my project as a Debug pick up the >> Debug Boost libraries? >> > > No, boost-cmake doesn't play nice with this kind of thing. In the > beginning we were attempting to do things the way bjam does them, compiling > all variants with one command. In retrospect I think this was a really bad > idea. Now things clash, and it would be major surgery to fix... major > surgery that I may yet do, but realize that it would break a growing amount > of code that depends on the way boost-cmake now does things. :( > > You could check CMAKE_BUILD_TYPE and tweak the name that you're linking > against: > > if (CMAKE_BUILD_TYPE STREQUAL Debug) > set(DBG_OR_RELEASE "-debug") > endif() > > target_link_libraries(mything boost_filesystem-mt-shared${DBG_OR_RELEASE}) > > The do the right thing feature of bjam was quite nice. This is what I was looking for in CMake as well. It sounds from this discussion that it is a boost usage of CMake issue not a CMake issue correct or no? Not sure this is a "solution". > I see this as having some issues? I now have to detect when someone wants >> a "Debug" build then set the "BOOST_ENABLE_DEBUG=ON" before calling the >> add_subdirectory(boost-src). >> > > If you just let boost.cmake configure all the targets, use EXCLUDE_FROM_ALL > and tweak the name you link to above, only what you need gets built, and > your CMAKE_BUILD_TYPE works as you expect it to. The same name-tweaking > above will work if you use exported targets instead of > boost-src-in-subdirectory. > > ouch... ok will keep this in mind. > I say all this without having tried any of this but it _is_ intriguing me >> currently due to all the problems trying to get Boost built OS X and Windows >> without memory leaks, compile errors and, ya know, basic stuff like that. If >> I can have my own patched version of boost in my project this may save some >> serious head aches in the future. >> > > > And on the boost-cmake list we should talk about what those patches would > be. You're not the only one doing this, and we have the capacity to do > point releases of boost asynchronously from upstream. > > -t > > > > > > _______________________________________________ > 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 > -- Brian J. Davis
_______________________________________________ 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
