Update *Conflict Unload* mechanism to also include module loaded from
another modulepath than the one specified for a requirement to load.
As a result, such module loaded from another path will be unloaded to be
replaced by the module from the selected modulepath.
Use the modulepath-specific property of the requirements to correctly
compute module dependencies. Especially to determine if a loaded or
loading module is an actual dependency of another module.
g_unmetDepHash array structure is updated to hold the specific
modulepath list next to the loaded module name.
Split isLoadedMatchSpecificPath to create isModulefileMatchSpecificPath
procedure. Useful when working on a *not-yet loaded* context.
When a requirement is defined with a specific modulepath set, record
this spec in the user environment. This information is stored in
__MODULES_LMPREREQPATH environment variable.
Move stickiness check when unloading a module prior processing any
automated module handling mechanism.
Stickiness check procedure is renamed failOrSkipUnloadIfSticky and moved
from interp.tcl to modeval.tcl file.
Fixes#536
When unloading Dependent Reload modules, do not force this unload unless
asked with --force option. As a result an error is obtained when trying
to reload DepRe modules that conflict with other loaded modules. This
error may be by-passed with --force command-line option.
As force argument of cmdModuleUnload now only affects unload of module
depended by other loaded modules, this argument has no impact on
"urequn" unload context as a UReqUn module has no dependent by
definition.
When a loading module requires a Dependent Unload module, the unload of
this module was forced when it was triggered by a Conflict Unload or a
switched-off module. The unload of such Dependent Unload module is not
forced anymore by default and an error is raised if a loading module
requiring the Dependent Unload module is detected.
Fix source-sh tests in 50/400 test case to adapt expected value set to
MANPATH variable when the installed MANPATH value set at configure step
is included in the default MANPATH value set for test.
Fixes#549
Transform the Dependent Unload modules of Conflict Unload modules into
Dependent Reload Modules. An attempt to reload these modules is only
performed if their requirements are satisfied.
Proceed with Dependent Reload load phase on load, unload or switch
evaluation only when these evaluations are top level ones.
As a consequence DepRe modules are reloaded after top module load,
unload or switch. They were previously reloaded right after the load,
unload or switch of the module that triggered the DepRe unload phase.
In case a DepRe is a ReqLo for another module to load, it will be loaded
as ReqLo. Currently it looses its extra tags and gets the auto-loaded
tag. This is something to fix in the future.
With this change when a DepRe module triggered by a sub module switch
operation fails to reload, a real error is rendered rather a simple
warning.
As all DepRe are reloaded at the end, some of them that could be
qualified as UReqUn skip this step and are not auto unloaded.
Register current module evaluation context as a state to be able to
correctly determine is we are running the top evaluation.
As DepRe reload mechanism during switch occurs outside of a modulefile
evaluation it was wrongly considered top evaluation until now.
It also fixes UReqUn mechanism from unload evaluation, which now
correctly happens everytime after main evaluation.
Test that DepRe module is not conflicting with loaded environment and
its requirements are loaded prior reloading it. If its requirements are
not satisfied, skip its reload.
Exception is made if DepRe module is sticky (super-sticky or sticky and
force mode disabled). In which case an attempt to reload sticky DepRe is
performed even if its requirements are not satisfied.
Prior unloading a Dependent Reload module, save its tags, conflict and
prereq definitions. These information will help to determine if this
module is able to reload or if this is a DepUn rather a DepRe.
When unloading Dependent Reload modules, if one unload fails an error is
raised. If force mode is enabled, no evaluation may fail (as
super-sticky modules are allowed to be reloaded). So there is no need to
update DepRe module list as a failure will lead to a global error that
will stop processing.
Treat conflict unload of multiple modulefiles through "module unload"
command failing the same way like with "conflict": first failed module
evaluation leads to stop "module unload" processing unless force mode is
enabled.