Re: [boost] Switch to CMake -- Analysis

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

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:
>>> On 07/21/17 19:30, Stefan Seefeld via Boost wrote:
>>>> On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
>>>>>
>>>>> I'm sure it's been mentioned before by someone, but as a Boost user
>>>>> and packager (for my work projects) I don't want to deal with a dozen
>>>>> of build systems (worse yet - multiple versions of the same build
>>>>> system) to be able to build Boost. Having a single build system, a
>>>>> single interface and customization point is an important advantage
>>>>> regardless of what the actual build system is used.
>>>>
>>>> Don't you realize how impossible this has become, given the current
>>>> size
>>>> and scale of Boost ? You can't treat a project like Boost, with > 100
>>>> individual libraries in it, as a single entity. It's not going to
>>>> work.
>>>> And each attempt to impose a change will result in endless discussions
>>>> leading nowhere. We have to face this reality, and break Boost up into
>>>> parts that individually are amenable to such change. But not as a
>>>> single
>>>> orchestrated switch.
>>>>
>>>> Also, please note that I did not suggest that we open the door for any
>>>> other build systems (though that certainly could become an interesting
>>>> discussion later).
>>>
>>> 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. It's this claim that has taken
the actual community hostage, as it requires either a buy-in from
everyone (not going to happen), 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).

>
>> What I'm proposing can indeed be seen as one step
>> towards the multiplication of tools. But that would be quite a few steps
>> down the road, while what I'm saying here is that the step I propose
>> above seems to me to be essential to overcome the current stalemate. Now
>> assuming we progress somewhat using the above, with some libraries
>> having transitioned to using CMake, while others still using
>> Boost.Build, we have two choices: a) Test everything, and come to the
>> conclusion that it works well enough for users, so we can make another
>> release, or b) decide that we need to hold back the next release until
>> the remaining libraries have switched.
>
> 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".

>
>>> Regarding the transition process (to whatever build system, not
>>> necessarilly CMake), I think both ways have its merits. Making a
>>> whole-Boost switch is more resource expensive, but not impossible if
>>> there are enough interested people with enough permissions to do the
>>> job.
>>
>> I don't share your (apparent) mental model of software, or the practice
>> of software engineering. Software in general, and Boost libraries in
>> particular, live from the respective communities of people maintaining
>> and developing them. You can't just ask arbitrary "interested people"
>> that aren't already part of those communities to do "a job" on the
>> software.
>
> Sure. Those "interested people" would be members of the community.
> Alternatively, these could be paid individuals acting on behalf of the
> community, but I think this is unlikely to happen.

Indeed, because...

>
>> First, that's highly disrespectful of those who have been
>> working on and with the software being changed. And more importantly,
>> you aren't even addressing the real problem, of who would be responsible
>> for the maintenance of that new software ? Who would help users getting
>> stuck trying to build the library ? Who would fix issues ?
>
> Whatever plan you propose, nothing will happen unless all library
> developers are on board. This is an obvious implied pre-requisite.
> Doing it the other way will only leave you with a pile of dead code
> and no maintainers.

...of this. So the only possible way forward requires the individual
communities to agree. (And I do prefer to talk about communities in
plural - it's an illusion to think of a single "boost community". There
are many, heterogeneous ones, with quite different requirements.

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

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

        Stefan

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