Re: [boost] Switch to CMake -- Analysis

Subject: Re: [boost] Switch to CMake -- Analysis
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-21 21:48:16

On 21.07.2017 17:35, Andrey Semashev via Boost wrote:
> 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.
But in this thread I'm not proposing each library to use "its own build
system". I'm proposing to allow each library to choose whether to move
to CMake or to stay with Boost.Build, as an attempt to unlock the
current gridlock.

>> 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.

That's the problem. Some people are frustrated if they have to move,
other are frustrated if they have to stay. Thus an "either or" scenario
can't be the answer.

>
>> 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.

But if some projects complete the transition, there isn't anything
"unfinished", at least not if the infrastructure is set up to support
this. It's what's called incremental progress. To paraphrase: it's
better to have x% of the libraries converted 100% than 100% of the
libraries converted x%.

>>> 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.

Huh, now it's me who isn't sure what you mean :-) Can you please
rephrase this last set of sentences ? I'm not sure what you are trying
to say here. :-)

>
> 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.

Again, not sure what your point is in listing these options. To me it
seems clear that the SC is asking us to pick between 0. and 1., while I
propose 3.

>>> 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.

So ?

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...