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:10:49

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.