give it as argument to each sub-module.
With the type "types.attrsOf types.optionSet", you will obtain the name of
the attribute in which the sub-modules are contained.
svn path=/nixpkgs/trunk/; revision=17669
method, properties evaluated at the evaluation time are still on the values
which makes this interresting to use in conjunction with extraConfigs.
The extraConfigs values are merged with the other values and then the
properties gets evaluated.
Thus, we can keep properties like mkOverride with this method.
svn path=/nixpkgs/trunk/; revision=17482
insert definitions from an external location. As opposed to other
defintions, these definitions are always embedded into a list which allow
to add multiple definitions with one module.
!!! This feature _should not_ be used as a new mean to define options.
svn path=/nixpkgs/trunk/; revision=17481
builtin to force the evaluation of the configuration value. Thus the
success flag returned by tryEval corespond to the success of the
whole evaluation.
svn path=/nixpkgs/trunk/; revision=17478
moduleMerge because we may need to alter the result of the configuration
before using it inside other options.
svn path=/nixpkgs/trunk/; revision=17477
- Remove handleOptionSets which used option declarations & definitions
in the same set.
- Add a traversal of modules where "config" and "options" are traverse at
the same time.
This allow to have accruate error messages with the incriminated files
playing a role in the error.
This system add a new restriction compare to the previous system:
- A module with no structure (option definitions & option declarations
& require) should not contain any option declarations. If such module
exists you must convert it to the following form:
{ imports = <content of the require attribute>;
options = <set of option declarations>;
config = <set of option definitions>;
}
svn path=/nixpkgs/trunk/; revision=17163
other files.
Imports of imported attribute set are not working anymore because this
feature is hard to maintain and because this a potential source of error.
Imports are only accepted inside named modules where the system has some
control over mutual inclusion.
svn path=/nixpkgs/trunk/; revision=17144
* unifyModuleSyntax: handle all kind of module syntax to convert them into
a module which has the following form:
{
imports = [ <paths> ];
options = <attribute set of options declarations>;
config = <attribute set (with properties) of option definitions>;
}
This function assume that there is at most one imported attribute set which
correspond to option declarations.
* moduleClosure: handle a list of module's paths which are converted with
the previous function to do the closure of the imports with the function
lazyGenericClosure (which does the same as builtins.genericClosure except
that it doesn't evaluate the content of modules). The "key" and "paths"
attributes are left to be used as debug information in futur
implementation(s).
svn path=/nixpkgs/trunk/; revision=17108
The rationale is that usually applications don't care about the kernel
but rather about the C library, tool chain, and standard utilities,
which are GNU, not Linux.
svn path=/nixpkgs/trunk/; revision=17069
