Re: [boost] trunk vs release

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