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

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 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