hierarchical_mns

Implementation of an example hierarchical module naming scheme.

Authors:

Kenneth Hoste (Ghent University)
Markus Geimer (Forschungszentrum Juelich GmbH)

`HierarchicalMNS` ¶

Bases: ModuleNamingScheme

Class implementing an example hierarchical module naming scheme.

`det_full_module_name(ec)` ¶

Determine full module name, relative to the top of the module path. Examples: Core/GCC/4.8.3, Compiler/GCC/4.8.3/OpenMPI/1.6.5, MPI/GCC/4.8.3/OpenMPI/1.6.5/HPL/2.1

`det_full_version(ec)` ¶

Determine full version, taking into account version prefix/suffix.

`det_init_modulepaths(ec)` ¶

Determine list of initial module paths (i.e. top of the hierarchy).

`det_modpath_extensions(ec)` ¶

Determine module path extensions, if any. Examples: Compiler/GCC/4.8.3 (for GCC/4.8.3 module), MPI/GCC/4.8.3/OpenMPI/1.6.5 (for OpenMPI/1.6.5 module)

`det_module_subdir(ec)` ¶

Determine module subdirectory, relative to the top of the module path. This determines the separation between module names exposed to users, and what's part of the $MODULEPATH. Examples: Core, Compiler/GCC/4.8.3, MPI/GCC/4.8.3/OpenMPI/1.6.5

`det_module_symlink_paths(ec)` ¶

Determine list of paths in which symlinks to module files must be created.

`det_short_module_name(ec)` ¶

Determine short module name, i.e. the name under which modules will be exposed to users. Examples: GCC/4.8.3, OpenMPI/1.6.5, OpenBLAS/0.2.9, HPL/2.1, Python/2.7.5

`det_toolchain_compilers_name_version(tc_comps)` ¶

Determine toolchain compiler tag, for given list of compilers.

`expand_toolchain_load(ec=None)` ¶

Determine whether load statements for a toolchain should be expanded to load statements for its dependencies. This is useful when toolchains are not exposed to users.

`requires_toolchain_details()` ¶

Determine whether toolchain details are required by this module naming scheme, e.g. whether one of det_toolchain_* functions are relied upon.

hierarchical_mns