modules: Update evalModules doc
This commit is contained in:
parent
22584ce667
commit
86f5136baf
1 changed files with 26 additions and 3 deletions
|
@ -52,9 +52,32 @@ in
|
|||
|
||||
rec {
|
||||
|
||||
/* Evaluate a set of modules. The result is a set of two
|
||||
attributes: ‘options’: the nested set of all option declarations,
|
||||
and ‘config’: the nested set of all option values.
|
||||
/*
|
||||
Evaluate a set of modules. The result is a set with the attributes:
|
||||
|
||||
‘options’: The nested set of all option declarations,
|
||||
|
||||
‘config’: The nested set of all option values.
|
||||
|
||||
‘type’: A module system type representing the module set as a submodule,
|
||||
to be extended by configuration from the containing module set.
|
||||
|
||||
‘extendModules’: A function similar to ‘evalModules’ but building on top
|
||||
of the module set. Its arguments, ‘modules’ and ‘specialArgs’ are
|
||||
added to the existing values.
|
||||
|
||||
Using ‘extendModules’ a few times has no performance impact as long
|
||||
as you only reference the final ‘options’ and ‘config’.
|
||||
If you do reference multiple ‘config’ (or ‘options’) from before and
|
||||
after ‘extendModules’, performance is the same as with multiple
|
||||
‘evalModules’ invocations, because the new modules' ability to
|
||||
override existing configuration fundamentally requires a new
|
||||
fixpoint to be constructed.
|
||||
|
||||
‘_module’: A portion of the configuration tree which is elided from
|
||||
‘config’. It contains some values that are mostly internal to the
|
||||
module system implementation.
|
||||
|
||||
!!! Please think twice before adding to this argument list! The more
|
||||
that is specified here instead of in the modules themselves the harder
|
||||
it is to transparently move a set of modules to be a submodule of another
|
||||
|
|
Loading…
Reference in a new issue