Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-19 00:53:31

On 18.07.2017 19:43, Louis Dionne via Boost wrote:
>> On 18.07.2017 17:00, Vladimir Prus via Boost wrote:
>>> On 18/07/2017 16:12, Jon Kalb via Boost wrote:
>>>> Therefore, we, the Steering Committee, announce to the Boost
>>>> community our
>>>> desire and intent to move Boost’s build system to CMake for users and
>>>> developers alike.
>>> I am obviously biased, so I won't comment on technical merits of this
>>> desire. Also, as usual in open-source, those who write the most code
>>> get to decide in the end. 
>> Exactly ! A decision such as this one will affect project developers and
>> maintainers the most, as they are the ones who need to fix bugs or
>> respond to support requests. It is precisely in that spirit that I have
>> asked repeatedly for this decision to be made by individual projects,
>> rather than by any "Committee".
> Let me please quote the original message:
>
>   We are soliciting comments and proposals from the community to guide the 
>   process and the goals.
>
> Basically, what we're saying is not "we're doing this, now implement it". 
> It's more like "we've got some problems, let's figure how to fix them 
> together".

While I agree that sounds much better, it is not my reading of the
original.
"...announce to the Boost community our desire and intent to move
Boost’s build system to CMake for users and developers alike..." is a
statement of a (perceived) solution, not a problem statement combined
with an invitation to think about possible solutions.
>> To make this very explicit: I don't see myself either contributing to
>> nor maintaining any infrastructure that was imposed onto the
>> Boost.Python library by anyone who is not himself actively participating
>> in the project. In fact, I don't see how any single entity could impose
>> anything like this on Boost as a whole. 
> To be clear, things will be imposed on people in any decently-sized 
> organization. For example, it was imposed on me to add Boost.Build 
> support when Hana was accepted into Boost, and I conformed.

Yeah, when you submit a library to Boost, you know exactly what you get
yourself into. The current situation is quite different, though. (And
for avoidance of doubt: I don't really want to talk about the technical
details of the change, whether cmake really is the best choice, or how
hard it would be for me to learn. As Vladimir has said in another reply:
it's the process itself that is utterly broken, as those who are
concerned the most aren't even consulted, at least not in the
decision-making process.)

>> [...]
>>
>> So, in this spirit, I reiterate my counter-proposal: Change the Boost
>> (build) infrastructure to allow *individual projects* to decide what
>> tools are involved in the build process. To make this practical, this
>> could simply mean that individual projects get to decide whether they
>> want to move to cmake or stay with the original b2 infrastructure.
>> Coming up with a simple integration point so boost as a whole can be
>> built with a single command, while its components can use either cmake
>> or b2, shouldn't be any harder than the wholesale switch that is being
>> proposed.
> Please note that the original announcement does not preclude this from 
> happening;
It does.

>  so long as new authors can stick to CMake and users can 
> integrate with Boost seamlessly from CMake, I do think this would be
> a valid way to solve the problem.
But that's not at all what I'm saying. My point is precisely that I (as
Boost.Python maintainer) do not want others to request from me that
Boost.Python be buildable using cmake, and then submit bug reports about
a broken cmake infrastructure that I'm neither able nor willing to maintain.
What I do suggest is that I provide a (reasonably simple) way to build
Boost.Python (using infrastructure I understand and thus can maintain),
with integration points so the Boost super-project can be built with
Boost.Python being part of it.

>  I'm assuming that there would be a
> way to generate CMake config files that work out of the box from B2
> with your approach.

I think that is very naive. Of course, others are free to use their own
wrapper tools, but I feel in no way obliged to support those.

> It does add complexity to the system, but that's a solution like another, 
> and in fact it does have its advantages too since it means we don't need
> a wholesale migration when CMake is not cool anymore.

Yes. I have repeatedly pointed out another (much more natural) solution
for the problem of wholesale migrations (modularity !), which
unfortunately didn't receive the required support to be considered
seriously.

        Stefan

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