Boost logo

Boost :

Subject: Re: [boost] Switch to CMake -- Analysis
From: Florent Castelli (florent.castelli_at_[hidden])
Date: 2017-07-21 21:10:26


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.

>
> Stefan
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk