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