Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-06-17 01:26:30

On 6/16/17 5:33 PM, Stefan Seefeld via Boost wrote:
> Hi David,
> 
> On 16.06.2017 19:44, David Sankel via Boost wrote:
  The problem isn't a technical one, it's systemic / organisational.

Agreed.
> 
> Boost has grown a lot, and neither its organization nor its
> infrastructure (of which the build system is just one part) doesn't
> scale well. So instead of substituting a tool, I would like to invite
> you to consider a few organizational changes.

> Notably, I would like to see the long-stalled modularization process to
> be picked up again and be continued (and completed ?). Instead of
> managing all of Boost in terms of a single github super-repository, a
> single build system, a single issue tracker, a single website (etc.,
> etc.), I'd like to see all of this to be broken out into separate
> projects, where most of the tool choices could be handled locally, i.e.
> per project
> The role of Boost as the organization would be that of a umbrella
> organization that defines certain guidelines, provides services
> (financial, legal, etc.), but otherwise tries hard to stay out of the
> way to accelerate rather than hinder development.

> 
> Looking at the current set of libraries, I can see a number that already
> are relatively independent, so the remaining change to complete the
> "modularization" is minor. (Take as an example Boost.Python, which few
> other Boost libraries depend on, and if so, only optionally so.)
> The rest could be incrementally separated, eventually leaving a single
> "Boost core" project, which everything else depends on.

> 
> Once there, you could rephrase your proposal for each individual library
> project to consider to switch. There wouldn't be a huge discussion
> flooding everyone's inbox, and consuming lots of time and energy from
> way too many people. Smaller groups of people would much quicker come to
> a conclusion, and the implementation of the change would be swift.
> 
> At least that's one dream I keep having...

This is the vision that I had when I made my proposal at C++Now titled 
Boost 2.0.

It's also the vision that I had/have in mind when I create the Boost 
Library Incubator.

I believe the two lines about fleshout the vision you've articulated so 
you've got two votes - (not that it's up for a vote).

My presentation boost 2.0 was probably my least successful ever.  I lost 
control of it as it veered into and argument about automatically 
generating dependencies. I was sott of struck by lightning.  But still 
it articulated some ideas which have come to fruition such as the Boost 
Library Official Maintainer program and Boost Library Incubator. They 
haven't been the total success I would have hoped, but it does seem that 
we have less complaints about lack of library maintenance and we are 
reviewing more libraries which seem better prepared for review.  Of 
course maybe it's confirmation bias.

The last time this was discussed on the list, things circled down the 
drain of automatic dependencies.  Let's not do this again. Let's just 
accept that somehow dependencies will be figured out, even if it has to 
be done by hand.

The more interesting thing is the decoupling.  Let each library decide 
which build, test, documentation, deployment, bug tracking system to 
use.  The Boost Politburo would set requirements rather than design a 
specific system. Examples would be:

a) every libary has to have documentation.  Documentation has to be 
standards conforming.  That is it would have to describe libraries in 
terms of valid expressions rather than implementation

b) every library has to have a test suite

c) every library has to have a single button download, build and test 
functionality.

d) every library has to use a public version control system for it's 
source code

e) every library has to use the Boost License

f) every library has to fulfill a minimum set of directory structure 
requirements.

f) Review managers cannot accept library into boost if it fails any of 
the above.

Of course the Boost web page would have a portion which looks like the 
Boost library Incubator.  So be it.  Actually I've even considered just 
adding a page for each current boost library. The library dropdown would 
then specify accepted boost libraries, proposed boost libraries, etc.

Building of all of boost would of just the sequence of "one button" 
download build and test for each library.

I was going to put this in a separate post by you started down this path.

Robert Ramey