From: Jeff Garland (azswdude_at_[hidden])
Date: 2008-04-04 11:15:52
On Fri, Apr 4, 2008 at 8:03 AM, Stefan Seefeld <seefeld_at_[hidden]> wrote:
> Stefano Delli Ponti wrote:
> Yes, understood. However, there is much more effort going into a project
> than development. What about maintenance (adapting to new compilers,
> say), compiling all the new code and running all the new regression
> tests that such a project would surely add ? This impacts the whole
> boost project. (Again, with a modular boost where components would be
> built / tested / released all this would be mood.)
I don't see why this project is any different than any other boost library
project. It adds one more library to an aleady large collection. I suspect
the only way to solve this problem would be to move toward a 'pull as you
need it' solution (more like cpan) where there's a core boost install and
then an easy way to get the other libriaries one at a time or in batches.
But we still have to test them, etc. And it's still important for us to
have major releases because there's some folks that simply won't look at
libraries that aren't part of a major release.
> Also, as boost right now is released as a single entity, another concern
> is the perception from users. Boost already is huge.
> The boost developers not actively supporting modularization or even
> simple (platform-neutral) packaging really doesn't help.
I'm not sure how we "aren't supporting" modularization. Boost actually is
quite modular -- you can use bcp to snip out subparts for your needs -- or
do it by hand. I've certainly done it -- "rm -rf" is a handy tool for the
parts I don't need.
> Again, would boost not be a single entity, all these arguments would be
I'm all for alternative releases, modularization, etc but I think we still
need a simple way to get the whole enchilada at once.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk