On Mon, Jun 19, 2017 at 2:57 PM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:
On 19.06.2017 15:48, Peter Dimov via Boost wrote:
Stefan Seefeld wrote:
What would it take for Boost to support individual libraries to be built with anything else ?
In what scenario? Standalone, or as part of the Boost release?
Both, as the goal is not to add more infrastructure, but to replace it.
If standalone, it's up to you to support whatever you like.
If as part of the release, this would mean that everyone who wants to build a Boost release would now need to have your preferred build system installed. Currently, we don't require anything else, as Boost.Build is part of the release. So this would be a significant regression in usability.
I understand. This is a bit of a vicious circle: Right now Boost is always built as a whole, so lots of people do it. In a modular Boost world, fewer people would build all of boost, as it's much easier to build just the libraries people need.
I don't see it as much of a circle. As long as boost is monolithic, we need to stick with one tool (b2 or cmake or whatever). After it splits into a modular structure and no one needs/wants to build it all at once, then we could open up other tools. I don't mind installing one or two pre-requisites on my build machines, but if each library has their own (conflicting?!?) requirements that'd get un-workable. However, just because we go modular, doesn't mean that we should throw open the door to each library maintainer doing whatever they want. It might not be ideal for each library, but there is some benefit to standardizing on tools. Other organizations put requirements on disparate project. For a long time (not sure if this is still the case) the Apache project required all its member projects to use SVN for source control, and those projects are a lot less homogeneous than ours. Tom