Re: [boost] Switch to CMake -- Analysis

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

On 07/21/17 20:10, Andrey Semashev 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.
> 
>>> 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. 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.
> 
> 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.

Actually, as a user I do care and not in favor of CMake because there is 
always a possibility that Boost requires a newer CMake version that is 
not available on my platform.