Re: [boost] proposal - modularize Boost build system

Subject: Re: [boost] proposal - modularize Boost build system
From: Tom Kent (lists_at_[hidden])
Date: 2017-06-19 21:28:03

On Mon, Jun 19, 2017 at 2:57 PM, Stefan Seefeld via Boost <
boost_at_[hidden]> 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