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
Le 21/09/14 11:12, Andrey Semashev a écrit : 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