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