On 18.07.2017 19:43, Louis Dionne 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
On 18.07.2017 17:00, Vladimir Prus via Boost wrote: 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...