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