Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-07-19 02:12:31

On 7/18/2017 7:43 PM, Stefan Seefeld 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".
> 
> 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. It's not only entirely against
> the spirit of Free Software and Open Source, but it's also impossible to
> implement. Who will be responsible for the change ? Who will be
> responsible for any fallout generated in the process (and one has to be
> very naive to assume that there won't be any) ?
> 
> 
> 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.

In the current monolithic structure of Boost, with some 130+ libraries 
being involved, it would lead to quite a problem for end-users if each 
library just did their own thing as regards how a library is built, 
tested, and documented.

> 
>          Stefan
>