Boost logo

Boost :

Subject: [boost] [modularization] What is a module? What is a sub-module?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-09-21 04:36:45

Hi all,

After the long threads concerning the modularization it seems clear to
me that we are in an impasse.

While I guess breaking dependency cycles is a modularization goal for
all of us, it seems that moving files from one module to a sub-module
has not be well accepted, worst yet, could have some dramatic
consequences (a lot of testers were broken with the MPL split) due to
the way we build Boost.

I'm wondering if we don't need an alternative definition of
module/sub-module. This definition could be temporary, it would just be
useful to identify the modules/sub-modules that would be the good ones.
We could move the files when needed by some user oriented tools (install).

Let me try it. A module or submodule is just a list of files. The first
problem is how to identify this list. Currently, the boostdep tool
request that a module is associated to the files in the directory
include of a repository and a sub-module to the files in the directory
include in a subdirectory of a repository. I don't remember which
criteria Stephen Kelly is using in his tool. I propose to switch to a
less restrictive and more explicit mapping that don't implies any change
on how Boost is build/tested. The advantage is that we can change this
mapping without any trouble on the regressions tests :)

* If a repository don't have this explicit mapping, the module with the
same name as the repository is composed of the files in the directory
include, src and build of the repository. There could be other implicit
modules for test, examples, benchmarks, ..., which are not user oriented.
* If a repository has this explicit mapping, the module/sub-modules are
the ones described in this mapping.

Open points
  * Do we want/need to be able to define modules containing files in
more than one repository?
  * Where the explicit mapping should be stored?
  * Should we track the build dependencies? How?
  * Should we rethink how Boost is build in a modularized world?
  * Do we want/need to take in account optional dependencies from the

Note that this would not reduce the dependencies at the file level, but
at least would help us to break the cycles.

Peter, if we agree this is the way to exit from the impasse, would you
like to adapt your tool to use an explicit mapping ?

Any concrete proposal about how Boost could be installed in a
modularized world would be welcome.
Open point: Is anyone interested in working on this modular installation?


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