Open kubanrob opened 7 years ago
Summery of short discussion with @rottaran: Internally, we already treat arrays in configuration files as unordered sets. Also, the validity of configuration should not (implicitly) depend on the order of some array, as errors induced by ordering may be easy to make and hard to find.
So maybe we should document that we use set semantics for all arrays in configuration files, and merge them by union.
As a side effect, the second rule enables us to use variable names as a "guard" to forbid some configurations ... I am not sure if this a good idea, though.
The provides
field allows to do this already
Recap from quick talk with @rottaran yesterday: Maybe it is enough to make a merging interface accessible to the Mako template and allow it to merge only the variables it need using some kind of query.
Currently, modules can easily redefine variables.
This may lead to all kinds of indeterministic bugs in the build, as the last module parsed defines the actual value of the variable. (related: issue #15) On the other hand, we have no canonical way to gather information from multiple modules. This would be very useful for generating registries on build-time. For example: a static object registry shared by the kernel and the init application in MyThOS.
I suggest that we check for redefinition of variables and:
The first rule is a bit complicated: For dictionary, we have the same problems as before with duplicated keys. Therefore we should apply the rules recursively for dictionaries. Merging/concatenating arrays is even worse, as they are ordered per definition. Maybe we should concatenate them in the same order as the module order discussed in issue #15. The more I think about it: It should be possible to replace the current
includeModules
function by the array concatenation mechanism.As a side effect, the second rule enables us to use variable names as a "guard" to forbid some configurations ... I am not sure if this a good idea, though.