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