Boost logo

Boost :

Subject: [boost] [modularization] proposal and poll
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2014-05-29 16:22:05

Dear Boost mailing list members,

I would like to revive the topic of Boost inter-library dependencies,
suggest two global changes to Boost and ask whether you agree with the
course of action I propose.


Boost recently transitioned from a monolithic SVN repository to a
"modular" Git repository. One of the potential benefits of this new
structure is that it may allow users to copy much less of Boost when
they need only a small part of it. I believe that two additional,
evolutionary changes are needed to truly unlock that benefit.

The currently-standard way to use the new Git repository is to
recursively clone the super-project and all its submodules, one for
each of the >100 libraries. In order to use Boost in a truly modular
way, a developer would rather just clone only the libraries she needs
(including dependencies). Unfortunately, there is currently no
feasible way to do that [see also 1]:

 - Manually: this is cumbersome and generally hard because there are
    many (undocumented) interdependencies between Boost libraries.
 - Automatically: as far as I know Ryppl is the only existing attempt
    at providing automated dependency handling for Boost, but it is a
    very ambitious project that attempts to do much more and it is
    currently neither finished nor being actively developed.

I think there could be a less ambitious but faster way to provide
automated dependency handling. It would take no more than some static
configuration, to list for each library what other Boost libraries it
depends on, combined with a simple script that automatically traverses
the dependency graph and clones just the necessary submodules. This
script may then be hooked into the bootstrap script. I think I could
write the dependency handler, and I would be willing to, though I
can't currently provide any indication of when I would be able to

However, even if we had an automated way to handle dependencies, that
would not be a sufficient solution to true modularity. As has been
discussed before, the interdependencies between Boost libraries are
currently so strong, that even using a single header file may likely
require the user to copy a substantial portion of Boost [2]. This is
especially the case because there are many cyclical dependencies
[3, 4].

Stephen Kelly investigated how the interdependencies between Boost
libraries could be reduced, especially the cyclical dependencies. He
concluded that most cyclical dependencies could be eliminated and that
the dependency graph could be simplified substantially overall. He
also described concrete ways to achieve this. [3 and onwards]

I believe it would still be worthwhile to reduce interdependencies
between Boost libraries in the way Stephen proposed, or with a very
similar approach. Stephen told me he is willing to re-analyze the
dependencies as many times as needed as he did before and to make
recommendations. Together with an automated way to handle
dependencies, this should enable users to install only a small portion
of Boost if that is all they need. It will also make the Boost super-
project more flexible overall.


The following (evolutionary) global changes to Boost should be planned
and given priority over any other proposals [e.g. 5], in the following

1. Reduction of dependencies between Boost libraries.
2. Simple but effective automation of dependency handling.


I think it may be easier for the steering committee to justify any
decision on this proposal, if they have hard statistics about the
amount of support it receives. Therefore, I invite every opinionated
person reading this to reply with a vote, either in favour of the
proposal or against it. I invite you to do this even if you do not
feel the need or find the time to provide arguments for your position.
You can later re-vote if you change your mind.

I will count the votes, and when there are more than 30 I will start
posting the statistics occasionally. Votes are public so everyone can
verify my data when necessary. Anyone, including the steering
committee, can then use the numbers however they choose.

Thanks in advance,




Boost list run by bdawes at, gregod at, cpdaniel at, john at