Re: [boost] trunk vs release

Subject: Re: [boost] trunk vs release
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-05-21 16:41:53

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.

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?

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

Anyway none of this is coalescing into a grand vision, but the 
discussion has been productive so far:  thanks everybody.  Maybe about 
time to write some of this up.

-t