troy d. straszheim wrote:
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.
We probably can ignore doc builds for first step. But still, it appears there should be some way to mark a given library checkout as standalone, so that it does not depend on other parts of Boost checkout. But that's somewhat tricky -- in particular, that would mean that anything in top-levle Jamroot gets ignored, and any fixes or additions in tools/build/v2 will get ignored as well. And the same problem applies to CMake I believe -- since there's quite significant and growing set of local cmake definitions. So, maybe, it's better to do it otherwise: don't allow a standalone checkout of a single library, but allow, given a full checkout of Boost, to redirect some, or all libraries to some installed locations. E.g. --use-installed=python or --use-installed-except=serialization --install-root=/usr which will cause build of serialization to use installed libraries.
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?
What problem is here? You just add libs/process and there you go. At least in Boost.Build land, you don't need to hack anything outside.
*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.
Yes, bjam libs/{spirit,serialization/test on Linux. Windows users would have to spell down each directory explicitly. - Volodya