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

Subject: Re: [boost] A set of individual libraries vs. One big library
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-01-19 17:30:13

On Mon, Jan 19, 2009 at 2:03 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> Emil Dotchevski wrote:
>> On Mon, Jan 19, 2009 at 11:13 AM, Stefan Seefeld
>> <seefeld_at_[hidden]> wrote:
>>> Emil Dotchevski wrote:
>>> This seems to me a rather academic question, in contrast to the
>>> original request. Boost is still shipped as a single package on most
>>> (if not all) platforms, and providing some help to packagers to be
>>> able to split it up would be extremely useful.
>>
>> How would it be extremely useful?
>
> Permit me to answer that.
>
> a) First of all - it is ALOT less time to build and test only the libraries
> that one actually uses rather than the whole set.

Less time than downloading the (entire) pre-built Boost distribution,
that's already been tested?

> b) In practice, its common to find a couple of anomolies in one or the other
> libraries and this
> takes a disproportionate amount of tiem to track down and get
> things built.

Your best bet to avoid anomalies is to not migrate to another version
of Boost. Your second-best bet is to not mix and match headers from
different Boost releases: you want to download and use a single Boost
distribution.

> c) As boost grows - this problem gets bigger - even for someone
> using only a couple of libraries.  That is, the current system doesn't
> scale.

I consider myself a prime example of someone using only a few Boost
libraries. Still, the easiest and most reliable strategy for me is to
download the entire Boost.

The only better alternative would be if someone tests and distributes
a Boost release that includes just the stuff I personally need and
nothing else. But you can't convince me that I'm better off doing this
packaging myself -- even if it's automated -- compared to just
downloading an entire Boost release.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode