Re: [Boost-users] What's happened to Ryppl?

Subject: Re: [Boost-users] What's happened to Ryppl?
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-01-28 13:00:51

At Fri, 28 Jan 2011 08:45:48 -0800,
Robert Ramey wrote:
> 
> Dave Abrahams wrote:
> > On Thu, Jan 27, 2011 at 1:26 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> >> Beman Dawes wrote:
> >
> >>> Independent of modularization, ryppl, or anything else, is it time
> >>> to start a discussion on the main list about moving to Git?
> >>
> >> To me, this illustrates a fundamental problem. If the issue of
> >> modularization were addressed, there would be no requirement
> >> that all libraries use the same version control system. That is,
> >> change to a different version control system would occur
> >> one library at time.
> >>
> >> Same can be said for the build system.
> >
> > In principle, true.  In practice, we need some consistency across
> > boost or it will become hard for the community to contribute, and
> > especially hard for people (including release managers) to step in and
> > fix things, or even assemble a distribution.  This is to say nothing
> > of automated testing.
> >
> >> The only coupling really required between libraries is
> >>
> >> a) namespace coordination
> >> b) directory structure - to some extent at least at the top levels
> >> c) quality standards
> >>d) testing
> >
> > introduces a build system dependency.
> 
> A particular library will depend upon at least one build/test
> system.  But that doesn't imply that all libraries have to depend
> on the same one.  

Again, true in principle, but IMO not workable in practice, for the same
reasons I just cited.

> In fact, we already have the situation that
> many (all?) libraries can be built/tested with bjam or Ctest.
> 
> The "boost test" would be just the union of the test procedure
> implemented for each library.  That is
> 
> foreach(library L)
>     lib/L/test/test.bat // or /lib/L/test.sh
> 
> The current approach implements the view of Boost as a
> particular set of libraries ONLY built/tested/distributed as an
> whole.
> 
> My view is that is not scaling well and can never do so.

+1

Still, that doesn't mean we're going to be more nimble and scalable if
there's no standardization of tools across Boost.  Quite the contrary,
IMO.  I can imagine all kinds of problems coming up that are simply
ruled out by using the same tools.

> Each library should be "buildable, testable, and distributable"
> on it's own.  

Except that there are interdependencies among some of the libraries.
How many build tools should you need in order to install
Boost.Serialization?

> I see the centralized functions being limited to:
> a) reviews/certification
> b) accumulation of testing results
> c) coordination/maintainence of standards (a-d above)
> d) promotion of developer practices compatible with
> the above (licenses, etc).
> 
> Suppose such an environment existed today.  The whole
> issue of moving to git wouldn't be an issue.  Each library
> author could use which ever system he preferred.  Movement
> to git could proceed on a library by library basis if/when
> other developers were convinced it was an improvement.
> It would be one less thing to spend time on.

Or, it could be one more thing to spend time on.  

Standardization != coordination, and while coordination can slow
things down, standardization brings efficiencies.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com