lib/types: Revert handling submodules for "either"

This reverts commit 0f0805b, because @nbp had concerns about whether
this would be a good idea and pointed out problems with this.

We currently do not have a case where "either" is used in conjunction
with submodules, but I'm reverting it anyway to prevent people from
adding options using that type in that way.

This is now being reviewed in #14053.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This commit is contained in:
aszlig 2016-03-19 19:04:13 +01:00
parent 2dc1f2c934
commit 009fd5ef77
No known key found for this signature in database
GPG key ID: D0EBD0EC8C2DC961

View file

@ -246,25 +246,7 @@ rec {
either = t1: t2: mkOptionType {
name = "${t1.name} or ${t2.name}";
check = x: t1.check x || t2.check x;
merge = loc: defs:
if all t1.check (getValues defs) then t1.merge loc defs
else if all t2.check (getValues defs) then t2.merge loc defs
else throw ( "The option `${showOption loc}' has conflicting"
+ " definitions for type either, in"
+ " ${showFiles (getFiles defs)}.");
getSubOptions = prefix: t1.getSubOptions prefix
// t2.getSubOptions prefix;
getSubModules = concatLists (remove null [
t1.getSubModules
t2.getSubModules
]);
substSubModules = m: let
maybeDef = def: r: if r == null then def else r;
in either (maybeDef t1 (t1.substSubModules m))
(maybeDef t2 (t2.substSubModules m));
merge = mergeOneOption;
};
# Obsolete alternative to configOf. It takes its option