Re: [boost] proposal - modularize Boost build system

Subject: Re: [boost] proposal - modularize Boost build system
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-06-19 22:02:02

On 19.06.2017 17:28, Tom Kent via Boost wrote:
> 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.

I agree. So, please consider my use-case of "I want to use my own build
tool" purely as an illustration of why modularization is useful.
The main goal of this modularization proposal remains to break the build
process up, so a top-level `./b2` invocation would do little more than
iterate over all Boost libraries and invoke some build command there
(the details of which remaining to be determined).

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

Understood. One reason why I'm writing this proposal is also to question
whether the level of homogeneity that we currently have (and require) is
actually enforcible (or even desirable) for a project the size of Boost.
It may well have been the right choice when Boost only consisted of a
handful of libraries. But nowadays, the question is at least worth being
asked again.

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...