Re: [boost] Switch to CMake -- Analysis

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

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

>
>>> Besides, I have my doubts regarding the technical feasibility of this
>>> heterogenous infrastructure as well. I'm sure there will be quirks and
>>> points of incompatibiliy between the different build systems or some
>>> seemingly unreasonable limitations that follow from this integration
>>> that will leave someone, possibly users, unhappy.
>>
>> So you think we can't transition one library at a time, but you believe
>> it will be possible to do a switch for 100+ libraries synchronously ?
>> Sorry, but I can't follow your reasoning...
>
> I wasn't referring to the transition process but rather the resulting
> model adopted by Boost. If that model includes multiple build systems
> then it is bound to have problems stemming from the integration.
>
> 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. 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 ? The only
possible answer is "the community". So I think the only people who can
be reasonably expected to implement the change are actual members of
said communities. And if they aren't willing to go into the imposed
direction, there is very little you can do, if you don't want to risk a
project fork.

> A step by step switch adds a period (potentially, open-ended) when
> people have to maintain both build systems. As a Boost developer, I'm
> not happy about that. As a user, I might not be happy either, if one
> of the build systems doesn't actually work in a Boost release.

Well, if it doesn't work, don't switch ! A switch would obviously only
be useful if it improves upon the status quo.

>
> Regarding CMake as a candidate build system, I'm not convinced that
> the switch would benefit Boost in terms of "new blood" or something. I
> don't think the build system is something that is keeping millions of
> developers out there from contributing to Boost, as being advertised.
> It might be one, though probably not the major point, but I don't
> think anything will change e.g. wrt. maintenance if we switch right
> now. Most of the work doesn't even touch the build system or comes
> down to copying and pasting a piece of jamfile.
>
> I recognize that CMake has gained popularity and it is easier to find
> support for it online. But I know that more than once I've been
> puzzled about how to do one thing or the other in it, much like with
> Boost.Build. So as a Boost developer, there may be a slight plus on
> CMake side for me, but absolutely not worth the damage that has been
> inflicted on Boost already on the road to it. As a Boost user I really
> don't care as I never ever integrate third party projects into my
> project build system as I consider that a broken approach in the first
> place.

        Stefan

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