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.