On 21.07.2017 13:10, Andrey Semashev via Boost wrote:
On 07/21/17 19:30, Stefan Seefeld via Boost wrote:
On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
I'm sure it's been mentioned before by someone, but as a Boost user and packager (for my work projects) I don't want to deal with a dozen of build systems (worse yet - multiple versions of the same build system) to be able to build Boost. Having a single build system, a single interface and customization point is an important advantage regardless of what the actual build system is used.
Don't you realize how impossible this has become, given the current size and scale of Boost ? You can't treat a project like Boost, with > 100 individual libraries in it, as a single entity. It's not going to work. And each attempt to impose a change will result in endless discussions leading nowhere. We have to face this reality, and break Boost up into parts that individually are amenable to such change. But not as a single orchestrated switch.
Also, please note that I did not suggest that we open the door for any other build systems (though that certainly could become an interesting discussion later).
I think you did advocate for the model where each library picks its own tools, including the build system. Allowing two build systems would be just the first step. I'm just saying that this won't work well for Boost users, at least not for a significant part of them.
That's just FUD. What I'm proposing can indeed be seen as one step towards the multiplication of tools. But that would be quite a few steps down the road, while what I'm saying here is that the step I propose above seems to me to be essential to overcome the current stalemate. Now assuming we progress somewhat using the above, with some libraries having transitioned to using CMake, while others still using Boost.Build, we have two choices: a) Test everything, and come to the conclusion that it works well enough for users, so we can make another release, or b) decide that we need to hold back the next release until the remaining libraries have switched.
Besides, I have my doubts regarding the technical feasibility of this heterogenous infrastructure as well. I'm sure there will be quirks and points of incompatibiliy between the different build systems or some seemingly unreasonable limitations that follow from this integration that will leave someone, possibly users, unhappy.
So you think we can't transition one library at a time, but you believe it will be possible to do a switch for 100+ libraries synchronously ? Sorry, but I can't follow your reasoning...
I wasn't referring to the transition process but rather the resulting model adopted by Boost. If that model includes multiple build systems then it is bound to have problems stemming from the integration.
Regarding the transition process (to whatever build system, not necessarilly CMake), I think both ways have its merits. Making a whole-Boost switch is more resource expensive, but not impossible if there are enough interested people with enough permissions to do the job.
I don't share your (apparent) mental model of software, or the practice of software engineering. Software in general, and Boost libraries in particular, live from the respective communities of people maintaining and developing them. You can't just ask arbitrary "interested people" that aren't already part of those communities to do "a job" on the software. First, that's highly disrespectful of those who have been working on and with the software being changed. And more importantly, you aren't even addressing the real problem, of who would be responsible for the maintenance of that new software ? Who would help users getting stuck trying to build the library ? Who would fix issues ? The only possible answer is "the community". So I think the only people who can be reasonably expected to implement the change are actual members of said communities. And if they aren't willing to go into the imposed direction, there is very little you can do, if you don't want to risk a project fork.
A step by step switch adds a period (potentially, open-ended) when people have to maintain both build systems. As a Boost developer, I'm not happy about that. As a user, I might not be happy either, if one of the build systems doesn't actually work in a Boost release.
Well, if it doesn't work, don't switch ! A switch would obviously only be useful if it improves upon the status quo.
Regarding CMake as a candidate build system, I'm not convinced that the switch would benefit Boost in terms of "new blood" or something. I don't think the build system is something that is keeping millions of developers out there from contributing to Boost, as being advertised. It might be one, though probably not the major point, but I don't think anything will change e.g. wrt. maintenance if we switch right now. Most of the work doesn't even touch the build system or comes down to copying and pasting a piece of jamfile.
I recognize that CMake has gained popularity and it is easier to find support for it online. But I know that more than once I've been puzzled about how to do one thing or the other in it, much like with Boost.Build. So as a Boost developer, there may be a slight plus on CMake side for me, but absolutely not worth the damage that has been inflicted on Boost already on the road to it. As a Boost user I really don't care as I never ever integrate third party projects into my project build system as I consider that a broken approach in the first place.
Stefan -- ...ich hab' noch einen Koffer in Berlin...