Re: [boost] proposal - modularize Boost build system

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

On 18.06.2017 14:48, Raffi Enficiaud via Boost wrote:
> Le 18.06.17 à 18:09, Stefan Seefeld via Boost a écrit :
>> One of Boost's bottlenecks is its monolithic build infrastructure. It
>> would be beneficial for many different use cases (testing, packaging,
>> etc.) to decouple the building of Boost libraries (well, those that
>> require building, see the listing in
>> http://www.boost.org/doc/libs/1_64_0/more/getting_started/unix-variants.html#header-only-libraries)
>>
>> such that they may optionally be built stand-alone.
>>
>> At present, building a Boost library requires the entire
>> (super-)repository to be checked out, and the build logic itself
>> involves traversing the entire source tree, looking for a "Jamroot".
>>
>> What would be beneficial to many would be a workflow like this:
>>
>> 1) Have a development environment with (some version of) Boost
>> pre-installed (or at least the parts that the library being built
>> depends on).
>
> If you want to easily distribute boost libraries independently, having
> boost preinstalled (or already cloned or already downloaded from a
> release) is not exactly what I would like to see as a user.

You are right. As was pointed out before, "user" stands for two distinct
roles:

* "downstream boost developer" using an "upstream boost library"
* developers of other software using any boost library

My proposal is more targeted to benefit the former. While independent
release cycles would obviously also impact the latter. But decoupling
releases is an entirely separate discussion, which I'd rather not get
into in the context of this proposal.

> As a library maintainer, I can say that boost.test is having hard time
> to compete with other unit testing libraries such as Catch or google
> test, not because of the number of files in boost.test itself, because
> you need to pull a full boost release to run it, which is another
> level of magnitude.

Precisely, this is exactly one of the things modularization may improve.

> Packaging is out of the user story to my opinion, and there are nice
> people very good at this. Also if installation is easy, packaging is
> less important I would say (IMO).

Not true in practice. Consider a developer (of the second category
above) on Linux. Different distributions use different ways to split
Boost libraries into packages, so to be portable, I need to check for
them all. That's a huge maintenance burden which could be solved if some
basic support for packaging would be built right into the Boost build
system (be it Boost.Build or something else).

Of course you could argue that in many real-world cases even that
use-case isn't very common, as lots of commercial software is built by
cloning Boost and building that in-house. I think that's very
unfortunate if unavoidable, given the current state of things. See my
other proposal (about stability / compatibility) for how to improve
things on that front.

> There is also something a bit awkward I wanted to indicate, but we
> just forgot to mention one of the most important tools so far: the
> **compiler**.
>
> We cannot achieve any modularity if there is no agreement on what
> should be supported, and this definitely is the most important
> variable to take into account in the dependency graph of the
> boost.whatever libraries. If I consider only boost.test, a lot of
> dependencies can just be removed just by considering C++11, which in
> turn would lower dramatically the user overhead in order to use the
> library.

True. But again, let's not kill the discussion by widening the scope
further. For the sake of the discussion let's assume that the compiler
is a pre-defined constant, rather than an additional (almost free)
parameter.

        Stefan

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