Re: [boost] CMake Announcement from Boost Steering Committee

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: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

---
This email has been checked for viruses by AVG.
http://www.avg.com