Boost logo

Boost :

Subject: Re: [boost] trunk vs release
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-05-22 09:20:53

Vladimir Prus wrote:
> 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.

Hm. Let's discuss.

$our_projects = the libraries we're developing at the moment, say,
serialization and mpi.

$checkout = our development tree. Contains full boost.

$install = an install of boost, say in /usr/local/boost/(lib|include)

There is a buildsystem switch to enable the build in $checkout of only

Headerfile paths: $our_projects would see e.g. the $install
boost/version.hpp, and the $checkout serialization/export.hpp.

For the --use-installed-except=... case, you could implement this
without symlinks by simply deleting the non $our_projects headers from
the $checkout when --use-installed-except is turned on, and putting
$checkout/include first, $install/include second, in the include path.
   I think this may have certain advantages in practice... It is a
little harder to get confused about which header files are the ones
actually being used.

For the --use-installed=... case, you'd need symlinks, you need to
construct a 'forwarding' include/boost/<links>. But maybe you do anyway.

(I'm not proposing any of this. Just thinking out loud.)

>> 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.

I meant putting the process checkout *outside* the build tree. Now I
think this is a fake use case.... nevermind.


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