Boost logo

Boost :

From: John (EBo) David (ebo_at_[hidden])
Date: 2000-12-12 08:58:45


John Maddock wrote:
>
> >Agreed. I would extend this with a configuration option which allows for
> >easy subsetting of the library to only the desired libs.
>
> OK for an integrated build system that's OK, but it still doesn't address
> the problem IMO: many people will use all of boost at one point or another,
> but only some of boost at one time in a particular project. To my mind
> separate library builds satify this need the best - perhaps with a wrapper
> that allows the user to build everything if they really want it.

but a hastle to maintain and keep track of... I persoanlly would prefer
to grab the whole thing and throw away everything I do not need. But
that is just my preference. As a note, I have had problems even finding
specific version of an old library because of library version
interdependance. This was brought about in part because everything was
not bundled at time of shipment...

This is what motivated something I do not feel I explained well in a
prior post with the

bost-xxx-yyy/boost
bost-xxx-yyy/boost/lib1.hpp
bost-xxx-yyy/boost/lib1/lib1.cpp
bost-xxx-yyy/boost/lib1/lib1.html
...
bost-xxx-yyy/boost/lib2.hpp
bost-xxx-yyy/boost/lib2/more.hpp
bost-xxx-yyy/boost/lib2/lib2.cpp
bost-xxx-yyy/boost/lib2/lib2.html
...

In an example program I might use something like:

#include <boost/lib1.hpp>

#include <boost/lib2.hpp>
#include <boost/lib2/more.hpp>

If for a particular project I do not want to carry around lib1 then I
can strip all the stuff out of bost-xxx-yyy/boost/ subtree.

I get the feeling like I am seriously missing something in the argument
here. Is it really more than just a case of lumpers vs. splitters?

  EBo --


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk