Boost logo

Boost :

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: John Maddock (jz.maddock_at_[hidden])
Date: 2017-07-19 17:00:15

> There are two ways to do it. The first one is a gradual transition. We
> currently have two pieces of critical infrastructure reliant on
> Boost.Build - the test system and the build/install procedure. (Three
> actually if we include the doc build.)
> How would a gradual transition work? For the testing part, obviously,
> we keep the Boost.Build testing operational and start building a
> parallel test infrastructure based on CMake/CTest. Libraries that want
> to be tested via b2 supply test/Jamfile, libraries that want to be
> tested via CTest supply... test/CMakeLists.txt, for instance.
> Libraries that supply neither aren't tested by either.
> For the building part, we start supplying a secondary way to build and
> install Boost, alongside the existing one.
> The second possibility is a sudden jump. We move, for both testing and
> building, to CMake at once.

I don't believe that can work: the CMake branch would never keep up with
a constantly changing/evolving develop.

Frankly unless there are a huge amount of resources (probably at least
one full time developer keeping the CMake branch on track with develop),
I see this as a non-starter. Remember this was in effect tried before,
as I recall it failed because it just couldn't keep up despite
Boost.Consulting's resources behind it.

What might work, is a "lot of little bangs", moving one whole library at
a time to CMake. My concern is that folks leave the difficult stuff to
last, get bored, move on, and we're left stuck with a semi-working
mess. Frankly, I simply do not know enough about CMake to know if this
move is a good thing thing or not, but I am completely certain that
there are a lot of folks greatly under-estimating the amount of work
involved here.

And now I'll go back to lurking again... John.

> How would this be best handled? By building the CMake infrastructure
> on a branch until it's ready for the switch.
> Organizationally speaking, what needed to be done? First, we choose
> which scenario we prefer. Second, the SC appoints a person in charge
> of realizing the plan. If gradual, he sets off to work with the
> results immediately appearing in Boost as libraries are picked up by
> the CMake test/build infrastructure one by one. If sudden, he sets off
> to work on his branch. When ready, the SC votes on the switch.
> So far I have left unspoken something that everyone should have picked
> up - the role of Rene in all this. It's patently obvious that a
> gradual transition would be much (much!) harder without him around, so
> we've pretty much ruled that possibility out now. This was, in my
> opinion, completely unnecessary.
> Or was it?
>> The CMake issue has been around for years and hasn't been able to
>> progress primarily because "obviously biased" vocal minorities were
>> holding it back with threats.
> To put it bluntly, did the glorious CMake transition HAVE to start
> with killing the workhorse and driving away the rider who got us where
> we are?
> And even if some of you believe that the answer to this question is
> "yes, it did have", can you not at least bring yourselves to not state
> that openly?
> Boost.Build and Rene have done a lot for the C++ community. Unless and
> until you can match this track record...
> _______________________________________________
> Unsubscribe & other changes:

This email has been checked for viruses by AVG.

Boost list run by bdawes at, gregod at, cpdaniel at, john at