From: Maciej Sobczak (maciej_at_[hidden])
Date: 2002-06-27 06:31:01
Paul A. Bristow wrote:
> As a user who put off using many Boost bits for too long,
> for the reasons you say, and despite the discussion Dave A referenced,
> perhaps I can just say that you do have to have the whole thing.
> It takes while to download, clutters your disk, but once there,
> the only thing a MS IDE project (for example) needs to do is
> to add the top level Boost directory to the list of include locations.
> It doesn't clutter or slow your build in any way because
> only the bits needed are #included. Pretty Painless really.
Yes, if you are using Boost for your own development. Then - indeed -
there is no pain, only joy.
But you've missed my point, maybe I did not express myself clearly enough.
I would like to use one of the Boost components in the Open Source
project (in fact, one of its optional components that is very, very
small) that is distrubuted as a source code, with necessary Makefiles.
Now - it is really a problem, because I do not want neither of:
1. Include Boost in my little component. No, because it would overweight
the whole package without any merit.
2. Ask user of the package to download Boost by themselves. No, because
I want my component to be self-contained with regard to some known
As I say - once Boost gets standardized, it is no problem; I will be
able to assume its existence on the target platform and just use it. But
at the moment, I'm stuck. One of the options I consider is to make small
modifications to Boost sources I want to use, so that they compile
without any dependencies. Then - I'm concerned with the copyright
issues. I believe that commenting the changes is enough if I leave the
(c) stuff. This is something I can do by myself. Maybe, with time, I
will be able to come up with a subset of Boost components without
unnecessary dependencies (and publish it as my little contribution to
Boost!), but I believe I'm not the only one on this playground, which
makes me think about something differrent:
Create a "clean" subset of Boost that assumes *reasonable conformance of
the target platform*. Or even conformance on the level of gcc 3.1 or
Comeau. This way, Boost would contribute to the pressure that the C++
community has to put on compiler vendors and at the same time would
create set of *light and independent* libraries. No config.hpp, etc.
Without this move, Boost is going in the direction of monolithic
frameworks rather than freely reusable, small pieces of good C++
components. The problem is that it has to be You, Boost developers, to
make this move.
Longish, I know...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk