[boost] [modularization] What is a module? What is a sub-module?

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 
beginning?

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?

Best,
Vicente