Subject: Re: [boost] A set of individual libraries vs. One big library
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-01-19 17:10:28
On Mon, Jan 19, 2009 at 12:16 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> 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
>> 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
> those headers installed, then the user either has to get it, make his own
> or use a different library.
That's only enough to make the #include succeed. :) If you want
everything to work, your best bet is to include the headers from a
single Boost release.
>> 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
How tightly coupled Boost is is a separate topic, IMO. As long as you
have two libraries that include the same header file, you can't
reliably distribute the two libraries in separate packages (unless you
separate the shared header in its own package.)
As far as changing library interfaces, you _can_ break user code
without changing the interface of a library. For example, didn't
changes in shared_ptr implementation details break the serialization
library at some point?
What distributing a single giant release gives us is a single point of
reference for everything. You can distribute your own code and simply
state that it needs Boost version 1.37. What is the alternative?
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk