Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-06-17 00:33:06

Hi David,

On 16.06.2017 19:44, David Sankel via Boost wrote:
> Howdy all,
>
> This is a request for comments on a possible path for migrating Boost's
> build
> system to CMake. I am not speaking for the Boost Program Committee here,
> but I
> plan on bringing this up with them after getting feedback.

While I agree that there is a need to improve the current
infrastructure, I disagree on your proposal, not because I have any
well-formed opinion on CMake (I haven't), but because I think the
problem is more fundamental, and can't be solved by another switch of
tools. The problem isn't a technical one, it's systemic / organisational.

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

    Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...