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:
So this you would use with any project, boost or not. Autotools could
probably be made to do something similar.
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
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk