Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2017-07-18 23:43:43

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

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

> [...]
> 
> 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; 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. 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.

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.

Louis

--
View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Committee-tp4696934p4696984.html
Sent from the Boost - Dev mailing list archive at Nabble.com.