Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-02-15 14:59:11

At 06:55 PM 2/15/2001 +0100, Jens Maurer wrote:

>Jeff Garland wrote:
>> I'm thinking (and hearing) that the way to go would be to use zlib on
>> platform if it exists, and deliver it as a detail for those platforms
>where it
>> doesn't (essentially Peter's suggestion). This avoids any extra
>downloading and
>> means the maintenance means paying attention to zlib releases and
>upgrading the
>> boost detail as needed.
>I would like to point out that the full is already >2 MB
>compressed (500 KB of which are JPEGs of developers) and the Info-ZIP
>stuff adds another 200 KB compressed.
>Compare that to the full Linux 2.0.30 kernel, which is only 6 MB.
>> I doubt they would want to do this. zlib is a C library which is used
>> basis for compression libraries in C, JAVA, and LISP (at least). So
>> they would view a boost C++ adapter as another example of a layer on
>Yes, that's my impression as well.

Yes, those are all valid points.

So what's the solution? We really don't want to reinvent the wheel.

There must be some limited set of circumstances when it would be
permissible for a Boost library to depend on some other library. The
Python example is a good one; anyone using it will expect to have Python

Imagine this. Boost gets larger, and we break the download up into several
pieces. Say a base section, a graph section, an numerics section, and a
compression section. On the download page, these are presented in a table
with a link to click on to download the section you want.

For the base and graph sections there would be no other links.

For the compression section, there would be one additional link (with
explanation of why) that downloads the zlib distribution from their ftp

For the numerics section, there might be a couple of links, to a couple of
non-boost numerics libraries. Perhaps explanation of exactly what you
won't be able to link if you don't download them.

Presumably part of the formal review for any library that depends on a
non-Boost library would include pros and cons of the dependency. Thus
there is a protection against a detrimental dependency on a non-boost
library, but a mechanism to avoid reinventing the wheel if linking to
another library really is the smart thing to do.

I'm just thinking out loud, not advocating a position.


Boost list run by bdawes at, gregod at, cpdaniel at, john at