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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk