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:35:13

On 07/21/17 23:28, Stefan Seefeld via Boost wrote:
> On 21.07.2017 16:15, Andrey Semashev via Boost wrote:
>> On 07/21/17 21:58, Stefan Seefeld via Boost wrote:
>>> On 21.07.2017 13:10, Andrey Semashev via Boost wrote:
>>>>
>>>> I think you did advocate for the model where each library picks its
>>>> own tools, including the build system. Allowing two build systems
>>>> would be just the first step. I'm just saying that this won't work
>>>> well for Boost users, at least not for a significant part of them.
>>>
>>> That's just FUD.
>>
>> What exactly in my message is FUD?
> 
> The allusion to things not going to work for Boost users, unless the
> entirety of Boost has migrated to CMake.

This is not what I was saying. I was saying that the model of each 
library using its own build system won't work well for users.

> It's this claim that has taken
> the actual community hostage, as it requires either a buy-in from
> everyone (not going to happen),

If people don't agree to switch then the transition is not going to 
happen. Either that or those people will follow Rene's example.

> or some higher power to impose the
> change (which likewise isn't going to work out in the long term, even if
> it might initially look like progress).

Right.

>> 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.
> 
> Not sure what you have in mind with "half-baked support for CMake".

It means with CMake transition unfinished. Not all libraries converted, 
non-functional build/test/docs with CMake, etc.

>> The particular developers may not be willing or have the resource or
>> knowledge to do the actual transition, but it should be evident to
>> everyone that if and when the transition is complete (by those
>> interested champions willing to do the job), the maintenance burden is
>> left upon the particular library maintainers. This is similar to how
>> it happened with git and I see no other way.
> 
> Don't force anyone !

Not sure what you mean. Noone's forcing anyone. Well, except the SC 
after the announcement.

I'll paraphrase my point, in case if I failed to communicate. Basically, 
a Boost maintainer has the following options:

0. Actively help the transition and maintenance of CMake afterwards.

1. Accept the burden of maintaining CMake for his library. Depending on 
the migration plan and the final model, CMake may be the only build 
system to maintain or be an addition to Boost.Build.

2. Resign from maintenance.

3. Actively object migrating their particular library, leaving Boost 
multi-build-system.

4. Despite the SC the community decides not to switch to CMake and 
everything is kept as is.

Everyone are free to pick their poison.

>> There's nothing disrespectful in this approach. It would be
>> disrespectful if the SC or someone with universal commit permissions
>> imposed CMake on everyone. Which is why the latest announcement from
>> the SC is a big mistake, to put it mildly.
> 
> Oh, so we actually agree - or almost. :-)
> It seems the main difference is that you think the burden is the
> required work to switch, while to me it's the maintenance work after the
> switch.

Both are, and both require volunteers.