Boost logo

Boost :

Subject: Re: [boost] trunk vs release
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-05-22 05:14:25

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-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
> already does or could do something similiar.


        bjam libs/{spirit,serialization/test

on Linux. Windows users would have to spell down each directory explicitly.

- Volodya

Boost list run by bdawes at, gregod at, cpdaniel at, john at