Stefan Seefeld wrote:
I didn't mean to be talking about mixing versions. All I meant to suggest is that for building and testing a given boost module we may not want to assume the rest of boost is present as a source tree, but as a separately installed boost package. Also, boost is big enough that I may just not like having to "check out all of Boost", if all I'm interested in is a single boost module.
I'd put this under the 'build system issue' heading, and (of course) it is multifaceted. CMake provides (not boost-cmake) in its distributions a configure script that you use like this: find_package(Boost 1.38.0 system filesystem serialization) and there are ways to configure how it searches (env. variables etc), and special stuff you do to use particular libraries, etc, after it has done its thing: target_link_libraries(my_executable ${Boost_FILESYSTEM}) So this you would use with any project, boost or not. Autotools could probably be made to do something similar. But: you can't just do that, because the same jam/cmake files that live in boost.process' checkout shouldn't know whether they are part of a "big" or a small boost checkout. Maybe you just if/then it up. Which implies carrying around some buildsystem infrastructure. How much? Enough to handle the build of documentation, which implies that quickbook and spirit come along? I think we just bit our own collective tail. Then there is the 'middle' case: I have a 'big' boost tree sitting on disk, built, but not installed, and I want to hack on boost.process against that library. Are we having fun yet? *Testing* some subset is I think on yet another axis. The current cmake implementation has a way to do this (you set e.g. BOOST_TEST_LIBRARIES=spirit,serialization,variant at configure time) and then only those tests are run. The main reason this functionality exists is just because it speeds up makefile generation and build times; handy for developers. It could easily be used to let e.g. the spirit guys run their own test drones. I assume boost.build already does or could do something similiar. Anyway none of this is coalescing into a grand vision, but the discussion has been productive so far: thanks everybody. Maybe about time to write some of this up. -t