Re: [boost] Switch to CMake -- Analysis

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

On 07/22/17 00:48, Stefan Seefeld via Boost wrote:
> 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.

Right. For users, that would be somewhat better than everyone using 
their own build system, but the problems that I described in my original 
reply in this thread remain.

Again, I think for many users half CMake-based half Boost.Build-based 
Boost distribution would be more difficult to use than just CMake-based 
or just Boost.Build-based distribution.

>>>> 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 was coming from the premise of Boost migrating to CMake as a whole, 
which is what I think is being suggested by the SC. In this scenario, 
each maintainer has the options I listed below.

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