Re: [boost] Switch to CMake -- Analysis

Subject: Re: [boost] Switch to CMake -- Analysis
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-07-21 21:55:55

On 07/22/17 00:10, Florent Castelli via Boost wrote:
> On 21/07/2017 22:55, Stefan Seefeld via Boost wrote:
>> On 21.07.2017 16:35, Florent Castelli via Boost wrote:
>>> On 21/07/2017 22:15, Andrey Semashev via Boost wrote:
>>>> I don't think it is realistic to convert the whole Boost in a single
>>>> release time frame, unless you want to put the transition as a
>>>> release criteria (which would be a bad idea). It would make sense to
>>>> either release half-baked support for CMake for a few Boost releases
>>>> or to follow the switch-the-whole-Boost approach: work on libraries
>>>> in the background and then merge it to develop/master for all
>>>> libraries. In the former case there's that potentially endless period
>>>> of having two build systems.
>>> You could possibly ask developers from other major project who
>>> transitioned to CMake what was their experience. LLVM moved
>>> exclusively to CMake not too long ago and it would certainly be
>>> interesting for people doubting it is possible to talk to their build
>>> engineers and developers.
>>> Note that some people (certainly not everyone) are quite happy with
>>> the transition, I saw again some message the other day from people
>>> loving the new changes in the latest CMake and it made LLVM compile
>>> much faster.
>> All this is beside the point, as we are not arguing about the respective
>> advantages or disadvantages in Boost.Build or CMake. The point is about
>> who has the burden to a) implement the change and b) to maintain the
>> infrastructure, and how that affects (or should affect) the decision
>> making process.
> 
> No this is directly commenting on this point. LLVM did a gradual 
> transition, they survived and are moving forward.
> If someone questions the possibility of doing the same, then they can 
> just ask them how they did it.
> Remember they probably have way more developers working on it than Boost 
> itself and a successful migration.

I don't question that the transition can be done in principle. I don't 
think it can be done in the time span of one Boost release, which is 
about 4 months.