On Fri, Apr 4, 2008 at 8:03 AM, Stefan Seefeld <seefeld@sympatico.ca> 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 void.
I'm all for alternative releases, modularization, etc but I think we still need a simple way to get the whole enchilada at once. Jeff