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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-09-21 05:41:17

Le 21/09/14 11:12, Andrey Semashev a écrit :
> 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.
Right, this is why I'm saying that maybe we need to review the way we 
are building modular 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).
>>
>> <snip>
> 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.
As I said, this is temporary, to help to identify the 
modules/sub-modules. I guess that at the end the files would be moved to 
the a specific repository or 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).
>
I don't see any problem. For most of the modules the implicit mapping is 
the good one. For those that must be explicit, I purpose that the author 
maintain this metadata as far as it is located at the repository level. 
The boostdep tool should be able (or is already able?) to catch when 
there are new files that have been not mapped, and this should be fixed. 
There is still an case to answer if we need to have modules that are 
located now in multiple repositories, but the question is still open.

Best,
Vicente