A Module Conglomerate
Brought to you by:
dirkwallenstein
Menu
▾
▴
#5 A Module Conglomerate
How about having an explicit concept of a "module-group" (or
similar). A module-group would consist of the main module and all
of its forks. The module-group name could be a virtual reference to
the active module (like the main-module name is now).
A module-group could link to another module-group. That would replace
the module-group with a different one providing the same functionality.
Just in case it makes sense to keep more than one of such a module-group
around. (Wait, again config based revision selection? Maybe it can be
added to the fork-selection mechanism -- then called "module selection"
or similar)
Currently, there is a main-module that has the same name as the
module-group. Maybe remove that requirement and flag one module of
the module-group as main-module. I think, it makes sense to have a
dedicated main-module in some cases. For example, it would be
possible to keep remote repo links to all available forks up to date
in the main-module.
The configuration section for the module-group is shared among all
modules of that group. It can have subsections that apply to one
module only. The module-group section would basically extend its
subsections. The module group configuration section could have
unique items like fork selection and the module-group redirection
link, as well as defaults that can be overridden in module specific
subsections. The assembling of active values is _not_ done through
configuration sections, though. There are even (build-system specific)
global defaults, so that has to be done with other means, anyway.
[module.mg]
fork-select = me/mg
main-module = me/mg
redirect-to = another-mg
phase-configure = --opt
phase-build = --more --opt-in
[module.mg.me/mg]
phase-build = --go
This setup would support sharing a configuration among several
modules as well as allow to have modules configured individually.
Fork activation would become a separate mechanism. Similar to
revision selection inside a repo, you would just activate a fork
independently of the configuration. The configuration would just
recommend a fork, like it does for branches.
With individual fork configuration sections in place, and a separate
fork-selection mechanism, there could be multiple config-token files
active at the same time. It would be possible to have configuration
features turned on/off persistently (and combined). Some of those
config-token files could be managed by tools like GUI frontends (build
systems could make options available in some parsable form)
Build systems could register additional options for these module
sections (or they would be made available there). The options should be
namespaced. That appears to be better than having build-system specific
options in a separate subsection.
[module.mg]
build-system = autotools # disambiguate if necessary
autotools-opt5 = on
distutils-opt9 = on