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

Subject: Re: [boost] [modularization] What is a module? What is a sub-module?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-09-21 05:12:09

On Sunday 21 September 2014 10:36:45 Vicente J. Botet Escriba wrote:
> 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.

The current problems in testing are not caused by MPL per se, but by a 
Boost.Build issue which manifested itself when MPL got modularized. The 
Boost.Build problem can appear in other contexts and should be fixed even if 
we revert MPL.

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

I'm not sure I understand how this explicit mapping would be stored. With git 
submodules and sublibs the Boost modular structure can be inferred from the 
directory structure. With your approach there will be files belonging to 
different Boost modules in the same directory.

If you propose some kind of metadata describing the distribution of files 
between Boost modules then how this metadata is supposed to be filled and 
maintained? I'd really like to avoid any approach that involves us manually 
filling it (and git hooks aren't really a good solution either, as we 
discussed earlier).