... | ... | @@ -3,16 +3,18 @@ |
|
|
|
|
|
This is work in progress!!!
|
|
|
|
|
|
== Overview
|
|
|
|
|
|
== Motivation
|
|
|
Idea: seamless stacking of multiple module hierarchies, use cases:
|
|
|
|
|
|
* develop/build new modules without exposing them to other users
|
|
|
* transparent/seamless support for modules optimised for certain CPUs
|
|
|
* modules for HPC systems like slurm and required software to support HPC hardware.
|
|
|
* modules on another filesystem or location than the default (@PSI: `/opt/psi`)
|
|
|
* ...
|
|
|
|
|
|
* adding new groups. Examples
|
|
|
** system specific software
|
|
|
** software used only by certain groups
|
|
|
** ..
|
|
|
* ..
|
|
|
|
|
|
== Overlay stacks
|
|
|
Overlays can be stacked. The first overlay - the overlay at the bottom of the stack - is called "base overlay". Multiple loaded overlays are organised as stack. Loading an overlay pushes it on top of the stack. It is only possible to unload the overlay on top of the stack.
|
... | ... | @@ -21,13 +23,13 @@ The 'overlay' at the bottom of the stack is called the base overlay and cannot b |
|
|
|
|
|
== Limitations
|
|
|
|
|
|
The relative directory structure of a hierarchy group must be identical to the base overlay. It is also not possible to define a new hierarchical group.
|
|
|
The relative directory structure of a hierarchical group must be identical to the base overlay. It is **not** possible to define a new hierarchical group.
|
|
|
|
|
|
Overlays must be loaded before the first module.
|
|
|
|
|
|
Unloading an overlay is only possible if no modules are loaded.
|
|
|
|
|
|
Note: an overlay can add new non-hierarchical groups.
|
|
|
Only the overlay on top of the stack can be unloaded.
|
|
|
|
|
|
== Overlay configuration
|
|
|
|
... | ... | |