Re: [boost] Switch to CMake -- Analysis

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

On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
> On 07/21/17 18:57, Stefan Seefeld via Boost wrote:
>>
>> Here is (once again) how I would approach this instead:
>>
>> * Improve the existing Boost.Build infrastructure to allow libraries to
>> be built stand-alone. (I remember from discussing with Rene a year ago
>> that he had some work in progress to achieve this, so I don't think this
>> is particularly hard, at least not for someone understanding Boost.Build
>> internals).
>> * Replace the top-level build logic  to simply iterate over all
>> libraries, invoking this stand-alone build logic.
>> * With the above in place, it becomes possible to switch from
>> Boost.Build to CMake one library at a time, so the original question can
>> be reframed as "which library wants to switch from Boost.Build to
>> CMake", which, I'm sure, will be much less disruptive (if at all) and
>> non-controversial, as the people to decide will be project maintainers
>> and communities.
>>
>> Does this process appeal to anyone ?
>
> 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'm merely pointing out that rather then switching
from Boost.Build to CMake atomically, we should attempt to do this
piece-wise (and allow projects to keep the current logic if they
prefer), which means supporting *two* build systems, not "a dozen".
I'm really trying hard to come up with *practical* proposals to get out
of the current stalemate. But replies like the above don't help at all.

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

        Stefan

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