Subject: Re: [boost] A set of individual libraries vs. One big library
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-01-19 14:04:50
On Mon, Jan 19, 2009 at 11:38 AM, Emil Dotchevski
> On Mon, Jan 19, 2009 at 8:03 AM, Anis Benyelloul
> <anis.benyelloul_at_[hidden]> wrote:
>> I was wondering if there was any interest into making the boost libraries
>> more ``independent''?
>> Boost contains many libraries with very different application domains. In
>> most cases you'll want to use only one/two libraries in your project
> Let's say that somehow you manage to separate Boost into a bunch of
> libraries. Consider a situation where Boost library A uses only a
> single header file from another (large) Boost library B. Doesn't your
> original reasoning apply? Shouldn't that single header file be a
> separate library (since -- obviously -- it makes sense on its own)?
> You could go for a system where a C++ cpp/header pair is the only
> logical unit. Such a unit would contain the minimum declarations and
> definitions that can possibly exist on their own.
> But this is pretty much how the header-only libraries in Boost are
> organized. :) For example, if you need to use shared_ptr.hpp you just
> #include it; if you need weak_ptr.hpp, you don't care if it's part of
> the Boost smart pointer "library", you just #include it when needed.
> >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. Therefore, the only way Boost can be distributed is as
> a single giant release.
> Emil Dotchevski
> Reverge Studios, Inc.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
However, if you only need a part of boost for a project and you wish
to include it with your source distribution, use the boost tool "bcp".
It can be given some files to look at, or some names, and it copies
out from your boost directory into a custom directory everything that
is needed for those files, and nothing else. Then just put that
directory somewhere in your build tree and use it like a normal linked
in header directory in your build scripts/solutions. It has been very
useful for me recently.