Re: [boost] A set of individual libraries vs. One big library

Subject: Re: [boost] A set of individual libraries vs. One big library
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-01-19 15:16:32

Emil Dotchevski wrote:
> On Mon, Jan 19, 2009 at 8:03 AM, Anis Benyelloul
> <anis.benyelloul_at_[hidden]> wrote:

>> From this point of view, the solution is a tool that can
>> automatically
> extract the minimum subset of Boost that you need. The reason why this
> is not practical is that you can't mix and match units from different
> Boost versions.

Actually I don't see any need for any special tool of this sort.  Suppose
I have a simple application.

#include "boost/archive/xml_archive.hpp"
...

Which drags in only the headers it actually uses..  If one doesn't have one 
of
those headers installed, then the user either has to get it, make his own
or use a different library.

Likewise, precompiled libraries are are included only to the extent they are 
used.

Finally, modules within libraries are included only to the extent they are 
used.

And this currently works pretty well.  If you set your directory to the
library you're interested in, move the the corresponing test directory
invoke bjam with the appropriate switches (a whole other topic!)
You will:

a) build all the required libraries - if any - and no other libraries
b) build and run all the tests in the library you're interested in.

There are only a couple of things lacking here.
a) The only thing is that the libraries will be built in an inconvenient
place so you'll have to move them to some central place
"by hand"
b) The "test" isn't recursive.  That is if I invoke the test/build
for some library A which uses library B, the libraries for A
and B are built, but tests are only run for library A.

> Therefore, the only way Boost can be distributed is as
> a single giant release.

This point is true only because boost libraries are:

a) too tightly coupled.
b) some library authors are to cavalier about changing the library
interface.

Even this could be addressed by establishing some convention such
as
#define BOOST_SERIALIZATION_LIBRARY_VERSION 137
in each header of the library.

Then each library which requires it could specify

#include <boost/archive/xml_archive.hpp>

// specifiy requirements for other libraries.
BOOST_REQUIRES(BOOST_EXCEPTION, 130, 136)

Probably each library would have to have to have a "manifest"
with all the above macros.

Of course, to actually get there from here would probably not be worth
the effort.  But this is not due to any fundamental obstacle, but rather
due to common boost development practices which I don't expect
to change in my lifetime.

Robert Ramey