Re: [boost] trunk vs release

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

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.

-t