Re: [boost] toward a more modular boost (was: [Review] xpressive)

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-09-22 09:24:40

On Wed, 21 Sep 2005 22:41:32 -0700, Eric Niebler wrote
> Joel de Guzman wrote:
> > The Boost
> > libraries is nothing compared to the list that Source Forge
> > provides, yet no one complains about being overwhelmed by SF's
> > immensity. It's actually an ingredient to its success!
> 
> But would you feel the same way if you had to download everything on 
> SourceForge in order to use any part of it? :-) As boost grows (and 
> grow it must), it is inevitable that it move to a more modular 
> distribution mechanism. If boost had something like a cygwin 
> installer which let you install individual libraries (and the libs 
> they depend on!) the OMG-boost-is-sooo-big-and-scary arguments will 
> simply go away, and we will have removed one more (perceived)
>  barrier to adoption.

I think better installers is certainly an important part of this puzzle.
Still, I suspect there will be folks that are intimidated anyway.  There's
lots of reasons for this attitude -- most of which I think we cannot solve...

> Also, I had the good fortune to have dinner with Scott Meyers this 
> evening, and he asked why C++ didn't have the equivalent of Perl's 
> CPAN -- that is, a huge repository of useful code to which anybody 
> can submit. No releases. No quality assurance. No reviews. Survival 
> of the fittest. Here's a wacky thought: can we turn boost-sandbox 
> into CBAN 
> (the Comprehensive Boost Archive Network), and cherry-pick the best 
> libraries from CBAN for inclusion in boost? If anybody could make 
> something like this fly, it's boost. We'd need to look closely at 
> the CPAN model to find out why it's successful.

This was actually one of the examples I used in our OOPSLA gathering last
year.  The CPAN model is very different than Boost in the ways you cite.  On
the other hand, CPAN submissions are all structured the same: documentation
structure, directory structure, install structure, license, etc.  This is, of
course, a prerequisite to smooth support of incremental installation and basic
library usability. Of course, Boost has similar standards that can be
leveraged for C++, so I think it's obvious to see how the current Boost
infrastructure enables such a concept.  

My experience with CPAN is that alot of its usefulnesss is in grazing for
ideas.  That is, often you can't find what you want but you can find something
close that gives you a jump on what you want to do.  

Anyway, I'm generally in favor of evolving Boost to enable a broader
contribution base -- done in a way that allows users the information to
evaluate the suitability of a library for a task.  

> (And for the record, I don't find boost overwhelming either.)

I don't either.  When I compare Boost to the available JAVA libraries the
state of C++ is still disappointing.  In my mind we have a lot of catching up
to get C++ library support to the point where 'language choice' is driven by a
'lack of libraries'.  Or put another way, people that have good reason to
implement in C++ shouldn't need to 'suffer' from the lack of libraries.

Jeff