From 576a9fc9964c43212d8e0ff71f89841febd0254e Mon Sep 17 00:00:00 2001 From: Achim Gsell Date: Thu, 13 Aug 2026 15:46:16 +0200 Subject: [PATCH 1/5] doc updated --- doc/src/index.adoc | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/doc/src/index.adoc b/doc/src/index.adoc index 1934d0e..58d4aba 100644 --- a/doc/src/index.adoc +++ b/doc/src/index.adoc @@ -13,16 +13,10 @@ endif::[] include::Introduction.adoc[leveloffset=+1] -include::Nutshell.adoc[leveloffset=+1] - -include::The_module_command.adoc[leveloffset=+1] - -include::modulefiles.adoc[leveloffset=+1] +:sectnumlevels: 2 +include::Tutorials.adoc[leveloffset=+1] :sectnumlevels: 4 include::Building_Pmodules.adoc[leveloffset=+1] -:sectnumlevels: 2 -include::Tutorials.adoc[leveloffset=+1] - include::links.adoc[leveloffset=+1] From e748295b5c62141b698480f5764a28366560b12a Mon Sep 17 00:00:00 2001 From: Achim Gsell Date: Thu, 13 Aug 2026 17:13:52 +0200 Subject: [PATCH 2/5] cleanup --- doc/src/Nutshell.adoc | 444 ------------------ doc/src/The_module_command.adoc | 36 -- doc/src/The_module_command/module-avail.adoc | 61 --- doc/src/The_module_command/module-clear.adoc | 50 -- .../The_module_command/module-display.adoc | 60 --- doc/src/The_module_command/module-help.adoc | 53 --- .../The_module_command/module-initcmds.adoc | 53 --- .../The_module_command/module-keyword.adoc | 29 -- doc/src/The_module_command/module-list.adoc | 54 --- doc/src/The_module_command/module-load.adoc | 115 ----- doc/src/The_module_command/module-purge.adoc | 32 -- .../The_module_command/module-refresh.adoc | 17 - doc/src/The_module_command/module-search.adoc | 71 --- doc/src/The_module_command/module-swap.adoc | 46 -- doc/src/The_module_command/module-use.adoc | 114 ----- doc/src/The_module_command/module-whatis.adoc | 41 -- doc/src/The_module_command/module.adoc | 60 --- doc/src/overlays.adoc | 3 - 18 files changed, 1339 deletions(-) delete mode 100644 doc/src/Nutshell.adoc delete mode 100644 doc/src/The_module_command.adoc delete mode 100644 doc/src/The_module_command/module-avail.adoc delete mode 100644 doc/src/The_module_command/module-clear.adoc delete mode 100644 doc/src/The_module_command/module-display.adoc delete mode 100644 doc/src/The_module_command/module-help.adoc delete mode 100644 doc/src/The_module_command/module-initcmds.adoc delete mode 100644 doc/src/The_module_command/module-keyword.adoc delete mode 100644 doc/src/The_module_command/module-list.adoc delete mode 100644 doc/src/The_module_command/module-load.adoc delete mode 100644 doc/src/The_module_command/module-purge.adoc delete mode 100644 doc/src/The_module_command/module-refresh.adoc delete mode 100644 doc/src/The_module_command/module-search.adoc delete mode 100644 doc/src/The_module_command/module-swap.adoc delete mode 100644 doc/src/The_module_command/module-use.adoc delete mode 100644 doc/src/The_module_command/module-whatis.adoc delete mode 100644 doc/src/The_module_command/module.adoc delete mode 100644 doc/src/overlays.adoc diff --git a/doc/src/Nutshell.adoc b/doc/src/Nutshell.adoc deleted file mode 100644 index 7b3ad4a..0000000 --- a/doc/src/Nutshell.adoc +++ /dev/null @@ -1,444 +0,0 @@ -= *PMODULES IN A NUTSHELL* - -Before reading this section you should be familiar with an environment module system - either http://modules.sourceforge.net/[Environment Modules] or https://www.tacc.utexas.edu/research-development/tacc-projects/lmod[Lmod]. - -Pmodules organizes modules in groups like `Tools`, `Programming`, `Libraries`, `System` etc. for a clear arrangement. Groups of modules can easily be added to the available modules. Read section <> for more details about module groups. - -One issue with Environment Modules is the flat naming scheme. Pmodules and Lmod solves the issue by organizing the modules hierarchically. Providing modules for a toolkit like parallel HDF5 ends up in dozen of modules. One user wants to use GCC 4.8.4 and OpenMPI 1.6.5 another Intel C 15 and MPICH 3.1.4, a third user requires GCC 4.9.2 with MPICH 3.1.4. After a couple of month, some users want new versions. In a flat naming scheme you see all installed versions, even if you just want to see what is available for particular compiler. The solution to this problem is a hierarchical organization of the modules. In section <> we describe how to load and search for modules in a module hierarchy. - -Neither Lmod nor Environment Modules provides something like a life cycle management. A module is either available or not. There is no way to inform the users, whether a module is still unstable or already deprecated. Pmodules solves this problem by introducing releases like `unstable`, `stable` and `deprecated`. In section <> we explain what this means to the user. - ---- - -[id="nutshell-motivation",reftext="Motivation"] -== Motivation - -Environment module systems provide a solution for the dynamic -modification of a user's environment by loading special files named -'modulefiles'. - -Each modulefile contains the information needed to configure the shell -for an application or library. The environment can be modified on a -per-module basis using the `module` command which interprets -modulefiles. Typically modulefiles instruct the `module` command to -alter or set shell environment variables such as `PATH`, `MANPATH` -etc. modulefiles may be shared by many users on a system and users may -have their own collection to supplement or replace the shared -modulefiles. - -Environment module systems are widely used on HPC systems to provide -multiple compilers and multiple versions of the same library or API -implementations to the users. The -http://modules.sourceforge.net/[Environment Modules] system is the -most widely used implementation. Another - more recent - -implementation is -https://www.tacc.utexas.edu/research-development/tacc-projects/lmod[Lmod]. Lmod -addresses some weaknesses of the Environment Modules, but solves only -some of them. - -One issue with the Environment Modules is the flat naming scheme. The -Lmod system and Pmodules solves the problem by organizing the modules -hierarchically. What is the problem with a flat naming scheme? Provide -different versions of the same library, like openmpi 1.6.5/1.8.4, -compiled with different (versions) of compilers, like gcc -4.7.4/4.8.4/4.9.2 and Intel 14.0.2/15.2, the number of modules is -growing quite fast. Providing dozens of libraries will end up in -hundreds of modules - not very clear to the users. - -Neither Environment Modules nor Lmod have build-in support for phasing -out modules or marking modules as unstable. Pmodules solves this -problem by introducing 'releases' like stable, unstable and -deprecated. A user will be warned while loading a non-stable module. - -With Environment Modules and Lmod everything must be coded in the -modulefile - even things which are obvious. If a `bin` directory -exists, why not adding this directory to the `PATH` variable -automatically? The same can be done for `MANPATH`, `LD_LIBRARY_PATH` -and other environment variables. - -Usually modules are installed on a network file-systems. In some cases -it is convenient or even required to install modules locally. Pmodules -provides a tool to install all or a sub-set of the modules from any -location to another location. - -Pmodules has its own (simple) build environment. For a new module you -have to write a build script and a modulefile. Updating an existing -modules is very simple. In most cases it's downloading the new version -and calling the build script. Anyway, nobody forces you to use this -build environment, but in most cases it is very handy. - -[id="nutshell-module-groups",reftext="Module groups"] -== Module groups -Pmodules organizes modules in groups. By default only the groups -`Tools` and `Programming` are visible. To get a list of 'used' and -'unused' groups, run the command `module use`: ----- -$ module use -Used groups: - Tools - Programming - -Unused groups: - Libraries - System -... ----- - -To make the modules in a given group available, run the command - ----- -$ module use GROUP ----- - -Example:: - ----- -$ module use System -$ module avail ---------------------------------------------- System --------------------------------------------- - -fsstress/1.0.0 nmap/6.46 - ---------------------------------------------- Tools --------------------------------------------- - -Eclipse/4.4.2 Firefox/31.0 Opera/23.0 Thunderbird/31.0 emacs/24.4 -global/6.3.1 gnuplot/4.6.3 - ------------------------------------------- Programming ------------------------------------------ - -Python/3.4.0 Python/3.4.3 autoconf/2.69 automake/1.14 cmake/2.8.12.2 gcc/4.7.4 -gcc/4.8.3 gcc/4.8.4 gcc/4.9.2 libtool/2.4.2 m4/1.4.17 ----- - -To make groups unavailable, run the command - ----- -$ module unuse GROUP ----- - -Example:: -Make modules in the groups `System` and `Programming` unavailable: - ----- -$ module unuse System Programming -$ module avail ---------------------------------------------- Tools --------------------------------------------- - -Eclipse/4.4.2 Firefox/31.0 Opera/23.0 Thunderbird/31.0 dialog/1.2.1(u) -emacs/24.4 emacs/24.5(u) git/2.3.3(u) global/6.3.1 gnuplot/4.6.3 gnuplot/5.0.0(u) ----- - ---- - -[id="nutshell-module-hierarchies",reftext="Module hierarchies"] -== Module hierarchies -Unstructured, flat naming schemes are confusing. Why? Lets assume we have to -provide modules for the compilers `gcc-4.8.4`, `gcc-4.9.2`, `intel-15.2`, -the MPI implementations `openmpi-1.6.5`, `openmpi-1.8.4`, `mpich-3.1.4` -and parallel versions of `hdf5-1.8.10` and `hdf5-1.8.14` compiled with -all compiler/MPI combinations. So, we have to provide 30(!) modules: - -* 3 compiler modules -* 9 MPI modules -* 18 hdf5 modules - -Even with a reasonable naming convention this is quite confusing. In a flat naming scheme a listing of available modules might look like: - ----- -$ module avail -gcc-4.8.4 -gcc-4.9.2 -hdf5-1.8.10-mpi-3.1.4-gcc-4.8.4 -hdf5-1.8.10-mpi-3.1.4-gcc-4.9.2 -hdf5-1.8.10-mpi-3.1.4-intel-15.2 -hdf5-1.8.10-openmpi-1.6.5-gcc-4.8.4 -hdf5-1.8.10-openmpi-1.6.5-gcc-4.9.2 -hdf5-1.8.10-openmpi-1.6.5-intel-15.2 -hdf5-1.8.10-openmpi-1.8.4-gcc-4.8.4 -hdf5-1.8.10-openmpi-1.8.4-gcc-4.9.2 -hdf5-1.8.10-openmpi-1.8.4-intel-15.2 -hdf5-1.8.14-mpi-3.1.4-gcc-4.8.4 -hdf5-1.8.14-mpi-3.1.4-gcc-4.9.2 -hdf5-1.8.14-mpi-3.1.4-intel-15.2 -hdf5-1.8.14-openmpi-1.6.5-gcc-4.8.4 -hdf5-1.8.14-openmpi-1.6.5-intel-15.2 -hdf5-1.8.14-openmpi-1.8.4-gcc-4.8.4 -hdf5-1.8.14-openmpi-1.8.4-gcc-4.9.2 -hdf5-1.8.14-openmpi-1.8.4-intel-15.2 -intel-15.3 -mpi-3.1.4-gcc-4.8.4 -mpi-3.1.4-gcc-4.9.2 -mpi-3.1.4-intel-15.2 -openmpi-1.6.5-gcc-4.8.4 -openmpi-1.6.5-gcc-4.9.2 -openmpi-1.6.5-intel-15.2 -openmpi-1.8.4-gcc-4.8.4 -openmpi-1.8.4-gcc-4.9.2 -openmpi-1.8.4-intel-15.2 ----- - -Got it? One combination is missing. But which one? - -Actually we have to provide more compilers than the three mentioned above: while writing this documentation the number is already seven(!): five GCC versions and two Intel C versions. - -Another issue with a flat naming scheme is, that all modules are listed independent of already loaded modules. But listing a module providing `hdf5 1.8.14` compiled with `Intel 15.2` and `mpich 3.1.4` makes not much sense if modules for `gcc 4.9.2` and `openmpi 1.8.4` are already loaded. A solution to these issues is a to structure the modules hierarchically. - ----- - ... _________________________________________|________________________________________... - / | \ - gcc gcc intel - 4.8.4 4.9.2 15.2 - _____________|_____________ _____________|_____________ _____________|_____________ - / | \ / | \ / | \ - openmpi openmpi mpich openmpi openmpi mpich openmpi openmpi mpich - 1.6.5 1.8.4 3.1.4 1.6.5 1.8.4 3.1.4 1.6.5 1.8.4 3.1.4 - __|__ __|__ __|__ __|__ __|__ __|__ __|__ __|__ __|__ - / \ / \ / \ / \ / \ / \ / \ / \ / \ - hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 hdf5 - 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 ----- - -[NOTE] -In a hierarchical structured module environment the command `module -avail` does '''not''' reveal all modules. Modules like `openmpi` and -`hdf5` are not listed as long as the dependencies are not loaded. - - Example:: - Before you can load a hdf5 module, you must first - * load a particular compiler module, - * than a particular MPI module - * and then the desired hdf5 module. - ----- -$ module list -No Modulefiles Currently Loaded. -$ module avail - ------------------------------------------ Programming ------------------------------------------ - -autoconf/2.69 automake/1.14 binutils/2.25(u) cmake/2.8.12.2 cmake/3.1.3 -gcc/4.7.4 gcc/4.8.3 gcc/4.8.4 gcc/4.9.2 gcc/5.1.0(u) intel/14.0.3 -intel/15.2(u) libtool/2.4.2 m4/1.4.17 psi-python27/2.1.0(u) -psi-python34/2.1.0(u) Python/3.4.3 Tcl/8.6.3(u) Tcl/8.6.4(u) Tk/8.6.4(u) ----- - -After loading the module `gcc/4.9.2` we see the available MPI implementations compiled with this compiler: - ----- -$ module load gcc/4.9.2 -$ module avail ------------------------------------------- Programming ------------------------------------------ - -autoconf/2.69 automake/1.14 binutils/2.25(u) cmake/2.8.12.2 cmake/3.1.3 -gcc/4.7.4 gcc/4.8.3 gcc/4.8.4 gcc/4.9.2 gcc/5.1.0(u) intel/14.0.3 -intel/15.2(u) libtool/2.4.2 m4/1.4.17 psi-python27/2.1.0(u) -psi-python34/2.1.0(u) Python/3.4.3 Tcl/8.6.3(u) Tcl/8.6.4(u) Tk/8.6.4(u) - ---------------------------------------- Compiler/gcc/4.9.2 --------------------------------------- - -boost/1.55.0 boost/1.57.0 gsl/1.15 hdf5_serial/1.8.12 hdf5_serial/1.8.13 -hdf5_serial/1.8.14 mpich/3.1.4(u) OpenBLAS/0.2.9 OpenBLAS_OMP/0.2.9 -openmpi/1.6.5 openmpi/1.8.2 openmpi/1.8.4 root/5.34.19 root/5.34.26 SuperLU/4.3 -UMFPACK/5.6.2 vtk/5.10.1 ----- - -Next step is loading a MPI module: - ----- -$ module load openmpi/1.8.4 -$ module avail ------------------------------------------- Programming ------------------------------------------ - -autoconf/2.69 automake/1.14 binutils/2.25(u) cmake/2.8.12.2 cmake/3.1.3 -gcc/4.7.4 gcc/4.8.3 gcc/4.8.4 gcc/4.9.2 gcc/5.1.0(u) intel/14.0.3 -intel/15.2(u) libtool/2.4.2 m4/1.4.17 psi-python27/2.1.0(u) -psi-python34/2.1.0(u) Python/3.4.3 Tcl/8.6.3(u) Tcl/8.6.4(u) Tk/8.6.4(u) - ---------------------------------------- Compiler/gcc/4.9.2 --------------------------------------- - -boost/1.55.0 boost/1.57.0 gsl/1.15 hdf5_serial/1.8.12 hdf5_serial/1.8.13 -hdf5_serial/1.8.14 mpich/3.1.4(u) OpenBLAS/0.2.9 OpenBLAS_OMP/0.2.9 -openmpi/1.6.5 openmpi/1.8.2 openmpi/1.8.4 root/5.34.19 root/5.34.26 SuperLU/4.3 -UMFPACK/5.6.2 vtk/5.10.1 - ----------------------------------- MPI/gcc/4.9.2/openmpi/1.8.4 ---------------------------------- - -BoxLib/2014-02-28 hdf5/1.8.12 hdf5/1.8.13 hdf5/1.8.14 ippl/1.1.4 -parmetis/3.2.0 SuperLU_DIST/3.3 trilinos/11.10.2 trilinos/11.12.1 -trilinos/11.14.1 ----- - -Now you can load the HDF5 module: - ----- -$ module load hdf5/1.8.14 ----- - -Instead of - ----- -$ module load gcc/4.9.2 -$ module load openmpi/1.8.4 -$ module load hdf5/1.8.14 ----- -you can also execute ----- -$ module load gcc/4.9.2 openmpi/1.8.4 hdf5/1.8.14 ----- -[NOTE] -Modules marked with `(u)` are unstable. ---- - -[id="nutshell-searching",reftext="Searching the module hierarchy"] -== Searching the module hierarchy - -Now you may ask: How do I know which hdf5 (or Trilinos, boost...) modules are really available? To get an answer to this question you can run the `module search` command. - -Example:: -To get a list of all installed hdf5 modules run ----- -$ module search hdf5 --all-releases -Module Release Group Requires ------------------------------------------------------------- -hdf5/1.8.12 unstable MPI gcc/4.7.4 mpich/3.1.4 -hdf5/1.8.12 stable MPI gcc/4.7.4 openmpi/1.6.5 -hdf5/1.8.12 stable MPI gcc/4.7.4 openmpi/1.8.2 -hdf5/1.8.12 stable MPI gcc/4.7.4 openmpi/1.8.4 -hdf5/1.8.12 stable MPI gcc/4.8.3 openmpi/1.6.5 -hdf5/1.8.12 stable MPI gcc/4.8.3 openmpi/1.8.2 -hdf5/1.8.12 stable MPI gcc/4.8.3 openmpi/1.8.4 -hdf5/1.8.12 unstable MPI gcc/4.8.4 mpich/3.1.4 -hdf5/1.8.12 stable MPI gcc/4.8.4 openmpi/1.6.5 -hdf5/1.8.12 stable MPI gcc/4.8.4 openmpi/1.8.2 -hdf5/1.8.12 stable MPI gcc/4.8.4 openmpi/1.8.4 -hdf5/1.8.12 unstable MPI gcc/4.9.2 mpich/3.1.4 -hdf5/1.8.12 stable MPI gcc/4.9.2 openmpi/1.6.5 -hdf5/1.8.12 stable MPI gcc/4.9.2 openmpi/1.8.2 -hdf5/1.8.12 stable MPI gcc/4.9.2 openmpi/1.8.4 -hdf5/1.8.12 unstable MPI gcc/5.1.0 mpich/3.1.4 -hdf5/1.8.12 unstable MPI gcc/5.1.0 openmpi/1.6.5 -hdf5/1.8.12 unstable MPI gcc/5.1.0 openmpi/1.8.4 -hdf5/1.8.12 unstable MPI intel/15.2 mpich/3.1.4 -hdf5/1.8.12 unstable MPI intel/15.2 openmpi/1.6.5 -hdf5/1.8.12 unstable MPI intel/15.2 openmpi/1.8.4 -hdf5/1.8.13 stable MPI gcc/4.7.4 openmpi/1.6.5 -hdf5/1.8.13 stable MPI gcc/4.7.4 openmpi/1.8.2 -hdf5/1.8.13 stable MPI gcc/4.7.4 openmpi/1.8.4 -hdf5/1.8.13 stable MPI gcc/4.8.3 openmpi/1.6.5 -hdf5/1.8.13 stable MPI gcc/4.8.3 openmpi/1.8.2 -hdf5/1.8.13 stable MPI gcc/4.8.3 openmpi/1.8.4 -hdf5/1.8.13 stable MPI gcc/4.8.4 openmpi/1.6.5 -hdf5/1.8.13 stable MPI gcc/4.8.4 openmpi/1.8.2 -hdf5/1.8.13 stable MPI gcc/4.8.4 openmpi/1.8.4 -hdf5/1.8.13 stable MPI gcc/4.9.2 openmpi/1.6.5 -hdf5/1.8.13 stable MPI gcc/4.9.2 openmpi/1.8.2 -hdf5/1.8.13 stable MPI gcc/4.9.2 openmpi/1.8.4 -hdf5/1.8.14 unstable MPI gcc/4.7.4 mpich/3.1.4 -hdf5/1.8.14 stable MPI gcc/4.7.4 openmpi/1.6.5 -hdf5/1.8.14 stable MPI gcc/4.7.4 openmpi/1.8.2 -hdf5/1.8.14 stable MPI gcc/4.7.4 openmpi/1.8.4 -hdf5/1.8.14 stable MPI gcc/4.8.3 openmpi/1.6.5 -hdf5/1.8.14 stable MPI gcc/4.8.3 openmpi/1.8.2 -hdf5/1.8.14 stable MPI gcc/4.8.3 openmpi/1.8.4 -hdf5/1.8.14 unstable MPI gcc/4.8.4 mpich/3.1.4 -hdf5/1.8.14 stable MPI gcc/4.8.4 openmpi/1.6.5 -hdf5/1.8.14 stable MPI gcc/4.8.4 openmpi/1.8.2 -hdf5/1.8.14 stable MPI gcc/4.8.4 openmpi/1.8.4 -hdf5/1.8.14 unstable MPI gcc/4.9.2 mpich/3.1.4 -hdf5/1.8.14 stable MPI gcc/4.9.2 openmpi/1.6.5 -hdf5/1.8.14 stable MPI gcc/4.9.2 openmpi/1.8.2 -hdf5/1.8.14 stable MPI gcc/4.9.2 openmpi/1.8.4 -hdf5/1.8.14 unstable MPI gcc/5.1.0 mpich/3.1.4 -hdf5/1.8.14 unstable MPI gcc/5.1.0 openmpi/1.6.5 -hdf5/1.8.14 unstable MPI gcc/5.1.0 openmpi/1.8.4 -hdf5/1.8.14 unstable MPI intel/15.2 mpich/3.1.4 -hdf5/1.8.14 unstable MPI intel/15.2 openmpi/1.6.5 -hdf5/1.8.14 unstable MPI intel/15.2 openmpi/1.8.4 -hdf5_serial/1.8.12 stable Compiler gcc/4.7.4 -hdf5_serial/1.8.12 stable Compiler gcc/4.8.3 -hdf5_serial/1.8.12 stable Compiler gcc/4.8.4 -hdf5_serial/1.8.12 stable Compiler gcc/4.9.2 -hdf5_serial/1.8.12 unstable Compiler intel/15.2 -hdf5_serial/1.8.14 stable Compiler gcc/4.7.4 -hdf5_serial/1.8.14 stable Compiler gcc/4.8.3 -hdf5_serial/1.8.14 stable Compiler gcc/4.8.4 -hdf5_serial/1.8.14 stable Compiler gcc/4.9.2 -hdf5_serial/1.8.14 unstable Compiler intel/15.2 ----- -Example:: -To get a list of all installed hdf5 modules compiled with GCC 4.9.2, run ----- -$ module search hdf5 --with=gcc/4.9.2 --all-releases -Module Release Group Requires ------------------------------------------------------------- -hdf5/1.8.12 unstable MPI gcc/4.9.2 mpich/3.1.4 -hdf5/1.8.12 stable MPI gcc/4.9.2 openmpi/1.6.5 -hdf5/1.8.12 stable MPI gcc/4.9.2 openmpi/1.8.2 -hdf5/1.8.12 stable MPI gcc/4.9.2 openmpi/1.8.4 -hdf5/1.8.13 stable MPI gcc/4.9.2 openmpi/1.6.5 -hdf5/1.8.13 stable MPI gcc/4.9.2 openmpi/1.8.2 -hdf5/1.8.13 stable MPI gcc/4.9.2 openmpi/1.8.4 -hdf5/1.8.14 unstable MPI gcc/4.9.2 mpich/3.1.4 -hdf5/1.8.14 stable MPI gcc/4.9.2 openmpi/1.6.5 -hdf5/1.8.14 stable MPI gcc/4.9.2 openmpi/1.8.2 -hdf5/1.8.14 stable MPI gcc/4.9.2 openmpi/1.8.4 -hdf5_serial/1.8.12 stable Compiler gcc/4.9.2 -hdf5_serial/1.8.13 stable Compiler gcc/4.9.2 -hdf5_serial/1.8.14 stable Compiler gcc/4.9.2 ----- -Example:: -To get a list of all installed modules providing (parallel) HDF5 1.8.14, execute ----- -$ module search hdf5/1.8.14 --with=gcc/4.9.2 --all-releases -Module Release Group Requires ------------------------------------------------------------- -hdf5/1.8.14 unstable MPI gcc/4.9.2 mpich/3.1.4 -hdf5/1.8.14 stable MPI gcc/4.9.2 openmpi/1.6.5 -hdf5/1.8.14 stable MPI gcc/4.9.2 openmpi/1.8.2 -hdf5/1.8.14 stable MPI gcc/4.9.2 openmpi/1.8.4 ----- - -[NOTE] -Without the option `--all-releases`, only modules of "used" releases are listed. - - ---- - -[id="nutshell-module-lifecycle",reftext="Module lifecycle"] -== Module lifecycle -Pmodules supports a simple lifecycle management. This solves the -problem of introducing new modules, which are still in development or -considered to be unstable and it supports phasing out old and -deprecated modules. The lifecycle of a module is `unstable` -> -`stable` -> `deprecated`. By default only stable modules are -visible. If you want to use unstable or deprecated modules, you have -to run - ----- -$ module use unstable ----- - -or - ----- -$ module use deprecated ----- - -first. - -All modules start as `unstable`. This implies something like "use on -your on risk". Unstable modules may be changed without warning or even -be removed. If you load an unstable module, a warning will be printed. - -A `stable` module is, well, stable. It will not be changed during the -remaining life time and the provided software is considered to be -stable. - -A `deprecated` module should not be used any more. Deprecated modules -might be removed without further warning. While loading a deprecated -module, a warning will be printed. Kind module developers might add an -end of life message with more detailed information. - -[id="nutshell-overlays",reftext="Overlays"] -== Overlays - -TBW \ No newline at end of file diff --git a/doc/src/The_module_command.adoc b/doc/src/The_module_command.adoc deleted file mode 100644 index a55a192..0000000 --- a/doc/src/The_module_command.adoc +++ /dev/null @@ -1,36 +0,0 @@ -= THE `module` COMMAND - -*Table of Content* + -The module-command: <> + -List available modules: <> + -Clear list of loaded modules: <> + -Display information about chances in environment when loaded: <> + -Print sub-command or module-specific help: <> + -Add or remove modules from shell’s initialization file: <> + -Search for keywords in 'whatis': <> + -List loaded modules: <> + -Load and unload modules: <> + -Purge all loaded modules: <> + -Refresh loaded modules: <> + -Search installed modules: <> + -Replace a loaded module by another: <> + -Manipulate module path, used releases, groups and overlays: <> + -Search for keywords in 'whatis': <> + - -include::The_module_command/module.adoc[leveloffset=+1] - -== Sub-commands - -include::The_module_command/module-avail.adoc[leveloffset=+2] -include::The_module_command/module-clear.adoc[leveloffset=+2] -include::The_module_command/module-display.adoc[leveloffset=+2] -include::The_module_command/module-help.adoc[leveloffset=+2] -include::The_module_command/module-initcmds.adoc[leveloffset=+2] -include::The_module_command/module-list.adoc[leveloffset=+2] -include::The_module_command/module-load.adoc[leveloffset=+2] -include::The_module_command/module-purge.adoc[leveloffset=+2] -include::The_module_command/module-refresh.adoc[leveloffset=+2] -include::The_module_command/module-search.adoc[leveloffset=+2] -include::The_module_command/module-swap.adoc[leveloffset=+2] -include::The_module_command/module-use.adoc[leveloffset=+2] -include::The_module_command/module-whatis.adoc[leveloffset=+2] diff --git a/doc/src/The_module_command/module-avail.adoc b/doc/src/The_module_command/module-avail.adoc deleted file mode 100644 index e555a28..0000000 --- a/doc/src/The_module_command/module-avail.adoc +++ /dev/null @@ -1,61 +0,0 @@ -[id="module-avail",reftext="`module avail`"] -= List available/loadable modules -:sectnums!: -== NAME - -`module avail` - list loadable modules - -== SYNOPSIS - -`module avail [OPTIONS] [string...]` - -== DESCRIPTION - -List all available module in the current `MODULEPATH`. If an argument is given, then each directory in the `MODULEPATH` is searched for modules whose pathname match the argument. - -This command does *not* display all installed modules on the system. Only loadable modules are listed. To get a list of all installed modules use the command link:module%20search[`module search`]. - -The list of available modules may change either by loading other modules, e.g. a compiler, or by using/accepting unstable or deprecated modules. For the later read the description of link:module%20use[`module use`]. - -With the switches you can change the output format. The default output format is 'human' (readable). For the time being terse and long output are identical. - -== OPTIONS - -`-a`:: List loadable modules in all release-stages. Unstable modules are marked with `(u)`, - deprecated modules with `(d)`. - -`-t | --terse`:: Terse output. - -`-h | --human`:: Human readable output. This is the default. - -`-l | --long`:: Long output. - -== EXAMPLES - ------ -$ module avail git ------------------------------------------ Tools ----------------------------------------- - -ygit/2.3.3 git/2.8.1 git/2.21.0 git/2.22.0 git/2.30.0 git/2.33.1 - -$ module avail -a gcc --------------------------------------- Programming -------------------------------------- - -gcc/4.7.4 gcc/4.8.2 gcc/4.8.3 gcc/4.8.4 gcc/4.8.5 gcc/4.9.2 -gcc/4.9.3 gcc/4.9.4 gcc/5.1.0(d) gcc/5.2.0(d) gcc/5.3.0 gcc/5.4.0 -gcc/5.5.0 gcc/6.1.0 gcc/6.2.0 gcc/6.3.0 gcc/6.4.0 gcc/6.5.0 -gcc/7.1.0 gcc/7.2.0 gcc/7.3.0 gcc/7.4.0 gcc/7.5.0 gcc/8.1.0 -gcc/8.2.0 gcc/8.3.0 gcc/8.4.0 gcc/8.5.0 gcc/9.1.0 gcc/9.2.0 -gcc/9.3.0 gcc/9.5.0 gcc/10.1.0 gcc/10.2.0 gcc/10.3.0 gcc/11.2.0 -gcc/11.3.0 gcc/12.1.0 ------ - -=== SEE ALSO - -<>, -<>, -<>, -<>, -<> - -:sectnums: \ No newline at end of file diff --git a/doc/src/The_module_command/module-clear.adoc b/doc/src/The_module_command/module-clear.adoc deleted file mode 100644 index ed059f9..0000000 --- a/doc/src/The_module_command/module-clear.adoc +++ /dev/null @@ -1,50 +0,0 @@ -[id="module-clear",reftext="`module clear`"] -:secnums: -= Clear list of loaded modules -:secnums!: -== NAME - -`module clear` - clear list of loaded modules. - -== SYNOPSIS - -`module clear` - -== DESCRIPTION - -Force the Pmodules package to believe that no modules are currently loaded. The sub-command clear does not unload the loaded modules! In other words: changes made to the shell's environment by loaded modules are not reverted. - -== EXAMPLES - -After loading the module for `gcc/4.9.2` the following environment variables are set: - ------ -$ env | grep ^GCC -GCC_HOME=/opt/psi/Programming/gcc/4.9.2 -GCC_DIR=/opt/psi/Programming/gcc/4.9.2 -GCC_PREFIX=/opt/psi/Programming/gcc/4.9.2 -GCC_VERSION=4.9.2 -GCC_INCLUDE_DIR=/opt/psi/Programming/gcc/4.9.2/include -GCC_LIBRARY_DIR=/opt/psi/Programming/gcc/4.9.2/lib ------ - -After clearing the list of loaded modules the environment variables set by the GCC module are still set - ------ -$ module clear -$ module list -No Modulefiles Currently Loaded. -$ env | grep ^GCC -GCC_HOME=/opt/psi/Programming/gcc/4.9.2 -GCC_DIR=/opt/psi/Programming/gcc/4.9.2 -GCC_PREFIX=/opt/psi/Programming/gcc/4.9.2 -GCC_VERSION=4.9.2 -GCC_INCLUDE_DIR=/opt/psi/Programming/gcc/4.9.2/include -GCC_LIBRARY_DIR=/opt/psi/Programming/gcc/4.9.2/lib ------ - -== SEE ALSO - -<>, <> - -:secnums: diff --git a/doc/src/The_module_command/module-display.adoc b/doc/src/The_module_command/module-display.adoc deleted file mode 100644 index 7630a6e..0000000 --- a/doc/src/The_module_command/module-display.adoc +++ /dev/null @@ -1,60 +0,0 @@ -[id="module-display",reftext="`module display`"] -:sectnums: -= Display information about a module -:sectnums!: -== NAME - -`module display\|show` - display information about chances in environment - -== SYNOPSIS - -`module display modulefile...` + -`module show modulefile...` - -== DESCRIPTION - -Display information about modulefile(s). The display sub-command will list the full path of the modulefile(s) and all of the environment changes the modulefile(s) will make if loaded. (It will not display any environment changes found within conditional statements.) - -== EXAMPLES - -Display chances the module `gcc/5.4.0` will make to the environment if loaded: -```sh -$ module display gcc/5.4.0 -------------------------------------------------------------------- -/opt/psi/Programming/modulefiles/gcc/5.4.0: - -module-whatis GNU Compiler Collection -conflict gcc -setenv GCC_VERSION 5.4.0 -setenv GCC_PREFIX /opt/psi/Programming/gcc/5.4.0 -setenv GCC_DIR /opt/psi/Programming/gcc/5.4.0 -setenv GCC_HOME /opt/psi/Programming/gcc/5.4.0 -prepend-path PATH /opt/psi/Programming/gcc/5.4.0/bin -prepend-path MANPATH /opt/psi/Programming/gcc/5.4.0/share/man -prepend-path C_INCLUDE_PATH /opt/psi/Programming/gcc/5.4.0/include -prepend-path CPLUS_INCLUDE_PATH /opt/psi/Programming/gcc/5.4.0/include -setenv GCC_INCLUDE_DIR /opt/psi/Programming/gcc/5.4.0/include -prepend-path LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib -prepend-path LD_LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib -setenv GCC_LIBRARY_DIR /opt/psi/Programming/gcc/5.4.0/lib -prepend-path LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib64 -prepend-path LD_LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib64 -setenv GCC_LIBRARY_DIR /opt/psi/Programming/gcc/5.4.0/lib64 -append-path PMODULES_LOADED_PROGRAMMING gcc/5.4.0 -remove-path PMODULES_LOADED_PROGRAMMING --APPMARKER-- -setenv COMPILER gcc -setenv COMPILER_VERSION 5.4.0 -setenv CC /opt/psi/Programming/gcc/5.4.0/bin/gcc -setenv CXX /opt/psi/Programming/gcc/5.4.0/bin/g++ -setenv F77 /opt/psi/Programming/gcc/5.4.0/bin/gfortran -setenv F90 /opt/psi/Programming/gcc/5.4.0/bin/gfortran -setenv FC /opt/psi/Programming/gcc/5.4.0/bin/gfortran -setenv FORTRAN /opt/psi/Programming/gcc/5.4.0/bin/gfortran -------------------------------------------------------------------- -``` - -== SEE ALSO - -<> - -:sectnums: \ No newline at end of file diff --git a/doc/src/The_module_command/module-help.adoc b/doc/src/The_module_command/module-help.adoc deleted file mode 100644 index 41dad1d..0000000 --- a/doc/src/The_module_command/module-help.adoc +++ /dev/null @@ -1,53 +0,0 @@ -[id="module-help",reftext="`module help`"] -= Print sub-command or module-specific help -== NAME - -`module help` - print sub-command or module-specific help - -== SYNOPSIS - -`module help [module|sub-command...]` - -== DESCRIPTION - -Print help for specific modules, sub-commands or the module command itself. - -== EXAMPLES - -Get help for the module git/2.3.3: -```sh -$ module help git/2.3.3 - ------------ Module Specific Help for 'git/2.3.3' ------------------ - -distributed version control system -Version: 2.3.3 -Homepage: http://git-scm.com/ -License: GNU GPL v2 -Maintainer: Achim Gsell - -Git is a free and open source distributed version control system -designed to handle everything from small to very large projects -with speed and efficiency. - -Git is easy to learn and has a tiny footprint with lightning fast -performance. It outclasses SCM tools like Subversion, CVS, Perforce, -and ClearCase with features like cheap local branching, convenient -staging areas, and multiple workflows. -``` -Print help for the sub-command load: -```sh -$ module help load - -USAGE: - module add modulefile... - module load modulefile... - Load modulefile(s) into the shell environment. Loading a - 'group-head' will extend the MODULEPATH. E.g.: loading a - compiler makes additional modules like openmpi and libraries - compiled with this compiler available. -``` - -== SEE ALSO - -<> diff --git a/doc/src/The_module_command/module-initcmds.adoc b/doc/src/The_module_command/module-initcmds.adoc deleted file mode 100644 index 95ef074..0000000 --- a/doc/src/The_module_command/module-initcmds.adoc +++ /dev/null @@ -1,53 +0,0 @@ -[id="module-initcmds",reftext="`module initcmds`"] -= Manipulate shell’s initialization file - -== NAME - -`module initadd|initprepend|initrm|initswitch|initrm|initlist|initclear` - add or remove modules from shell’s initialization file - -== SYNOPSIS - -`module initadd module...` + -`module initprepend module...` + -`module initrm module...` + -`module initswitch module1 module2` + -`module initlist` + -`module initclear` - -== DESCRIPTION - -Add modulefile(s) to, list modulefile(s) in or remove modulefile(s) from the shell's initialization file in the user's home directory. The startup files checked (in order) are: - -**csh**:: -`.modules`, `.cshrc(.ext)`, `.csh_variables`, and `.login(.ext)` - -**tcsh**:: -`.modules`, `.tcshrc`, `.cshrc(.ext)`, `.csh_variables`, and `.login(.ext)` - -**bash**:: -`.modules`, `.bash_profile`, `.bash_login`, `.profile(.ext)`, and `.bashrc(.ext)` - -**zsh**:: -`.modules`, `.zcshrc(.ext)`, `.zshenv(.ext)`, and `.zlogin(.ext)` - -`module initadd module...`:: -If a module load line is found in any of these files, the modulefile(s) is(are) appended to any existing list of modulefiles. The module load line must be located in at least one of the files listed above for any of the init sub-commands to work properly. If the module load line is found in multiple shell initialization files, all of the lines are changed. - -`module initprepend module...`:: -Does the same as initadd but prepends the given modules to the beginning of the list. - -`module initrm module...`:: -Remove modulefile(s) from the shell's initialization files. - -`module initswitch module1 module2`:: -Switch `module1` with `module2` in the shell's initialization files. - -`module initlist`:: -List all of the module(s) loaded from the shell's initialization file. - -`module initclear`:: -Clear all of the module(s) from the shell's initialization files. - -== SEE ALSO - -<>, <>, <> diff --git a/doc/src/The_module_command/module-keyword.adoc b/doc/src/The_module_command/module-keyword.adoc deleted file mode 100644 index d393093..0000000 --- a/doc/src/The_module_command/module-keyword.adoc +++ /dev/null @@ -1,29 +0,0 @@ -[id="module-keyword",reftext="`module keyword|apropos`"] -= Show/search 'whatis' information -== NAME - -`module keyword|apropos` - search for keywords in 'whatis' - -== SYN[]OPSIS - -`module apropos string...` + -`module keyword string...` - -== Description - -Search through the 'whatis' informations of all modulefiles for the specified string. All whatis informations matching the string will be displayed. - -== EXAMPLES - -```sh -$ module keyword editor ------------ /opt/psi/Tools/modulefiles ------------- - emacs/24.3: extensible, customizable text editor—and more - emacs/24.4: extensible, customizable text editor—and more - emacs/24.5: extensible, customizable text editor—and more - emacs/25.1: extensible, customizable text editor—and more ------------ /opt/psi/Programming/modulefiles ------------- -``` -== SEE ALSO - -<>, <> diff --git a/doc/src/The_module_command/module-list.adoc b/doc/src/The_module_command/module-list.adoc deleted file mode 100644 index db66659..0000000 --- a/doc/src/The_module_command/module-list.adoc +++ /dev/null @@ -1,54 +0,0 @@ -[id="module-list",reftext="`module list`"] -= List loaded modules -== NAME - -`module list` - list loaded modules - -== SYNOPSIS - -`module list [OPTIONS]` - -== DESCRIPTION - -List loaded modules. - -== OPTIONS - -`-t | --terse`:: -Terse output. - -`-h | --human`:: -Human readable output. This is the default. - -`-l | --long`:: -Long output. - -== EXAMPLES - -Assuming the modules `gcc/4.8.3`, `openmpi/1.8.2` and `hdf5/1.8.12`. List with default (human readable) output: -```sh -$ module list -Currently Loaded Modulefiles: - 1) gcc/4.8.3 2) openmpi/1.8.2 3) hdf5/1.8.12 -``` -List in terse output: -```sh -$ module list -t -Currently Loaded Modulefiles: -gcc/4.8.3 -openmpi/1.8.2 -hdf5/1.8.12 -``` -Long listing: -```sh -$ module list -l -- Package -----------------------------+- Versions -+- Last mod. ------ -Currently Loaded Modulefiles: -gcc/4.8.3 2014/12/05 17:39:24 -openmpi/1.8.2 2014/11/25 8:15:40 -hdf5/1.8.12 2014/11/25 8:15:40 -``` - -== SEE ALSO - -<>, <> diff --git a/doc/src/The_module_command/module-load.adoc b/doc/src/The_module_command/module-load.adoc deleted file mode 100644 index 6aaab0e..0000000 --- a/doc/src/The_module_command/module-load.adoc +++ /dev/null @@ -1,115 +0,0 @@ -[id="module-load",reftext="`module load|unload`"] -= Load and unloading a module -== NAME - -`module add|load` - load modules + -`module rm|unload` - unload modules - -== SYNOPSIS - -`module add [OPTIONS] modulefile...` + -`module load [OPTIONS] modulefile...` + -`module rm modulefile...` + -`module unload modulefile...` - -== DESCRIPTION - -Load modulefile(s) into shell environment. Loading a group-head will extend the `MODULEPATH`. E.g.: loading a compiler makes additional modules like openmpi and other libraries/packages compiled with this compiler available. - -If you try to load a module which is not available in the current `MODULEPATH` but installed in the module hierarchy, a message will be printed showing prerequisite modules. - -If you load a deprecated or unstable module, a warning will be printed. - -You can change the verbosity of the load sub-command by setting the environment variable `PMODULES_VERBOSITY` to silent, warn or verbose. - -silent:: Print error messages only. -warn:: Print a warning message, when loading a deprecated or unstable module. -verbose:: Print warning messages and print prerequisite modules if the module to load is not available, but installed in hierarchy. - - -== OPTIONS / FLAGS - -`-f | --force`:: Force active dependency resolution. This will result in modules found on a prereq command inside a module file being load automatically. Unloading module files using this switch will result in all required modules which have been loaded automatically using the -f switch being unload. This switch is experimental at the moment. - -`-v | --verbose`:: Set verbosity level to verbose. - -`-w | --warn`:: Set verbosity level to warn. - -`-s | --silent`:: Set verbosity level to silent. - -== EXAMPLES (add|load) - -Loading the modules `gcc/4.9.2`, `openmpi/1.8.4` and `hdf5/1.8.14`: - ------ -$ module load gcc/4.9.2 -$ module load openmpi/1.8.4 -$ module load hdf5/1.8.14 -$ module list -Currently Loaded Modulefiles: - 1) gcc/4.9.2 2) openmpi/1.8.4 3) hdf5/1.8.14 ------ - -or - ------ -$ module load gcc/4.9.2 openmpi/1.8.4 hdf5/1.8.14 ------ - -If you try to load `hdf5/1.8.14` without the prerequisite modules, some "hints" will be printed, if the default verbosity level is set: - ------ -$ module purge -$ module load hdf5/1.8.14 -The module 'hdf5/1.8.14' cannot be loaded! -Try with one of the following command(s): - -module load gcc/4.7.4 openmpi/1.6.5 hdf5/1.8.14 -module load gcc/4.7.4 openmpi/1.8.2 hdf5/1.8.14 -module load gcc/4.7.4 openmpi/1.8.4 hdf5/1.8.14 -module load gcc/4.8.3 openmpi/1.6.5 hdf5/1.8.14 -module use deprecated; module load gcc/4.8.3 openmpi/1.8.2 hdf5/1.8.14 -module use deprecated; module load gcc/4.8.3 openmpi/1.8.4 hdf5/1.8.14 -module load gcc/4.8.4 openmpi/1.6.5 hdf5/1.8.14 -module use deprecated; module load gcc/4.8.4 openmpi/1.8.2 hdf5/1.8.14 -module use deprecated; module load gcc/4.8.4 openmpi/1.8.4 hdf5/1.8.14 -module use deprecated; module load gcc/4.8.4 openmpi/1.8.8 hdf5/1.8.14 -module use deprecated; module load gcc/4.9.2 openmpi/1.6.5 hdf5/1.8.14 -module use deprecated; module load gcc/4.9.2 openmpi/1.8.2 hdf5/1.8.14 -module use deprecated; module load gcc/4.9.2 openmpi/1.8.4 hdf5/1.8.14 ------ - -Use verbosity level `warn` to suppress the hints: - ------ -$ module load hdf5/1.8.14 --warn -module load: module unavailable -- hdf5/1.8.14 ------ - -Loading an unstable module: - ------ -$ module use unstable -$ module load cmake/3.1.3 -Warning: the unstable module 'cmake/3.1.3' has been loaded. ------ - -To supress the warning, use the `--silent` option. - -== EXAMPLES (rm|unload) - ------ -$ module list -Currently Loaded Modulefiles: - 1) gcc/4.9.2 2) openmpi/1.8.4 3) hdf5/1.8.14 -$ module rm openmpi/1.8.4 -$ module list -Currently Loaded Modulefiles: - 1) gcc/4.9.2 ------ - -The module `hdf5/1.8.14` is unloaded as a dependency of `openmpi/1.8.4`. - -== SEE ALSO - -<>, <>, <>, <>, <> diff --git a/doc/src/The_module_command/module-purge.adoc b/doc/src/The_module_command/module-purge.adoc deleted file mode 100644 index 4444cb5..0000000 --- a/doc/src/The_module_command/module-purge.adoc +++ /dev/null @@ -1,32 +0,0 @@ -[id="module-purge",reftext="`module purge`"] -= Purge all loaded modules -== NAME - -`module purge` - purge all loaded modules - -== SYNOPSIS - -`module purge` - -== DESCRIPTION - -Unload all loaded module and reset everything to original state. - -== EXAMPLES - -List loaded modules: ------ -$ module list -Currently Loaded Modulefiles: - 1) gcc/4.8.3 2) openmpi/1.8.2 3) gnuplot/4.6.3 ------ -Now we purge everything and list the loaded modules again: ------ -$ module purge -$ module list -No Modulefiles Currently Loaded. ------ - -== SEE ALSO - -<>, <>, <> diff --git a/doc/src/The_module_command/module-refresh.adoc b/doc/src/The_module_command/module-refresh.adoc deleted file mode 100644 index e946b01..0000000 --- a/doc/src/The_module_command/module-refresh.adoc +++ /dev/null @@ -1,17 +0,0 @@ -[id="module-refresh",reftext="`module refresh`"] -= Refresh loaded modules -== NAME - -`module refresh` - refresh loaded modules - -== SYNOPSIS - -`module refresh` - -== DESCRIPTION - -Force a refresh of all non-persistent components of currently loaded modules. This should be used on derived shells where aliases need to be reinitialized but the environment variables have already been set by the currently loaded modules. - -== SEE ALSO - -<> diff --git a/doc/src/The_module_command/module-search.adoc b/doc/src/The_module_command/module-search.adoc deleted file mode 100644 index 753bc4b..0000000 --- a/doc/src/The_module_command/module-search.adoc +++ /dev/null @@ -1,71 +0,0 @@ -[id="module-search",reftext="`module search`"] -= Search modules -== NAME - -`module search` - search installed modules - -== SYNOPSIS - -`module search [switches] string...` - -== DESCRIPTION - -List all modules in the current `MODULEPATH` and the module hierarchy. If an argument is given, search for modules whose name match the argument. -Options - -== OPTIONS - -`--no-header`:: Suppress output of a header. - -`--release=RELEASE`:: Search for modules within this release. You can specify this switch multiple times. Without this switch, the used releases will be searched. - -`-a|--all-releases`:: -Search within all releases. - -`--with=STRING`:: -Search for modules compiled with modules matching string. The command. See example below. - -`--src=dir`:: -Search module hierarchy in dir. -Eine Textbeschreibung der Funktionsweise des Befehls oder der Funktion. (Üblicherweise jedoch nicht der Benutzung, siehe unten.) - -== EXAMPLES - -Get list of all installed GCC: -```shell -$ module search --all-releases gcc -Module Release Group Requires ------------------------------------------------------------- -gcc/4.7.4 stable Programming -gcc/4.8.2 stable Programming -gcc/4.8.3 stable Programming -gcc/4.8.4 stable Programming -gcc/4.8.5 stable Programming -gcc/4.9.2 stable Programming -gcc/4.9.3 stable Programming -gcc/4.9.4 stable Programming -gcc/5.1.0 deprecated Programming -gcc/5.2.0 deprecated Programming -gcc/5.3.0 stable Programming -gcc/5.4.0 stable Programming -gcc/6.1.0 stable Programming -gcc/6.2.0 stable Programming -gcc/6.3.0 stable Programming -gcc/6.4.0 stable Programming -gcc/7.1.0 stable Programming -gcc/7.2.0 stable Programming -``` - -Get list of all open-mpi versions compiled with GCC 5.4.0: -```shell -$ module search --all-releases openmpi --with=gcc/5.4.0 -Module Release Group Requires ------------------------------------------------------------- -openmpi/1.10.2 stable Compiler gcc/5.4.0 -openmpi/1.10.4 stable Compiler gcc/5.4.0 -openmpi/2.0.1 stable Compiler gcc/5.4.0 -``` - -== SEE ALSO - -<> diff --git a/doc/src/The_module_command/module-swap.adoc b/doc/src/The_module_command/module-swap.adoc deleted file mode 100644 index bf32024..0000000 --- a/doc/src/The_module_command/module-swap.adoc +++ /dev/null @@ -1,46 +0,0 @@ -[id="module-swap",reftext="`module swap`"] -= Swapping modules -== NAME - -`module swap|switch` - replace a loaded module by another - -== SYNOPSIS - -`module swap [modulefile1] modulefile2` + -`module switch [modulefile1] modulefile2` - -== DESCRIPTION - -Switch loaded `modulefile1` with `modulefile2`. If `modulefile1` is not specified, then it is assumed to be the currently loaded module with the same root name as `modulefile2`. - -== OPTIONS / FLAGS - -None - -== EXAMPLES - ------ -$ module load gcc/4.8.4 -$ module swap gcc/4.9.2 -$ module list -Currently Loaded Modulefiles: - 1) gcc/4.9.2 ------ - -== BUGS - -You can only swap between different version. The following commands are working (assuming that `gcc/4.8.2` is loaded): ------ -$ module swap gcc/4.9.2 -$ module swap gcc/4.9.2 gcc/5.4.0 ------ -The following command does *not* working as expected: ------ -$ module swap gcc/4.8.2 intel/15.0 ------ - -This command does not work with the Tcl implementation (environment variable `PMOUDLE_PURETCL` set). - -== SEE ALSO - -<>, <>, <> diff --git a/doc/src/The_module_command/module-use.adoc b/doc/src/The_module_command/module-use.adoc deleted file mode 100644 index e729e4b..0000000 --- a/doc/src/The_module_command/module-use.adoc +++ /dev/null @@ -1,114 +0,0 @@ -[id="module-use",reftext="`module use`"] -= Manipulate module path, used releases, groups or overlays -== NAME - -`module use|unuse` - manipulate module path, used releases or groups - -== SYNOPSIS - -`module use [OPTIONS] [string...]` - -`module unuse string...` - -== DESCRIPTION - -If called *without* arguments, print a summary about used groups, releases and additional directories in `MODULEPATH`. - -If string is a *directory*, append, prepend or remove this directory to/from `MODULEPATH`. - -If string is a *group name*, append, prepend or remove the corresponding directory to/from `MODULEPATH`. - -If string is a *releases name*, make all modules with this release available/unavailable. Known releases are; - -*stable*:: Modules released as stable are considered to be production ready. The files of a stable module will never change. - -*unstable*:: These modules are still unstable. They may not be ready for production use. The files of unstable modules may change to fix bugs or add functionality. Use at your own risk. - -*deprecated*:: Deprecated modules should not be used any more and may be removed without further notice. - -If string matches `flag=[-_a-zA-Z0-9]*` the RHS will be interpreted as use-flag. - -== OPTIONS / FLAGS - -`-a | --append`:: append directory or group to `MODULEPATH`. - -`-p | --prepend`:: prepend directory or group to `MODULEPATH`. - -== EXAMPLES - -*List used/unused groups, releases and additional directories in `MODULEPATH`:* ------ -$ module use -Used groups: - Tools - Programming - Compiler - -Unused groups: - Legacy - Libraries - System - -Used releases: - stable - unstable - -Unused releases: - deprecated - -Used flags: - omp - -Additonal directories in MODULEPATH: - none ------ -*Adding the 'System' group* ------ -$ module use System -$ module avail --------------------------------------------- System: -------------------------------------------- - -filebench/1.4.9.1 fsstress/1.0.0 nmap/6.46 patchelf/0.8.1 - --------------------------------------------- Tools: -------------------------------------------- - -ANSYS/18.2 emacs/24.4 git/2.3.3 global/6.3.1 gnuplot/4.6.3 gnuplot/5.0.0 -... - ------------------------------------------ Programming: ----------------------------------------- - -autoconf/2.69 automake/1.14 automake/1.15 binutils/2.25 cmake/2.8.12.2 cmake/3.1.3 -cmake/3.6.3 gcc/4.7.4 gcc/4.8.3 gcc/4.8.4 gcc/4.9.2 gcc/4.8.5 -... ------ -*Adding a directory to `MODULEPATH`* ------ -$ module use /afs/psi.ch/project/amas/modulefiles -$ module avail ------------------------------------ /afs/psi.ch/project/amas: ----------------------------------- - -H5hut_parallel-toolchain/2.0 H5hut_serial-toolchain/2.0 OPAL/1.6 OPAL/1.6.0rc5 -opal-toolschain/1.6 opal-toolschain/2.0 - --------------------------------------------- Tools: -------------------------------------------- - -ANSYS/18.2 emacs/24.4 git/2.3.3 global/6.3.1 gnuplot/4.6.3 gnuplot/5.0.0 -... ------------------------------------------ Programming: ----------------------------------------- - -autoconf/2.69 automake/1.14 automake/1.15 binutils/2.25 cmake/2.8.12.2 cmake/3.1.3 -cmake/3.6.3 gcc/4.7.4 gcc/4.8.3 gcc/4.8.4 gcc/4.9.2 gcc/4.8.5 -... ------ - ------ -$ module unuse /afs/psi.ch/project/amas/modulefiles -$ module unuse System -$ module unuse unstable ------ - -== SEE ALSO - -<>, <>, <> - - diff --git a/doc/src/The_module_command/module-whatis.adoc b/doc/src/The_module_command/module-whatis.adoc deleted file mode 100644 index 76f0f89..0000000 --- a/doc/src/The_module_command/module-whatis.adoc +++ /dev/null @@ -1,41 +0,0 @@ -[id="module-whatis",reftext="`module whatis|keyword`"] -= Show/search 'what is' information -== NAME - -`module whatis` - print one-line information about module -`module keyword|apropos` - search for keywords in 'whatis' - -== SYNOPSIS - -`module whatis [module...]` + -`module apropos string...` + -`module keyword string...` - -== DESCRIPTION - -`whatis`:: -Display the information set up by the `module-whatis` commands inside -the specified modulefile(s). If no modulefile is specified, all whatis -lines will be shown. - -`keyword|apropos`:: -Search through the 'whatis' informations of all modulefiles for the -specified string. All whatis informations matching the string will be -displayed. - -== EXAMPLES -Get whatis for all available Git modules - -```sh -$ module whatis git ------------ /opt/psi/Tools/modulefiles ------------- - git/2.3.3: distributed version control system - git/2.5.2: distributed version control system - git/2.8.1: distributed version control system - git/2.11.1: distributed version control system ------------ /opt/psi/Programming/modulefiles ------------- -``` - -== SEE ALSO - -<> diff --git a/doc/src/The_module_command/module.adoc b/doc/src/The_module_command/module.adoc deleted file mode 100644 index 8a1be2c..0000000 --- a/doc/src/The_module_command/module.adoc +++ /dev/null @@ -1,60 +0,0 @@ -[id="module-cmd",reftext="`module`"] -= `module` - using Pmodules - -:sectnums!: -== NAME - -`module` - command line interface to the Pmodules package - -== SYNOPSIS -`module [ switches ] [ sub-command ] [ sub-command-args ]` - -== DESCRIPTION -Environment Modules provide a convenient way to dynamically change the -users' environment through modulefiles. This includes easily adding or -removing directories to the `PATH` environment variable. -A modulefile contains the necessary information to allow a user to run -a particular application or provide access to a particular -library. All of this can be done dynamically without logging out and -back in. Modulefiles for applications modify the user’s shell -environment to make access easy. Modulefiles for Library packages -provide environment variables that specify where the library and -header files can be found. -Packages can be loaded and unloaded cleanly through the `module` command. - -Available sub-commands are: - -List available modules: <> - -Clear list of loaded modules: <> - -Display information about chances in environment when loaded: <> - -Print sub-command or module-specific help: <> - -Add or remove modules from shell’s initialization file: <> - -Search for keywords in 'whatis': <> - -List loaded modules: <> - -Load and unload modules: <> - -Purge all loaded modules: <> - -Refresh loaded modules: <> - -Search installed modules: <> - -Replace a loaded module by another: <> - -Manipulate module path, used releases, groups and overlays: <> - -Search for keywords in 'whatis': <> - -[NOTE] -===================================================================== -For the time being Pmodules supports bash, tcsh and zsh only. -===================================================================== - -:sectnums: \ No newline at end of file diff --git a/doc/src/overlays.adoc b/doc/src/overlays.adoc deleted file mode 100644 index cfc5923..0000000 --- a/doc/src/overlays.adoc +++ /dev/null @@ -1,3 +0,0 @@ -== Overlays - -TBW \ No newline at end of file From 7b502a32556fe66d919d2c10b0c4cdf17ffe9313 Mon Sep 17 00:00:00 2001 From: Achim Gsell Date: Thu, 13 Aug 2026 17:30:11 +0200 Subject: [PATCH 3/5] doc updated --- doc/src/Building_Pmodules.adoc | 20 -------------------- doc/src/Introduction.adoc | 17 +++-------------- doc/src/Tutorials.adoc | 17 ++++++----------- 3 files changed, 9 insertions(+), 45 deletions(-) diff --git a/doc/src/Building_Pmodules.adoc b/doc/src/Building_Pmodules.adoc index 4e5b646..3e48365 100644 --- a/doc/src/Building_Pmodules.adoc +++ b/doc/src/Building_Pmodules.adoc @@ -45,12 +45,6 @@ The module provides a 'Hello, world!' program. " ---- -.Example: configuration file `/opt/psi/Sandbox/modulefiles/HelloWorld/.release-1.0.0` for the `HelloWorld/1.0.0` module -[source,sh] ----- -unstable ----- - .Example: `/opt/psi/Sandbox/HelloWorld/1.0.0/bin/hello`: [source,sh] ---- @@ -81,18 +75,6 @@ source. The building plan of a module is coded in a so called *_build-block_*. A build-block consists at least of a build-script with instruction how to download, compile and install a dedicated piece of software, a modulefile and a configuration file. -To avoid problems with dependencies to system libraries or installed software it is best practice to build modules on dedicated systems. At PSI: - -* For modules which should be able to run on all RHEL7 and newer systems, use the system pmod7.psi.ch. If you need access to the system please contact achim.gsell@psi.ch. - -* Merlin6 specific modules - like `openmpi`, `mpich` and modules depending on them - must be compiled on a Merlin6 login node. - -* Modules specific for a beamline should be compiled on a Ra login node with RHEL8 or a dedicated RHEL8 beamline system. - -[NOTE] -==== -If you build a module on RHEL7, it might not run on RHEL8 due to newer versions of system libraries. In must cases this can be solved by installing these system libraries in the module itself and setting the `RPATH`. The recommended path in this case is `$PREFIX/lib/system` whereby `$PREFIX` is the installation prefix of the software. -==== In the next section we describe how to write build recipes. @@ -131,8 +113,6 @@ Since we use BASH for our build-scripts and Tcl for modulefiles, we use BASH/Tcl [id="building-modules", reftext="Building Pmodules"] == Building a Pmodule -To simplify the building of modules, Pmodules has a simple build system. The build system of Pmodules is far less powerful than the build system of Spack or NixOS, but fulfills its purpose for many modules. - Perform the following steps for a new Pmodule: 1. Create a directory with the name of the module. diff --git a/doc/src/Introduction.adoc b/doc/src/Introduction.adoc index 041bb0a..add3e30 100644 --- a/doc/src/Introduction.adoc +++ b/doc/src/Introduction.adoc @@ -1,18 +1,7 @@ = *INTRODUCTION* -Pmodules is the environment modules system at PSI. Since it uses AFS as storage backend it is an easy and convinient solution for software distribution. +Pmodules is the environment modules system at PSI. -It is available for all PSI supported Linux systems including +It is available on PSI's HPC systems Ra, Merlin7 and Merlin6 (and maybe on other systems too). -* login.psi.ch (llc.psi.ch) -* Merlin6 -* Ra - -A list of available modules and changes is avail https://pmodules.gitpages.psi.ch/Pmodules_tools/[*here*]. - -[NOTE] -===================================================================== -Some parts of this documentation has been copied from the documentation -of http://modules.sourceforge.net/[Environment Modules] and -https://www.tacc.utexas.edu/research-development/tacc-projects/lmod[Lmod]. -===================================================================== \ No newline at end of file +In this document we explain how to build modules for the Pmodules system. diff --git a/doc/src/Tutorials.adoc b/doc/src/Tutorials.adoc index 1781455..c186bcf 100644 --- a/doc/src/Tutorials.adoc +++ b/doc/src/Tutorials.adoc @@ -2,16 +2,6 @@ == Step-by-step guide to build a 'Hello, world!' module -[NOTE] -==== -This is for Pmodules 2.0 or newer! -==== - -[NOTE] -==== -For linting YAML files use the tool https://yamllint.readthedocs.io/en/stable/[`yamlint`] or an on-line linter like https://jsonformatter.org/yaml-validator[yaml-validator]. -==== - 1. Download a stub for a new build-block + [source,shell] @@ -60,6 +50,11 @@ hello_world: # <1> <8> Configuration for version 1.0.0. <9> Overwrite the default release stage. +[NOTE] +==== +For linting YAML files use the tool https://yamllint.readthedocs.io/en/stable/[`yamlint`] or an on-line linter like https://jsonformatter.org/yaml-validator[yaml-validator]. +==== + 1. Edit the build script + [source,shell] @@ -112,7 +107,7 @@ hello_world: [NOTE] ==== -To change the release stage the build-script must be called again: `./build 1.0.0` +To change the release stage run the build-script again: `./build 1.0.0` ==== == Add new version, build with autotools From 64345cddec00f09fa09f1e7ff6bbd2bcfbbe54a3 Mon Sep 17 00:00:00 2001 From: Achim Gsell Date: Sun, 16 Aug 2026 12:11:46 +0200 Subject: [PATCH 4/5] doc updated --- .gitignore | 1 + doc/html/Appendix.html | 547 -- doc/html/Building_Pmodules.html | 1201 +--- .../build-config-files/config_yaml.html | 563 +- .../build-config-files/variants.html | 2 +- .../functions/add_configure_args.html | 2 +- .../functions/add_patch.html | 2 +- .../functions/add_to_group.html | 23 +- .../functions/cmp_versions.html | 2 +- .../Building_Pmodules/functions/compile.html | 2 +- .../functions/compile_in_sourcetree.html | 60 - .../functions/configure.html | 2 +- .../Building_Pmodules/functions/install.html | 2 +- .../functions/install_docfile.html | 60 - .../Building_Pmodules/functions/prep.html | 2 +- .../functions/set_download_url.html | 23 +- .../functions/set_sha256sum.html | 58 - .../functions/supported_compilers.html | 60 - .../functions/supported_os.html | 2 +- .../functions/use_autotools.html | 2 +- .../functions/use_cmake.html | 2 +- doc/html/Building_Pmodules/modulefile.html | 480 -- .../runtime-config-files/module_config.html | 2 +- ...ing-build-scripts-for-binary-packages.html | 2 +- .../writing-build-scripts.html | 2 +- doc/html/Directory-structure.html | 212 - doc/html/Introduction.html | 37 +- doc/html/Motivation.html | 108 - doc/html/Nutshell.html | 618 -- doc/html/Overview.html | 52 - doc/html/The_module_command.html | 1225 ---- doc/html/The_module_command/module-avail.html | 122 - doc/html/The_module_command/module-clear.html | 97 - .../The_module_command/module-display.html | 106 - doc/html/The_module_command/module-help.html | 107 - .../The_module_command/module-initcmds.html | 107 - .../The_module_command/module-keyword.html | 78 - doc/html/The_module_command/module-list.html | 122 - doc/html/The_module_command/module-load.html | 207 - doc/html/The_module_command/module-purge.html | 86 - .../The_module_command/module-refresh.html | 61 - .../The_module_command/module-search.html | 138 - doc/html/The_module_command/module-swap.html | 109 - doc/html/The_module_command/module-use.html | 197 - .../The_module_command/module-whatis.html | 96 - doc/html/The_module_command/module.html | 119 - doc/html/Writing-a-modulefile.html | 136 - doc/html/build-block-files-and-hierarchy.html | 79 - doc/html/build-blocks-at-a-glance.html | 272 - doc/html/build-script-functions.html | 93 - doc/html/build-system/Building-a-Pmodule.html | 122 - .../build-system/Directory-structure.html | 212 - doc/html/build-system/Notations.html | 130 - .../build-system/Writing-a-modulefile.html | 136 - .../build-block-files-and-hierarchy.html | 79 - .../build-blocks-at-a-glance.html | 272 - .../build-config-files/config_yaml.html | 520 -- .../build-config-files/variants.html | 201 - .../build-system/build-script-functions.html | 93 - .../functions/add_configure_args.html | 67 - .../build-system/functions/add_patch.html | 62 - .../build-system/functions/add_to_group.html | 106 - doc/html/build-system/functions/compile.html | 89 - .../functions/compile_in_sourcetree.html | 60 - .../build-system/functions/configure.html | 176 - doc/html/build-system/functions/install.html | 71 - .../functions/install_docfile.html | 60 - doc/html/build-system/functions/prep.html | 94 - .../functions/set_download_url.html | 72 - .../build-system/functions/set_sha256sum.html | 58 - .../functions/supported_compilers.html | 60 - .../build-system/functions/supported_os.html | 50 - .../build-system/functions/use_autotools.html | 56 - .../build-system/functions/use_cmake.html | 56 - doc/html/build-system/make_all.html | 52 - doc/html/build-system/module-names.html | 122 - doc/html/build-system/modulefile.html | 480 -- doc/html/build-system/releases.html | 45 - .../runtime-config-files/module_config.html | 145 - .../build-system/site-specific-notes.html | 157 - ...writing-and-maintaining-variant-files.html | 154 - ...ing-build-scripts-for-binary-packages.html | 37 - .../build-system/writing-build-scripts.html | 272 - doc/html/build.html | 2199 ------- doc/html/index.html | 5598 ++++------------- doc/html/links.html | 6 +- doc/html/man1/module-avail.html | 122 - doc/html/man1/module-clear.html | 97 - doc/html/man1/module-display.html | 106 - doc/html/man1/module-help.html | 107 - doc/html/man1/module-initcmds.html | 107 - doc/html/man1/module-keyword.html | 78 - doc/html/man1/module-list.html | 122 - doc/html/man1/module-load.html | 207 - doc/html/man1/module-purge.html | 86 - doc/html/man1/module-refresh.html | 61 - doc/html/man1/module-search.html | 138 - doc/html/man1/module-swap.html | 109 - doc/html/man1/module-use.html | 197 - doc/html/man1/module-whatis.html | 96 - doc/html/man1/module.html | 119 - doc/html/man3/add_configure_args.html | 67 - doc/html/man3/add_patch.html | 62 - doc/html/man3/add_to_group.html | 106 - doc/html/man3/compile.html | 89 - doc/html/man3/compile_in_sourcetree.html | 60 - doc/html/man3/configure.html | 176 - doc/html/man3/install.html | 71 - doc/html/man3/install_docfile.html | 60 - doc/html/man3/prep.html | 94 - doc/html/man3/set_download_url.html | 72 - doc/html/man3/set_sha256sum.html | 58 - doc/html/man3/supported_compilers.html | 60 - doc/html/man3/supported_os.html | 50 - doc/html/man3/use_autotools.html | 56 - doc/html/man3/use_cmake.html | 56 - doc/html/man3/use_flag.html | 92 - doc/html/man4/module_config.html | 145 - doc/html/man4/modulefile.html | 480 -- doc/html/man5/config_yaml.html | 520 -- doc/html/man5/variants.html | 201 - doc/html/module-names.html | 122 - doc/html/overlays.html | 33 - doc/html/pbuild.html | 91 - doc/html/releases.html | 45 - doc/html/site-specific-notes.html | 157 - doc/html/use_flag.html | 92 - ...writing-and-maintaining-variant-files.html | 154 - .../build-config-files/config_yaml.adoc | 4 +- doc/src/Introduction.adoc | 4 +- doc/src/modubuild.adoc | 0 131 files changed, 1647 insertions(+), 23239 deletions(-) delete mode 100644 doc/html/Appendix.html delete mode 100644 doc/html/Building_Pmodules/functions/compile_in_sourcetree.html delete mode 100644 doc/html/Building_Pmodules/functions/install_docfile.html delete mode 100644 doc/html/Building_Pmodules/functions/set_sha256sum.html delete mode 100644 doc/html/Building_Pmodules/functions/supported_compilers.html delete mode 100644 doc/html/Building_Pmodules/modulefile.html delete mode 100644 doc/html/Directory-structure.html delete mode 100644 doc/html/Motivation.html delete mode 100644 doc/html/Nutshell.html delete mode 100644 doc/html/Overview.html delete mode 100644 doc/html/The_module_command.html delete mode 100644 doc/html/The_module_command/module-avail.html delete mode 100644 doc/html/The_module_command/module-clear.html delete mode 100644 doc/html/The_module_command/module-display.html delete mode 100644 doc/html/The_module_command/module-help.html delete mode 100644 doc/html/The_module_command/module-initcmds.html delete mode 100644 doc/html/The_module_command/module-keyword.html delete mode 100644 doc/html/The_module_command/module-list.html delete mode 100644 doc/html/The_module_command/module-load.html delete mode 100644 doc/html/The_module_command/module-purge.html delete mode 100644 doc/html/The_module_command/module-refresh.html delete mode 100644 doc/html/The_module_command/module-search.html delete mode 100644 doc/html/The_module_command/module-swap.html delete mode 100644 doc/html/The_module_command/module-use.html delete mode 100644 doc/html/The_module_command/module-whatis.html delete mode 100644 doc/html/The_module_command/module.html delete mode 100644 doc/html/Writing-a-modulefile.html delete mode 100644 doc/html/build-block-files-and-hierarchy.html delete mode 100644 doc/html/build-blocks-at-a-glance.html delete mode 100644 doc/html/build-script-functions.html delete mode 100644 doc/html/build-system/Building-a-Pmodule.html delete mode 100644 doc/html/build-system/Directory-structure.html delete mode 100644 doc/html/build-system/Notations.html delete mode 100644 doc/html/build-system/Writing-a-modulefile.html delete mode 100644 doc/html/build-system/build-block-files-and-hierarchy.html delete mode 100644 doc/html/build-system/build-blocks-at-a-glance.html delete mode 100644 doc/html/build-system/build-config-files/config_yaml.html delete mode 100644 doc/html/build-system/build-config-files/variants.html delete mode 100644 doc/html/build-system/build-script-functions.html delete mode 100644 doc/html/build-system/functions/add_configure_args.html delete mode 100644 doc/html/build-system/functions/add_patch.html delete mode 100644 doc/html/build-system/functions/add_to_group.html delete mode 100644 doc/html/build-system/functions/compile.html delete mode 100644 doc/html/build-system/functions/compile_in_sourcetree.html delete mode 100644 doc/html/build-system/functions/configure.html delete mode 100644 doc/html/build-system/functions/install.html delete mode 100644 doc/html/build-system/functions/install_docfile.html delete mode 100644 doc/html/build-system/functions/prep.html delete mode 100644 doc/html/build-system/functions/set_download_url.html delete mode 100644 doc/html/build-system/functions/set_sha256sum.html delete mode 100644 doc/html/build-system/functions/supported_compilers.html delete mode 100644 doc/html/build-system/functions/supported_os.html delete mode 100644 doc/html/build-system/functions/use_autotools.html delete mode 100644 doc/html/build-system/functions/use_cmake.html delete mode 100644 doc/html/build-system/make_all.html delete mode 100644 doc/html/build-system/module-names.html delete mode 100644 doc/html/build-system/modulefile.html delete mode 100644 doc/html/build-system/releases.html delete mode 100644 doc/html/build-system/runtime-config-files/module_config.html delete mode 100644 doc/html/build-system/site-specific-notes.html delete mode 100644 doc/html/build-system/writing-and-maintaining-variant-files.html delete mode 100644 doc/html/build-system/writing-build-scripts-for-binary-packages.html delete mode 100644 doc/html/build-system/writing-build-scripts.html delete mode 100644 doc/html/build.html delete mode 100644 doc/html/man1/module-avail.html delete mode 100644 doc/html/man1/module-clear.html delete mode 100644 doc/html/man1/module-display.html delete mode 100644 doc/html/man1/module-help.html delete mode 100644 doc/html/man1/module-initcmds.html delete mode 100644 doc/html/man1/module-keyword.html delete mode 100644 doc/html/man1/module-list.html delete mode 100644 doc/html/man1/module-load.html delete mode 100644 doc/html/man1/module-purge.html delete mode 100644 doc/html/man1/module-refresh.html delete mode 100644 doc/html/man1/module-search.html delete mode 100644 doc/html/man1/module-swap.html delete mode 100644 doc/html/man1/module-use.html delete mode 100644 doc/html/man1/module-whatis.html delete mode 100644 doc/html/man1/module.html delete mode 100644 doc/html/man3/add_configure_args.html delete mode 100644 doc/html/man3/add_patch.html delete mode 100644 doc/html/man3/add_to_group.html delete mode 100644 doc/html/man3/compile.html delete mode 100644 doc/html/man3/compile_in_sourcetree.html delete mode 100644 doc/html/man3/configure.html delete mode 100644 doc/html/man3/install.html delete mode 100644 doc/html/man3/install_docfile.html delete mode 100644 doc/html/man3/prep.html delete mode 100644 doc/html/man3/set_download_url.html delete mode 100644 doc/html/man3/set_sha256sum.html delete mode 100644 doc/html/man3/supported_compilers.html delete mode 100644 doc/html/man3/supported_os.html delete mode 100644 doc/html/man3/use_autotools.html delete mode 100644 doc/html/man3/use_cmake.html delete mode 100644 doc/html/man3/use_flag.html delete mode 100644 doc/html/man4/module_config.html delete mode 100644 doc/html/man4/modulefile.html delete mode 100644 doc/html/man5/config_yaml.html delete mode 100644 doc/html/man5/variants.html delete mode 100644 doc/html/module-names.html delete mode 100644 doc/html/overlays.html delete mode 100644 doc/html/pbuild.html delete mode 100644 doc/html/releases.html delete mode 100644 doc/html/site-specific-notes.html delete mode 100644 doc/html/use_flag.html delete mode 100644 doc/html/writing-and-maintaining-variant-files.html create mode 100644 doc/src/modubuild.adoc diff --git a/.gitignore b/.gitignore index bca2cd5..c43adba 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ pbuild.log +doc/html diff --git a/doc/html/Appendix.html b/doc/html/Appendix.html deleted file mode 100644 index e729acb..0000000 --- a/doc/html/Appendix.html +++ /dev/null @@ -1,547 +0,0 @@ - - - - - - - -"legacy" configuration files in Pmodules 1.0 - - - - - -
-
-

Appendix A: "legacy" configuration files in Pmodules 1.0

-
-
- - - - - -
- - -
-

These type of configuration file is deprecated in version 1.1 and -newer. Starting with version 1.2 the use of YAML configuration files -documented in the next section is recommended.

-
-
-
-
-

In the Pmodules 1.0 configuration files the following properties are -defined per version:

-
-
-
    -
  • -

    module name and version

    -
    • -
  • -

    release stage

    -
    • -
  • -

    dependencies

    -
    • -
-
-
-

Each definition must be on a single line.

-
-
-

Configuration filenames and search order

-
-

Configuration files are searched in the following order:

-
-
-
    -
  1. -

    build-recipe-dir/files/variants.system

    -
    2. -
  2. -

    build-recipe-dir/files/variants.OS

    -
    3. -
  3. -

    build-recipe-dir/files/variants

    -
    4. -
-
-
-

Whereby

-
-
-
-
system
-
-

If the build script is called with the option --system=sytem, this configuration file is used.

-
-
OS
-
-

Is the operating system/kernel name returned by uname --s. On Linux this is Linux on macOS this is Darwin.

-
-
-
-
-
-

Format

-
-

A line in a configuration file is either

-
-
-
    -
  • -

    a comment line starting with #

    -
    • -
  • -

    a empty line or a with white-space only

    -
    • -
  • -

    a definition of a variant

    -
    • -
-
-
-
-

Variant specifications

-
-

The form of a variant specification is

-
-
-

module-name release_stage dependencies

-
-
-

Whereby:

-
-
-
-
module-name
-
-

Is the name of the module including the version, an -optional release number and an optional suffix. The general form is

-
-

P/V[-V_RELEASE][_SUFFIX]

-
-
-
release_stage
-
-

Defines the release stage of this module -variant. Allowed values are unstable, stable, deprecated, -remove and removed. If the release stage is remove or removed, -this module variant will be removed (if not already removed).

-
-
dependencies
-
-

Defines the module dependencies. Dependencies can -be either a hierarchical dependency, a runtime dependency or a build -dependency. Hierarchical and runtime dependencies are loaded before -a module itself. Build dependencies are only loaded during build-time -and must be prefixed with b:.

-
-

Dependencies are loaded in the specified order. It is recommended to -specify the dependencies of a the (hierarchical) group first, then -additional modules required at run-time and the modules required to -build it at the end.

-
-
-

If the module is in a hierarchical group like MPI, you must specify -the modules required for this group. For modules in the group

-
-
-
    -
  • -

    Compiler a compiler must be specified.

    -
    • -
  • -

    MPI a compiler and a MPI implementation must be specified.

    -
    • -
  • -

    HDF5 a compiler, a MPI implementation and a parallel HDF5 module -must be specified.

    -
    • -
  • -

    HDF5_serial a compiler and a serial HDF5 module -must be specified.

    -
    • -
-
-
-
-
-
-
Example
-
-
parmetis/4.0.3  stable gcc/7.3.0 openmpi/3.0.0  b:cmake/3.6.3
-
-
-
-
-
-
-
-

Appendix B: Legacy build function (Pmodules version 1.0)

-
-
- - - - - -
- - -
-

These functions are deprecated in Pmodules 1.1 and newer!

-
-
-
-
-

Define the group of a module: pbuild::add_to_group

-
-

Synopsis

-
-
-
pbuild::add_to_group GROUP
-
-
-
-
-

Description

-
-

Define the group the module will be installed in. Sometimes it is not obvious in which group a module should go. If in doubt, Tools might be the best.

-
-
-

A (incomplete) list of available groups:

-
-
-
-
Tools
-
-

Group for tools like Gnuplot, Git, vim, Emacs, openssl. This group is visible by default.

-
-
Programming
-
-

Group for compilers, scripting languages and tools used for programming, like GCC, Python, CMake, autotools, Matlab. This group is visible by default.

-
-
Compiler
-
-

Hierarchical group for modules compiled with a certain compiler module. Examples: open-mpi, MPICH, serial HDF5.

-
-
HDF5_serial
-
-

Hierarchical group for modules compiled with a certain compiler and serial HDF5 module. Examples: netCDF, H5hut.

-
-
MPI
-
-

Hierarchical group for modules compiled with a certain compiler and MPI module. Examples: parallel Boost, parallel HDF5, ParMETIS, Gromacs.

-
-
HDF5
-
-

Hierarchical group for modules compiled with a certain compiler, MPI and parallel HDF5 module. Examples: netCDF, H5hut, Trilinos.

-
-
System
-
-

Group for system tools. This group is not visible by default. Examples: filebench, fsstress, nmap, patchelf.

-
-
Libraries
-
-

Group for libraries required to compile other modules but not providing (useful) tools. This group is not visible by default. Examples: GMP, MPC, MPFR

-
-
MX
-
-

Group for special tools used at the MX beam-line. This group is visible only on dedicated systems.

-
-
EM
-
-

Group for Ra specific software. This group is only visible and available on Ra.

-
-
-
-
-
-

Example

-
-
Example 1. Define the group for the Gnuplot module:
-
-
-
-
pbuild::add_to_group 'Tools'
-
-
-
-
-
-
-
-
-

Set download URL: pbuild::set_download_url

-
-

Synopsis

-
-
-
pbuild::set_download_url URL [fname]
-
-
-
-
-

Description

-
-

Tell the build system where to download the required (source-)files. If fname is passed, it will be used as the output file-name of the download.

-
-
-

In some cases software must be downloaded from a Git repository on Github, Bitbucket or Gitlab.

-
-
-

To download a certain tag/version from Github, Bitbucket or Gitlab use:

-
-
-
-
https://github.com/OWNER/PROJECT/archive/${V_PKG}/$P-${V_PKG}.tar.gz
-https://bitbucket.org/OWNER/PROJECT/get/${V_PKG}.tar.gz#/$P-%{V_PKG}.tar.gz
-https://gitlab.com/OWNER/PROJECT/-/archive/${V_PKG}/$P-${V_PKG}.tar.gz
-
-
-
-
-

Examples

-
-

Excerpt from Trilinos build-script:

-
-
-
-
pbuild::set_download_url \
-        "https://github.com/$P/$P/tarball/$P-release-${V//./-}" \
-        "$P-$V.tar.gz"
-
-
-
-
-

Compile in source tree: pbuild::compile_in_sourcetree (Pmodules 1.0)

-
-
Synopsis
-
-
-
pbuild::compile_in_sourcetree
-
-
-
-
-
Description
-
-

By default the build-system compiles software in a separate build-directory. This is not possible with all software. With the function pbuild::compile_in_sourcetree the build-directory is set to the source-directory.

-
-
-
-
Example
-
-
-
pbuild::compile_in_sourcetree
-
-
-
-
-
-
-

Set documentation files to be installed: pbuild::install_docfiles (Pmodules 1.0)

-
-
Synopsis
-
-
-
pbuild::install_docfiles fname...
-
-
-
-
-
Description
-
-

Install the passed files into $PREFIX/share/doc/$P. At least the file containing the license and copyright should be installed.

-
-
-
-
Example
-
-

Excerpt from parallel-netcdf build-script:

-
-
-
-
pbuild::add_docfiles 'AUTHORS' 'CREDITS'
-pbuild::add_docfiles 'COPYING' 'COPYRIGHT'
-pbuild::add_docfiles 'ChangeLog' 'NEWS'
-pbuild::add_docfiles 'RELEASE_NOTES'
-
-
-
-
-
-
-

Pass SHA256 hash sum to build-system: pbuild::set_sha256sum (Pmodules 1.0)

-
-
Synopsis
-
-
-
pbuild::set_sha256sum SHA256_HASH
-
-
-
-
-
Description
-
-

Tell the build-system which SHA256 hash sum a file must have. The format of the argument is file-name:hash-sum.

-
-
-
-
Examples
-
-

Excerpt from Trilinos build-script:

-
-
-
-
pbuild::set_sha256sum \
-	"trilinos-12.12.1.tar.gz:c8f2029fa36230b9f384c56139aaa33111227bcf653e73f7daf3c9efdecc1d2d"
-
-
-
-
-
-
-

Supported compilers: pbuild::set_supported_compilers (Pmodules 1.0)

-
-
Synopsis
-
-
-
pbuild::supported_compilers STRING...
-
-
-
-
-
Description
-
-

Set list of compiler which can be used to compile the module.

-
-
-
-
Example
-
-
-
pbuild::supported_compilers gcc clang
-
-
-
-
-
-
-

Set which OS are supported: pbuild::supported_systems (Pmodules 1.0)

-
-
Synopsis
-
-
-
pbuild::supported_system STRING...
-
-
-
-
-
Description
-
-

Some modules can be build only for dedicated operating systems. This is particularly the case for operating system specific tools like patchelf.

-
-
-
-
-
-

Forece use of autotools: pbuild::use_autotools (Pmodules 1.0)

-
-
Synopsis
-
-
-
pbuild::use_autotools
-
-
-
-
-
Description
-
-

Force the use of autotools.

-
-
-
-
-
-

Force use of CMake: pbuild::use_cmake

-
-
Synopsis
-
-
-
pbuild::use_cmake
-
-
-
-
-
Description
-
-

Force the use of CMake.

-
-
-
-
-
-
-
-

Appendix C: Links

-
-
-

Other implementation of environment module systems

-
- -
-
-
-

Articles

-
- -
-
-
-
-

Talks

-
- -
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/Building_Pmodules.html b/doc/html/Building_Pmodules.html index e3c27b6..7f52036 100644 --- a/doc/html/Building_Pmodules.html +++ b/doc/html/Building_Pmodules.html @@ -4,7 +4,7 @@ - + BUILDING PMODULES - - - - -
-
-
-
-
-
pbuild::compile_in_sourcetree
-
-
-
-
-
-

Description

-
-
-

By default the build-system compiles software in a separate build-directory. This is not possible with all software. With the function pbuild::compile_in_sourcetree the build-directory is set to the source-directory.

-
-
-
-
-

Example

-
-
-
-
pbuild::compile_in_sourcetree
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/Building_Pmodules/functions/configure.html b/doc/html/Building_Pmodules/functions/configure.html index c88ecd4..ada7d6b 100644 --- a/doc/html/Building_Pmodules/functions/configure.html +++ b/doc/html/Building_Pmodules/functions/configure.html @@ -4,7 +4,7 @@ - + Configure software: pbuild::configure - - - - -
-
-

Synopsis

-
-
-
-
pbuild::install_docfiles fname...
-
-
-
-
-
-

Description

-
-
-

Install the passed files into $PREFIX/share/doc/$P. At least the file containing the license and copyright should be installed.

-
-
-
-
-

Example

-
-
-

Excerpt from parallel-netcdf build-script:

-
-
-
-
pbuild::add_docfiles 'AUTHORS' 'CREDITS'
-pbuild::add_docfiles 'COPYING' 'COPYRIGHT'
-pbuild::add_docfiles 'ChangeLog' 'NEWS'
-pbuild::add_docfiles 'RELEASE_NOTES'
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/Building_Pmodules/functions/prep.html b/doc/html/Building_Pmodules/functions/prep.html index 5be8826..7440879 100644 --- a/doc/html/Building_Pmodules/functions/prep.html +++ b/doc/html/Building_Pmodules/functions/prep.html @@ -4,7 +4,7 @@ - + Download and unpack: pbuild::prep - - - - -
-
-

Synopsis

-
-
-
-
pbuild::set_sha256sum SHA256_HASH
-
-
-
-
-
-

Description

-
-
-

Tell the build-system which SHA256 hash sum a file must have. The format of the argument is file-name:hash-sum.

-
-
-
-
-

Examples

-
-
-

Excerpt from Trilinos build-script:

-
-
-
-
pbuild::set_sha256sum \
-	"trilinos-12.12.1.tar.gz:c8f2029fa36230b9f384c56139aaa33111227bcf653e73f7daf3c9efdecc1d2d"
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/Building_Pmodules/functions/supported_compilers.html b/doc/html/Building_Pmodules/functions/supported_compilers.html deleted file mode 100644 index ecba506..0000000 --- a/doc/html/Building_Pmodules/functions/supported_compilers.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - - -Supported compilers: pbuild::set_supported_compilers (Pmodules 1.0) - - - - - -
-
-
-
-
-
pbuild::supported_compilers STRING...
-
-
-
-
-
-

Description

-
-
-

Set list of compiler which can be used to compile the module.

-
-
-
-
-

Example

-
-
-
-
pbuild::supported_compilers gcc clang
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/Building_Pmodules/functions/supported_os.html b/doc/html/Building_Pmodules/functions/supported_os.html index 2ec436c..7a2667b 100644 --- a/doc/html/Building_Pmodules/functions/supported_os.html +++ b/doc/html/Building_Pmodules/functions/supported_os.html @@ -4,7 +4,7 @@ - + Set which OS are supported: pbuild::supported_systems (Pmodules 1.0) - - - - -
-
-

NAME

-
-
-

modulefile - files containing Tcl code for the Modules package

-
-
-
-
-

DESCRIPTION

-
-
-

modulefiles are written in the Tool Command Language, Tcl(n) and are -interpreted by the modulecmd program via the module(1) user -interface. modulefiles can be loaded, unloaded, or switched on-the-fly -while the user is working; and can be used to implement site policies -regarding the access and use of applications.

-
-
-

A modulefile begins with the shebang, ‘#%Pmodule’ or -‘#%Module’. The shebang ‘#%Pmodule’ should be used in modulefiles -using the Pmodules extension. A version number may be placed after -this string. The version number is useful as the modulefile format may -change. If a version number doesn’t exist, then modulecmd will assume -the modulefile is compatible with the latest version. The current -modulefile version is 1.0. Files without the magic cookie will not be -interpreted by modulecmd.

-
-
-

Each modulefile contains the changes to a user’s environment needed to -access an application. Tcl is a simple programming language which -permits modulefiles to be arbitrarily complex, depending upon the -application’s and the modulefile writer’s needs.

-
-
-

A typical modulefiles is a simple bit of code that set or add entries -to the PATH, MANPATH, or other environment variables. Tcl has -conditional statements that are evaluated when the modulefile is -loaded. This is very effective for managing path or environment -changes due to different OS releases or architectures. The user -environment information is encapsulated into a single modulefile kept -in a central location. The same modulefile is used by every user on -any machine. So, from the user’s perspective, starting an application -is exactly the same irrespective of the machine or platform they are -on.

-
-
-

modulefiles also hide the notion of different types of shells. From -the user’s perspective, changing the environment for one shell looks -exactly the same as changing the environment for another shell. This -is useful for new or novice users and eliminates the need for -statements such as "if you’re using the C Shell do this …​, otherwise -if you’re using the Bourne shell do this …​". Announcing and -accessing new software is uniform and independent of the user’s -shell. From the modulefile writer’s perspective, this means one set of -information will take care of every type of shell.

-
-
-

Module specific commands

-
-

The Pmodules Package uses commands which are extensions to the "standard" Tool Command Language Tcl(n) package.

-
-
- - - - - -
- - -
-

The following commands are Pmodules extensions:

-
-
-
    -
  • -

    module-addgroup

    -
    • -
  • -

    module-url

    -
    • -
  • -

    module-license

    -
    • -
  • -

    module-maintainer

    -
    • -
-
-
-
-
-

Unless otherwise specified, the Module commands return the empty string. Some commands behave differently when a modulefile is loaded or unloaded. The command descriptions assume the modulefile is being loaded.

-
-
-
-
break
-
-

This is not a Modules-specific command, it’s actually part of Tcl, which has been overloaded similar to the continue and exit commands to have the effect of causing the module not to be listed as loaded and not affect other modules being loaded concurrently. All non-environment commands within the module will be performed up to this point and processing will continue on to the next module on the command line. The break command will only have this effect if not used within a Tcl loop though.

-
-

An example: Suppose that a full selection of modulefiles are needed for various different architectures, but some of the modulefiles are not needed and the user should be alerted. Having the unnecessary modulefile be a link to the following notavail modulefile will perform the task as required.

-
-
-
-
#%Module1.0
-## notavail modulefile
-##
-proc ModulesHelp { } {
-            puts stderr "This module does nothing but alert the user"
-            puts stderr "that the [module-info name] module is not available"
-}
-
-module-whatis "Notifies user that module is not available."
-set curMod [module-info name]
-if { [ module-info mode load ] } {
-            puts stderr "Note: '$curMod' is not available for [uname sysname]."
-}
-break
-
-
-
-
chdir directory
-
-

Set the current working directory to directory.

-
-
continue
-
-

This is not a modules specific command but another overloaded Tcl command and is similar to the break or exit commands except the module will be listed as loaded as well as performing any environment or Tcl commands up to this point and then continuing on to the next module on the command line. The continue command will only have this effect if not used within a Tcl loop though.

-
-
exit [N]
-
-

This is not a modules specific command but another overloaded Tcl command and is similar to the break or continue commands. However, this command will cause the immediate cessation of this module and any additional ones on the command line. This module and the subsequent modules will not be listed as loaded. No environment commands will be performed in the current module.

-
-
setenv variable value
-
-

Set environment variable to value. The setenv command will also change the process' environment. A reference using Tcl’s env associative array will reference changes made with the setenv command. Changes made using Tcl’s env associative array will NOT change the user’s environment variable like the setenv command. An environment change made this way will only affect the module parsing process. The setenv command is also useful for changing the environment prior to the exec or system command. When a modulefile is unloaded, setenv becomes unsetenv. If the environment variable had been defined it will be overwritten while loading the modulefile. A subsequent unload will unset the environment variable - the previous value cannot be restored! (Unless you handle it explicitly …​ see below.)

-
-
unsetenv variable [value]
-
-

Unsets environment variable. However, if there is an optional value, then when unloading a module, it will set variable to value. The unsetenv command changes the process' environment like setenv.

-
-
append-path|prepend-path [-d C|--delim C|--delim=C] variable value
-
-

Append or prepend value to environment variable. The variable is a colon, or delimiter, separated list such as PATH=directory:directory:directory. The default delimiter is a colon ':', but an arbitrary one can be given by the --delim option. For example a space can be used instead (which will need to be handled in the Tcl specially by enclosing it in " " or { }). A space, however, can not be specified by the --delim=C form.

-
-

If the variable is not set, it is created. When a modulefile is unloaded, append-path and prepend-path become remove-path.

-
-
-
remove-path [-d C|--delim C|--delim=C] variable value
-
-

Remove value from the colon, or delimiter, separated list in variable. See prepend-path or append-path for further explanation of using an arbitrary delimiter. Every string between colons, or delimiters, in variable is compared to value. If the two match, value is removed from variable.

-
-
prereq|conflict modulefile…​
-
-

prereq and conflict control whether or not the modulefile will be loaded. The prereq command lists modulefiles which must have been previously loaded before the current modulefile will be loaded. Similarly, the conflict command lists modulefiles which conflict with the current modulefile. If a list contains more than one modulefile, then each member of the list acts as a Boolean OR operation. Multiple prereq and conflict commands may be used to create a Boolean AND operation. If one of the requirements have not been satisfied, an error is reported and the current modulefile makes no changes to the user’s environment.

-
-
-
-
-

If an argument for prereq is a directory and any modulefile from the directory has been loaded, then the prerequisite is met. For example, specifying X11 as a prereq means that any version of X11, X11/R4 or X11/R5, must be loaded before proceeding.

-
-
-

If an argument for conflict is a directory and any other modulefile from that directory has been loaded, then a conflict will occur. For example, specifying X11 as a conflict will stop X11/R4 and X11/R5 from being loaded at the same time.

-
-
-
-
is-loaded modulefile…​
-
-

The is-loaded command returns a true value if any of the listed modulefiles has been loaded. If a list contains more than one modulefile, then each member acts as a boolean OR operation. If an argument for is-loaded is a directory and any modulefile from the directory has been loaded is-loaded would return a true value.

-
-
module [sub-command] [sub-command-args]
-
-

Contains the same sub-commands as described in the module(1) man page in the Module Sub-Commands section. This command permits a modulefile to load or unload other modulefiles. No checks are made to ensure that the modulefile does not try to load itself. Often it is useful to have a single modulefile that performs a number of module load commands. For example, if every user on the system requires a basic set of applications loaded, then a core modulefile would contain the necessary -module load commands.

-
-
module-info mode [modetype]
-
-

Returns the current modulecmd’s mode as a string if no modetype is given.

-
-

Returns 1 if modulecmd’s mode is modetype. modetype can be: load, unload, remove, switch, display, help, test or whatis.

-
-
-
module-info name
-
-

Return the name of the modulefile. This is not the full pathname for modulefile. See the Modules Variables section for information on the full pathname.

-
-
module-info specified
-
-

Return the name of the modulefile specified on the command line.

-
-
module-info shell [shellname]
-
-

Return the current shell under which modulecmd.tcl was invoked if no shellname is given. The current shell is the first parameter of modulecmd.tcl, which is normally hidden by the module alias.

-
-

If a shellname is given, returns 1 if modulecmd.tcl’s current shell is shellname, returns 0 elsewhere. shellname can be: sh, bash, ksh, zsh, csh, tcsh, fish, tcl, perl, python, ruby, lisp, cmake, r.

-
-
-
module-info shelltype [shelltypename]
-
-

Return the family of the shell under which modulefile was invoked if no shelltypename is given. As of module-info shell this depends on the first parameter of modulecmd.tcl. The output reflects a shell type determining the shell syntax of the commands produced by modulecmd.tcl.

-
-

If a shelltypename is given, returns 1 if modulecmd.tcl’s current shell type is shelltypename, returns 0 elsewhere. shelltypename can be: sh, csh, fish, tcl, perl, python, ruby, lisp, cmake, r.

-
-
-
module-info alias name
-
-

Returns the full modulefile name to which the modulefile alias name is assigned

-
-
module-info version modulefile
-
-

Returns the physical module name and version of the passed symbolic version modulefile. The parameter modulefile might either be a full qualified modulefile with name and version, another symbolic modulefile name or a modulefile alias.

-
-
module-info symbols modulefile
-
-

Returns a list of all symbolic versions assigned to the passed modulefile. The parameter modulefile might either be a full qualified modulefile with name and version, another symbolic modulefile name or a modulefile alias.

-
-
module-version modulefile version-name…​
-
-

Assigns the symbolic version-name to the modulefile. This command should be placed in one of the modulecmd.tcl rc files in order to provide shorthand invocations of frequently used modulefile names.

-
-

The special version-name default specifies the default version to be used for module commands, if no specific version is given. This replaces the definitions made in the .version file in former modulecmd releases.

-
-
-

The parameter modulefile may be either -* a fully or partially qualified modulefile with name / version. If name is '.' then the current directory name is assumed to be the module name. (Use this for deep modulefile directories.) -* a symbolic modulefile name -* another modulefile alias

-
-
-
module-alias name modulefile
-
-

Assigns the modulefile to the alias name. This command should be placed in one of the modulecmd rc files in order to provide shorthand invocations of frequently used modulefile names.

-
-

The parameter modulefile may be either

-
-
-
    -
  • -

    a fully qualified modulefile with name and version

    -
    • -
  • -

    a symbolic modulefile name

    -
    • -
  • -

    another modulefile alias

    -
    • -
-
-
-
module-whatis string
-
-

Defines a string which is displayed in case of the invocation of the module whatis command. There may be more than one module-whatis line in a modulefile. This command takes no actions in case of load, display, etc. invocations of modulecmd.

-
-

The string parameter has to be enclosed in double-quotes if there’s more than one word specified. Words are defined to be separated by white-space characters (space, tab, cr).

-
-
-
module-url url
-
-

Sets an URL which is displayed in case of the invocation of the module help command. The URL should point to the home-page of the software loaded by the module if any.

-
-
module-license string
-
-

Defines a string which is displayed in case of the invocation of the module help command. The string should either be the name of a well known license (like GPL V2) or a filename with the license text installed in the module.

-
-
module-maintainer email
-
-

Defines a string which is displayed in case of the invocation of the module help command. The -string should be the email address of the module maintainer.

-
-
module-addgroup group
-
-

Add the hierarchical group group to MODULEPATH.

-
-
set-alias alias-name alias-string
-
-

Sets an alias or function with the name alias-name in the user’s environment to the string alias-string. For some shells, aliases are not possible and the command has no effect. When a modulefile is unloaded, set-alias becomes unset-alias.

-
-
unset-alias alias-name
-
-

Unsets an alias with the name alias-name in the user’s environment.

-
-
system string
-
-

Pass string to the Tcl built-in command exec(n). For the exec(n) call modulecmd redirects stdout to stderr since stdout would be parsed by the evaluating shell. The exit status of the executed command is returned.

-
-
uname field
-
-

Provide lookup of system information. Most field information are retrieved from the tcl_platform array (see tclvars(n) man page). Uname will return the string "unknown" if information is unavailable for the field.

-
-

uname will invoke uname(1) command in order to get the operating system version and domainname(1) to figure out the name of the domain.

-
-
-

field values are: -* sysname: the operating system name -* nodename: the hostname -* domain: the name of the domain -* release: the operating system release -* version: the operating system version -* machine: a standard name that identifies the system’s hardware

-
-
-
x-resource [resource-string|filename]
-
-

Merge resources into the X11 resource database. The resources are used to control look and behavior of X11 applications. The command will attempt to read resources from filename. If the argument isn’t a valid file name, then string will be interpreted as a resource. Either filename or resource-string is then passed down to be xrdb(1) command.

-
-

modulefiles that use this command, should in most cases contain one or more x-resource lines, each defining one X11 resource. The DISPLAY environment variable should be properly set and the X11 server should be accessible. If x-resource can’t manipulate the X11 resource database, the modulefile will exit with an error message.

-
-
-

Examples:

-
-
-
-
-
-
-
x-resource /u2/staff/leif/.xres/Ileaf
-
-
-
-

The content of the Ileaf file is merged into the X11 resource database.

-
-
-
-
x-resource [glob ~/.xres/ileaf]
-
-
-
-

The Tcl glob function is used to have the modulefile read different resource files for different users.

-
-
-
-
x-resource {Ileaf.popup.saveUnder: True}
-
-
-
-

Merge the Ileaf resource into the X11 resource database.

-
-
-
-

Modules Variables

-
-

The ModulesCurrentModulefile variable contains the full pathname of the modulefile being interpreted.

-
-
-
-

Locating Modulefiles

-
-

Every directory in MODULEPATH is searched to find the modulefile. A directory in MODULEPATH can have an arbitrary number of sub-directories. If the user names a modulefile to be loaded which is actually a directory, the directory is opened and a search begins for an actual modulefile. First, modulecmd looks for a file with the name .modulerc in the directory. If this file exists, its contents will be evaluated as if it was a modulefile to be loaded. You may place module-version and module-alias commands inside this file.

-
-
-

Additionally, before seeking for .modulerc files in the module directory, the global modulerc file is sourced, too. If a named version default now exists for the modulefile to be loaded, the assigned modulefile now will be sourced. Otherwise the file .version is looked up in the directory.

-
-
-

If the .version file exists, it is opened and interpreted as Tcl code and takes precedence over a .modulerc file in the same directory. If the Tcl variable ModulesVersion is set by the .version file, modulecmd will use the name as if it specifies a modulefile in the directory. This will become the default modulefile in this case.

-
-
-

If ModulesVersion is a directory, the search begins anew down that directory. If the name does not match any files located in the current directory, the search continues through the remaining directories in MODULEPATH.

-
-
-

Every .version and .modulerc file found is Tcl interpreted. The difference is that .version only applies to the current directory, and the .modulerc applies to the current directory and all subdirectories. Changes made in these files will affect the subsequently interpreted modulefile.

-
-
-

If no default version may be figured out, then the highest numerically sorted modulefile or module alias under the directory will be used. The dictionary comparison method of the lsort(n) Tcl command is used to achieve this sort. If highest numerically sorted element is an alias, search continues on its modulefile target.

-
-
-

For example, it is possible for a user to have a directory named X11 which simply contains a .version file specifying which version of X11 is to be loaded. Such a file would look like:

-
-
-
-
#%Module1.0
-##
-##  The desired version of X11
-##
-set ModulesVersion "R4"
-
-
-
-

The equivalent .modulerc would look like:

-
-
-
-
#%Module1.0
-##
-##  The desired version of X11
-##
-module-version "./R4" default
-
-
-
-

If user names a modulefile that cannot be found in the first modulepath directory, modulefile will be searched in next modulepath directory and so on until a matching modulefile is found. If search goes through a module alias or a symbolic version, this alias or symbol is resolved by first looking at the modulefiles in the modulepath where this alias or symbol is defined. If not found, resolution looks at the other modulepaths in their definition order.

-
-
-

When locating modulefiles, if a .modulerc, a .version, a directory or a modulefile cannot be read during the search it is simply ignored with no error message produced. Visibility of modulefiles can thus be adapted to the rights the user has been granted. Exception is made when trying to directly access a directory or a modulefile. In this case, the access issue is returned as an error message.

-
-
-

A modulefile whose name or element in its name starts with a '.' dot is considered hidden. Hidden modulefile is not displayed or taken into account except if it is explicitly named. By inheritance, a symbolic version-name assigned to a hidden modulefile is displayed or taken into account only if explicitly named. Module alias targeting a hidden modulefile appears like any other module alias.

-
-
-
-

Modulefile Specific Help

-
-

Users can request help about a specific modulefile through the module(1) command. The modulefile can print helpful information or start help oriented programs by defining a ModulesHelp subroutine. The subroutine will be called when the module help modulefile command is used.

-
-
-
-

Modulefile Specific Test

-
-

Users can request test of a specific modulefile through the module(1) command. The modulefile can perform some sanity checks on its definition or on its underlying programs by defining a ModulesTest subroutine. The subroutine will be called when the module test modulefile command is used. The subroutine should return 1 in case of success. If no or any other value is returned, test is considered failed.

-
-
-
-

Modulefile Display

-
-

The module display modulefile command will detail all changes that will be made to the environment. After displaying all of the environment changes modulecmd.tcl will call the ModulesDisplay subroutine. The ModulesDisplay subroutine is a good place to put additional descriptive information about the modulefile.

-
-
-
-
-
-

ENVIRONMENT

-
-
-
-
MODULEPATH
-
-

Path of directories containing modulefiles.

-
-
-
-
-
-
-

SEE ALSO

-
-
-

module(1), Tcl(n), TclX(n), xrdb(1), exec(n), uname(1), domainname(1), tclvars(n), lsort(n)

-
-
-
-
-

NOTES

-
-
-

Tcl was developed by John Ousterhout at the University of California at Berkeley.

-
-
-

TclX was developed by Karl Lehenbauer and Mark Diekhans.

-
-
-

Modules is covered by the GNU General Public License, version 2 and the GNU Lesser General Public License, version 2.1. Copyright © 1996-1999 John L. Furlani & Peter W. Osel, © 1998-2017 R.K.Owen, © 2002-2004 Mark Lakata, © 2004-2017 Kent Mein, © 2016-2017 Xavier Delaruelle. All rights reserved. Trademarks used are the property of their respective owners.

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/Building_Pmodules/runtime-config-files/module_config.html b/doc/html/Building_Pmodules/runtime-config-files/module_config.html index 4d33df8..baab90f 100644 --- a/doc/html/Building_Pmodules/runtime-config-files/module_config.html +++ b/doc/html/Building_Pmodules/runtime-config-files/module_config.html @@ -4,7 +4,7 @@ - + Pmodules 1.0: .release-version - - - - -
-
-

Introduction

-
-

The Pmodules environment organize modules in groups. Groups are either simple or hierarchical. Modules in a simple group has no or only simple dependencies. Modules in a hierarchical group always have at least one hierarchical (run-time)dependency. See the following examples to get the idea of simple and hierarchical groups and dependencies.

-
-
-
Example 1. Hierarchical groups and dependencies
-
-
-

The module openmpi/3.1.2 is in the group Compiler. Before this module can be loaded, a compiler must loaded, for example gcc/7.3.0. The group Compiler is a hierarchical group because multiple variants of the same modules in this group exist for different compilers. In this example openmpi/3.1.2 have been compiled with gcc/6.4.0, gcc/7.3.0…​ As a consequence you have to select and load a compiler before you can load the modules in this group.

-
-
-
-
-
Example 2. Simple groups
-
-
-

The module gcc/7.3.0 is in the group Programming. This group is simple. There is no need for several variants of this modules.

-
-
-
-
-
Example 3. Simple dependencies
-
-
-

The module git/2.16.2 is in the simple group Tools. Git requires Tcl/Tk for the gui-subcommand. Simple dependencies must be loaded in the modulefile or better specified in the build-block. If specified in the build-block, they are loaded are loaded automatically.

-
-
-
-
-

In this chapter we use several variables used in build-blocks and/or modulefiles. Please read this chapter for details.

-
-
-
-

File hierarchy of a simple group

-
-
-
$PMODULES_ROOT/$GROUP
-
-

container for $GROUP.

-
-
$PMODULES_ROOT/$GROUP/modulefiles/$P/$V
-
-

modulefile for $P/$V.

-
-
$PMODULES_ROOT/$GROUP/modulefiles/$P/.release-$V
-
-

release of module $P/$V.

-
-
$PMODULES_ROOT/$GROUP/$P/$V
-
-

prefix for module $P/$V.

-
-
-
-
-
-

File hierarchy of the hierarchical group Compiler

-
-
-
$PMODULES_ROOT/Compiler
-
-

container for group Compiler

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$P/$V
-
-

modulefile for $P/$V.

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$P/.release-$V
-
-

release of module $P/$V.

-
-
…​/$P/$V/$COMPILER/$COMPILER_VERSION
-
-

prefix for module $P/$V.

-
-
-
-
-
-

File hierarchy of the hierarchical group MPI

-
-
-
$PMODULES_ROOT/MPI
-
-

container for group MPI.

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$MPI/$MPI_VERSION/$P/$V
-
-

modulefile for $P/$V.

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$MPI/$MPI_VERSION/$P/.release-$V
-
-

release of module $P/$V.

-
-
…​/$P/$V/$MPI/$MPI_VERSION/$COMPILER/$COMPILER_VERSION
-
-

prefix for module $P/$V.

-
-
-
-
-
-

File hierarchy of the hierarchical group HDF5

-
-
-
$PMODULES_ROOT/HDF5
-
-

container for group MPI.

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$MPI/$MPI_VERSION/hdf5/$HDF5_VERSION/$P/$V
-
-

modulefile for $P/$V.

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$MPI/$MPI_VERSION/hdf5/$HDF5_VERSION/$P/.release-$V
-
-

release of module $P/$V.

-
-
…​/$P/$V/hdf5/$HDF5_VERSION/$MPI/$MPI_VERSION/$COMPILER/$COMPILER_VERSION
-
-

prefix for module $P/$V.

-
-
-
-
-
-

File hierarchy inside a module

-
-

The file hierarchy defined in the Linux File Hierarchy Standard should be used. In the following we document only Pmodules special features:

-
-
-
-
$PREFIX
-
-

Prefix of the module.

-
-
$PREFIX/.dependencies
-
-

Run-time dependencies, loaded automatically

-
-
$PREFIX/{bin,sbin}
-
-

If exists, added to PATH while loading.

-
-
$PREFIX/include
-
-

If exists, added to C_INCLUDE_PATH and CPLUS_INCLUDE_PATH while loading.

-
-
$PREFIX/{lib,lib64}
-
-

If exists, added to LIBRARY_PATH and LD_LIBRARY_PATH while loading

-
-
$PREFIX/lib/cmake
-
-

If exist, added to CMAKE_MODULE_PATH while loading

-
-
$PREFIX/lib/pkgconfig
-
-

If exist, added to PKG_CONFIG_PATH while loading

-
-
$PREFIX/share/man
-
-

If exists, added to MANPATH while loading.

-
-
$PREFIX/share/Pmoudles/$GROUP/$P
-
-

Build-block used to build this module

-
-
$PREFIX/share/Pmoudles/$GROUP/$P/build
-
-

Build-script

-
-
$PPREFIX/share/Pmoudles/$GROUP/$P/dependencies
-
-

All dependencies loaded while building. This includes build- and run-time dependencies.

-
-
$PREFIX/share/Pmoudles/$GROUP/$P/files/variants
-
-

Used variants-file.

-
-
$PREFIX/share/Pmoudles/$GROUP/$P/modulefile
-
-

Used Modulefile.

-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/Introduction.html b/doc/html/Introduction.html index 3fcb491..b4d0d95 100644 --- a/doc/html/Introduction.html +++ b/doc/html/Introduction.html @@ -4,7 +4,7 @@ - + INTRODUCTION - - - - -
-
-

MOTIVATION

-
-
-

Environment module systems provide a solution for the dynamic -modification of a user’s environment by loading special files named -'modulefiles'.

-
-
-

Each modulefile contains the information needed to configure the shell -for an application or library. The environment can be modified on a -per-module basis using the module command which interprets -modulefiles. Typically modulefiles instruct the module command to -alter or set shell environment variables such as PATH, MANPATH -etc. modulefiles may be shared by many users on a system and users may -have their own collection to supplement or replace the shared -modulefiles.

-
-
-

Environment module systems are widely used on HPC systems to provide -multiple compilers and multiple versions of the same library or API -implementations to the users. The -Environment Modules system is the -most widely used implementation. Another - more recent - -implementation is -Lmod. Lmod -addresses some weaknesses of the Environment Modules, but solves only -some of them.

-
-
-

One issue with the Environment Modules is the flat naming scheme. The -Lmod system and Pmodules solves the problem by organizing the modules -hierarchically. What is the problem with a flat naming scheme? Provide -different versions of the same library, like openmpi 1.6.5/1.8.4, -compiled with different (versions) of compilers, like gcc -4.7.4/4.8.4/4.9.2 and Intel 14.0.2/15.2, the number of modules is -growing quite fast. Providing dozens of libraries will end up in -hundreds of modules - not very clear to the users.

-
-
-

Neither Environment Modules nor Lmod have build-in support for phasing -out modules or marking modules as unstable. Pmodules solves this -problem by introducing 'releases' like stable, unstable and -deprecated. A user will be warned while loading a non-stable module.

-
-
-

With Environment Modules and Lmod everything must be coded in the -modulefile - even things which are obvious. If a bin directory -exists, why not adding this directory to the PATH variable -automatically? The same can be done for MANPATH, LD_LIBRARY_PATH -and other environment variables.

-
-
-

Usually modules are installed on a network file-systems. In some cases -it is convenient or even required to install modules locally. Pmodules -provides a tool to install all or a sub-set of the modules from any -location to another location.

-
-
-

Pmodules has its own (simple) build environment. For a new module you -have to write a build script and a modulefile. Updating an existing -modules is very simple. In most cases it’s downloading the new version -and calling the build script. Anyway, nobody forces you to use this -build environment, but in most cases it is very handy.

-
-
- - - - - -
- - -
-

Some parts of this documentation has been copied from the documentation -of Environment Modules and -Lmod.

-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/Nutshell.html b/doc/html/Nutshell.html deleted file mode 100644 index 4f5f26f..0000000 --- a/doc/html/Nutshell.html +++ /dev/null @@ -1,618 +0,0 @@ - - - - - - - -PMODULES IN A NUTSHELL - - - - - -
-
-
-
-

Before reading this section you should be familiar with an environment module system - either Environment Modules or Lmod.

-
-
-

Pmodules organizes modules in groups like Tools, Programming, Libraries, System etc. for a clear arrangement. Groups of modules can easily be added to the available modules. Read section Module groups for more details about module groups.

-
-
-

One issue with Environment Modules is the flat naming scheme. Pmodules and Lmod solves the issue by organizing the modules hierarchically. Providing modules for a toolkit like parallel HDF5 ends up in dozen of modules. One user wants to use GCC 4.8.4 and OpenMPI 1.6.5 another Intel C 15 and MPICH 3.1.4, a third user requires GCC 4.9.2 with MPICH 3.1.4. After a couple of month, some users want new versions. In a flat naming scheme you see all installed versions, even if you just want to see what is available for particular compiler. The solution to this problem is a hierarchical organization of the modules. In section Module hierarchies we describe how to load and search for modules in a module hierarchy.

-
-
-

Neither Lmod nor Environment Modules provides something like a life cycle management. A module is either available or not. There is no way to inform the users, whether a module is still unstable or already deprecated. Pmodules solves this problem by introducing releases like unstable, stable and deprecated. In section Module lifecycle we explain what this means to the user.

-
-
-
-
-
-

Motivation

-
-
-

Environment module systems provide a solution for the dynamic -modification of a user’s environment by loading special files named -'modulefiles'.

-
-
-

Each modulefile contains the information needed to configure the shell -for an application or library. The environment can be modified on a -per-module basis using the module command which interprets -modulefiles. Typically modulefiles instruct the module command to -alter or set shell environment variables such as PATH, MANPATH -etc. modulefiles may be shared by many users on a system and users may -have their own collection to supplement or replace the shared -modulefiles.

-
-
-

Environment module systems are widely used on HPC systems to provide -multiple compilers and multiple versions of the same library or API -implementations to the users. The -Environment Modules system is the -most widely used implementation. Another - more recent - -implementation is -Lmod. Lmod -addresses some weaknesses of the Environment Modules, but solves only -some of them.

-
-
-

One issue with the Environment Modules is the flat naming scheme. The -Lmod system and Pmodules solves the problem by organizing the modules -hierarchically. What is the problem with a flat naming scheme? Provide -different versions of the same library, like openmpi 1.6.5/1.8.4, -compiled with different (versions) of compilers, like gcc -4.7.4/4.8.4/4.9.2 and Intel 14.0.2/15.2, the number of modules is -growing quite fast. Providing dozens of libraries will end up in -hundreds of modules - not very clear to the users.

-
-
-

Neither Environment Modules nor Lmod have build-in support for phasing -out modules or marking modules as unstable. Pmodules solves this -problem by introducing 'releases' like stable, unstable and -deprecated. A user will be warned while loading a non-stable module.

-
-
-

With Environment Modules and Lmod everything must be coded in the -modulefile - even things which are obvious. If a bin directory -exists, why not adding this directory to the PATH variable -automatically? The same can be done for MANPATH, LD_LIBRARY_PATH -and other environment variables.

-
-
-

Usually modules are installed on a network file-systems. In some cases -it is convenient or even required to install modules locally. Pmodules -provides a tool to install all or a sub-set of the modules from any -location to another location.

-
-
-

Pmodules has its own (simple) build environment. For a new module you -have to write a build script and a modulefile. Updating an existing -modules is very simple. In most cases it’s downloading the new version -and calling the build script. Anyway, nobody forces you to use this -build environment, but in most cases it is very handy.

-
-
-
-
-

Module groups

-
-
-

Pmodules organizes modules in groups. By default only the groups -Tools and Programming are visible. To get a list of 'used' and -'unused' groups, run the command module use:

-
-
-
-
$ module use
-Used groups:
-	Tools
-	Programming
-
-Unused groups:
-	Libraries
-	System
-...
-
-
-
-

To make the modules in a given group available, run the command

-
-
-
-
$ module use GROUP
-
-
-
-
-
Example
-
-
-
-
-
$ module use System
-$ module avail
---------------------------------------------- System ---------------------------------------------
-
-fsstress/1.0.0  nmap/6.46
-
---------------------------------------------- Tools ---------------------------------------------
-
-Eclipse/4.4.2   Firefox/31.0    Opera/23.0      Thunderbird/31.0                emacs/24.4
-global/6.3.1    gnuplot/4.6.3
-
------------------------------------------- Programming ------------------------------------------
-
-Python/3.4.0    Python/3.4.3    autoconf/2.69   automake/1.14   cmake/2.8.12.2  gcc/4.7.4
-gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       libtool/2.4.2   m4/1.4.17
-
-
-
-

To make groups unavailable, run the command

-
-
-
-
$ module unuse GROUP
-
-
-
-
-
Example
-
-

Make modules in the groups System and Programming unavailable:

-
-
-
-
-
-
$ module unuse System Programming
-$ module avail
---------------------------------------------- Tools ---------------------------------------------
-
-Eclipse/4.4.2   Firefox/31.0    Opera/23.0      Thunderbird/31.0                dialog/1.2.1(u)
-emacs/24.4      emacs/24.5(u)   git/2.3.3(u)    global/6.3.1    gnuplot/4.6.3   gnuplot/5.0.0(u)
-
-
-
-
-
-
-

Module hierarchies

-
-
-

Unstructured, flat naming schemes are confusing. Why? Lets assume we have to -provide modules for the compilers gcc-4.8.4, gcc-4.9.2, intel-15.2, -the MPI implementations openmpi-1.6.5, openmpi-1.8.4, mpich-3.1.4 -and parallel versions of hdf5-1.8.10 and hdf5-1.8.14 compiled with -all compiler/MPI combinations. So, we have to provide 30(!) modules:

-
-
-
    -
  • -

    3 compiler modules

    -
    • -
  • -

    9 MPI modules

    -
    • -
  • -

    18 hdf5 modules

    -
    • -
-
-
-

Even with a reasonable naming convention this is quite confusing. In a flat naming scheme a listing of available modules might look like:

-
-
-
-
$ module avail
-gcc-4.8.4
-gcc-4.9.2
-hdf5-1.8.10-mpi-3.1.4-gcc-4.8.4
-hdf5-1.8.10-mpi-3.1.4-gcc-4.9.2
-hdf5-1.8.10-mpi-3.1.4-intel-15.2
-hdf5-1.8.10-openmpi-1.6.5-gcc-4.8.4
-hdf5-1.8.10-openmpi-1.6.5-gcc-4.9.2
-hdf5-1.8.10-openmpi-1.6.5-intel-15.2
-hdf5-1.8.10-openmpi-1.8.4-gcc-4.8.4
-hdf5-1.8.10-openmpi-1.8.4-gcc-4.9.2
-hdf5-1.8.10-openmpi-1.8.4-intel-15.2
-hdf5-1.8.14-mpi-3.1.4-gcc-4.8.4
-hdf5-1.8.14-mpi-3.1.4-gcc-4.9.2
-hdf5-1.8.14-mpi-3.1.4-intel-15.2
-hdf5-1.8.14-openmpi-1.6.5-gcc-4.8.4
-hdf5-1.8.14-openmpi-1.6.5-intel-15.2
-hdf5-1.8.14-openmpi-1.8.4-gcc-4.8.4
-hdf5-1.8.14-openmpi-1.8.4-gcc-4.9.2
-hdf5-1.8.14-openmpi-1.8.4-intel-15.2
-intel-15.3
-mpi-3.1.4-gcc-4.8.4
-mpi-3.1.4-gcc-4.9.2
-mpi-3.1.4-intel-15.2
-openmpi-1.6.5-gcc-4.8.4
-openmpi-1.6.5-gcc-4.9.2
-openmpi-1.6.5-intel-15.2
-openmpi-1.8.4-gcc-4.8.4
-openmpi-1.8.4-gcc-4.9.2
-openmpi-1.8.4-intel-15.2
-
-
-
-

Got it? One combination is missing. But which one?

-
-
-

Actually we have to provide more compilers than the three mentioned above: while writing this documentation the number is already seven(!): five GCC versions and two Intel C versions.

-
-
-

Another issue with a flat naming scheme is, that all modules are listed independent of already loaded modules. But listing a module providing hdf5 1.8.14 compiled with Intel 15.2 and mpich 3.1.4 makes not much sense if modules for gcc 4.9.2 and openmpi 1.8.4 are already loaded. A solution to these issues is a to structure the modules hierarchically.

-
-
-
-
                  ... _________________________________________|________________________________________...
-                     /                                         |                                        \
-                    gcc                                       gcc                                      intel
-                   4.8.4                                     4.9.2                                     15.2
-        _____________|_____________               _____________|_____________               _____________|_____________
-       /             |             \             /             |             \             /             |             \
-    openmpi       openmpi        mpich        openmpi       openmpi        mpich        openmpi       openmpi        mpich
-     1.6.5         1.8.4         3.1.4         1.6.5         1.8.4         3.1.4         1.6.5         1.8.4         3.1.4
-     __|__         __|__         __|__         __|__         __|__         __|__         __|__         __|__         __|__
-    /     \       /     \       /     \       /     \       /     \       /     \       /     \       /     \       /     \
-  hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5
- 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14
-
-
-
- - - - - -
- - -In a hierarchical structured module environment the command module -avail does '''not''' reveal all modules. Modules like openmpi and -hdf5 are not listed as long as the dependencies are not loaded. -
-
-
-
-
Example
-
-

Before you can load a hdf5 module, you must first

-
-
    -
  • -

    load a particular compiler module,

    -
    • -
  • -

    than a particular MPI module

    -
    • -
  • -

    and then the desired hdf5 module.

    -
    • -
-
-
-
-
-
-
-
$ module list
-No Modulefiles Currently Loaded.
-$ module avail
- ------------------------------------------ Programming ------------------------------------------
-
-autoconf/2.69   automake/1.14   binutils/2.25(u)                cmake/2.8.12.2  cmake/3.1.3
-gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/5.1.0(u)    intel/14.0.3
-intel/15.2(u)   libtool/2.4.2   m4/1.4.17       psi-python27/2.1.0(u)
-psi-python34/2.1.0(u)           Python/3.4.3    Tcl/8.6.3(u)    Tcl/8.6.4(u)    Tk/8.6.4(u)
-
-
-
-

After loading the module gcc/4.9.2 we see the available MPI implementations compiled with this compiler:

-
-
-
-
$ module load gcc/4.9.2
-$ module avail
------------------------------------------- Programming ------------------------------------------
-
-autoconf/2.69   automake/1.14   binutils/2.25(u)                cmake/2.8.12.2  cmake/3.1.3
-gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/5.1.0(u)    intel/14.0.3
-intel/15.2(u)   libtool/2.4.2   m4/1.4.17       psi-python27/2.1.0(u)
-psi-python34/2.1.0(u)           Python/3.4.3    Tcl/8.6.3(u)    Tcl/8.6.4(u)    Tk/8.6.4(u)
-
---------------------------------------- Compiler/gcc/4.9.2 ---------------------------------------
-
-boost/1.55.0    boost/1.57.0    gsl/1.15        hdf5_serial/1.8.12              hdf5_serial/1.8.13
-hdf5_serial/1.8.14              mpich/3.1.4(u)  OpenBLAS/0.2.9  OpenBLAS_OMP/0.2.9
-openmpi/1.6.5   openmpi/1.8.2   openmpi/1.8.4   root/5.34.19    root/5.34.26    SuperLU/4.3
-UMFPACK/5.6.2   vtk/5.10.1
-
-
-
-

Next step is loading a MPI module:

-
-
-
-
$ module load openmpi/1.8.4
-$ module avail
------------------------------------------- Programming ------------------------------------------
-
-autoconf/2.69   automake/1.14   binutils/2.25(u)                cmake/2.8.12.2  cmake/3.1.3
-gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/5.1.0(u)    intel/14.0.3
-intel/15.2(u)   libtool/2.4.2   m4/1.4.17       psi-python27/2.1.0(u)
-psi-python34/2.1.0(u)           Python/3.4.3    Tcl/8.6.3(u)    Tcl/8.6.4(u)    Tk/8.6.4(u)
-
---------------------------------------- Compiler/gcc/4.9.2 ---------------------------------------
-
-boost/1.55.0    boost/1.57.0    gsl/1.15        hdf5_serial/1.8.12              hdf5_serial/1.8.13
-hdf5_serial/1.8.14              mpich/3.1.4(u)  OpenBLAS/0.2.9  OpenBLAS_OMP/0.2.9
-openmpi/1.6.5   openmpi/1.8.2   openmpi/1.8.4   root/5.34.19    root/5.34.26    SuperLU/4.3
-UMFPACK/5.6.2   vtk/5.10.1
-
----------------------------------- MPI/gcc/4.9.2/openmpi/1.8.4 ----------------------------------
-
-BoxLib/2014-02-28               hdf5/1.8.12     hdf5/1.8.13     hdf5/1.8.14     ippl/1.1.4
-parmetis/3.2.0  SuperLU_DIST/3.3                trilinos/11.10.2                trilinos/11.12.1
-trilinos/11.14.1
-
-
-
-

Now you can load the HDF5 module:

-
-
-
-
$ module load hdf5/1.8.14
-
-
-
-

Instead of

-
-
-
-
$ module load gcc/4.9.2
-$ module load openmpi/1.8.4
-$ module load hdf5/1.8.14
-
-
-
-

you can also execute

-
-
-
-
$ module load gcc/4.9.2 openmpi/1.8.4 hdf5/1.8.14
-
-
-
- - - - - -
- - -Modules marked with (u) are unstable. ---- -
-
-
-
-
-

Searching the module hierarchy

-
-
-

Now you may ask: How do I know which hdf5 (or Trilinos, boost…​) modules are really available? To get an answer to this question you can run the module search command.

-
-
-
-
Example
-
-

To get a list of all installed hdf5 modules run

-
-
-
-
-
-
$ module search hdf5 --all-releases
-Module               Release    Group        Requires
-------------------------------------------------------------
-hdf5/1.8.12          unstable   MPI          gcc/4.7.4 mpich/3.1.4
-hdf5/1.8.12          stable     MPI          gcc/4.7.4 openmpi/1.6.5
-hdf5/1.8.12          stable     MPI          gcc/4.7.4 openmpi/1.8.2
-hdf5/1.8.12          stable     MPI          gcc/4.7.4 openmpi/1.8.4
-hdf5/1.8.12          stable     MPI          gcc/4.8.3 openmpi/1.6.5
-hdf5/1.8.12          stable     MPI          gcc/4.8.3 openmpi/1.8.2
-hdf5/1.8.12          stable     MPI          gcc/4.8.3 openmpi/1.8.4
-hdf5/1.8.12          unstable   MPI          gcc/4.8.4 mpich/3.1.4
-hdf5/1.8.12          stable     MPI          gcc/4.8.4 openmpi/1.6.5
-hdf5/1.8.12          stable     MPI          gcc/4.8.4 openmpi/1.8.2
-hdf5/1.8.12          stable     MPI          gcc/4.8.4 openmpi/1.8.4
-hdf5/1.8.12          unstable   MPI          gcc/4.9.2 mpich/3.1.4
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5/1.8.12          unstable   MPI          gcc/5.1.0 mpich/3.1.4
-hdf5/1.8.12          unstable   MPI          gcc/5.1.0 openmpi/1.6.5
-hdf5/1.8.12          unstable   MPI          gcc/5.1.0 openmpi/1.8.4
-hdf5/1.8.12          unstable   MPI          intel/15.2 mpich/3.1.4
-hdf5/1.8.12          unstable   MPI          intel/15.2 openmpi/1.6.5
-hdf5/1.8.12          unstable   MPI          intel/15.2 openmpi/1.8.4
-hdf5/1.8.13          stable     MPI          gcc/4.7.4 openmpi/1.6.5
-hdf5/1.8.13          stable     MPI          gcc/4.7.4 openmpi/1.8.2
-hdf5/1.8.13          stable     MPI          gcc/4.7.4 openmpi/1.8.4
-hdf5/1.8.13          stable     MPI          gcc/4.8.3 openmpi/1.6.5
-hdf5/1.8.13          stable     MPI          gcc/4.8.3 openmpi/1.8.2
-hdf5/1.8.13          stable     MPI          gcc/4.8.3 openmpi/1.8.4
-hdf5/1.8.13          stable     MPI          gcc/4.8.4 openmpi/1.6.5
-hdf5/1.8.13          stable     MPI          gcc/4.8.4 openmpi/1.8.2
-hdf5/1.8.13          stable     MPI          gcc/4.8.4 openmpi/1.8.4
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          gcc/4.7.4 mpich/3.1.4
-hdf5/1.8.14          stable     MPI          gcc/4.7.4 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.7.4 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.7.4 openmpi/1.8.4
-hdf5/1.8.14          stable     MPI          gcc/4.8.3 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.8.3 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.8.3 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          gcc/4.8.4 mpich/3.1.4
-hdf5/1.8.14          stable     MPI          gcc/4.8.4 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.8.4 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.8.4 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          gcc/4.9.2 mpich/3.1.4
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          gcc/5.1.0 mpich/3.1.4
-hdf5/1.8.14          unstable   MPI          gcc/5.1.0 openmpi/1.6.5
-hdf5/1.8.14          unstable   MPI          gcc/5.1.0 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          intel/15.2 mpich/3.1.4
-hdf5/1.8.14          unstable   MPI          intel/15.2 openmpi/1.6.5
-hdf5/1.8.14          unstable   MPI          intel/15.2 openmpi/1.8.4
-hdf5_serial/1.8.12   stable     Compiler     gcc/4.7.4
-hdf5_serial/1.8.12   stable     Compiler     gcc/4.8.3
-hdf5_serial/1.8.12   stable     Compiler     gcc/4.8.4
-hdf5_serial/1.8.12   stable     Compiler     gcc/4.9.2
-hdf5_serial/1.8.12   unstable   Compiler     intel/15.2
-hdf5_serial/1.8.14   stable     Compiler     gcc/4.7.4
-hdf5_serial/1.8.14   stable     Compiler     gcc/4.8.3
-hdf5_serial/1.8.14   stable     Compiler     gcc/4.8.4
-hdf5_serial/1.8.14   stable     Compiler     gcc/4.9.2
-hdf5_serial/1.8.14   unstable   Compiler     intel/15.2
-
-
-
-
-
Example
-
-

To get a list of all installed hdf5 modules compiled with GCC 4.9.2, run

-
-
-
-
-
-
$ module search hdf5 --with=gcc/4.9.2 --all-releases
-Module               Release    Group        Requires
-------------------------------------------------------------
-hdf5/1.8.12          unstable   MPI          gcc/4.9.2 mpich/3.1.4
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          gcc/4.9.2 mpich/3.1.4
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5_serial/1.8.12   stable     Compiler     gcc/4.9.2
-hdf5_serial/1.8.13   stable     Compiler     gcc/4.9.2
-hdf5_serial/1.8.14   stable     Compiler     gcc/4.9.2
-
-
-
-
-
Example
-
-

To get a list of all installed modules providing (parallel) HDF5 1.8.14, execute

-
-
-
-
-
-
$ module search hdf5/1.8.14 --with=gcc/4.9.2 --all-releases
-Module               Release    Group        Requires
-------------------------------------------------------------
-hdf5/1.8.14          unstable   MPI          gcc/4.9.2 mpich/3.1.4
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-
-
-
- - - - - -
- - -Without the option --all-releases, only modules of "used" releases are listed. -
-
-
-
-
-
-

Module lifecycle

-
-
-

Pmodules supports a simple lifecycle management. This solves the -problem of introducing new modules, which are still in development or -considered to be unstable and it supports phasing out old and -deprecated modules. The lifecycle of a module is unstable → -stable → deprecated. By default only stable modules are -visible. If you want to use unstable or deprecated modules, you have -to run

-
-
-
-
$ module use unstable
-
-
-
-

or

-
-
-
-
$ module use deprecated
-
-
-
-

first.

-
-
-

All modules start as unstable. This implies something like "use on -your on risk". Unstable modules may be changed without warning or even -be removed. If you load an unstable module, a warning will be printed.

-
-
-

A stable module is, well, stable. It will not be changed during the -remaining life time and the provided software is considered to be -stable.

-
-
-

A deprecated module should not be used any more. Deprecated modules -might be removed without further warning. While loading a deprecated -module, a warning will be printed. Kind module developers might add an -end of life message with more detailed information.

-
-
-
-
-

Overlays

-
-
-

TBW

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/Overview.html b/doc/html/Overview.html deleted file mode 100644 index c65e252..0000000 --- a/doc/html/Overview.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - - -OVERVIEW - - - - - -
-
-

OVERVIEW

-
-
-

Pmodules is the environment modules system at PSI. Since it uses AFS as storage backend it is an easy and convinient solution for software distribution.

-
-
-

It is available for all PSI supported Linux systems including

-
-
-
    -
  • -

    login.psi.ch (llc.psi.ch)

    -
    • -
  • -

    Merlin6

    -
    • -
  • -

    Ra

    -
    • -
-
-
-

A list of available modules and changes is avail here.

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command.html b/doc/html/The_module_command.html deleted file mode 100644 index 98f67bf..0000000 --- a/doc/html/The_module_command.html +++ /dev/null @@ -1,1225 +0,0 @@ - - - - - - - -THE module COMMAND - - - - - -
-
-
-
-

Table of Content
-The module-command: module
-List available modules: module avail
-Clear list of loaded modules: module clear
-Display information about chances in environment when loaded: module display
-Print sub-command or module-specific help: module help
-Add or remove modules from shell’s initialization file: module initcmds
-Search for keywords in 'whatis': [module-keyword]
-List loaded modules: module list
-Load and unload modules: module load|unload
-Purge all loaded modules: module purge
-Refresh loaded modules: module refresh
-Search installed modules: module search
-Replace a loaded module by another: module swap
-Manipulate module path, used releases, groups and overlays: module use
-Search for keywords in 'whatis': module whatis|keyword

-
-
-
-
-

module - using Pmodules

-
-
-

NAME

-
-

module - command line interface to the Pmodules package

-
-
-
-

SYNOPSIS

-
-

module [ switches ] [ sub-command ] [ sub-command-args ]

-
-
-
-

DESCRIPTION

-
-

Environment Modules provide a convenient way to dynamically change the -users' environment through modulefiles. This includes easily adding or -removing directories to the PATH environment variable. -A modulefile contains the necessary information to allow a user to run -a particular application or provide access to a particular -library. All of this can be done dynamically without logging out and -back in. Modulefiles for applications modify the user’s shell -environment to make access easy. Modulefiles for Library packages -provide environment variables that specify where the library and -header files can be found. -Packages can be loaded and unloaded cleanly through the module command.

-
-
-

Available sub-commands are:

-
-
-

List available modules: module avail

-
-
-

Clear list of loaded modules: module clear

-
-
-

Display information about chances in environment when loaded: module display

-
-
-

Print sub-command or module-specific help: module help

-
-
-

Add or remove modules from shell’s initialization file: module initcmds

-
-
-

Search for keywords in 'whatis': [module-keyword]

-
-
-

List loaded modules: module list

-
-
-

Load and unload modules: module load|unload

-
-
-

Purge all loaded modules: module purge

-
-
-

Refresh loaded modules: module refresh

-
-
-

Search installed modules: module search

-
-
-

Replace a loaded module by another: module swap

-
-
-

Manipulate module path, used releases, groups and overlays: module use

-
-
-

Search for keywords in 'whatis': module whatis|keyword

-
-
- - - - - -
- - -
-

For the time being Pmodules supports bash, tcsh and zsh only.

-
-
-
-
-
-
-
-

1. Sub-commands

-
-
-

1.1. List available/loadable modules

-
-

NAME

-
-

module avail - list loadable modules

-
-
-
-

SYNOPSIS

-
-

module avail [OPTIONS] [string…​]

-
-
-
-

DESCRIPTION

-
-

List all available module in the current MODULEPATH. If an argument is given, then each directory in the MODULEPATH is searched for modules whose pathname match the argument.

-
-
-

This command does not display all installed modules on the system. Only loadable modules are listed. To get a list of all installed modules use the command module search.

-
-
-

The list of available modules may change either by loading other modules, e.g. a compiler, or by using/accepting unstable or deprecated modules. For the later read the description of module use.

-
-
-

With the switches you can change the output format. The default output format is 'human' (readable). For the time being terse and long output are identical.

-
-
-
-

OPTIONS

-
-
-
-a
-
-

List loadable modules in all release-stages. Unstable modules are marked with (u), -deprecated modules with (d).

-
-
-t | --terse
-
-

Terse output.

-
-
-h | --human
-
-

Human readable output. This is the default.

-
-
-l | --long
-
-

Long output.

-
-
-
-
-
-

EXAMPLES

-
-
-
$ module avail git
------------------------------------------ Tools -----------------------------------------
-
-ygit/2.3.3       git/2.8.1       git/2.21.0      git/2.22.0      git/2.30.0      git/2.33.1
-
-$ module avail -a gcc
--------------------------------------- Programming --------------------------------------
-
-gcc/4.7.4       gcc/4.8.2       gcc/4.8.3       gcc/4.8.4       gcc/4.8.5       gcc/4.9.2
-gcc/4.9.3       gcc/4.9.4       gcc/5.1.0(d)    gcc/5.2.0(d)    gcc/5.3.0       gcc/5.4.0
-gcc/5.5.0       gcc/6.1.0       gcc/6.2.0       gcc/6.3.0       gcc/6.4.0       gcc/6.5.0
-gcc/7.1.0       gcc/7.2.0       gcc/7.3.0       gcc/7.4.0       gcc/7.5.0       gcc/8.1.0
-gcc/8.2.0       gcc/8.3.0       gcc/8.4.0       gcc/8.5.0       gcc/9.1.0       gcc/9.2.0
-gcc/9.3.0       gcc/9.5.0       gcc/10.1.0      gcc/10.2.0      gcc/10.3.0      gcc/11.2.0
-gcc/11.3.0      gcc/12.1.0
-
-
-
-
SEE ALSO
-
-

module list, -module load|unload, -module search, -module use, -[module-unuse]

-
-
-
-
-
-

1.2. Clear list of loaded modules

-
-

1.2.1. NAME

-
-

module clear - clear list of loaded modules.

-
-
-
-

1.2.2. SYNOPSIS

-
-

module clear

-
-
-
-

1.2.3. DESCRIPTION

-
-

Force the Pmodules package to believe that no modules are currently loaded. The sub-command clear does not unload the loaded modules! In other words: changes made to the shell’s environment by loaded modules are not reverted.

-
-
-
-

1.2.4. EXAMPLES

-
-

After loading the module for gcc/4.9.2 the following environment variables are set:

-
-
-
-
$ env | grep ^GCC
-GCC_HOME=/opt/psi/Programming/gcc/4.9.2
-GCC_DIR=/opt/psi/Programming/gcc/4.9.2
-GCC_PREFIX=/opt/psi/Programming/gcc/4.9.2
-GCC_VERSION=4.9.2
-GCC_INCLUDE_DIR=/opt/psi/Programming/gcc/4.9.2/include
-GCC_LIBRARY_DIR=/opt/psi/Programming/gcc/4.9.2/lib
-
-
-
-

After clearing the list of loaded modules the environment variables set by the GCC module are still set

-
-
-
-
$ module clear
-$ module list
-No Modulefiles Currently Loaded.
-$ env | grep ^GCC
-GCC_HOME=/opt/psi/Programming/gcc/4.9.2
-GCC_DIR=/opt/psi/Programming/gcc/4.9.2
-GCC_PREFIX=/opt/psi/Programming/gcc/4.9.2
-GCC_VERSION=4.9.2
-GCC_INCLUDE_DIR=/opt/psi/Programming/gcc/4.9.2/include
-GCC_LIBRARY_DIR=/opt/psi/Programming/gcc/4.9.2/lib
-
-
-
-
-

1.2.5. SEE ALSO

-
-

module purge, module load|unload

-
-
-
-
-

1.3. Display information about a module

-
-

NAME

-
-

module display\|show - display information about chances in environment

-
-
-
-

SYNOPSIS

-
-

module display modulefile…​
-module show modulefile…​

-
-
-
-

DESCRIPTION

-
-

Display information about modulefile(s). The display sub-command will list the full path of the modulefile(s) and all of the environment changes the modulefile(s) will make if loaded. (It will not display any environment changes found within conditional statements.)

-
-
-
-

EXAMPLES

-
-

Display chances the module gcc/5.4.0 will make to the environment if loaded:

-
-
-
-
$ module display gcc/5.4.0
--------------------------------------------------------------------
-/opt/psi/Programming/modulefiles/gcc/5.4.0:
-
-module-whatis	 GNU Compiler Collection
-conflict	 gcc
-setenv		 GCC_VERSION 5.4.0
-setenv		 GCC_PREFIX /opt/psi/Programming/gcc/5.4.0
-setenv		 GCC_DIR /opt/psi/Programming/gcc/5.4.0
-setenv		 GCC_HOME /opt/psi/Programming/gcc/5.4.0
-prepend-path	 PATH /opt/psi/Programming/gcc/5.4.0/bin
-prepend-path	 MANPATH /opt/psi/Programming/gcc/5.4.0/share/man
-prepend-path	 C_INCLUDE_PATH /opt/psi/Programming/gcc/5.4.0/include
-prepend-path	 CPLUS_INCLUDE_PATH /opt/psi/Programming/gcc/5.4.0/include
-setenv		 GCC_INCLUDE_DIR /opt/psi/Programming/gcc/5.4.0/include
-prepend-path	 LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib
-prepend-path	 LD_LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib
-setenv		 GCC_LIBRARY_DIR /opt/psi/Programming/gcc/5.4.0/lib
-prepend-path	 LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib64
-prepend-path	 LD_LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib64
-setenv		 GCC_LIBRARY_DIR /opt/psi/Programming/gcc/5.4.0/lib64
-append-path	 PMODULES_LOADED_PROGRAMMING gcc/5.4.0
-remove-path	 PMODULES_LOADED_PROGRAMMING --APPMARKER--
-setenv		 COMPILER gcc
-setenv		 COMPILER_VERSION 5.4.0
-setenv		 CC /opt/psi/Programming/gcc/5.4.0/bin/gcc
-setenv		 CXX /opt/psi/Programming/gcc/5.4.0/bin/g++
-setenv		 F77 /opt/psi/Programming/gcc/5.4.0/bin/gfortran
-setenv		 F90 /opt/psi/Programming/gcc/5.4.0/bin/gfortran
-setenv		 FC /opt/psi/Programming/gcc/5.4.0/bin/gfortran
-setenv		 FORTRAN /opt/psi/Programming/gcc/5.4.0/bin/gfortran
--------------------------------------------------------------------
-
-
-
-
-

SEE ALSO

-
-

module help

-
-
-
-
-

1.4. Print sub-command or module-specific help

-
-

1.4.1. NAME

-
-

module help - print sub-command or module-specific help

-
-
-
-

1.4.2. SYNOPSIS

-
-

module help [module|sub-command…​]

-
-
-
-

1.4.3. DESCRIPTION

-
-

Print help for specific modules, sub-commands or the module command itself.

-
-
-
-

1.4.4. EXAMPLES

-
-

Get help for the module git/2.3.3:

-
-
-
-
$ module help git/2.3.3
-
------------ Module Specific Help for 'git/2.3.3' ------------------
-
-distributed version control system
-Version:    2.3.3
-Homepage:   http://git-scm.com/
-License:    GNU GPL v2
-Maintainer: Achim Gsell <achim.gsell@psi.ch>
-
-Git is a free and open source distributed version control system
-designed to handle everything from small to very large projects
-with speed and efficiency.
-
-Git is easy to learn and has a tiny footprint with lightning fast
-performance. It outclasses SCM tools like Subversion, CVS, Perforce,
-and ClearCase with features like cheap local branching, convenient
-staging areas, and multiple workflows.
-
-
-
-

Print help for the sub-command load:

-
-
-
-
$ module help load
-
-USAGE:
-        module add     modulefile...
-        module load    modulefile...
-                Load modulefile(s) into the shell environment. Loading a
-		'group-head' will extend the MODULEPATH. E.g.: loading a
-		compiler makes additional modules like openmpi and libraries
-		compiled with this compiler available.
-
-
-
-
-

1.4.5. SEE ALSO

-
-

module whatis|keyword

-
-
-
-
-

1.5. Manipulate shell’s initialization file

-
-

1.5.1. NAME

-
-

module initadd|initprepend|initrm|initswitch|initrm|initlist|initclear - add or remove modules from shell’s initialization file

-
-
-
-

1.5.2. SYNOPSIS

-
-

module initadd module…​
-module initprepend module…​
-module initrm module…​
-module initswitch module1 module2
-module initlist
-module initclear

-
-
-
-

1.5.3. DESCRIPTION

-
-

Add modulefile(s) to, list modulefile(s) in or remove modulefile(s) from the shell’s initialization file in the user’s home directory. The startup files checked (in order) are:

-
-
-
-
csh
-
-

.modules, .cshrc(.ext), .csh_variables, and .login(.ext)

-
-
tcsh
-
-

.modules, .tcshrc, .cshrc(.ext), .csh_variables, and .login(.ext)

-
-
bash
-
-

.modules, .bash_profile, .bash_login, .profile(.ext), and .bashrc(.ext)

-
-
zsh
-
-

.modules, .zcshrc(.ext), .zshenv(.ext), and .zlogin(.ext)

-
-
module initadd module…​
-
-

If a module load line is found in any of these files, the modulefile(s) is(are) appended to any existing list of modulefiles. The module load line must be located in at least one of the files listed above for any of the init sub-commands to work properly. If the module load line is found in multiple shell initialization files, all of the lines are changed.

-
-
module initprepend module…​
-
-

Does the same as initadd but prepends the given modules to the beginning of the list.

-
-
module initrm module…​
-
-

Remove modulefile(s) from the shell’s initialization files.

-
-
module initswitch module1 module2
-
-

Switch module1 with module2 in the shell’s initialization files.

-
-
module initlist
-
-

List all of the module(s) loaded from the shell’s initialization file.

-
-
module initclear
-
-

Clear all of the module(s) from the shell’s initialization files.

-
-
-
-
-
-

1.5.4. SEE ALSO

-
-

module load|unload, module load|unload, [module-switch]

-
-
-
-
-

1.6. List loaded modules

-
-

1.6.1. NAME

-
-

module list - list loaded modules

-
-
-
-

1.6.2. SYNOPSIS

-
-

module list [OPTIONS]

-
-
-
-

1.6.3. DESCRIPTION

-
-

List loaded modules.

-
-
-
-

1.6.4. OPTIONS

-
-
-
-t | --terse
-
-

Terse output.

-
-
-h | --human
-
-

Human readable output. This is the default.

-
-
-l | --long
-
-

Long output.

-
-
-
-
-
-

1.6.5. EXAMPLES

-
-

Assuming the modules gcc/4.8.3, openmpi/1.8.2 and hdf5/1.8.12. List with default (human readable) output:

-
-
-
-
$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.8.3       2) openmpi/1.8.2   3) hdf5/1.8.12
-
-
-
-

List in terse output:

-
-
-
-
$ module list -t
-Currently Loaded Modulefiles:
-gcc/4.8.3
-openmpi/1.8.2
-hdf5/1.8.12
-
-
-
-

Long listing:

-
-
-
-
$ module list -l
-- Package -----------------------------+- Versions -+- Last mod. ------
-Currently Loaded Modulefiles:
-gcc/4.8.3                                            2014/12/05 17:39:24
-openmpi/1.8.2                                        2014/11/25  8:15:40
-hdf5/1.8.12                                          2014/11/25  8:15:40
-
-
-
-
-

1.6.6. SEE ALSO

-
-

module load|unload, module avail

-
-
-
-
-

1.7. Load and unloading a module

-
-

1.7.1. NAME

-
-

module add|load - load modules
-module rm|unload - unload modules

-
-
-
-

1.7.2. SYNOPSIS

-
-

module add [OPTIONS] modulefile…​
-module load [OPTIONS] modulefile…​
-module rm modulefile…​
-module unload modulefile…​

-
-
-
-

1.7.3. DESCRIPTION

-
-

Load modulefile(s) into shell environment. Loading a group-head will extend the MODULEPATH. E.g.: loading a compiler makes additional modules like openmpi and other libraries/packages compiled with this compiler available.

-
-
-

If you try to load a module which is not available in the current MODULEPATH but installed in the module hierarchy, a message will be printed showing prerequisite modules.

-
-
-

If you load a deprecated or unstable module, a warning will be printed.

-
-
-

You can change the verbosity of the load sub-command by setting the environment variable PMODULES_VERBOSITY to silent, warn or verbose.

-
-
-
-
silent
-
-

Print error messages only.

-
-
warn
-
-

Print a warning message, when loading a deprecated or unstable module.

-
-
verbose
-
-

Print warning messages and print prerequisite modules if the module to load is not available, but installed in hierarchy.

-
-
-
-
-
-

1.7.4. OPTIONS / FLAGS

-
-
-
-f | --force
-
-

Force active dependency resolution. This will result in modules found on a prereq command inside a module file being load automatically. Unloading module files using this switch will result in all required modules which have been loaded automatically using the -f switch being unload. This switch is experimental at the moment.

-
-
-v | --verbose
-
-

Set verbosity level to verbose.

-
-
-w | --warn
-
-

Set verbosity level to warn.

-
-
-s | --silent
-
-

Set verbosity level to silent.

-
-
-
-
-
-

1.7.5. EXAMPLES (add|load)

-
-

Loading the modules gcc/4.9.2, openmpi/1.8.4 and hdf5/1.8.14:

-
-
-
-
$ module load gcc/4.9.2
-$ module load openmpi/1.8.4
-$ module load hdf5/1.8.14
-$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2       2) openmpi/1.8.4   3) hdf5/1.8.14
-
-
-
-

or

-
-
-
-
$ module load gcc/4.9.2 openmpi/1.8.4 hdf5/1.8.14
-
-
-
-

If you try to load hdf5/1.8.14 without the prerequisite modules, some "hints" will be printed, if the default verbosity level is set:

-
-
-
-
$ module purge
-$ module load hdf5/1.8.14
-The module 'hdf5/1.8.14' cannot be loaded!
-Try with one of the following command(s):
-
-module load gcc/4.7.4 openmpi/1.6.5 hdf5/1.8.14
-module load gcc/4.7.4 openmpi/1.8.2 hdf5/1.8.14
-module load gcc/4.7.4 openmpi/1.8.4 hdf5/1.8.14
-module load gcc/4.8.3 openmpi/1.6.5 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.3 openmpi/1.8.2 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.3 openmpi/1.8.4 hdf5/1.8.14
-module load gcc/4.8.4 openmpi/1.6.5 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.4 openmpi/1.8.2 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.4 openmpi/1.8.4 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.4 openmpi/1.8.8 hdf5/1.8.14
-module use deprecated; module load gcc/4.9.2 openmpi/1.6.5 hdf5/1.8.14
-module use deprecated; module load gcc/4.9.2 openmpi/1.8.2 hdf5/1.8.14
-module use deprecated; module load gcc/4.9.2 openmpi/1.8.4 hdf5/1.8.14
-
-
-
-

Use verbosity level warn to suppress the hints:

-
-
-
-
$ module load hdf5/1.8.14 --warn
-module load: module unavailable -- hdf5/1.8.14
-
-
-
-

Loading an unstable module:

-
-
-
-
$ module use unstable
-$ module load cmake/3.1.3
-Warning: the unstable module 'cmake/3.1.3' has been loaded.
-
-
-
-

To supress the warning, use the --silent option.

-
-
-
-

1.7.6. EXAMPLES (rm|unload)

-
-
-
$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2       2) openmpi/1.8.4   3) hdf5/1.8.14
-$ module rm openmpi/1.8.4
-$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2
-
-
-
-

The module hdf5/1.8.14 is unloaded as a dependency of openmpi/1.8.4.

-
-
-
-

1.7.7. SEE ALSO

-
-

module use, module load|unload, module purge, module swap, module list

-
-
-
-
-

1.8. Purge all loaded modules

-
-

1.8.1. NAME

-
-

module purge - purge all loaded modules

-
-
-
-

1.8.2. SYNOPSIS

-
-

module purge

-
-
-
-

1.8.3. DESCRIPTION

-
-

Unload all loaded module and reset everything to original state.

-
-
-
-

1.8.4. EXAMPLES

-
-

List loaded modules:

-
-
-
-
$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.8.3       2) openmpi/1.8.2   3) gnuplot/4.6.3
-
-
-
-

Now we purge everything and list the loaded modules again:

-
-
-
-
$ module purge
-$ module list
-No Modulefiles Currently Loaded.
-
-
-
-
-

1.8.5. SEE ALSO

-
-

module load|unload, module load|unload, module clear

-
-
-
-
-

1.9. Refresh loaded modules

-
-

1.9.1. NAME

-
-

module refresh - refresh loaded modules

-
-
-
-

1.9.2. SYNOPSIS

-
-

module refresh

-
-
-
-

1.9.3. DESCRIPTION

-
-

Force a refresh of all non-persistent components of currently loaded modules. This should be used on derived shells where aliases need to be reinitialized but the environment variables have already been set by the currently loaded modules.

-
-
-
-

1.9.4. SEE ALSO

-
-

module load|unload

-
-
-
-
- -
-

1.10.1. NAME

-
-

module search - search installed modules

-
-
-
-

1.10.2. SYNOPSIS

-
-

module search [switches] string…​

-
-
-
-

1.10.3. DESCRIPTION

-
-

List all modules in the current MODULEPATH and the module hierarchy. If an argument is given, search for modules whose name match the argument. -Options

-
-
-
-

1.10.4. OPTIONS

-
-
-
--no-header
-
-

Suppress output of a header.

-
-
--release=RELEASE
-
-

Search for modules within this release. You can specify this switch multiple times. Without this switch, the used releases will be searched.

-
-
-a|--all-releases
-
-

Search within all releases.

-
-
--with=STRING
-
-

Search for modules compiled with modules matching string. The command. See example below.

-
-
--src=dir
-
-

Search module hierarchy in dir. -Eine Textbeschreibung der Funktionsweise des Befehls oder der Funktion. (Üblicherweise jedoch nicht der Benutzung, siehe unten.)

-
-
-
-
-
-

1.10.5. EXAMPLES

-
-

Get list of all installed GCC:

-
-
-
-
$ module search --all-releases gcc
-Module               Release    Group        Requires
-------------------------------------------------------------
-gcc/4.7.4            stable     Programming
-gcc/4.8.2            stable     Programming
-gcc/4.8.3            stable     Programming
-gcc/4.8.4            stable     Programming
-gcc/4.8.5            stable     Programming
-gcc/4.9.2            stable     Programming
-gcc/4.9.3            stable     Programming
-gcc/4.9.4            stable     Programming
-gcc/5.1.0            deprecated Programming
-gcc/5.2.0            deprecated Programming
-gcc/5.3.0            stable     Programming
-gcc/5.4.0            stable     Programming
-gcc/6.1.0            stable     Programming
-gcc/6.2.0            stable     Programming
-gcc/6.3.0            stable     Programming
-gcc/6.4.0            stable     Programming
-gcc/7.1.0            stable     Programming
-gcc/7.2.0            stable     Programming
-
-
-
-

Get list of all open-mpi versions compiled with GCC 5.4.0:

-
-
-
-
$ module search --all-releases openmpi --with=gcc/5.4.0
-Module               Release    Group        Requires
-------------------------------------------------------------
-openmpi/1.10.2       stable     Compiler     gcc/5.4.0
-openmpi/1.10.4       stable     Compiler     gcc/5.4.0
-openmpi/2.0.1        stable     Compiler     gcc/5.4.0
-
-
-
-
-

1.10.6. SEE ALSO

-
-

module avail

-
-
-
-
-

1.11. Swapping modules

-
-

1.11.1. NAME

-
-

module swap|switch - replace a loaded module by another

-
-
-
-

1.11.2. SYNOPSIS

-
-

module swap [modulefile1] modulefile2
-module switch [modulefile1] modulefile2

-
-
-
-

1.11.3. DESCRIPTION

-
-

Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified, then it is assumed to be the currently loaded module with the same root name as modulefile2.

-
-
-
-

1.11.4. OPTIONS / FLAGS

-
-

None

-
-
-
-

1.11.5. EXAMPLES

-
-
-
$ module load gcc/4.8.4
-$ module swap gcc/4.9.2
-$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2
-
-
-
-
-

1.11.6. BUGS

-
-

You can only swap between different version. The following commands are working (assuming that gcc/4.8.2 is loaded):

-
-
-
-
$ module swap gcc/4.9.2
-$ module swap gcc/4.9.2 gcc/5.4.0
-
-
-
-

The following command does not working as expected:

-
-
-
-
$ module swap gcc/4.8.2 intel/15.0
-
-
-
-

This command does not work with the Tcl implementation (environment variable PMOUDLE_PURETCL set).

-
-
-
-

1.11.7. SEE ALSO

-
-

module load|unload, module load|unload, module list

-
-
-
-
-

1.12. Manipulate module path, used releases, groups or overlays

-
-

1.12.1. NAME

-
-

module use|unuse - manipulate module path, used releases or groups

-
-
-
-

1.12.2. SYNOPSIS

-
-

module use [OPTIONS] [string…​]

-
-
-

module unuse string…​

-
-
-
-

1.12.3. DESCRIPTION

-
-

If called without arguments, print a summary about used groups, releases and additional directories in MODULEPATH.

-
-
-

If string is a directory, append, prepend or remove this directory to/from MODULEPATH.

-
-
-

If string is a group name, append, prepend or remove the corresponding directory to/from MODULEPATH.

-
-
-

If string is a releases name, make all modules with this release available/unavailable. Known releases are;

-
-
-
-
stable
-
-

Modules released as stable are considered to be production ready. The files of a stable module will never change.

-
-
unstable
-
-

These modules are still unstable. They may not be ready for production use. The files of unstable modules may change to fix bugs or add functionality. Use at your own risk.

-
-
deprecated
-
-

Deprecated modules should not be used any more and may be removed without further notice.

-
-
-
-
-

If string matches flag=[-_a-zA-Z0-9]* the RHS will be interpreted as use-flag.

-
-
-
-

1.12.4. OPTIONS / FLAGS

-
-
-
-a | --append
-
-

append directory or group to MODULEPATH.

-
-
-p | --prepend
-
-

prepend directory or group to MODULEPATH.

-
-
-
-
-
-

1.12.5. EXAMPLES

-
-

List used/unused groups, releases and additional directories in MODULEPATH:

-
-
-
-
$ module use
-Used groups:
-	Tools
-	Programming
-	Compiler
-
-Unused groups:
-	Legacy
-	Libraries
-	System
-
-Used releases:
-	stable
-	unstable
-
-Unused releases:
-	deprecated
-
-Used flags:
-	omp
-
-Additonal directories in MODULEPATH:
-	none
-
-
-
-

Adding the 'System' group

-
-
-
-
$ module use System
-$ module avail
--------------------------------------------- System:  --------------------------------------------
-
-filebench/1.4.9.1               fsstress/1.0.0  nmap/6.46       patchelf/0.8.1
-
--------------------------------------------- Tools:  --------------------------------------------
-
-ANSYS/18.2      emacs/24.4      git/2.3.3       global/6.3.1    gnuplot/4.6.3   gnuplot/5.0.0
-...
-
------------------------------------------ Programming:  -----------------------------------------
-
-autoconf/2.69   automake/1.14   automake/1.15   binutils/2.25   cmake/2.8.12.2  cmake/3.1.3
-cmake/3.6.3     gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/4.8.5
-...
-
-
-
-

Adding a directory to MODULEPATH

-
-
-
-
$ module use /afs/psi.ch/project/amas/modulefiles
-$ module avail
------------------------------------ /afs/psi.ch/project/amas:  -----------------------------------
-
-H5hut_parallel-toolchain/2.0    H5hut_serial-toolchain/2.0      OPAL/1.6        OPAL/1.6.0rc5
-opal-toolschain/1.6             opal-toolschain/2.0
-
--------------------------------------------- Tools:  --------------------------------------------
-
-ANSYS/18.2      emacs/24.4      git/2.3.3       global/6.3.1    gnuplot/4.6.3   gnuplot/5.0.0
-...
------------------------------------------ Programming:  -----------------------------------------
-
-autoconf/2.69   automake/1.14   automake/1.15   binutils/2.25   cmake/2.8.12.2  cmake/3.1.3
-cmake/3.6.3     gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/4.8.5
-...
-
-
-
-
-
$ module unuse /afs/psi.ch/project/amas/modulefiles
-$ module unuse System
-$ module unuse unstable
-
-
-
-
-

1.12.6. SEE ALSO

-
-

[module-unuse], module avail, module search

-
-
-
-
-

1.13. Show/search 'what is' information

-
-

1.13.1. NAME

-
-

module whatis - print one-line information about module -module keyword|apropos - search for keywords in 'whatis'

-
-
-
-

1.13.2. SYNOPSIS

-
-

module whatis [module…​]
-module apropos string…​
-module keyword string…​

-
-
-
-

1.13.3. DESCRIPTION

-
-
-
whatis
-
-

Display the information set up by the module-whatis commands inside -the specified modulefile(s). If no modulefile is specified, all whatis -lines will be shown.

-
-
keyword|apropos
-
-

Search through the 'whatis' informations of all modulefiles for the -specified string. All whatis informations matching the string will be -displayed.

-
-
-
-
-
-

1.13.4. EXAMPLES

-
-

Get whatis for all available Git modules

-
-
-
-
$ module  whatis git
------------ /opt/psi/Tools/modulefiles -------------
-           git/2.3.3: distributed version control system
-           git/2.5.2: distributed version control system
-           git/2.8.1: distributed version control system
-          git/2.11.1: distributed version control system
------------ /opt/psi/Programming/modulefiles -------------
-
-
-
-
-

1.13.5. SEE ALSO

-
-

module help

-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-avail.html b/doc/html/The_module_command/module-avail.html deleted file mode 100644 index 1bcf9ad..0000000 --- a/doc/html/The_module_command/module-avail.html +++ /dev/null @@ -1,122 +0,0 @@ - - - - - - - - -List available/loadable modules - - - - - -
-
-
-
-

module avail - list loadable modules

-
-
-
-
-

SYNOPSIS

-
-
-

module avail [OPTIONS] [string…​]

-
-
-
-
-

DESCRIPTION

-
-
-

List all available module in the current MODULEPATH. If an argument is given, then each directory in the MODULEPATH is searched for modules whose pathname match the argument.

-
-
-

This command does not display all installed modules on the system. Only loadable modules are listed. To get a list of all installed modules use the command module search.

-
-
-

The list of available modules may change either by loading other modules, e.g. a compiler, or by using/accepting unstable or deprecated modules. For the later read the description of module use.

-
-
-

With the switches you can change the output format. The default output format is 'human' (readable). For the time being terse and long output are identical.

-
-
-
-
-

OPTIONS

-
-
-
-
-a
-
-

List loadable modules in all release-stages. Unstable modules are marked with (u), -deprecated modules with (d).

-
-
-t | --terse
-
-

Terse output.

-
-
-h | --human
-
-

Human readable output. This is the default.

-
-
-l | --long
-
-

Long output.

-
-
-
-
-
-
-

EXAMPLES

-
-
-
-
$ module avail git
------------------------------------------ Tools -----------------------------------------
-
-ygit/2.3.3       git/2.8.1       git/2.21.0      git/2.22.0      git/2.30.0      git/2.33.1
-
-$ module avail -a gcc
--------------------------------------- Programming --------------------------------------
-
-gcc/4.7.4       gcc/4.8.2       gcc/4.8.3       gcc/4.8.4       gcc/4.8.5       gcc/4.9.2
-gcc/4.9.3       gcc/4.9.4       gcc/5.1.0(d)    gcc/5.2.0(d)    gcc/5.3.0       gcc/5.4.0
-gcc/5.5.0       gcc/6.1.0       gcc/6.2.0       gcc/6.3.0       gcc/6.4.0       gcc/6.5.0
-gcc/7.1.0       gcc/7.2.0       gcc/7.3.0       gcc/7.4.0       gcc/7.5.0       gcc/8.1.0
-gcc/8.2.0       gcc/8.3.0       gcc/8.4.0       gcc/8.5.0       gcc/9.1.0       gcc/9.2.0
-gcc/9.3.0       gcc/9.5.0       gcc/10.1.0      gcc/10.2.0      gcc/10.3.0      gcc/11.2.0
-gcc/11.3.0      gcc/12.1.0
-
-
-
-

SEE ALSO

-
-

[module-list], -[module-load], -[module-search], -[module-use], -[module-unuse]

-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-clear.html b/doc/html/The_module_command/module-clear.html deleted file mode 100644 index 30163d1..0000000 --- a/doc/html/The_module_command/module-clear.html +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - - - -Clear list of loaded modules - - - - - -
-
-
-
-

module clear - clear list of loaded modules.

-
-
-
-
-

SYNOPSIS

-
-
-

module clear

-
-
-
-
-

DESCRIPTION

-
-
-

Force the Pmodules package to believe that no modules are currently loaded. The sub-command clear does not unload the loaded modules! In other words: changes made to the shell’s environment by loaded modules are not reverted.

-
-
-
-
-

EXAMPLES

-
-
-

After loading the module for gcc/4.9.2 the following environment variables are set:

-
-
-
-
$ env | grep ^GCC
-GCC_HOME=/opt/psi/Programming/gcc/4.9.2
-GCC_DIR=/opt/psi/Programming/gcc/4.9.2
-GCC_PREFIX=/opt/psi/Programming/gcc/4.9.2
-GCC_VERSION=4.9.2
-GCC_INCLUDE_DIR=/opt/psi/Programming/gcc/4.9.2/include
-GCC_LIBRARY_DIR=/opt/psi/Programming/gcc/4.9.2/lib
-
-
-
-

After clearing the list of loaded modules the environment variables set by the GCC module are still set

-
-
-
-
$ module clear
-$ module list
-No Modulefiles Currently Loaded.
-$ env | grep ^GCC
-GCC_HOME=/opt/psi/Programming/gcc/4.9.2
-GCC_DIR=/opt/psi/Programming/gcc/4.9.2
-GCC_PREFIX=/opt/psi/Programming/gcc/4.9.2
-GCC_VERSION=4.9.2
-GCC_INCLUDE_DIR=/opt/psi/Programming/gcc/4.9.2/include
-GCC_LIBRARY_DIR=/opt/psi/Programming/gcc/4.9.2/lib
-
-
-
-
-
-

SEE ALSO

-
-
-

[module-purge], [module-load]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-display.html b/doc/html/The_module_command/module-display.html deleted file mode 100644 index 4f3b8d7..0000000 --- a/doc/html/The_module_command/module-display.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - - - - - -Display information about a module - - - - - -
-
-
-
-

module display\|show - display information about chances in environment

-
-
-
-
-

SYNOPSIS

-
-
-

module display modulefile…​
-module show modulefile…​

-
-
-
-
-

DESCRIPTION

-
-
-

Display information about modulefile(s). The display sub-command will list the full path of the modulefile(s) and all of the environment changes the modulefile(s) will make if loaded. (It will not display any environment changes found within conditional statements.)

-
-
-
-
-

EXAMPLES

-
-
-

Display chances the module gcc/5.4.0 will make to the environment if loaded:

-
-
-
-
$ module display gcc/5.4.0
--------------------------------------------------------------------
-/opt/psi/Programming/modulefiles/gcc/5.4.0:
-
-module-whatis	 GNU Compiler Collection
-conflict	 gcc
-setenv		 GCC_VERSION 5.4.0
-setenv		 GCC_PREFIX /opt/psi/Programming/gcc/5.4.0
-setenv		 GCC_DIR /opt/psi/Programming/gcc/5.4.0
-setenv		 GCC_HOME /opt/psi/Programming/gcc/5.4.0
-prepend-path	 PATH /opt/psi/Programming/gcc/5.4.0/bin
-prepend-path	 MANPATH /opt/psi/Programming/gcc/5.4.0/share/man
-prepend-path	 C_INCLUDE_PATH /opt/psi/Programming/gcc/5.4.0/include
-prepend-path	 CPLUS_INCLUDE_PATH /opt/psi/Programming/gcc/5.4.0/include
-setenv		 GCC_INCLUDE_DIR /opt/psi/Programming/gcc/5.4.0/include
-prepend-path	 LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib
-prepend-path	 LD_LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib
-setenv		 GCC_LIBRARY_DIR /opt/psi/Programming/gcc/5.4.0/lib
-prepend-path	 LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib64
-prepend-path	 LD_LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib64
-setenv		 GCC_LIBRARY_DIR /opt/psi/Programming/gcc/5.4.0/lib64
-append-path	 PMODULES_LOADED_PROGRAMMING gcc/5.4.0
-remove-path	 PMODULES_LOADED_PROGRAMMING --APPMARKER--
-setenv		 COMPILER gcc
-setenv		 COMPILER_VERSION 5.4.0
-setenv		 CC /opt/psi/Programming/gcc/5.4.0/bin/gcc
-setenv		 CXX /opt/psi/Programming/gcc/5.4.0/bin/g++
-setenv		 F77 /opt/psi/Programming/gcc/5.4.0/bin/gfortran
-setenv		 F90 /opt/psi/Programming/gcc/5.4.0/bin/gfortran
-setenv		 FC /opt/psi/Programming/gcc/5.4.0/bin/gfortran
-setenv		 FORTRAN /opt/psi/Programming/gcc/5.4.0/bin/gfortran
--------------------------------------------------------------------
-
-
-
-
-
-

SEE ALSO

-
-
-

[module-help]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-help.html b/doc/html/The_module_command/module-help.html deleted file mode 100644 index fcf4645..0000000 --- a/doc/html/The_module_command/module-help.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - - - -Print sub-command or module-specific help - - - - - -
-
-
-
-

module help - print sub-command or module-specific help

-
-
-
-
-

SYNOPSIS

-
-
-

module help [module|sub-command…​]

-
-
-
-
-

DESCRIPTION

-
-
-

Print help for specific modules, sub-commands or the module command itself.

-
-
-
-
-

EXAMPLES

-
-
-

Get help for the module git/2.3.3:

-
-
-
-
$ module help git/2.3.3
-
------------ Module Specific Help for 'git/2.3.3' ------------------
-
-distributed version control system
-Version:    2.3.3
-Homepage:   http://git-scm.com/
-License:    GNU GPL v2
-Maintainer: Achim Gsell <achim.gsell@psi.ch>
-
-Git is a free and open source distributed version control system
-designed to handle everything from small to very large projects
-with speed and efficiency.
-
-Git is easy to learn and has a tiny footprint with lightning fast
-performance. It outclasses SCM tools like Subversion, CVS, Perforce,
-and ClearCase with features like cheap local branching, convenient
-staging areas, and multiple workflows.
-
-
-
-

Print help for the sub-command load:

-
-
-
-
$ module help load
-
-USAGE:
-        module add     modulefile...
-        module load    modulefile...
-                Load modulefile(s) into the shell environment. Loading a
-		'group-head' will extend the MODULEPATH. E.g.: loading a
-		compiler makes additional modules like openmpi and libraries
-		compiled with this compiler available.
-
-
-
-
-
-

SEE ALSO

-
-
-

[module-whatis]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-initcmds.html b/doc/html/The_module_command/module-initcmds.html deleted file mode 100644 index 25c2473..0000000 --- a/doc/html/The_module_command/module-initcmds.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - - -Manipulate shell’s initialization file - - - - - -
-
-

NAME

-
-
-

module initadd|initprepend|initrm|initswitch|initrm|initlist|initclear - add or remove modules from shell’s initialization file

-
-
-
-
-

SYNOPSIS

-
-
-

module initadd module…​
-module initprepend module…​
-module initrm module…​
-module initswitch module1 module2
-module initlist
-module initclear

-
-
-
-
-

DESCRIPTION

-
-
-

Add modulefile(s) to, list modulefile(s) in or remove modulefile(s) from the shell’s initialization file in the user’s home directory. The startup files checked (in order) are:

-
-
-
-
csh
-
-

.modules, .cshrc(.ext), .csh_variables, and .login(.ext)

-
-
tcsh
-
-

.modules, .tcshrc, .cshrc(.ext), .csh_variables, and .login(.ext)

-
-
bash
-
-

.modules, .bash_profile, .bash_login, .profile(.ext), and .bashrc(.ext)

-
-
zsh
-
-

.modules, .zcshrc(.ext), .zshenv(.ext), and .zlogin(.ext)

-
-
module initadd module…​
-
-

If a module load line is found in any of these files, the modulefile(s) is(are) appended to any existing list of modulefiles. The module load line must be located in at least one of the files listed above for any of the init sub-commands to work properly. If the module load line is found in multiple shell initialization files, all of the lines are changed.

-
-
module initprepend module…​
-
-

Does the same as initadd but prepends the given modules to the beginning of the list.

-
-
module initrm module…​
-
-

Remove modulefile(s) from the shell’s initialization files.

-
-
module initswitch module1 module2
-
-

Switch module1 with module2 in the shell’s initialization files.

-
-
module initlist
-
-

List all of the module(s) loaded from the shell’s initialization file.

-
-
module initclear
-
-

Clear all of the module(s) from the shell’s initialization files.

-
-
-
-
-
-
-

SEE ALSO

-
-
-

[module-load], [module-load], [module-switch]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-keyword.html b/doc/html/The_module_command/module-keyword.html deleted file mode 100644 index 98b35d3..0000000 --- a/doc/html/The_module_command/module-keyword.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - - - -Show/search 'whatis' information - - - - - -
-
-
-
-

module keyword|apropos - search for keywords in 'whatis'

-
-
-
-
-

SYN[]OPSIS

-
-
-

module apropos string…​
-module keyword string…​

-
-
-
-
-

Description

-
-
-

Search through the 'whatis' informations of all modulefiles for the specified string. All whatis informations matching the string will be displayed.

-
-
-
-
-

EXAMPLES

-
-
-
-
$ module keyword editor
------------ /opt/psi/Tools/modulefiles -------------
-          emacs/24.3: extensible, customizable text editor—and more
-          emacs/24.4: extensible, customizable text editor—and more
-          emacs/24.5: extensible, customizable text editor—and more
-          emacs/25.1: extensible, customizable text editor—and more
------------ /opt/psi/Programming/modulefiles -------------
-
-
-
-
-
-

SEE ALSO

-
-
-

[module-help], [module-whatis]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-list.html b/doc/html/The_module_command/module-list.html deleted file mode 100644 index 06b88c7..0000000 --- a/doc/html/The_module_command/module-list.html +++ /dev/null @@ -1,122 +0,0 @@ - - - - - - - - -List loaded modules - - - - - -
-
-
-
-

module list - list loaded modules

-
-
-
-
-

SYNOPSIS

-
-
-

module list [OPTIONS]

-
-
-
-
-

DESCRIPTION

-
-
-

List loaded modules.

-
-
-
-
-

OPTIONS

-
-
-
-
-t | --terse
-
-

Terse output.

-
-
-h | --human
-
-

Human readable output. This is the default.

-
-
-l | --long
-
-

Long output.

-
-
-
-
-
-
-

EXAMPLES

-
-
-

Assuming the modules gcc/4.8.3, openmpi/1.8.2 and hdf5/1.8.12. List with default (human readable) output:

-
-
-
-
$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.8.3       2) openmpi/1.8.2   3) hdf5/1.8.12
-
-
-
-

List in terse output:

-
-
-
-
$ module list -t
-Currently Loaded Modulefiles:
-gcc/4.8.3
-openmpi/1.8.2
-hdf5/1.8.12
-
-
-
-

Long listing:

-
-
-
-
$ module list -l
-- Package -----------------------------+- Versions -+- Last mod. ------
-Currently Loaded Modulefiles:
-gcc/4.8.3                                            2014/12/05 17:39:24
-openmpi/1.8.2                                        2014/11/25  8:15:40
-hdf5/1.8.12                                          2014/11/25  8:15:40
-
-
-
-
-
-

SEE ALSO

-
-
-

[module-load], [module-avail]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-load.html b/doc/html/The_module_command/module-load.html deleted file mode 100644 index e5fc8b9..0000000 --- a/doc/html/The_module_command/module-load.html +++ /dev/null @@ -1,207 +0,0 @@ - - - - - - - - -Load and unloading a module - - - - - -
-
-
-
-

module add|load - load modules
-module rm|unload - unload modules

-
-
-
-
-

SYNOPSIS

-
-
-

module add [OPTIONS] modulefile…​
-module load [OPTIONS] modulefile…​
-module rm modulefile…​
-module unload modulefile…​

-
-
-
-
-

DESCRIPTION

-
-
-

Load modulefile(s) into shell environment. Loading a group-head will extend the MODULEPATH. E.g.: loading a compiler makes additional modules like openmpi and other libraries/packages compiled with this compiler available.

-
-
-

If you try to load a module which is not available in the current MODULEPATH but installed in the module hierarchy, a message will be printed showing prerequisite modules.

-
-
-

If you load a deprecated or unstable module, a warning will be printed.

-
-
-

You can change the verbosity of the load sub-command by setting the environment variable PMODULES_VERBOSITY to silent, warn or verbose.

-
-
-
-
silent
-
-

Print error messages only.

-
-
warn
-
-

Print a warning message, when loading a deprecated or unstable module.

-
-
verbose
-
-

Print warning messages and print prerequisite modules if the module to load is not available, but installed in hierarchy.

-
-
-
-
-
-
-

OPTIONS / FLAGS

-
-
-
-
-f | --force
-
-

Force active dependency resolution. This will result in modules found on a prereq command inside a module file being load automatically. Unloading module files using this switch will result in all required modules which have been loaded automatically using the -f switch being unload. This switch is experimental at the moment.

-
-
-v | --verbose
-
-

Set verbosity level to verbose.

-
-
-w | --warn
-
-

Set verbosity level to warn.

-
-
-s | --silent
-
-

Set verbosity level to silent.

-
-
-
-
-
-
-

EXAMPLES (add|load)

-
-
-

Loading the modules gcc/4.9.2, openmpi/1.8.4 and hdf5/1.8.14:

-
-
-
-
$ module load gcc/4.9.2
-$ module load openmpi/1.8.4
-$ module load hdf5/1.8.14
-$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2       2) openmpi/1.8.4   3) hdf5/1.8.14
-
-
-
-

or

-
-
-
-
$ module load gcc/4.9.2 openmpi/1.8.4 hdf5/1.8.14
-
-
-
-

If you try to load hdf5/1.8.14 without the prerequisite modules, some "hints" will be printed, if the default verbosity level is set:

-
-
-
-
$ module purge
-$ module load hdf5/1.8.14
-The module 'hdf5/1.8.14' cannot be loaded!
-Try with one of the following command(s):
-
-module load gcc/4.7.4 openmpi/1.6.5 hdf5/1.8.14
-module load gcc/4.7.4 openmpi/1.8.2 hdf5/1.8.14
-module load gcc/4.7.4 openmpi/1.8.4 hdf5/1.8.14
-module load gcc/4.8.3 openmpi/1.6.5 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.3 openmpi/1.8.2 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.3 openmpi/1.8.4 hdf5/1.8.14
-module load gcc/4.8.4 openmpi/1.6.5 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.4 openmpi/1.8.2 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.4 openmpi/1.8.4 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.4 openmpi/1.8.8 hdf5/1.8.14
-module use deprecated; module load gcc/4.9.2 openmpi/1.6.5 hdf5/1.8.14
-module use deprecated; module load gcc/4.9.2 openmpi/1.8.2 hdf5/1.8.14
-module use deprecated; module load gcc/4.9.2 openmpi/1.8.4 hdf5/1.8.14
-
-
-
-

Use verbosity level warn to suppress the hints:

-
-
-
-
$ module load hdf5/1.8.14 --warn
-module load: module unavailable -- hdf5/1.8.14
-
-
-
-

Loading an unstable module:

-
-
-
-
$ module use unstable
-$ module load cmake/3.1.3
-Warning: the unstable module 'cmake/3.1.3' has been loaded.
-
-
-
-

To supress the warning, use the --silent option.

-
-
-
-
-

EXAMPLES (rm|unload)

-
-
-
-
$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2       2) openmpi/1.8.4   3) hdf5/1.8.14
-$ module rm openmpi/1.8.4
-$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2
-
-
-
-

The module hdf5/1.8.14 is unloaded as a dependency of openmpi/1.8.4.

-
-
-
-
-

SEE ALSO

-
-
-

[module-use], module load|unload, [module-purge], [module-swap], [module-list]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-purge.html b/doc/html/The_module_command/module-purge.html deleted file mode 100644 index c4da769..0000000 --- a/doc/html/The_module_command/module-purge.html +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - - - -Purge all loaded modules - - - - - -
-
-
-
-

module purge - purge all loaded modules

-
-
-
-
-

SYNOPSIS

-
-
-

module purge

-
-
-
-
-

DESCRIPTION

-
-
-

Unload all loaded module and reset everything to original state.

-
-
-
-
-

EXAMPLES

-
-
-

List loaded modules:

-
-
-
-
$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.8.3       2) openmpi/1.8.2   3) gnuplot/4.6.3
-
-
-
-

Now we purge everything and list the loaded modules again:

-
-
-
-
$ module purge
-$ module list
-No Modulefiles Currently Loaded.
-
-
-
-
-
-

SEE ALSO

-
-
-

[module-load], [module-load], [module-clear]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-refresh.html b/doc/html/The_module_command/module-refresh.html deleted file mode 100644 index db0e001..0000000 --- a/doc/html/The_module_command/module-refresh.html +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - - - -Refresh loaded modules - - - - - -
-
-
-
-

module refresh - refresh loaded modules

-
-
-
-
-

SYNOPSIS

-
-
-

module refresh

-
-
-
-
-

DESCRIPTION

-
-
-

Force a refresh of all non-persistent components of currently loaded modules. This should be used on derived shells where aliases need to be reinitialized but the environment variables have already been set by the currently loaded modules.

-
-
-
-
-

SEE ALSO

-
-
-

[module-load]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-search.html b/doc/html/The_module_command/module-search.html deleted file mode 100644 index 856660a..0000000 --- a/doc/html/The_module_command/module-search.html +++ /dev/null @@ -1,138 +0,0 @@ - - - - - - - - -Search modules - - - - - -
-
-
-
-

module search - search installed modules

-
-
-
-
-

SYNOPSIS

-
-
-

module search [switches] string…​

-
-
-
-
-

DESCRIPTION

-
-
-

List all modules in the current MODULEPATH and the module hierarchy. If an argument is given, search for modules whose name match the argument. -Options

-
-
-
-
-

OPTIONS

-
-
-
-
--no-header
-
-

Suppress output of a header.

-
-
--release=RELEASE
-
-

Search for modules within this release. You can specify this switch multiple times. Without this switch, the used releases will be searched.

-
-
-a|--all-releases
-
-

Search within all releases.

-
-
--with=STRING
-
-

Search for modules compiled with modules matching string. The command. See example below.

-
-
--src=dir
-
-

Search module hierarchy in dir. -Eine Textbeschreibung der Funktionsweise des Befehls oder der Funktion. (Üblicherweise jedoch nicht der Benutzung, siehe unten.)

-
-
-
-
-
-
-

EXAMPLES

-
-
-

Get list of all installed GCC:

-
-
-
-
$ module search --all-releases gcc
-Module               Release    Group        Requires
-------------------------------------------------------------
-gcc/4.7.4            stable     Programming
-gcc/4.8.2            stable     Programming
-gcc/4.8.3            stable     Programming
-gcc/4.8.4            stable     Programming
-gcc/4.8.5            stable     Programming
-gcc/4.9.2            stable     Programming
-gcc/4.9.3            stable     Programming
-gcc/4.9.4            stable     Programming
-gcc/5.1.0            deprecated Programming
-gcc/5.2.0            deprecated Programming
-gcc/5.3.0            stable     Programming
-gcc/5.4.0            stable     Programming
-gcc/6.1.0            stable     Programming
-gcc/6.2.0            stable     Programming
-gcc/6.3.0            stable     Programming
-gcc/6.4.0            stable     Programming
-gcc/7.1.0            stable     Programming
-gcc/7.2.0            stable     Programming
-
-
-
-

Get list of all open-mpi versions compiled with GCC 5.4.0:

-
-
-
-
$ module search --all-releases openmpi --with=gcc/5.4.0
-Module               Release    Group        Requires
-------------------------------------------------------------
-openmpi/1.10.2       stable     Compiler     gcc/5.4.0
-openmpi/1.10.4       stable     Compiler     gcc/5.4.0
-openmpi/2.0.1        stable     Compiler     gcc/5.4.0
-
-
-
-
-
-

SEE ALSO

-
-
-

[module-avail]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-swap.html b/doc/html/The_module_command/module-swap.html deleted file mode 100644 index afc9b8c..0000000 --- a/doc/html/The_module_command/module-swap.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - - -Swapping modules - - - - - -
-
-
-
-

module swap|switch - replace a loaded module by another

-
-
-
-
-

SYNOPSIS

-
-
-

module swap [modulefile1] modulefile2
-module switch [modulefile1] modulefile2

-
-
-
-
-

DESCRIPTION

-
-
-

Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified, then it is assumed to be the currently loaded module with the same root name as modulefile2.

-
-
-
-
-

OPTIONS / FLAGS

-
-
-

None

-
-
-
-
-

EXAMPLES

-
-
-
-
$ module load gcc/4.8.4
-$ module swap gcc/4.9.2
-$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2
-
-
-
-
-
-

BUGS

-
-
-

You can only swap between different version. The following commands are working (assuming that gcc/4.8.2 is loaded):

-
-
-
-
$ module swap gcc/4.9.2
-$ module swap gcc/4.9.2 gcc/5.4.0
-
-
-
-

The following command does not working as expected:

-
-
-
-
$ module swap gcc/4.8.2 intel/15.0
-
-
-
-

This command does not work with the Tcl implementation (environment variable PMOUDLE_PURETCL set).

-
-
-
-
-

SEE ALSO

-
-
-

[module-load], [module-load], [module-list]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-use.html b/doc/html/The_module_command/module-use.html deleted file mode 100644 index 065c8f1..0000000 --- a/doc/html/The_module_command/module-use.html +++ /dev/null @@ -1,197 +0,0 @@ - - - - - - - - -Manipulate module path, used releases, groups or overlays - - - - - -
-
-
-
-

module use|unuse - manipulate module path, used releases or groups

-
-
-
-
-

SYNOPSIS

-
-
-

module use [OPTIONS] [string…​]

-
-
-

module unuse string…​

-
-
-
-
-

DESCRIPTION

-
-
-

If called without arguments, print a summary about used groups, releases and additional directories in MODULEPATH.

-
-
-

If string is a directory, append, prepend or remove this directory to/from MODULEPATH.

-
-
-

If string is a group name, append, prepend or remove the corresponding directory to/from MODULEPATH.

-
-
-

If string is a releases name, make all modules with this release available/unavailable. Known releases are;

-
-
-
-
stable
-
-

Modules released as stable are considered to be production ready. The files of a stable module will never change.

-
-
unstable
-
-

These modules are still unstable. They may not be ready for production use. The files of unstable modules may change to fix bugs or add functionality. Use at your own risk.

-
-
deprecated
-
-

Deprecated modules should not be used any more and may be removed without further notice.

-
-
-
-
-

If string matches flag=[-_a-zA-Z0-9]* the RHS will be interpreted as use-flag.

-
-
-
-
-

OPTIONS / FLAGS

-
-
-
-
-a | --append
-
-

append directory or group to MODULEPATH.

-
-
-p | --prepend
-
-

prepend directory or group to MODULEPATH.

-
-
-
-
-
-
-

EXAMPLES

-
-
-

List used/unused groups, releases and additional directories in MODULEPATH:

-
-
-
-
$ module use
-Used groups:
-	Tools
-	Programming
-	Compiler
-
-Unused groups:
-	Legacy
-	Libraries
-	System
-
-Used releases:
-	stable
-	unstable
-
-Unused releases:
-	deprecated
-
-Used flags:
-	omp
-
-Additonal directories in MODULEPATH:
-	none
-
-
-
-

Adding the 'System' group

-
-
-
-
$ module use System
-$ module avail
--------------------------------------------- System:  --------------------------------------------
-
-filebench/1.4.9.1               fsstress/1.0.0  nmap/6.46       patchelf/0.8.1
-
--------------------------------------------- Tools:  --------------------------------------------
-
-ANSYS/18.2      emacs/24.4      git/2.3.3       global/6.3.1    gnuplot/4.6.3   gnuplot/5.0.0
-...
-
------------------------------------------ Programming:  -----------------------------------------
-
-autoconf/2.69   automake/1.14   automake/1.15   binutils/2.25   cmake/2.8.12.2  cmake/3.1.3
-cmake/3.6.3     gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/4.8.5
-...
-
-
-
-

Adding a directory to MODULEPATH

-
-
-
-
$ module use /afs/psi.ch/project/amas/modulefiles
-$ module avail
------------------------------------ /afs/psi.ch/project/amas:  -----------------------------------
-
-H5hut_parallel-toolchain/2.0    H5hut_serial-toolchain/2.0      OPAL/1.6        OPAL/1.6.0rc5
-opal-toolschain/1.6             opal-toolschain/2.0
-
--------------------------------------------- Tools:  --------------------------------------------
-
-ANSYS/18.2      emacs/24.4      git/2.3.3       global/6.3.1    gnuplot/4.6.3   gnuplot/5.0.0
-...
------------------------------------------ Programming:  -----------------------------------------
-
-autoconf/2.69   automake/1.14   automake/1.15   binutils/2.25   cmake/2.8.12.2  cmake/3.1.3
-cmake/3.6.3     gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/4.8.5
-...
-
-
-
-
-
$ module unuse /afs/psi.ch/project/amas/modulefiles
-$ module unuse System
-$ module unuse unstable
-
-
-
-
-
-

SEE ALSO

-
-
-

[module-unuse], [module-avail], [module-search]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module-whatis.html b/doc/html/The_module_command/module-whatis.html deleted file mode 100644 index bc5070d..0000000 --- a/doc/html/The_module_command/module-whatis.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - - - -Show/search 'what is' information - - - - - -
-
-
-
-

module whatis - print one-line information about module -module keyword|apropos - search for keywords in 'whatis'

-
-
-
-
-

SYNOPSIS

-
-
-

module whatis [module…​]
-module apropos string…​
-module keyword string…​

-
-
-
-
-

DESCRIPTION

-
-
-
-
whatis
-
-

Display the information set up by the module-whatis commands inside -the specified modulefile(s). If no modulefile is specified, all whatis -lines will be shown.

-
-
keyword|apropos
-
-

Search through the 'whatis' informations of all modulefiles for the -specified string. All whatis informations matching the string will be -displayed.

-
-
-
-
-
-
-

EXAMPLES

-
-
-

Get whatis for all available Git modules

-
-
-
-
$ module  whatis git
------------ /opt/psi/Tools/modulefiles -------------
-           git/2.3.3: distributed version control system
-           git/2.5.2: distributed version control system
-           git/2.8.1: distributed version control system
-          git/2.11.1: distributed version control system
------------ /opt/psi/Programming/modulefiles -------------
-
-
-
-
-
-

SEE ALSO

-
-
-

[module-help]

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/The_module_command/module.html b/doc/html/The_module_command/module.html deleted file mode 100644 index 0f12e3d..0000000 --- a/doc/html/The_module_command/module.html +++ /dev/null @@ -1,119 +0,0 @@ - - - - - - - -module - using Pmodules - - - - - -
-
-

NAME

-
-
-

module - command line interface to the Pmodules package

-
-
-
-
-

SYNOPSIS

-
-
-

module [ switches ] [ sub-command ] [ sub-command-args ]

-
-
-
-
-

DESCRIPTION

-
-
-

Environment Modules provide a convenient way to dynamically change the -users' environment through modulefiles. This includes easily adding or -removing directories to the PATH environment variable. -A modulefile contains the necessary information to allow a user to run -a particular application or provide access to a particular -library. All of this can be done dynamically without logging out and -back in. Modulefiles for applications modify the user’s shell -environment to make access easy. Modulefiles for Library packages -provide environment variables that specify where the library and -header files can be found. -Packages can be loaded and unloaded cleanly through the module command.

-
-
-

Available sub-commands are:

-
-
-

List available modules: [module-avail]

-
-
-

Clear list of loaded modules: [module-clear]

-
-
-

Display information about chances in environment when loaded: [module-display]

-
-
-

Print sub-command or module-specific help: [module-help]

-
-
-

Add or remove modules from shell’s initialization file: [module-initcmds]

-
-
-

Search for keywords in 'whatis': [module-keyword]

-
-
-

List loaded modules: [module-list]

-
-
-

Load and unload modules: [module-load]

-
-
-

Purge all loaded modules: [module-purge]

-
-
-

Refresh loaded modules: [module-refresh]

-
-
-

Search installed modules: [module-search]

-
-
-

Replace a loaded module by another: [module-swap]

-
-
-

Manipulate module path, used releases, groups and overlays: [module-use]

-
-
-

Search for keywords in 'whatis': [module-whatis]

-
-
- - - - - -
- - -
-

For the time being Pmodules supports bash, tcsh and zsh only.

-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/Writing-a-modulefile.html b/doc/html/Writing-a-modulefile.html deleted file mode 100644 index a565cc8..0000000 --- a/doc/html/Writing-a-modulefile.html +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - - -Writing modulefiles - - - - - -
-
-

Writing modulefiles

-
-
-

modulefiles for the Pmodules Environment

-
-

The Pmodules environment modules are an extension to the well known Tcl Environment Modules. modulefiles written for the Tcl Environment Modules are fully supported by Pmodules. All Tcl extensions for the Tcl Environment Modules are supported by Pmodules. Pmodules introduces a few additional commands and features described in the next section.

-
-
-

The shebang ("magic cookie") for Pmodules is #%Pmodules.

-
-
-
-

Pmodules extensions

-
-

Extensions for hierarchical groups

-
-
module-addgroup
-
-
Synopsis
-
-
module-addgroup GROUP
-
-
-
-
Description
-

Add a the hierarchical group GROUP to MODULEPATH.

-
-
-
Example
-
-
module-addgroup Compiler
-
-
-
-
-
-

Standardize help message

-
-

The Pmodules Environment Modules provide a standardized ModulesHelp procedure. With the following functions, the content of the help message will be setup.

-
-
-
module-url
-
-
Synopsis
-
-
module-license LICENSE
-
-
-
-
Description
-

Indicate the license of the software. LICENSE can be a string like GNU GPLv2, a path to the license file(s) installed in the module or an URL.

-
-
-
Example
-
-
module-license ""See \$GNUPLOT_DIR/share/doc/gnuplot/Copyright""
-
-
-
-
-
module-maintainer
-
-
Synopsis
-
-
module-maintainer MAINTAINER
-
-
-
-
Description
-

Indicate the maintainer of the module.

-
-
-
Example
-
-
module-maintainer "Karlheinz Mustermann <kmusermann@example.com"
-
-
-
-
-
module-help
-
-
Synopsis
-
-
module-help HELP_TEXT
-
-
-
-
Description
-

Setup a more elaborated help text for the ModulesHelp procedure.

-
-
-
Example
-
-
module-help "
-Gnuplot is a portable command-line driven graphing utility for Linux,
-OS/2, MS Windows, OSX, VMS, and many other platforms. The source code
-is copyrighted but freely distributed (i.e., you don't have to pay for
-it). It was originally created to allow scientists and students to
-visualize mathematical functions and data interactively, but has grown
-to support many non-interactive uses such as web scripting. It is also
-used as a plotting engine by third-party applications like Octave.
-Gnuplot has been supported and under active development since 1986.
-"
-
-
-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-block-files-and-hierarchy.html b/doc/html/build-block-files-and-hierarchy.html deleted file mode 100644 index 4f045c6..0000000 --- a/doc/html/build-block-files-and-hierarchy.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - -Files and directories in a build-block - - - - - -
-
-

Files and directories in a build-block

-
-
-

Mandatory files in a build-block are

-
-
-
    -
  1. -

    the build-script,

    -
    2. -
  2. -

    the modulefile

    -
    3. -
  3. -

    and a variants file

    -
    4. -
-
-
-

In some cases additional files like patches are required. These additional files might be required only for certain versions or operating systems.

-
- ---- - - - - - - - - - - - - - - - - - - - - - - - - -
$Ptop-level directory, defines the name of the module.

$P/build

build-script with instructions to build the module. This script will be executed by the modbuild interpreter.

$P/modulefile

the modulefile

$P/$V_MAJOR[.$V_MINOR[.$V_PATCH_LEVEL]]/

Directories for patches or other required files which are specific to certain versions. These directories can also be used for variant-files.

$P/files/variants[.$SYSTEM]

file specifying the variants for the module and given version. A variant specifies the build- and run-time dependencies and the release for a particular module version. The value of $SYSTEM defaults to the string returned by uname -s or can be set on the command line with the --system option.

-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-blocks-at-a-glance.html b/doc/html/build-blocks-at-a-glance.html deleted file mode 100644 index 777a3b1..0000000 --- a/doc/html/build-blocks-at-a-glance.html +++ /dev/null @@ -1,272 +0,0 @@ - - - - - - - -Build-blocks at a glance - - - - - -
-
-

Build-blocks at a glance

-
-
-

A build block-block consists of all files required to build and -install a module from source and defines the name of the module. All -files of a build-block resides in a directory with the name of the -build-block.

-
-
-

In its basic form a build-block consist of the following files:

-
- ---- - - - - - - - - - - - - - - - - - - - - -
$Ptop-level directory, also defines the name of the module.

$P/build

build-script with instructions to build the module. This script will be executed by the modbuild interpreter.

$P/modulefile

the module-file

$P/files/variants

file specifying the variants for the module and given version. A variant specifies the build- and run-time dependencies and the release for a particular module version.

-
-
-
-

The name of the module is defined by the directory of the build-block $P.

-
-
-
-
-

Example of a simple build-block

-
-

In this section we give a short and simple example of a -build-block. The following files are required to build the gnuplot -module. The build-block consist of the three files:

-
- ---- - - - - - - - - - - - - - - - - -
gnuplot/buildbuild-script

gnuplot/modulefile

module-file

gnuplot/files/variants

variants-file

-
-

The gnuplot build-script

-
-
-
#!/usr/bin/env modbuild
-
-pbuild::add_to_group 'Tools'
-
-pbuild::set_download_url \
-        "https://sourceforge.net/projects/gnuplot/files/$P/$V/$P-$V.tar.gz"
-pbuild::set_sha256sum 'gnuplot-5.2.4.tar.gz:1515f000bd373aaa53b16183f274189d4f5e0ae47d22f434857933d16a4770cb'
-pbuild::install_docfiles 'Copyright' 'ChangeLog' 'NEWS' 'README'
-
-
-
-
-

The gnuplot modulefile

-
-
-
#%PModule
-
-module-whatis		"portable command-line driven graphing utility"
-module-url		"http://www.gnuplot.info/"
-module-license		"See \$GNUPLOT_DIR/share/doc/gnuplot/Copyright"
-module-maintainer	"Achim Gsell <achim.gsell@psi.ch>"
-
-module-help		"
-Gnuplot is a portable command-line driven graphing utility for Linux,
-OS/2, MS Windows, OSX, VMS, and many other platforms. The source code
-is copyrighted but freely distributed (i.e., you don't have to pay for
-it). It was originally created to allow scientists and students to
-visualize mathematical functions and data interactively, but has grown
-to support many non-interactive uses such as web scripting. It is also
-used as a plotting engine by third-party applications like Octave.
-Gnuplot has been supported and under active development since 1986.
-"
-
-
-
-
-

The gnuplot variants file

-
-
-
gnuplot/4.6.3	stable
-gnuplot/5.0.0	stable
-gnuplot/5.2.0	stable
-gnuplot/5.2.4	stable
-
-
-
-
-
-

Example of a more complex build-block

-
-

HDF5 build-script

-
-
-
#!/usr/bin/env modbuild
-
-pbuild::set_download_url "https://support.hdfgroup.org/ftp/HDF5/releases/$P-${V_MAJOR}.${V_MINOR}/$P-$V/src/hdf5-$V.tar.bz2"
-pbuild::add_to_group 'MPI'
-
-pbuild::add_docfiles ACKNOWLEDGMENTS
-pbuild::add_docfiles COPYING
-pbuild::add_docfiles MANIFEST
-pbuild::add_docfiles README.txt
-
-pbuild::pre_configure() {
-        pbuild::add_configure_args "CC=${MPICC}"
-        pbuild::add_configure_args "CXX=${MPICXX}"
-
-        pbuild::add_configure_args "--enable-shared"
-        pbuild::add_configure_args "--enable-parallel"
-        pbuild::add_configure_args "--enable-cxx"
-        pbuild::add_configure_args "--enable-unsupported"
-        #pbuild::add_configure_args "--enable-threadsafe"
-        pbuild::add_configure_args "--with-pic"
-
-        local enable_fortran='yes'
-
-        case "${COMPILER}" in
-                clang-macos )
-                        enable_fortran='no'
-                        # we do not have Fortran in Xcode
-                        ;;
-                pgi )
-                        # PGI uses GCC's include files, some object files and
-                        # the STL implementation!
-                        # The PGI C pre-processor is broken and doesn't work
-                        # for HDF5. We use the pre-processor of the underlying
-                        # GCC...
-                        # This is a bit hackish!
-                        #
-                        # The following eval sets GCCDIR! Which is something
-                        # like:
-                        # /opt/psi/Programming/gcc/7.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.0
-                        #
-                        eval $(pgcc -show 2>/dev/null | \
-                                awk '/^GCCDIR[[:space:]]*=/{gsub(/[[:space:]]/,""); print $0}')
-                        pbuild::add_configure_args "CPP=${GCCDIR%%/..*}/cpp"
-                        pbuild::add_configure_args "CFLAGS=-fPIC"
-                        pbuild::add_configure_args "CXXFLAGS=-fPIC"
-                        pbuild::add_configure_args "FCFLAGS=-fPIC"
-                        ;;
-        esac
-
-        if [[ "${enable_fortran}" == 'yes' ]]; then
-                pbuild::add_configure_args "F77=${MPIF77}"
-                pbuild::add_configure_args "F90=${MPIF90}"
-                pbuild::add_configure_args "FC=${MPIFC}"
-                pbuild::add_configure_args "FORTRAN=${MPIFORTRAN}"
-                pbuild::add_configure_args "--enable-fortran"
-        fi
-
-}
-
-
-
-
-

The HDF5 modulefile

-
-
-
#%Module1.0
-
-module-whatis		"Hierachical Data Format 5"
-module-url		"http://www.hdfgroup.org/HDF5"
-module-license		"HDF license (BSD-like)"
-module-maintainer	"Achim Gsell <achim.gsell@psi.ch>"
-module-help		"
-HDF5 is a data model, library, and file format for storing and managing
-data. It supports an unlimited variety of datatypes, and is designed for
-flexible and efficient I/O and for high volume and complex data. HDF5 is
-portable and is extensible, allowing applications to evolve in their use
-of HDF5. The HDF5 Technology suite includes tools and applications for
-managing, manipulating, viewing, and analyzing data in the HDF5 format.
-"
-
-conflict	hdf5_serial
-module-addgroup	HDF5
-
-
-
-
-

The HDF5 1.10 variants file

-
-
-
hdf5/1.10.0	stable		gcc/4.8.5 openmpi/1.10.2
-hdf5/1.10.0	stable		gcc/4.9.3 openmpi/1.10.2
-hdf5/1.10.0	stable		gcc/5.3.0 openmpi/1.10.2
-hdf5/1.10.0	stable		gcc/6.1.0 openmpi/1.10.2
-
-hdf5/1.10.1	unstable	gcc/7.3.0 openmpi/1.10.2
-hdf5/1.10.1	unstable	gcc/7.3.0 openmpi/1.10.7
-hdf5/1.10.1	unstable	gcc/7.3.0 openmpi/2.1.2
-hdf5/1.10.1	unstable	gcc/7.3.0 openmpi/3.0.0
-hdf5/1.10.1	unstable	gcc/7.3.0 openmpi/3.0.1
-
-hdf5/1.10.1	unstable	intel/17.4 openmpi/1.10.7
-hdf5/1.10.1	unstable	intel/17.4 openmpi/2.1.2
-hdf5/1.10.1	unstable	intel/17.4 openmpi/3.0.0
-hdf5/1.10.1	unstable	intel/17.4 intel-mpi/17.4
-
-hdf5/1.10.1	unstable	pgi/18.5 pgi-mpi/18.5
-
-hdf5/1.10.2 	stable    	gcc/7.3.0 openmpi/3.0.1
-hdf5/1.10.3 	stable    	gcc/7.3.0 openmpi/3.1.2
-hdf5/1.10.3	unstable	intel/17.4 intel-mpi/17.4
-
-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-script-functions.html b/doc/html/build-script-functions.html deleted file mode 100644 index d65f72c..0000000 --- a/doc/html/build-script-functions.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - - -Build script functions - - - - - -
-
-

Build script functions

-
-
-

Setup functions

-
- -
-
-
-

Building and installing

-
- -
-
-
-

Less common functions

-
- -
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/Building-a-Pmodule.html b/doc/html/build-system/Building-a-Pmodule.html deleted file mode 100644 index 0ff28d0..0000000 --- a/doc/html/build-system/Building-a-Pmodule.html +++ /dev/null @@ -1,122 +0,0 @@ - - - - - - - - - -Building a Pmodule - - - - - -
-
-
-
-

Back to home

-
-
-

next page: Conventions and notations

-
-
-
-
-

Table of Contents

-
-
-
    -
  1. -

    Introduction

    -
    2. -
  2. -

    Conventions and notations

    -
    3. -
  3. -

    Pmodules directory structure

    -
    4. -
  4. -

    Site specific notes

    -
    5. -
  5. -

    Module names and version numbers

    -
    6. -
  6. -

    Build-blocks at a glance

    -
    7. -
  7. -

    Files and directories in a build-block

    -
    8. -
  8. -

    Writing modulefiles

    -
    9. -
  9. -

    Releases

    -
    10. -
  10. -

    Writing and maintaining variant files

    -
    11. -
  11. -

    Writing build scripts to compile a module from source

    -
    12. -
  12. -

    Build scripts functions

    -
    13. -
  13. -

    Build-blocks for binary packages

    -
    14. -
-
-
-
-
-

Introduction

-
-
-

Many modules for the Pmodules environment have to be build from -source. The building plan of a module is coded in a so called -build-block. A build-block consists of a build-script with -instruction how to download, compile and install a dedicated piece of -software, a module-file and files specifying which version should be -available and the dependencies. Optionally additional files can be -stored in a build-block, for example required patches.

-
-
-

On this Wiki page we explain how to build a module from source for the -Pmodule environment. Please make yourself familiar with the -variables used in build-blocks and -modulefiles.

-
-
-

Git repository

-
-

All build-blocks are on Gitlab in the repository git@gitlab.psi.ch:Pmodules/buildblocks.git.

-
-
-
-

Build-system

-
-

All modules should be build on the system pmod6.psi.ch. Building on -other system may cause issues like compatibility errors due to differences in installed packages or CPU instruction set.

-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/Directory-structure.html b/doc/html/build-system/Directory-structure.html deleted file mode 100644 index 7a599ef..0000000 --- a/doc/html/build-system/Directory-structure.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - -Introduction - - - - - -
-
-

Introduction

-
-

The Pmodules environment organize modules in groups. Groups are either simple or hierarchical. Modules in a simple group has no or only simple dependencies. Modules in a hierarchical group always have at least one hierarchical (run-time)dependency. See the following examples to get the idea of simple and hierarchical groups and dependencies.

-
-
-
Example 1. Hierarchical groups and dependencies
-
-
-

The module openmpi/3.1.2 is in the group Compiler. Before this module can be loaded, a compiler must loaded, for example gcc/7.3.0. The group Compiler is a hierarchical group because multiple variants of the same modules in this group exist for different compilers. In this example openmpi/3.1.2 have been compiled with gcc/6.4.0, gcc/7.3.0…​ As a consequence you have to select and load a compiler before you can load the modules in this group.

-
-
-
-
-
Example 2. Simple groups
-
-
-

The module gcc/7.3.0 is in the group Programming. This group is simple. There is no need for several variants of this modules.

-
-
-
-
-
Example 3. Simple dependencies
-
-
-

The module git/2.16.2 is in the simple group Tools. Git requires Tcl/Tk for the gui-subcommand. Simple dependencies must be loaded in the modulefile or better specified in the build-block. If specified in the build-block, they are loaded are loaded automatically.

-
-
-
-
-

In this chapter we use several variables used in build-blocks and/or modulefiles. Please read this chapter for details.

-
-
-
-

File hierarchy of a simple group

-
-
-
$PMODULES_ROOT/$GROUP
-
-

container for $GROUP.

-
-
$PMODULES_ROOT/$GROUP/modulefiles/$P/$V
-
-

modulefile for $P/$V.

-
-
$PMODULES_ROOT/$GROUP/modulefiles/$P/.release-$V
-
-

release of module $P/$V.

-
-
$PMODULES_ROOT/$GROUP/$P/$V
-
-

prefix for module $P/$V.

-
-
-
-
-
-

File hierarchy of the hierarchical group Compiler

-
-
-
$PMODULES_ROOT/Compiler
-
-

container for group Compiler

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$P/$V
-
-

modulefile for $P/$V.

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$P/.release-$V
-
-

release of module $P/$V.

-
-
…​/$P/$V/$COMPILER/$COMPILER_VERSION
-
-

prefix for module $P/$V.

-
-
-
-
-
-

File hierarchy of the hierarchical group MPI

-
-
-
$PMODULES_ROOT/MPI
-
-

container for group MPI.

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$MPI/$MPI_VERSION/$P/$V
-
-

modulefile for $P/$V.

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$MPI/$MPI_VERSION/$P/.release-$V
-
-

release of module $P/$V.

-
-
…​/$P/$V/$MPI/$MPI_VERSION/$COMPILER/$COMPILER_VERSION
-
-

prefix for module $P/$V.

-
-
-
-
-
-

File hierarchy of the hierarchical group HDF5

-
-
-
$PMODULES_ROOT/HDF5
-
-

container for group MPI.

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$MPI/$MPI_VERSION/hdf5/$HDF5_VERSION/$P/$V
-
-

modulefile for $P/$V.

-
-
…​/modulefiles/$COMPILER/$COMPILER_VERSION/$MPI/$MPI_VERSION/hdf5/$HDF5_VERSION/$P/.release-$V
-
-

release of module $P/$V.

-
-
…​/$P/$V/hdf5/$HDF5_VERSION/$MPI/$MPI_VERSION/$COMPILER/$COMPILER_VERSION
-
-

prefix for module $P/$V.

-
-
-
-
-
-

File hierarchy inside a module

-
-

The file hierarchy defined in the Linux File Hierarchy Standard should be used. In the following we document only Pmodules special features:

-
-
-
-
$PREFIX
-
-

Prefix of the module.

-
-
$PREFIX/.dependencies
-
-

Run-time dependencies, loaded automatically

-
-
$PREFIX/{bin,sbin}
-
-

If exists, added to PATH while loading.

-
-
$PREFIX/include
-
-

If exists, added to C_INCLUDE_PATH and CPLUS_INCLUDE_PATH while loading.

-
-
$PREFIX/{lib,lib64}
-
-

If exists, added to LIBRARY_PATH and LD_LIBRARY_PATH while loading

-
-
$PREFIX/lib/cmake
-
-

If exist, added to CMAKE_MODULE_PATH while loading

-
-
$PREFIX/lib/pkgconfig
-
-

If exist, added to PKG_CONFIG_PATH while loading

-
-
$PREFIX/share/man
-
-

If exists, added to MANPATH while loading.

-
-
$PREFIX/share/Pmoudles/$GROUP/$P
-
-

Build-block used to build this module

-
-
$PREFIX/share/Pmoudles/$GROUP/$P/build
-
-

Build-script

-
-
$PPREFIX/share/Pmoudles/$GROUP/$P/dependencies
-
-

All dependencies loaded while building. This includes build- and run-time dependencies.

-
-
$PREFIX/share/Pmoudles/$GROUP/$P/files/variants
-
-

Used variants-file.

-
-
$PREFIX/share/Pmoudles/$GROUP/$P/modulefile
-
-

Used Modulefile.

-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/Notations.html b/doc/html/build-system/Notations.html deleted file mode 100644 index 48c8c20..0000000 --- a/doc/html/build-system/Notations.html +++ /dev/null @@ -1,130 +0,0 @@ - - - - - - - -Conventions and notations used in this documentation and build-blocks - - - - - -
-
-

Conventions and notations used in this documentation and build-blocks

-
-
-

Since we use BASH for our build-scripts and Tcl for modulefiles, we use BASH/Tcl syntax for variables in this documentation. So, if VARIABLE is the name of a variable, $VARIABLE the value of it.

-
-
-

In modulefiles and build-scripts the following variables are predefined:

-
-
-
-
P
-
-

the name of the module

-
-
V
-
-

the module version. The version number consists of a major- and a minor version number, a patch-level and a release number. All numbers but the major version number are optional. Major-, minor number and patch-level are separated by dots, the release number by a minus. Example: 1.0.3-2

-
-
V_MAJOR
-
-

the major version number. Example: 1

-
-
V_MINOR
-
-

the minor version number. Example: 0

-
-
V_PATCHLVL
-
-

the patch-level. Example: 3

-
-
V_RELEASE
-
-

the release number. Example: 2

-
-
V_PKG
-
-

version number without release.

-
-
GROUP
-
-

group the module is in.

-
-
PREFIX
-
-

installation prefix of the module.

-
-
PMODULES_ROOT
-
-

root of Pmodules installation. At PSI this is /opt/psi.

-
-
-
-
-

In build-scripts the following variables are predefined too:

-
-
-
-
TEMP_DIR
-
-

directory for temporary files.

-
-
SRC_DIR
-
-

directory of unpacked sources, set to $PMODULES_TMPDIR/$P-$V/src

-
-
BUILD_DIR
-
-

build directory, set to $PMODULES_TMPDIR/$P-$V/build

-
-
BUILDBLOCK_DIR
-
-

Directory where the build-script is in.

-
-
BUILD_SCRIPT
-
-

Name of the build script.

-
-
SYSTEM,OS
-
-

Can be set with the --system option. The value defaults to the string returned by uname -s. The use of OS is obsolete.

-
-
-
-
-

In modulefiles the following variables are predefined too:

-
-
-
-
name
-
-

Same as P (obsolete, for historical reasons).

-
-
version
-
-

Same as V (obsolete, for historical reasons).

-
-
group
-
-

The group the module is member of.

-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/Writing-a-modulefile.html b/doc/html/build-system/Writing-a-modulefile.html deleted file mode 100644 index e4d75bc..0000000 --- a/doc/html/build-system/Writing-a-modulefile.html +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - - -Writing modulefiles - - - - - -
-
-

Writing modulefiles

-
-
-

modulefiles for the Pmodules Environment

-
-

The Pmodules environment modules are an extension to the well known Tcl Environment Modules. modulefiles written for the Tcl Environment Modules are fully supported by Pmodules. All Tcl extensions for the Tcl Environment Modules are supported by Pmodules. Pmodules introduces a few additional commands and features described in the next section.

-
-
-

The shebang ("magic cookie") for Pmodules is #%Pmodules.

-
-
-
-

Pmodules extensions

-
-

Extensions for hierarchical groups

-
-
module-addgroup
-
-
Synopsis
-
-
module-addgroup GROUP
-
-
-
-
Description
-

Add a the hierarchical group GROUP to MODULEPATH.

-
-
-
Example
-
-
module-addgroup Compiler
-
-
-
-
-
-

Standardize help message

-
-

The Pmodules Environment Modules provide a standardized ModulesHelp procedure. With the following functions, the content of the help message will be setup.

-
-
-
module-url
-
-
Synopsis
-
-
module-license LICENSE
-
-
-
-
Description
-

Indicate the license of the software. LICENSE can be a string like GNU GPLv2, a path to the license file(s) installed in the module or an URL.

-
-
-
Example
-
-
module-license ""See \$GNUPLOT_DIR/share/doc/gnuplot/Copyright""
-
-
-
-
-
module-maintainer
-
-
Synopsis
-
-
module-maintainer MAINTAINER
-
-
-
-
Description
-

Indicate the maintainer of the module.

-
-
-
Example
-
-
module-maintainer "Karlheinz Mustermann <kmusermann@example.com"
-
-
-
-
-
module-help
-
-
Synopsis
-
-
module-help HELP_TEXT
-
-
-
-
Description
-

Setup a more elaborated help text for the ModulesHelp procedure.

-
-
-
Example
-
-
module-help "
-Gnuplot is a portable command-line driven graphing utility for Linux,
-OS/2, MS Windows, OSX, VMS, and many other platforms. The source code
-is copyrighted but freely distributed (i.e., you don't have to pay for
-it). It was originally created to allow scientists and students to
-visualize mathematical functions and data interactively, but has grown
-to support many non-interactive uses such as web scripting. It is also
-used as a plotting engine by third-party applications like Octave.
-Gnuplot has been supported and under active development since 1986.
-"
-
-
-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/build-block-files-and-hierarchy.html b/doc/html/build-system/build-block-files-and-hierarchy.html deleted file mode 100644 index 4f2f377..0000000 --- a/doc/html/build-system/build-block-files-and-hierarchy.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - -Files and directories in a build-block - - - - - -
-
-

Files and directories in a build-block

-
-
-

Mandatory files in a build-block are

-
-
-
    -
  1. -

    the build-script,

    -
    2. -
  2. -

    the modulefile

    -
    3. -
  3. -

    and a variants file

    -
    4. -
-
-
-

In some cases additional files like patches are required. These additional files might be required only for certain versions or operating systems.

-
- ---- - - - - - - - - - - - - - - - - - - - - - - - - -
$Ptop-level directory, defines the name of the module.

$P/build

build-script with instructions to build the module. This script will be executed by the modbuild interpreter.

$P/modulefile

the modulefile

$P/$V_MAJOR[.$V_MINOR[.$V_PATCH_LEVEL]]/

Directories for patches or other required files which are specific to certain versions. These directories can also be used for variant-files.

$P/files/variants[.$SYSTEM]

file specifying the variants for the module and given version. A variant specifies the build- and run-time dependencies and the release for a particular module version. The value of $SYSTEM defaults to the string returned by uname -s or can be set on the command line with the --system option.

-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/build-blocks-at-a-glance.html b/doc/html/build-system/build-blocks-at-a-glance.html deleted file mode 100644 index 43f6bc2..0000000 --- a/doc/html/build-system/build-blocks-at-a-glance.html +++ /dev/null @@ -1,272 +0,0 @@ - - - - - - - -Build-blocks at a glance - - - - - -
-
-

Build-blocks at a glance

-
-
-

A build block-block consists of all files required to build and -install a module from source and defines the name of the module. All -files of a build-block resides in a directory with the name of the -build-block.

-
-
-

In its basic form a build-block consist of the following files:

-
- ---- - - - - - - - - - - - - - - - - - - - - -
$Ptop-level directory, also defines the name of the module.

$P/build

build-script with instructions to build the module. This script will be executed by the modbuild interpreter.

$P/modulefile

the module-file

$P/files/variants

file specifying the variants for the module and given version. A variant specifies the build- and run-time dependencies and the release for a particular module version.

-
-
-
-

The name of the module is defined by the directory of the build-block $P.

-
-
-
-
-

Example of a simple build-block

-
-

In this section we give a short and simple example of a -build-block. The following files are required to build the gnuplot -module. The build-block consist of the three files:

-
- ---- - - - - - - - - - - - - - - - - -
gnuplot/buildbuild-script

gnuplot/modulefile

module-file

gnuplot/files/variants

variants-file

-
-

The gnuplot build-script

-
-
-
#!/usr/bin/env modbuild
-
-pbuild::add_to_group 'Tools'
-
-pbuild::set_download_url \
-        "https://sourceforge.net/projects/gnuplot/files/$P/$V/$P-$V.tar.gz"
-pbuild::set_sha256sum 'gnuplot-5.2.4.tar.gz:1515f000bd373aaa53b16183f274189d4f5e0ae47d22f434857933d16a4770cb'
-pbuild::install_docfiles 'Copyright' 'ChangeLog' 'NEWS' 'README'
-
-
-
-
-

The gnuplot modulefile

-
-
-
#%PModule
-
-module-whatis		"portable command-line driven graphing utility"
-module-url		"http://www.gnuplot.info/"
-module-license		"See \$GNUPLOT_DIR/share/doc/gnuplot/Copyright"
-module-maintainer	"Achim Gsell <achim.gsell@psi.ch>"
-
-module-help		"
-Gnuplot is a portable command-line driven graphing utility for Linux,
-OS/2, MS Windows, OSX, VMS, and many other platforms. The source code
-is copyrighted but freely distributed (i.e., you don't have to pay for
-it). It was originally created to allow scientists and students to
-visualize mathematical functions and data interactively, but has grown
-to support many non-interactive uses such as web scripting. It is also
-used as a plotting engine by third-party applications like Octave.
-Gnuplot has been supported and under active development since 1986.
-"
-
-
-
-
-

The gnuplot variants file

-
-
-
gnuplot/4.6.3	stable
-gnuplot/5.0.0	stable
-gnuplot/5.2.0	stable
-gnuplot/5.2.4	stable
-
-
-
-
-
-

Example of a more complex build-block

-
-

HDF5 build-script

-
-
-
#!/usr/bin/env modbuild
-
-pbuild::set_download_url "https://support.hdfgroup.org/ftp/HDF5/releases/$P-${V_MAJOR}.${V_MINOR}/$P-$V/src/hdf5-$V.tar.bz2"
-pbuild::add_to_group 'MPI'
-
-pbuild::add_docfiles ACKNOWLEDGMENTS
-pbuild::add_docfiles COPYING
-pbuild::add_docfiles MANIFEST
-pbuild::add_docfiles README.txt
-
-pbuild::pre_configure() {
-        pbuild::add_configure_args "CC=${MPICC}"
-        pbuild::add_configure_args "CXX=${MPICXX}"
-
-        pbuild::add_configure_args "--enable-shared"
-        pbuild::add_configure_args "--enable-parallel"
-        pbuild::add_configure_args "--enable-cxx"
-        pbuild::add_configure_args "--enable-unsupported"
-        #pbuild::add_configure_args "--enable-threadsafe"
-        pbuild::add_configure_args "--with-pic"
-
-        local enable_fortran='yes'
-
-        case "${COMPILER}" in
-                clang-macos )
-                        enable_fortran='no'
-                        # we do not have Fortran in Xcode
-                        ;;
-                pgi )
-                        # PGI uses GCC's include files, some object files and
-                        # the STL implementation!
-                        # The PGI C pre-processor is broken and doesn't work
-                        # for HDF5. We use the pre-processor of the underlying
-                        # GCC...
-                        # This is a bit hackish!
-                        #
-                        # The following eval sets GCCDIR! Which is something
-                        # like:
-                        # /opt/psi/Programming/gcc/7.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.0
-                        #
-                        eval $(pgcc -show 2>/dev/null | \
-                                awk '/^GCCDIR[[:space:]]*=/{gsub(/[[:space:]]/,""); print $0}')
-                        pbuild::add_configure_args "CPP=${GCCDIR%%/..*}/cpp"
-                        pbuild::add_configure_args "CFLAGS=-fPIC"
-                        pbuild::add_configure_args "CXXFLAGS=-fPIC"
-                        pbuild::add_configure_args "FCFLAGS=-fPIC"
-                        ;;
-        esac
-
-        if [[ "${enable_fortran}" == 'yes' ]]; then
-                pbuild::add_configure_args "F77=${MPIF77}"
-                pbuild::add_configure_args "F90=${MPIF90}"
-                pbuild::add_configure_args "FC=${MPIFC}"
-                pbuild::add_configure_args "FORTRAN=${MPIFORTRAN}"
-                pbuild::add_configure_args "--enable-fortran"
-        fi
-
-}
-
-
-
-
-

The HDF5 modulefile

-
-
-
#%Module1.0
-
-module-whatis		"Hierachical Data Format 5"
-module-url		"http://www.hdfgroup.org/HDF5"
-module-license		"HDF license (BSD-like)"
-module-maintainer	"Achim Gsell <achim.gsell@psi.ch>"
-module-help		"
-HDF5 is a data model, library, and file format for storing and managing
-data. It supports an unlimited variety of datatypes, and is designed for
-flexible and efficient I/O and for high volume and complex data. HDF5 is
-portable and is extensible, allowing applications to evolve in their use
-of HDF5. The HDF5 Technology suite includes tools and applications for
-managing, manipulating, viewing, and analyzing data in the HDF5 format.
-"
-
-conflict	hdf5_serial
-module-addgroup	HDF5
-
-
-
-
-

The HDF5 1.10 variants file

-
-
-
hdf5/1.10.0	stable		gcc/4.8.5 openmpi/1.10.2
-hdf5/1.10.0	stable		gcc/4.9.3 openmpi/1.10.2
-hdf5/1.10.0	stable		gcc/5.3.0 openmpi/1.10.2
-hdf5/1.10.0	stable		gcc/6.1.0 openmpi/1.10.2
-
-hdf5/1.10.1	unstable	gcc/7.3.0 openmpi/1.10.2
-hdf5/1.10.1	unstable	gcc/7.3.0 openmpi/1.10.7
-hdf5/1.10.1	unstable	gcc/7.3.0 openmpi/2.1.2
-hdf5/1.10.1	unstable	gcc/7.3.0 openmpi/3.0.0
-hdf5/1.10.1	unstable	gcc/7.3.0 openmpi/3.0.1
-
-hdf5/1.10.1	unstable	intel/17.4 openmpi/1.10.7
-hdf5/1.10.1	unstable	intel/17.4 openmpi/2.1.2
-hdf5/1.10.1	unstable	intel/17.4 openmpi/3.0.0
-hdf5/1.10.1	unstable	intel/17.4 intel-mpi/17.4
-
-hdf5/1.10.1	unstable	pgi/18.5 pgi-mpi/18.5
-
-hdf5/1.10.2 	stable    	gcc/7.3.0 openmpi/3.0.1
-hdf5/1.10.3 	stable    	gcc/7.3.0 openmpi/3.1.2
-hdf5/1.10.3	unstable	intel/17.4 intel-mpi/17.4
-
-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/build-config-files/config_yaml.html b/doc/html/build-system/build-config-files/config_yaml.html deleted file mode 100644 index 187babe..0000000 --- a/doc/html/build-system/build-config-files/config_yaml.html +++ /dev/null @@ -1,520 +0,0 @@ - - - - - - - -YAML configuration files in Pmodules 1.1 and newer - - - - - -
-
-
-
- - - - - -
- - -
-

Pmodules 1.1 and newer are supporting configuration files in YAML -format. For backward compatibility the build-systems supports both -types of configuration files with the YAML configuration file as -default.

-
-
-
-
-

The old format of the variants file is simple but very limited and -almost impossible to extend for new features. To overcome the -limitations a new format using YAML for variants files has been -introduced. For the time being both format are supported. But it is -highly recommended to use the YAML format for new modules and to -migrate existing variants files in the old format to the new.

-
-
-
-
-

Path to configuration file

-
-
-

The path to the configuration file is

-
-
-

build-recipe-dir/files/config.yaml

-
-
-
-
-

Format

-
-
-
-
format: 1
-module-name-1:
-  defaults:                                       # optional
-    config-block
-  shasums:                                        # optional
-    filename-1: sha256sum-1
-    ...
-  versions:
-    version-keys-1:
-      config:                                     # optional
-        config-block
-      variants:                                   # optional
-        - config-block-1
-        - ...
-    ...
-module-name-2:
-  ...
-
-
- ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field-NameTypeDescription

format

unsigned int

Format version of the YAML configuration file. For now it must be 1

module-name-N

config-block

Configuration for the Pmodule module-name-N. Example: openmpi

defaults

config-block

Default configuration. This block is optional.

shasums

MAP of string

SHA256 hash sums of source files. Keys are filenames, the value the
- corresponding SHA256 hash sum. This block is optional. A warning is - printed if a hash-sum is missing for a required file.

versions

MAP of configurations for different version keys

A version key is a semicolon separated string of version - numbers. Version numbers can be specified with shell brace - expansion. Example:
- 5.4.{0,1,2,3,4,5,8,9};5.2.{0,4,6,7,8};5.0.0;4.6.3

config

config-block

Optional, version specific configuration block. Configurations - specified here are overriding the defaults.

variants

map of config-block

Variants can be used to compile the some software with different

-
-
-
-

Configuration blocks

-
-
- - - - - -
- - -
-

In configuration blocks everything is optional!

-
-
-
-
-
config-block
-
-
build_requires: [build-req-1, ...]
-compile_in_sourcetree: bool
-configure_with: auto|autotools|cmake
-default_variant: variant
-docfiles: [file-1, ...]
-group: group
-group_deps:
-  compilers:
-    cpmpiler-1: [version-1, ...]
-  mpi:
-    mpi-implemation-1: [version-1, ...]
-  hdf5:
-    hdf5: [version-1, ...]
-  hdf5_serial:
-    hdf5[_serial]: [_version-1, ...]
-overlay: overlay
-relstage: release-stage
-runtime_deps: [rt-dep-1, ...]
-suffix: suffix
-systems: [system-1, ...]
-urls:
-  - url: link
-    name: filename
-  - ...
-variant: [variant-1, ...]
-
-
- ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field-NameTypeDescription

build_requires

array of string

Modules required to build this module

compile_in_sourcetree

boolean

Compile in source tree or in a dedicate build directory.

configure_with

string

Choose software configuration system. Allowed values are:
- auto: use autotools if available
- autotools: use autotools
- cmake: use cmake

default_variant

string

(opt) Specifies the default variant to build if no variant is specified

docfiles

array of string

Array with documentation files to be installed in share/doc/

group

string

Group of the module

group_deps

group-deps-object

Group/hierarchical dependencies like compiler, MPI, HDF5 modules

overlay

string

Overlay of the module

relstage

string

Release stage of the module. Allowed values are:
-unstable: the module is still under development
-stable: the module is ready to be used
-deprecated: the module is deprecated
-remove: the module is deprecated and marked to be removed
-removed: the module has been removed

runtime_deps

sequence of strings

Module to be loaded at runtime

suffix

string

This string will be added to the version of the module

systems

sequence of strings

A 'system' is either a hostname or OS name like rhel8. For
- hostnames shell glob pattern matching like merlin-* can be used.

urls

sequence of links and optional file-names

Software which must be downloaded to build a specific module.
- url: Download link
- name: optional output filename. The filename defaults the last - component of the url.
- Default URLs can be defined by using the variables P, V, - V_PKG, V_MAJOR, V_MINOR and V_PATCHLVL. Example:
- https://sourceforge.net/projects/gnuplot/files/$P/$V/$P-${V_PKG}.tar.gz

variant

sequence of strings

Sequence of synonyms for a variant.

-
-
-
-

Examples

-
-
-
Example: Gnuplot
-
-
format: 1
-gnuplot:
-  defaults:                                             (1)
-    group: Tools                                        (2)
-    overlay: base                                       (3)
-    relstage: stable                                    (4)
-    systems: [rhel8, rhel7, rhel6]                      (5)
-    docfiles: [Copyright, NEWS, README]                 (6)
-    urls:                                               (7)
-      - url: https://sourceforge.net/projects/gnuplot/files/$P/$V/$P-${V_PKG}.tar.gz
-  shasums:                                              (8)
-    gnuplot-5.4.10.tar.gz: 975d8c1cc2c41c7cedc4e323aff035d977feb9a97f0296dd2a8a66d197a5b27c
-    gnuplot-5.4.9.tar.gz: a328a021f53dc05459be6066020e9a71e8eab6255d3381e22696120d465c6a97
-    gnuplot-5.4.8.tar.gz: 931279c7caad1aff7d46cb4766f1ff41c26d9be9daf0bcf0c79deeee3d91f5cf
-    gnuplot-5.4.5.tar.gz: 66f679115dd30559e110498fc94d926949d4d370b4999a042e724b8e910ee478
-    gnuplot-5.4.4.tar.gz: 372300b7867f5b3538b25fc5d0ac7734af6e3fe0d202b6db926e4369913f0902
-    gnuplot-5.4.3.tar.gz: 51f89bbab90f96d3543f95235368d188eb1e26eda296912256abcd3535bd4d84
-    gnuplot-5.4.2.tar.gz: e57c75e1318133951d32a83bcdc4aff17fed28722c4e71f2305cfc2ae1cae7ba
-    gnuplot-5.4.1.tar.gz: 6b690485567eaeb938c26936e5e0681cf70c856d273cc2c45fabf64d8bc6590e
-    gnuplot-5.4.0.tar.gz: eb4082f03a399fd1e9e2b380cf7a4f785e77023d8dcc7e17570c1b5570a49c47
-    gnuplot-5.2.8.tar.gz: 60a6764ccf404a1668c140f11cc1f699290ab70daa1151bb58fed6139a28ac37
-    gnuplot-5.2.7.tar.gz: 97fe503ff3b2e356fe2ae32203fc7fd2cf9cef1f46b60fe46dc501a228b9f4ed
-    gnuplot-5.2.6.tar.gz: 35dd8f013139e31b3028fac280ee12d4b1346d9bb5c501586d1b5a04ae7a94ee
-    gnuplot-5.2.4.tar.gz: 1515f000bd373aaa53b16183f274189d4f5e0ae47d22f434857933d16a4770cb
-    gnuplot-5.0.0.tar.gz: 417d4bc5bc914a60409bb75cf18dd14f48b07f53c6ad3c4a4d3cd9a8d7370faf
-    gnuplot-4.6.3.tar.gz: df5ffafa25fb32b3ecc0206a520f6bca8680e6dcc961efd30df34c0a1b7ea7f5
-  versions:
-    5.4.{0,1,2,3,4,5,8,9};5.2.{0,4,6,7,8};5.0.0;4.6.3:  (9)
-    5.4.10:                                             (10)
-      config:
-        relstage: unstable
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1Configuration is for gnuplot
2will be installed in the group Tools
3will be installed in the base overlay (/opt/psi)
4the default release stage is stable
5the module is available on these systems
6install these files to $PREFIX/share/doc/gnuplot
7download via this link
8SHA256 hash sums for all available versions
9no specific configuration required for these versions
10release stage of version 5.4.10 is still unstable, override -default release stage. ----
-
-
-
Example: HDF5
-
-
---
-# yamllint disable rule:line-length             (1)
-format: 1
-hdf5:                                           (2)
-  defaults:
-    group: MPI                                  (3)
-    overlay: base                               (4)
-    relstage: stable                            (5)
-    systems: [rhel7, rhel8, rhel9]              (6)
-    urls:                                       (7)
-      - url: https://support.hdfgroup.org/ftp/HDF5/releases/$P-${V_MAJOR}.${V_MINOR}/$P-${V_PKG}/src/$P-${V_PKG}.tar.bz2
-  shasums:                                      (8)
-    hdf5-1.8.10-patch1.tar.bz2: 292afb3615ad9e68f4d5d18ebb11e4a73f2aece39f2da3875a457ff1e109fc41
-    hdf5-1.8.12.tar.bz2: 10a369a4fc207bb09245f57c758e587420e06dfc0e445e337a58b0848b75a949
-    ...
-    hdf5-1.13.1.tar.bz2: e16973ec893e2d5aa9c8dc73e196db9b99a605578e7317b421c713936f8bf57d
-
-  versions:
-    1.8.12:
-      config:
-        relstage: deprecated                    (9)
-      variants:
-        -
-          group_deps:
-            compiler: {gcc: [4.7.4, 4.8.3, 4.8.4, 4.9.2]}
-            mpi: {openmpi: [1.6.5, 1.8.2, 1.8.4]}
-        -
-          group_deps:
-            compiler: {gcc: [4.8.2]}
-            mpi: {openmpi: [1.6.5]}
-        ...
-        -
-          group_deps:
-            compiler: {gcc: [5.1.0], intel: [15.2, 15.3]}
-            mpi: {openmpi: [1.8.4]}
-    ...
-    1.10.8_slurm:
-      variants:
-        -
-          group_deps:                           (10)
-            compiler: {gcc: [10.4.0]}
-            mpi: {openmpi: [4.1.4_slurm]}
-        -
-          relstage: unstable                    (11)
-          group_deps:
-            compiler: {gcc: [9.5.0, 10.4.0, 11.4.0, 12.3.0, 13.1.0]}
-            mpi: {openmpi: [4.1.5_slurm]}
-    ...
-    1.12.0:
-      variants:
-        -
-          group_deps:                           (12)
-            compiler: {gcc: [7.5.0, 8.4.0, 9.3.0, 10.2.0]}
-            mpi: {openmpi: [4.0.5]}
-        -
-          relstage: unstable                    (13)
-          group_deps:
-            compiler: {pgi: [21.5]}
-            mpi: {pgi-mpi: [21.5]}
-
-    1.13.1:
-      variants:
-        -
-          suffix: _slurm                        (14)
-          variant: [_slurm]
-          relstage: unstable
-          group_deps:
-            compiler: {gcc: [11.2.0]}
-            mpi: {openmpi: [4.1.3_slurm]}
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1disable rule to check line length in yamllint. Default is 80.
2this configuration is for HDF5
3TBW
4TBW
5TBW
6TBW
7TBW
8TBW
9TBW
10TBW
11TBW
12TBW
13TBW
14TBW
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/build-config-files/variants.html b/doc/html/build-system/build-config-files/variants.html deleted file mode 100644 index 5e7abc4..0000000 --- a/doc/html/build-system/build-config-files/variants.html +++ /dev/null @@ -1,201 +0,0 @@ - - - - - - - -"legacy" configuration files in Pmodules 1.0 - - - - - -
-
-
-
- - - - - -
- - -
-

These type of configuration file is deprecated in version 1.1 and -newer. Starting with version 1.2 the use of YAML configuration files -documented in the next section is recommended.

-
-
-
-
-

In the Pmodules 1.0 configuration files the following properties are -defined per version:

-
-
-
    -
  • -

    module name and version

    -
    • -
  • -

    release stage

    -
    • -
  • -

    dependencies

    -
    • -
-
-
-

Each definition must be on a single line.

-
-
-
-
-

Configuration filenames and search order

-
-
-

Configuration files are searched in the following order:

-
-
-
    -
  1. -

    build-recipe-dir/files/variants.system

    -
    2. -
  2. -

    build-recipe-dir/files/variants.OS

    -
    3. -
  3. -

    build-recipe-dir/files/variants

    -
    4. -
-
-
-

Whereby

-
-
-
-
system
-
-

If the build script is called with the option --system=sytem, this configuration file is used.

-
-
OS
-
-

Is the operating system/kernel name returned by uname --s. On Linux this is Linux on macOS this is Darwin.

-
-
-
-
-
-
-

Format

-
-
-

A line in a configuration file is either

-
-
-
    -
  • -

    a comment line starting with #

    -
    • -
  • -

    a empty line or a with white-space only

    -
    • -
  • -

    a definition of a variant

    -
    • -
-
-
-
-
-

Variant specifications

-
-
-

The form of a variant specification is

-
-
-

module-name release_stage dependencies

-
-
-

Whereby:

-
-
-
-
module-name
-
-

Is the name of the module including the version, an -optional release number and an optional suffix. The general form is

-
-

P/V[-V_RELEASE][_SUFFIX]

-
-
-
release_stage
-
-

Defines the release stage of this module -variant. Allowed values are unstable, stable, deprecated, -remove and removed. If the release stage is remove or removed, -this module variant will be removed (if not already removed).

-
-
dependencies
-
-

Defines the module dependencies. Dependencies can -be either a hierarchical dependency, a runtime dependency or a build -dependency. Hierarchical and runtime dependencies are loaded before -a module itself. Build dependencies are only loaded during build-time -and must be prefixed with b:.

-
-

Dependencies are loaded in the specified order. It is recommended to -specify the dependencies of a the (hierarchical) group first, then -additional modules required at run-time and the modules required to -build it at the end.

-
-
-

If the module is in a hierarchical group like MPI, you must specify -the modules required for this group. For modules in the group

-
-
-
    -
  • -

    Compiler a compiler must be specified.

    -
    • -
  • -

    MPI a compiler and a MPI implementation must be specified.

    -
    • -
  • -

    HDF5 a compiler, a MPI implementation and a parallel HDF5 module -must be specified.

    -
    • -
  • -

    HDF5_serial a compiler and a serial HDF5 module -must be specified.

    -
    • -
-
-
-
-
-
-
Example
-
-
parmetis/4.0.3  stable gcc/7.3.0 openmpi/3.0.0  b:cmake/3.6.3
-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/build-script-functions.html b/doc/html/build-system/build-script-functions.html deleted file mode 100644 index 8b1cba3..0000000 --- a/doc/html/build-system/build-script-functions.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - - -Build script functions - - - - - -
-
-

Build script functions

-
-
-

Setup functions

-
- -
-
-
-

Building and installing

-
- -
-
-
-

Less common functions

-
- -
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/add_configure_args.html b/doc/html/build-system/functions/add_configure_args.html deleted file mode 100644 index 8847b1c..0000000 --- a/doc/html/build-system/functions/add_configure_args.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - - -pbuild::add_configure_args: Set configuration options - - - - - -
-
-

Synopsis

-
-
-
-
pbuild::add_configure_args arg...
-
-
-
-
-
-

Description

-
-
-

Add arguments/options to the call of configure or cmake.

-
-
-
-
-

Example

-
-
-

Excerpt from libtasn1 build-script (autotools):

-
-
-
-
pbuild::add_configure_args "--disable-shared"
-pbuild::add_configure_args "CFLAGS=-fPIC"
-
-
-
-

Excerpt from ParMETIS build-script (CMake):

-
-
-
-
pbuild::add_configure_args "-DMETIS_PATH=${SRC_DIR}/metis"
-pbuild::add_configure_args "-DGKLIB_PATH=${SRC_DIR}/metis/GKlib"
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/add_patch.html b/doc/html/build-system/functions/add_patch.html deleted file mode 100644 index 23143ff..0000000 --- a/doc/html/build-system/functions/add_patch.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - - - - -pbuild::add_patch: Adding patches to be applied - - - - - -
-
-

Synopsis

-
-
-
-
pbuild::add_patch patch_fname [strip_num_dirs]
-
-
-
-
-
-

Description

-
-
-

Apply a patch to the unpacked sources. The argument patch_fname must be a relative file-name to the build-block directory. The argument strip_num_dirs is optional and defaults to 1. Please read the patch(1) manual page for more details. The patches are applied inside the source directory with the command:

-
-
-
-
patch --strip=strip_num_dirs < "${BUILDBLOCK_DIR}/patch_fname"
-
-
-
-
-
-

Example

-
-
-

Excerpt from ioapi build-script:

-
-
-
-
pbuild::add_patch 'files/Makefile.pncf.sed.patch'
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/add_to_group.html b/doc/html/build-system/functions/add_to_group.html deleted file mode 100644 index 4385d2c..0000000 --- a/doc/html/build-system/functions/add_to_group.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - - - - -pbuild::add_to_group: Define the group of a module - - - - - -
-
-

Synopsis

-
-
-
-
pbuild::add_to_group GROUP
-
-
-
-
-
-

Description

-
-
-

Define the group the module will be installed in. Sometimes it is not obvious in which group a module should go. If in doubt, Tools might be the best.

-
-
-

A (incomplete) list of available groups:

-
-
-
-
Tools
-
-

Group for tools like Gnuplot, Git, vim, Emacs, openssl. This group is visible by default.

-
-
Programming
-
-

Group for compilers, scripting languages and tools used for programming, like GCC, Python, CMake, autotools, Matlab. This group is visible by default.

-
-
Compiler
-
-

Hierarchical group for modules compiled with a certain compiler module. Examples: open-mpi, MPICH, serial HDF5.

-
-
HDF5_serial
-
-

Hierarchical group for modules compiled with a certain compiler and serial HDF5 module. Examples: netCDF, H5hut.

-
-
MPI
-
-

Hierarchical group for modules compiled with a certain compiler and MPI module. Examples: parallel Boost, parallel HDF5, ParMETIS, Gromacs.

-
-
HDF5
-
-

Hierarchical group for modules compiled with a certain compiler, MPI and parallel HDF5 module. Examples: netCDF, H5hut, Trilinos.

-
-
System
-
-

Group for system tools. This group is not visible by default. Examples: filebench, fsstress, nmap, patchelf.

-
-
Libraries
-
-

Group for libraries required to compile other modules but not providing (useful) tools. This group is not visible by default. Examples: GMP, MPC, MPFR

-
-
MX
-
-

Group for special tools used at the MX beam-line. This group is visible only on dedicated systems.

-
-
EM
-
-

Group for Ra specific software. This group is only visible and available on Ra.

-
-
-
-
-
-
-

Example

-
-
-
Example 1. Define the group for the Gnuplot module:
-
-
-
-
pbuild::add_to_group 'Tools'
-
-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/compile.html b/doc/html/build-system/functions/compile.html deleted file mode 100644 index aff6c07..0000000 --- a/doc/html/build-system/functions/compile.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - - -pbuild::compile: Compile software - - - - - -
-
-

Synopsis

-
-
-
-
pbuild::pre_compile_${SYSTEM}
-pbuild::pre_compile
-pbuild::compile
-pbuild::post_compile_${SYSTEM}
-pbuild::post_compile
-
-
-
-
-
-

Description

-
-
-

Compile the software.

-
-
-

Before these functions are called, the build-system changes to the -build directory (${BUILD_DIR}).

-
-
-

In the most uses cases the default function pbuild::compile provided by -the build-system can be used and nothing must be implemented in the -build-script. The pre- and post-hooks might be useful in cases where

-
-
-
    -
  • -

    to run other make targets than all

    -
    • -
  • -

    multiple packages must be compiled into one module

    -
    • -
  • -

    to compile a dependency required by the main package.

    -
    • -
-
-
-

If the default function cannot be used, the pbuild::compile -function must be implemented in the build-script.

-
-
-
-
-

Example

-
-
-

Excerpt from perl build-script

-
-
-
-
pbuild::post_compile() {
-        make test
-}
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/compile_in_sourcetree.html b/doc/html/build-system/functions/compile_in_sourcetree.html deleted file mode 100644 index d4bfec5..0000000 --- a/doc/html/build-system/functions/compile_in_sourcetree.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - - -pbuild::compile_in_sourcetree - - - - - -
-
-
-
-
-
pbuild::compile_in_sourcetree
-
-
-
-
-
-

Description

-
-
-

By default the build-system compiles software in a separate build-directory. This is not possible with all software. With the function pbuild::compile_in_sourcetree the build-directory is set to the source-directory.

-
-
-
-
-

Example

-
-
-
-
pbuild::compile_in_sourcetree
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/configure.html b/doc/html/build-system/functions/configure.html deleted file mode 100644 index 8d8db5f..0000000 --- a/doc/html/build-system/functions/configure.html +++ /dev/null @@ -1,176 +0,0 @@ - - - - - - - -pbuild::configure: Configure software - - - - - -
-
-

Synopsis

-
-
-
-
pbuild::pre_configure_${SYSTEM}
-pbuild::pre_configure
-pbuild::configure
-pbuild::post_configure_${SYSTEM}
-pbuild::post_configure
-
-
-
-
-
-

Description

-
-
-

Configure the software for compilation.

-
-
-

Before these functions are called, the build-system changes to the -build directory (${BUILD_DIR}).

-
-
-

In the most uses cases the default function pbuild::configure provided by -the build-system can be used and nothing must be implemented in the -build-script.

-
-
-

The default function first searches whether the software can be -configured with autotools. If yes, configuration with autotools will -be performed. Otherwise the existence of a CMake script will be -checked. If found, configuration will be done via CMake. If scripts -for both configuration tools exist, the to be used tool can be -selected with pbuild::use_autotools or -pbuild::use_cmake. Arguments to configure or -cmake can be set with -pbuild::add_configure_args.

-
-
-

A common use case for the pre-configure hooks is to define arguments -passed to autotools or CMake by the default function.

-
-
-

If the default function cannot be used, the pbuild::configure -function must be implemented in the build-script.

-
-
-
-
-

Examples

-
-
-

Excerpt from the parallel HDF5 build-script

-
-
-
-
pbuild::pre_configure() {
-        pbuild::add_configure_args "CC=${MPICC}"
-        pbuild::add_configure_args "CXX=${MPICXX}"
-
-        pbuild::add_configure_args "--enable-shared"
-        pbuild::add_configure_args "--enable-parallel"
-        pbuild::add_configure_args "--enable-cxx"
-        pbuild::add_configure_args "--enable-unsupported"
-        #pbuild::add_configure_args "--enable-threadsafe"
-        pbuild::add_configure_args "--with-pic"
-
-        local enable_fortran='yes'
-
-        case "${COMPILER}" in
-                clang-macos )
-                        enable_fortran='no'
-                        # we do not have Fortran in Xcode
-                        ;;
-                pgi )
-                        # PGI uses GCC's include files, some object files and
-                        # the STL implementation!
-                        # The PGI C pre-processor is broken and doesn't work
-                        # for HDF5. We use the pre-processor of the underlying
-                        # GCC...
-                        # This is a bit hackish!
-                        #
-                        # The following eval sets GCCDIR! Which is something
-                        # like:
-                        # /opt/psi/Programming/gcc/7.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.0
-                        #
-                        eval $(pgcc -show 2>/dev/null | \
-                                awk '/^GCCDIR[[:space:]]*=/{gsub(/[[:space:]]/,""); print $0}')
-                        pbuild::add_configure_args "CPP=${GCCDIR%%/..*}/cpp"
-                        pbuild::add_configure_args "CFLAGS=-fPIC"
-                        pbuild::add_configure_args "CXXFLAGS=-fPIC"
-                        pbuild::add_configure_args "FCFLAGS=-fPIC"
-                        ;;
-        esac
-
-        if [[ "${enable_fortran}" ===== 'yes' ]]; then
-                pbuild::add_configure_args "F77=${MPIF77}"
-                pbuild::add_configure_args "F90=${MPIF90}"
-                pbuild::add_configure_args "FC=${MPIFC}"
-                pbuild::add_configure_args "FORTRAN=${MPIFORTRAN}"
-                pbuild::add_configure_args "--enable-fortran"
-        fi
-
-
-
-

Simplified excerpt from the OpenBLAS build-script

-
-
-
-
pbuild::configure() {
-        case ${COMPILER} in
-        gcc )
-                CC='gcc'
-                ;;
-        intel )
-                CC='icc'
-                ;;
-        clang-macos )
-                CC='gcc'
-                ;;
-        * )
-                die 3 "Oops: unknown compiler: ${COMPILER}"
-                ;;
-        esac
-        cat <<EOF > "${SRC_DIR}/make.inc"
-SHELL = /bin/sh
-PLAT =
-DRVOPTS  = \$(NOOPT)
-ARCHFLAGS= -ru
-EOF
-        echo "USE_SIMPLE_THREADED_LEVEL3 = 1" >> "${SRC_DIR}/Makefile.rule"
-        echo "NO_AVX = 1" >> "${SRC_DIR}/Makefile.rule"
-        echo "NO_AVX2 = 1" >> "${SRC_DIR}/Makefile.rule"
-        if pbuild::use_flag "omp"; then
-                echo "USE_THREAD = 1" >> "${SRC_DIR}/Makefile.rule"
-        else
-                echo "USE_THREAD = 0" >> "${SRC_DIR}/Makefile.rule"
-        fi
-}
-
-pbuild::post_configure_Darwin() {
-        sed -i.bak "s/MACOSX_DEPLOYMENT_TARGET=.*/MACOSX_DEPLOYMENT_TARGET=$MACOSX_DEPLOYMENT_TARGET/" \
-                "${SRC_DIR}/Makefile.system"
-}
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/install.html b/doc/html/build-system/functions/install.html deleted file mode 100644 index 94a1260..0000000 --- a/doc/html/build-system/functions/install.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - - -pbuild::install: Install software - - - - - -
-
-

Synopsis

-
-
-
-
pbuild::pre_install_${SYSTEM}
-pbuild::pre_install
-pbuild::install
-pbuild::post_install_${SYSTEM}
-pbuild::post_install
-
-
-
-
-
-

Description

-
-
-

Compile the software.

-
-
-

Before these functions are called, the build-system changes to the -build directory (${BUILD_DIR}).

-
-
-

In the many uses cases the default function pbuild::install provided by -the build-system can be used and nothing must be implemented in the -build-script. A typical use case for the post-install hook is to install required libraries from other modules or the system to reduce or eliminate run-time dependencies

-
-
-

If the default function cannot be used, the pbuild::install -function must be implemented in the build-script.

-
-
-
-
-

Example

-
-
-
-
pbuild::
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/install_docfile.html b/doc/html/build-system/functions/install_docfile.html deleted file mode 100644 index cd32b55..0000000 --- a/doc/html/build-system/functions/install_docfile.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - -pbuild::install_docfiles: Set documentation files to be installed - - - - - -
-
-

Synopsis

-
-
-
-
pbuild::install_docfiles fname...
-
-
-
-
-
-

Description

-
-
-

Install the passed files into $PREFIX/share/doc/$P. At least the file containing the license and copyright should be installed.

-
-
-
-
-

Example

-
-
-

Excerpt from parallel-netcdf build-script:

-
-
-
-
pbuild::add_docfiles 'AUTHORS' 'CREDITS'
-pbuild::add_docfiles 'COPYING' 'COPYRIGHT'
-pbuild::add_docfiles 'ChangeLog' 'NEWS'
-pbuild::add_docfiles 'RELEASE_NOTES'
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/prep.html b/doc/html/build-system/functions/prep.html deleted file mode 100644 index 3fcd813..0000000 --- a/doc/html/build-system/functions/prep.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - - -pbuild::prep: Download and unpack - - - - - -
-
-

Synopsis

-
-
-
-
pbuild::pre_prep_${SYSTEM}
-pbuild::pre_prep
-pbuild::prep
-pbuild::post_prep_${SYSTEM}
-pbuild::post_prep
-
-
-
-
-
-

Description

-
-
-

Functions to prepare the sources. This includes

-
-
-
    -
  • -

    downloading required files a verifying the checksums

    -
    • -
  • -

    unpacking

    -
    • -
  • -

    applying patches

    -
    • -
-
-
-

Before the prep-functions are called, the build-system changes to the source -directory (${SRC_DIR}).

-
-
-

In the most uses cases the default function pbuild::prep provided by -the build-system can be used and nothing must be implemented in the -build-script. In some rare cases pre- or post-hooks are required to -make the default function feasible. One use case with autotools for a post-hook is to create the configure scripts, if only configure.ac is shipped with the software.

-
-
-

The default hooks provided by the build system are only stubs and do -nothing.

-
-
-

If the default function cannot be used, it must be implemented in the build-script.

-
-
-
-
-

Example

-
-
-

The source distribution of the IOAPI library contains object files! These files must be removed after unpacking:

-
-
-
-
pbuild::post_prep() {
-        find "${SRC_DIR}" -name "*.mod" -exec rm {} \;
-        find "${SRC_DIR}" -name "*.o" -exec rm {} \;
-}
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/set_download_url.html b/doc/html/build-system/functions/set_download_url.html deleted file mode 100644 index 2c84a2c..0000000 --- a/doc/html/build-system/functions/set_download_url.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - - -pbuild::set_download_url: Set download URL - - - - - -
-
-

Synopsis

-
-
-
-
pbuild::set_download_url URL [fname]
-
-
-
-
-
-

Description

-
-
-

Tell the build system where to download the required (source-)files. If fname is passed, it will be used as the output file-name of the download.

-
-
-

In some cases software must be downloaded from a Git repository on Github, Bitbucket or Gitlab.

-
-
-

To download a certain tag/version from Github, Bitbucket or Gitlab use:

-
-
-
-
https://github.com/OWNER/PROJECT/archive/${V_PKG}/$P-${V_PKG}.tar.gz
-https://bitbucket.org/OWNER/PROJECT/get/${V_PKG}.tar.gz#/$P-%{V_PKG}.tar.gz
-https://gitlab.com/OWNER/PROJECT/-/archive/${V_PKG}/$P-${V_PKG}.tar.gz
-
-
-
-
-
-

Examples

-
-
-

Excerpt from Trilinos build-script:

-
-
-
-
pbuild::set_download_url \
-        "https://github.com/$P/$P/tarball/$P-release-${V//./-}" \
-        "$P-$V.tar.gz"
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/set_sha256sum.html b/doc/html/build-system/functions/set_sha256sum.html deleted file mode 100644 index 705808c..0000000 --- a/doc/html/build-system/functions/set_sha256sum.html +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - - -pbuild::set_sha256sum: Pass SHA256 hash sum to build-system - - - - - -
-
-

Synopsis

-
-
-
-
pbuild::set_sha256sum SHA256_HASH
-
-
-
-
-
-

Description

-
-
-

Tell the build-system which SHA256 hash sum a file must have. The format of the argument is file-name:hash-sum.

-
-
-
-
-

Examples

-
-
-

Excerpt from Trilinos build-script:

-
-
-
-
pbuild::set_sha256sum \
-	"trilinos-12.12.1.tar.gz:c8f2029fa36230b9f384c56139aaa33111227bcf653e73f7daf3c9efdecc1d2d"
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/supported_compilers.html b/doc/html/build-system/functions/supported_compilers.html deleted file mode 100644 index 8a09e1b..0000000 --- a/doc/html/build-system/functions/supported_compilers.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - - -pbuild::set_supported_compilers - - - - - -
-
-
-
-
-
pbuild::supported_compilers STRING...
-
-
-
-
-
-

Description

-
-
-

Set list of compiler which can be used to compile the module.

-
-
-
-
-

Example

-
-
-
-
pbuild::
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/supported_os.html b/doc/html/build-system/functions/supported_os.html deleted file mode 100644 index 96f5589..0000000 --- a/doc/html/build-system/functions/supported_os.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - - - - - -pbuild::supported_systems - - - - - -
-
-
-
-
-
pbuild::supported_system STRING...
-
-
-
-
-
-

Description

-
-
-

Some modules can be build only for dedicated operating systems. This is particularly the case for operating system specific tools like patchelf.

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/use_autotools.html b/doc/html/build-system/functions/use_autotools.html deleted file mode 100644 index 8cabadc..0000000 --- a/doc/html/build-system/functions/use_autotools.html +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - - - -pbuild::use_autotools - - - - - -
-
-
-
-
-
pbuild::use_autotools
-
-
-
-
-
-

Description

-
-
-

Force the use of autotools.

-
-
-
-
-

Example

-
- -
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/functions/use_cmake.html b/doc/html/build-system/functions/use_cmake.html deleted file mode 100644 index c968d12..0000000 --- a/doc/html/build-system/functions/use_cmake.html +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - - - -pbuild::use_cmake - - - - - -
-
-
-
-
-
pbuild::use_cmake
-
-
-
-
-
-

Description

-
-
-

Force the use of CMake.

-
-
-
-
-

Example

-
- -
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/make_all.html b/doc/html/build-system/make_all.html deleted file mode 100644 index aec051b..0000000 --- a/doc/html/build-system/make_all.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - - -main build function - - - - - -
-
-

Synopsis

-
-
-
-
pbuild::
-
-
-
-
-
-

Description

-
- -
-
-
-

Example

-
-
-
-
pbuild::
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/module-names.html b/doc/html/build-system/module-names.html deleted file mode 100644 index e796dc6..0000000 --- a/doc/html/build-system/module-names.html +++ /dev/null @@ -1,122 +0,0 @@ - - - - - - - -Module names - - - - - -
-
-

Module names

-
-
-

A full module name is composed of

-
-
-
    -
  • -

    a name,

    -
    • -
  • -

    a version number,

    -
    • -
  • -

    an optional release number and

    -
    • -
  • -

    an optional use-flag.

    -
    -
    -
     Example:
-the module name for the GNU multi-precision C library (MPC)
-version 1.0.3 is `mpc/1.0.3`.
    -
    -
    -
    • -
-
-
-

The optional release number reflects changes in the module build while using the same software and version. There are three typical use cases for adding respective incrementing the release number of a module:

-
-
-
    -
  1. -

    Changes in the way the software is compiled - for example by changing the arguments passed to autotools/CMake,

    -
    2. -
  2. -

    In many cases software depends on other software. It might be necessary to rebuild/update a module to incorporating these changes.

    -
    3. -
  3. -

    The modulefile and/or the build-script has been changed.

    -
    4. -
-
-
-

Example: The GNU MPC library depends on the GNU Multiple Precision -Arithmetic Library (GMP) and the GNU C library for multiple-precision -floating-point computations with correct rounding (MPFR). While MPC -version 1.0.3 was still the most current release, several version of -GMP and MPFR had been released. For an up to date MPC module, we had -to rebuild it several times:

-
- ---- - - - - - - - - - - - - - - - - - - - - -
MPC modulebuild with

mpc/1.0.3

gmp/6.1.0 mpfr/3.1.4

mpc/1.0.3-1

gmp/6.1.1 mpfr/3.1.4

mpc/1.0.3-2

gmp/6.1.2 mpfr/3.1.5

-
-

The optional use-flag must be appended and separated with an underscore. Modules without an use-flag must be compiled for the x86_64 architecture. This feature is still experimental. For the time being any string can be used. Use-flags can be selected with the module use flag=FLAG command. In case an use-flag is set a module compiled with this use-flag will be preferred over the same module compiled without a use-flag. Typical use cases for these flags are

-
-
-
    -
  • -

    compiling the same module for different CPU’s.

    -
    • -
  • -

    compiling the same module with different features enabled, like with and without OpenMPI.

    -
    • -
  • -

    support for special hardware for dedicated systems like Infiniband.

    -
    • -
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/modulefile.html b/doc/html/build-system/modulefile.html deleted file mode 100644 index 1a9b68b..0000000 --- a/doc/html/build-system/modulefile.html +++ /dev/null @@ -1,480 +0,0 @@ - - - - - - - -modulefiles - - - - - -
-
-

NAME

-
-
-

modulefile - files containing Tcl code for the Modules package

-
-
-
-
-

DESCRIPTION

-
-
-

modulefiles are written in the Tool Command Language, Tcl(n) and are -interpreted by the modulecmd program via the module(1) user -interface. modulefiles can be loaded, unloaded, or switched on-the-fly -while the user is working; and can be used to implement site policies -regarding the access and use of applications.

-
-
-

A modulefile begins with the shebang, ‘#%Pmodule’ or -‘#%Module’. The shebang ‘#%Pmodule’ should be used in modulefiles -using the Pmodules extension. A version number may be placed after -this string. The version number is useful as the modulefile format may -change. If a version number doesn’t exist, then modulecmd will assume -the modulefile is compatible with the latest version. The current -modulefile version is 1.0. Files without the magic cookie will not be -interpreted by modulecmd.

-
-
-

Each modulefile contains the changes to a user’s environment needed to -access an application. Tcl is a simple programming language which -permits modulefiles to be arbitrarily complex, depending upon the -application’s and the modulefile writer’s needs.

-
-
-

A typical modulefiles is a simple bit of code that set or add entries -to the PATH, MANPATH, or other environment variables. Tcl has -conditional statements that are evaluated when the modulefile is -loaded. This is very effective for managing path or environment -changes due to different OS releases or architectures. The user -environment information is encapsulated into a single modulefile kept -in a central location. The same modulefile is used by every user on -any machine. So, from the user’s perspective, starting an application -is exactly the same irrespective of the machine or platform they are -on.

-
-
-

modulefiles also hide the notion of different types of shells. From -the user’s perspective, changing the environment for one shell looks -exactly the same as changing the environment for another shell. This -is useful for new or novice users and eliminates the need for -statements such as "if you’re using the C Shell do this …​, otherwise -if you’re using the Bourne shell do this …​". Announcing and -accessing new software is uniform and independent of the user’s -shell. From the modulefile writer’s perspective, this means one set of -information will take care of every type of shell.

-
-
-

Module specific commands

-
-

The Pmodules Package uses commands which are extensions to the "standard" Tool Command Language Tcl(n) package.

-
-
- - - - - -
- - -
-

The following commands are Pmodules extensions:

-
-
-
    -
  • -

    module-addgroup

    -
    • -
  • -

    module-url

    -
    • -
  • -

    module-license

    -
    • -
  • -

    module-maintainer

    -
    • -
-
-
-
-
-

Unless otherwise specified, the Module commands return the empty string. Some commands behave differently when a modulefile is loaded or unloaded. The command descriptions assume the modulefile is being loaded.

-
-
-
-
break
-
-

This is not a Modules-specific command, it’s actually part of Tcl, which has been overloaded similar to the continue and exit commands to have the effect of causing the module not to be listed as loaded and not affect other modules being loaded concurrently. All non-environment commands within the module will be performed up to this point and processing will continue on to the next module on the command line. The break command will only have this effect if not used within a Tcl loop though.

-
-

An example: Suppose that a full selection of modulefiles are needed for various different architectures, but some of the modulefiles are not needed and the user should be alerted. Having the unnecessary modulefile be a link to the following notavail modulefile will perform the task as required.

-
-
-
-
#%Module1.0
-## notavail modulefile
-##
-proc ModulesHelp { } {
-            puts stderr "This module does nothing but alert the user"
-            puts stderr "that the [module-info name] module is not available"
-}
-
-module-whatis "Notifies user that module is not available."
-set curMod [module-info name]
-if { [ module-info mode load ] } {
-            puts stderr "Note: '$curMod' is not available for [uname sysname]."
-}
-break
-
-
-
-
chdir directory
-
-

Set the current working directory to directory.

-
-
continue
-
-

This is not a modules specific command but another overloaded Tcl command and is similar to the break or exit commands except the module will be listed as loaded as well as performing any environment or Tcl commands up to this point and then continuing on to the next module on the command line. The continue command will only have this effect if not used within a Tcl loop though.

-
-
exit [N]
-
-

This is not a modules specific command but another overloaded Tcl command and is similar to the break or continue commands. However, this command will cause the immediate cessation of this module and any additional ones on the command line. This module and the subsequent modules will not be listed as loaded. No environment commands will be performed in the current module.

-
-
setenv variable value
-
-

Set environment variable to value. The setenv command will also change the process' environment. A reference using Tcl’s env associative array will reference changes made with the setenv command. Changes made using Tcl’s env associative array will NOT change the user’s environment variable like the setenv command. An environment change made this way will only affect the module parsing process. The setenv command is also useful for changing the environment prior to the exec or system command. When a modulefile is unloaded, setenv becomes unsetenv. If the environment variable had been defined it will be overwritten while loading the modulefile. A subsequent unload will unset the environment variable - the previous value cannot be restored! (Unless you handle it explicitly …​ see below.)

-
-
unsetenv variable [value]
-
-

Unsets environment variable. However, if there is an optional value, then when unloading a module, it will set variable to value. The unsetenv command changes the process' environment like setenv.

-
-
append-path|prepend-path [-d C|--delim C|--delim=C] variable value
-
-

Append or prepend value to environment variable. The variable is a colon, or delimiter, separated list such as PATH=directory:directory:directory. The default delimiter is a colon ':', but an arbitrary one can be given by the --delim option. For example a space can be used instead (which will need to be handled in the Tcl specially by enclosing it in " " or { }). A space, however, can not be specified by the --delim=C form.

-
-

If the variable is not set, it is created. When a modulefile is unloaded, append-path and prepend-path become remove-path.

-
-
-
remove-path [-d C|--delim C|--delim=C] variable value
-
-

Remove value from the colon, or delimiter, separated list in variable. See prepend-path or append-path for further explanation of using an arbitrary delimiter. Every string between colons, or delimiters, in variable is compared to value. If the two match, value is removed from variable.

-
-
prereq|conflict modulefile…​
-
-

prereq and conflict control whether or not the modulefile will be loaded. The prereq command lists modulefiles which must have been previously loaded before the current modulefile will be loaded. Similarly, the conflict command lists modulefiles which conflict with the current modulefile. If a list contains more than one modulefile, then each member of the list acts as a Boolean OR operation. Multiple prereq and conflict commands may be used to create a Boolean AND operation. If one of the requirements have not been satisfied, an error is reported and the current modulefile makes no changes to the user’s environment.

-
-
-
-
-

If an argument for prereq is a directory and any modulefile from the directory has been loaded, then the prerequisite is met. For example, specifying X11 as a prereq means that any version of X11, X11/R4 or X11/R5, must be loaded before proceeding.

-
-
-

If an argument for conflict is a directory and any other modulefile from that directory has been loaded, then a conflict will occur. For example, specifying X11 as a conflict will stop X11/R4 and X11/R5 from being loaded at the same time.

-
-
-
-
is-loaded modulefile…​
-
-

The is-loaded command returns a true value if any of the listed modulefiles has been loaded. If a list contains more than one modulefile, then each member acts as a boolean OR operation. If an argument for is-loaded is a directory and any modulefile from the directory has been loaded is-loaded would return a true value.

-
-
module [sub-command] [sub-command-args]
-
-

Contains the same sub-commands as described in the module(1) man page in the Module Sub-Commands section. This command permits a modulefile to load or unload other modulefiles. No checks are made to ensure that the modulefile does not try to load itself. Often it is useful to have a single modulefile that performs a number of module load commands. For example, if every user on the system requires a basic set of applications loaded, then a core modulefile would contain the necessary -module load commands.

-
-
module-info mode [modetype]
-
-

Returns the current modulecmd’s mode as a string if no modetype is given.

-
-

Returns 1 if modulecmd’s mode is modetype. modetype can be: load, unload, remove, switch, display, help, test or whatis.

-
-
-
module-info name
-
-

Return the name of the modulefile. This is not the full pathname for modulefile. See the Modules Variables section for information on the full pathname.

-
-
module-info specified
-
-

Return the name of the modulefile specified on the command line.

-
-
module-info shell [shellname]
-
-

Return the current shell under which modulecmd.tcl was invoked if no shellname is given. The current shell is the first parameter of modulecmd.tcl, which is normally hidden by the module alias.

-
-

If a shellname is given, returns 1 if modulecmd.tcl’s current shell is shellname, returns 0 elsewhere. shellname can be: sh, bash, ksh, zsh, csh, tcsh, fish, tcl, perl, python, ruby, lisp, cmake, r.

-
-
-
module-info shelltype [shelltypename]
-
-

Return the family of the shell under which modulefile was invoked if no shelltypename is given. As of module-info shell this depends on the first parameter of modulecmd.tcl. The output reflects a shell type determining the shell syntax of the commands produced by modulecmd.tcl.

-
-

If a shelltypename is given, returns 1 if modulecmd.tcl’s current shell type is shelltypename, returns 0 elsewhere. shelltypename can be: sh, csh, fish, tcl, perl, python, ruby, lisp, cmake, r.

-
-
-
module-info alias name
-
-

Returns the full modulefile name to which the modulefile alias name is assigned

-
-
module-info version modulefile
-
-

Returns the physical module name and version of the passed symbolic version modulefile. The parameter modulefile might either be a full qualified modulefile with name and version, another symbolic modulefile name or a modulefile alias.

-
-
module-info symbols modulefile
-
-

Returns a list of all symbolic versions assigned to the passed modulefile. The parameter modulefile might either be a full qualified modulefile with name and version, another symbolic modulefile name or a modulefile alias.

-
-
module-version modulefile version-name…​
-
-

Assigns the symbolic version-name to the modulefile. This command should be placed in one of the modulecmd.tcl rc files in order to provide shorthand invocations of frequently used modulefile names.

-
-

The special version-name default specifies the default version to be used for module commands, if no specific version is given. This replaces the definitions made in the .version file in former modulecmd releases.

-
-
-

The parameter modulefile may be either -* a fully or partially qualified modulefile with name / version. If name is '.' then the current directory name is assumed to be the module name. (Use this for deep modulefile directories.) -* a symbolic modulefile name -* another modulefile alias

-
-
-
module-alias name modulefile
-
-

Assigns the modulefile to the alias name. This command should be placed in one of the modulecmd rc files in order to provide shorthand invocations of frequently used modulefile names.

-
-

The parameter modulefile may be either

-
-
-
    -
  • -

    a fully qualified modulefile with name and version

    -
    • -
  • -

    a symbolic modulefile name

    -
    • -
  • -

    another modulefile alias

    -
    • -
-
-
-
module-whatis string
-
-

Defines a string which is displayed in case of the invocation of the module whatis command. There may be more than one module-whatis line in a modulefile. This command takes no actions in case of load, display, etc. invocations of modulecmd.

-
-

The string parameter has to be enclosed in double-quotes if there’s more than one word specified. Words are defined to be separated by white-space characters (space, tab, cr).

-
-
-
module-url url
-
-

Sets an URL which is displayed in case of the invocation of the module help command. The URL should point to the home-page of the software loaded by the module if any.

-
-
module-license string
-
-

Defines a string which is displayed in case of the invocation of the module help command. The string should either be the name of a well known license (like GPL V2) or a filename with the license text installed in the module.

-
-
module-maintainer email
-
-

Defines a string which is displayed in case of the invocation of the module help command. The -string should be the email address of the module maintainer.

-
-
module-addgroup group
-
-

Add the hierarchical group group to MODULEPATH.

-
-
set-alias alias-name alias-string
-
-

Sets an alias or function with the name alias-name in the user’s environment to the string alias-string. For some shells, aliases are not possible and the command has no effect. When a modulefile is unloaded, set-alias becomes unset-alias.

-
-
unset-alias alias-name
-
-

Unsets an alias with the name alias-name in the user’s environment.

-
-
system string
-
-

Pass string to the Tcl built-in command exec(n). For the exec(n) call modulecmd redirects stdout to stderr since stdout would be parsed by the evaluating shell. The exit status of the executed command is returned.

-
-
uname field
-
-

Provide lookup of system information. Most field information are retrieved from the tcl_platform array (see tclvars(n) man page). Uname will return the string "unknown" if information is unavailable for the field.

-
-

uname will invoke uname(1) command in order to get the operating system version and domainname(1) to figure out the name of the domain.

-
-
-

field values are: -* sysname: the operating system name -* nodename: the hostname -* domain: the name of the domain -* release: the operating system release -* version: the operating system version -* machine: a standard name that identifies the system’s hardware

-
-
-
x-resource [resource-string|filename]
-
-

Merge resources into the X11 resource database. The resources are used to control look and behavior of X11 applications. The command will attempt to read resources from filename. If the argument isn’t a valid file name, then string will be interpreted as a resource. Either filename or resource-string is then passed down to be xrdb(1) command.

-
-

modulefiles that use this command, should in most cases contain one or more x-resource lines, each defining one X11 resource. The DISPLAY environment variable should be properly set and the X11 server should be accessible. If x-resource can’t manipulate the X11 resource database, the modulefile will exit with an error message.

-
-
-

Examples:

-
-
-
-
-
-
-
x-resource /u2/staff/leif/.xres/Ileaf
-
-
-
-

The content of the Ileaf file is merged into the X11 resource database.

-
-
-
-
x-resource [glob ~/.xres/ileaf]
-
-
-
-

The Tcl glob function is used to have the modulefile read different resource files for different users.

-
-
-
-
x-resource {Ileaf.popup.saveUnder: True}
-
-
-
-

Merge the Ileaf resource into the X11 resource database.

-
-
-
-

Modules Variables

-
-

The ModulesCurrentModulefile variable contains the full pathname of the modulefile being interpreted.

-
-
-
-

Locating Modulefiles

-
-

Every directory in MODULEPATH is searched to find the modulefile. A directory in MODULEPATH can have an arbitrary number of sub-directories. If the user names a modulefile to be loaded which is actually a directory, the directory is opened and a search begins for an actual modulefile. First, modulecmd looks for a file with the name .modulerc in the directory. If this file exists, its contents will be evaluated as if it was a modulefile to be loaded. You may place module-version and module-alias commands inside this file.

-
-
-

Additionally, before seeking for .modulerc files in the module directory, the global modulerc file is sourced, too. If a named version default now exists for the modulefile to be loaded, the assigned modulefile now will be sourced. Otherwise the file .version is looked up in the directory.

-
-
-

If the .version file exists, it is opened and interpreted as Tcl code and takes precedence over a .modulerc file in the same directory. If the Tcl variable ModulesVersion is set by the .version file, modulecmd will use the name as if it specifies a modulefile in the directory. This will become the default modulefile in this case.

-
-
-

If ModulesVersion is a directory, the search begins anew down that directory. If the name does not match any files located in the current directory, the search continues through the remaining directories in MODULEPATH.

-
-
-

Every .version and .modulerc file found is Tcl interpreted. The difference is that .version only applies to the current directory, and the .modulerc applies to the current directory and all subdirectories. Changes made in these files will affect the subsequently interpreted modulefile.

-
-
-

If no default version may be figured out, then the highest numerically sorted modulefile or module alias under the directory will be used. The dictionary comparison method of the lsort(n) Tcl command is used to achieve this sort. If highest numerically sorted element is an alias, search continues on its modulefile target.

-
-
-

For example, it is possible for a user to have a directory named X11 which simply contains a .version file specifying which version of X11 is to be loaded. Such a file would look like:

-
-
-
-
#%Module1.0
-##
-##  The desired version of X11
-##
-set ModulesVersion "R4"
-
-
-
-

The equivalent .modulerc would look like:

-
-
-
-
#%Module1.0
-##
-##  The desired version of X11
-##
-module-version "./R4" default
-
-
-
-

If user names a modulefile that cannot be found in the first modulepath directory, modulefile will be searched in next modulepath directory and so on until a matching modulefile is found. If search goes through a module alias or a symbolic version, this alias or symbol is resolved by first looking at the modulefiles in the modulepath where this alias or symbol is defined. If not found, resolution looks at the other modulepaths in their definition order.

-
-
-

When locating modulefiles, if a .modulerc, a .version, a directory or a modulefile cannot be read during the search it is simply ignored with no error message produced. Visibility of modulefiles can thus be adapted to the rights the user has been granted. Exception is made when trying to directly access a directory or a modulefile. In this case, the access issue is returned as an error message.

-
-
-

A modulefile whose name or element in its name starts with a '.' dot is considered hidden. Hidden modulefile is not displayed or taken into account except if it is explicitly named. By inheritance, a symbolic version-name assigned to a hidden modulefile is displayed or taken into account only if explicitly named. Module alias targeting a hidden modulefile appears like any other module alias.

-
-
-
-

Modulefile Specific Help

-
-

Users can request help about a specific modulefile through the module(1) command. The modulefile can print helpful information or start help oriented programs by defining a ModulesHelp subroutine. The subroutine will be called when the module help modulefile command is used.

-
-
-
-

Modulefile Specific Test

-
-

Users can request test of a specific modulefile through the module(1) command. The modulefile can perform some sanity checks on its definition or on its underlying programs by defining a ModulesTest subroutine. The subroutine will be called when the module test modulefile command is used. The subroutine should return 1 in case of success. If no or any other value is returned, test is considered failed.

-
-
-
-

Modulefile Display

-
-

The module display modulefile command will detail all changes that will be made to the environment. After displaying all of the environment changes modulecmd.tcl will call the ModulesDisplay subroutine. The ModulesDisplay subroutine is a good place to put additional descriptive information about the modulefile.

-
-
-
-
-
-

ENVIRONMENT

-
-
-
-
MODULEPATH
-
-

Path of directories containing modulefiles.

-
-
-
-
-
-
-

SEE ALSO

-
-
-

module(1), Tcl(n), TclX(n), xrdb(1), exec(n), uname(1), domainname(1), tclvars(n), lsort(n)

-
-
-
-
-

NOTES

-
-
-

Tcl was developed by John Ousterhout at the University of California at Berkeley.

-
-
-

TclX was developed by Karl Lehenbauer and Mark Diekhans.

-
-
-

Modules is covered by the GNU General Public License, version 2 and the GNU Lesser General Public License, version 2.1. Copyright © 1996-1999 John L. Furlani & Peter W. Osel, © 1998-2017 R.K.Owen, © 2002-2004 Mark Lakata, © 2004-2017 Kent Mein, © 2016-2017 Xavier Delaruelle. All rights reserved. Trademarks used are the property of their respective owners.

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/releases.html b/doc/html/build-system/releases.html deleted file mode 100644 index 26e8583..0000000 --- a/doc/html/build-system/releases.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - - - - -Releases - - - - - -
-
-

Releases

-
-
-

The life-time of a module has three phases:

-
-
-
unstable
-

A module is unstable during development and testing. As long as a module is unstable, it can be changed.

-
-
-
stable
-

After testing a module is marked as stable. Changes to the module are not allowed any more.

-
-
-
deprecated
-

A module marked as deprecated should not be used any more. Deprecated modules can be removed after a certain time in this phase.

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/runtime-config-files/module_config.html b/doc/html/build-system/runtime-config-files/module_config.html deleted file mode 100644 index 195725d..0000000 --- a/doc/html/build-system/runtime-config-files/module_config.html +++ /dev/null @@ -1,145 +0,0 @@ - - - - - - - -Pmodules 1.0: .release-version - - - - - -
-
-

Table of Contents
-Pmodules 1.0 configuration file .release-version
-Pmodules 1.1 and newer configuration file .config-version

-
-
- - - - - -
- - -
-

The runtime configuration files are evaluated only for modules inside -the Pmodules hierarchy. If you use modbuild these files are created -automatically. Otherwise you have to create them by hand.

-
-
-
-
-

Pmodules 1.0: .release-version

-
-
-

In .release-version the release stage of a module is -defined. The file must be in the same directory as the modulefile. The -content is a single line defining the release stage. Allowed text is

-
-
-
    -
  • -

    unstable

    -
    • -
  • -

    stable

    -
    • -
  • -

    deprecated

    -
    • -
-
-
-

If the file doesn’t exist and the module is inside the Pmodule -hierarchy unstable. All modules outside the Pmodules hierarchy are -considered as stable.

-
-
- - - - - -
- - -
-

This configuration file is deprecated in version 1.1 and newer. Please -see next section.

-
-
-
-
-
-
-

Pmodules 1.1 and newer: .config-version

-
-
-

In .config-version the following properties of a module can be -configured:

-
-
-
    -
  • -

    the release stage

    -
    • -
  • -

    the systems on which a module is available

    -
    • -
  • -

    the systems on which a module is unavailable

    -
    • -
-
-
-

The format of the file is YAML.

-
-
-
-
relstage
-
-

The release stage of the module. Allowed values are -unstable, stable and deprecated.

-
-
systems
-
-

Sequence of systems on which the module is available. Systems -can be hostnames with shell style glob pattern or OS names like -(rhel7, rhel8).

-
-
blocklist
-
-

Sequence of systems on which the module is no -available. Systems can be hostnames with shell style glob patterns or -OS names.

-
-
-
-
-

Example:

-
-
-
-
relstage: unstable
-systems: [merlin-*, ra-*]
-blocklist: []
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/site-specific-notes.html b/doc/html/build-system/site-specific-notes.html deleted file mode 100644 index 360023d..0000000 --- a/doc/html/build-system/site-specific-notes.html +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - -Site specific setup - - - - - -
-
-

Site specific setup

-
-
-

In this section we document site specific aspects of the Pmodules Environment installation.

-
-
-

Pmodules @PSI

-
-

Installation overview

-
-

The Pmodules Environment must be accessed via the path /opt/psi. This -is either a symbolic link to or a bind mount of a dedicated -directory on AFS.

-
-
-

The minimum required operating system is RHEL6 or clone. Other Linux -distributions with glibc 2.12 or newer should work too. It might be -necessary to install some libraries used by certain modules. In general -the modules are build with as few dependencies to system libraries as -possible.

-
-
-

At PSI several Pmodules Environments are available covering -miscellaneous use cases like desktop, dedicated HPC systems and -operating systems like Linux and macOS. The main reason to provide -different environments for the same operating systems is, to be able to -support different Pmodules configurations and different sets of groups -inside the environments. The following environments are available:

-
-
-
-
psi.x86_64_slp6
-
-

Pmodules environment for desktop systems.

-
-
psi.merlin
-
-

Pmodules environment for the HPC system Merlin. For the -time being this is identical with the environment for desktop systems.

-
-
psi.ra
-
-

Pmodules environment for the HPC system Merlin. This -environment provides all modules of the desktop environment plus the -groups EM and MX.

-
-
psi.pmod6
-
-

Pmodules environment for the development system -pmod6.psi.ch

-
-
psi.i386_el6
-
-

Pmodules environment for 32bit CPU. This is for legacy -applications and modules only!

-
-
psi.amd64_darwin_130
-
-

Pmodules environment for macOS >= 10.12.

-
-
-
-
-
-

Internal organisation with AFS volumes

-
-

At a first glance the internal organisation with several AFS volumes for -modules, groups and environments looks confusing, complicate and -overdone. But it is flexible and has some advantages on AFS like -reasonable volume sizes respective number of files per volume.

-
-
-
Module-volumes
-
-

It is strongly recommended to create and use a dedicated AFS volume per -module. In the normal case one volume is sufficient for all versions of -a module. In some special cases like Intel Compiler, Matlab etc. it is -strongly recommended to create and use one AFS volumes per version.

-
-
-
-
Group-volumes
-
-

Groups are containers for modules. Most groups are shared with multiple -environments. Groups are stored in dedicated AFS volumes, one volume per -group. In group-volumes module-volumes are mounted. It is strongly -recommended not to install modules in group-volumes but to create -volumes per module. For a group providing modules for a dedicated system -it can be acceptable to store special volumes directly into the -group-volume.

-
-
-
-
Environment-volumes
-
-

All environments are stored in a dedicated AFS volume. This volumes are -mounted in the directory /afs/psi.ch/sys. The name of the mount point -is the same as the environment names listed above. The volumes used to -provide an environment should be used to mount group volumes.

-
-
-
Example 1. GCC modules for Linux
-
-
-

All GCC versions are installed in the directory -/afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc. This is a mount point -for the module-volume m.e6.P.gcc.

-
-
-

/afs/psi.ch/sys/psi.x86_64_slp6/Programming is a mount-point for the -group-volume m.e6.Programming

-
-
-

/afs/psi.ch/sys/psi.x86_64_slp6 is a mount-point for the -environment-volume sys.psi.x86_64_sl6.

-
-
-
-
-
-
-

Adding a new group, module or version

-
-

A consequence of the organisation into AFS volumes is, that a new volume -must be created for each new module, group and environment. For the time -being this must be done by an AFS administrator.

-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/writing-and-maintaining-variant-files.html b/doc/html/build-system/writing-and-maintaining-variant-files.html deleted file mode 100644 index 4fd262a..0000000 --- a/doc/html/build-system/writing-and-maintaining-variant-files.html +++ /dev/null @@ -1,154 +0,0 @@ - - - - - - - -Writing and maintaining variant files - - - - - -
-
-

Writing and maintaining variant files

-
-
-

The purpose of the variants files is to define the release of a module, the build- and run-time dependencies for each module version.

-
-
-

Locations

-
-

variants files are searched in the several directories and various names, the first file found will be used:

-
-
-
    -
  1. -

    $P/$V_MAJOR.$V_MINOR.$V_PATCHLVL/variants.$SYSTEM

    -
    2. -
  2. -

    $P/$V_MAJOR.$V_MINOR.$V_PATCHLVL/variants

    -
    3. -
  3. -

    $P/$V_MAJOR.$V_MINOR/variants.$SYSTEM

    -
    4. -
  4. -

    $P/$V_MAJOR.$V_MINOR/variants

    -
    5. -
  5. -

    $P/$V_MAJOR/variants.$SYSTEM

    -
    6. -
  6. -

    $P/$V_MAJOR/variants

    -
    7. -
  7. -

    $P/files/variants.$SYSTEM

    -
    8. -
  8. -

    $P/files/variants

    -
    9. -
-
-
-

The reason for supporting several location is to keep the files short -and easy to read. Which scheme should be used depends on the software. For -software on the top-level of the hierarchy (like Gnuplot or GCC), -$P/files/variants or $P/$V_MAJOR/variants is a good choice. For -software with lot of combinations like HDF5, -$P/$V_MAJOR.$V_MINOR/variants or -$P/$V_MAJOR.$V_MINOR.$V_PATCHLVL/variants is recommended.

-
-
-

System specific variants files are supported for two reasons. On different -operating systems like Linux and macOS the required dependencies might differ. -We have the same problem, if we want to build modules on a HPC system like Euler (ETHZ) or Edison (NERSC). The value of system defaults to the string returned by uname -s and can be overwritten with the argument --system.

-
-
-
-

Format

-
-

The variants files can contain any number of lines. A line is either -* a variant specification consisting of the module name and version, the release and all dependencies -* an empty line (white space is allowed) -* or a comment line. Comment lines can start with any string not matching the module name.

-
-
-

Variant specifications

-
-

The form of a variant specification is

-
-
-
-
$P/$V[-$V_RELEASE][_USEFLAG] unstable|stable|deprecated [group dependency...] [run-time dependency...] [build dependency...]
-
-
-
-
Example
-
-
parmetis/4.0.3  stable gcc/7.3.0 openmpi/3.0.0  b:cmake/3.6.3
-
-
-
-
Module name and version
-

The line must begin with the full module name. This includes name, version as well as the optional release and use-flag. White-space at the beginning of the line is not allowed.

-
-
-
Release
-

The release is either unstable, stable or deprecated. The meaning of the releases is explained in the next section.

-
-
-
Dependencies
-

Dependencies are loaded in the specified order. It is recommended to specify the dependencies of a the (hierarchical) group first, then additional modules required at run-time and the modules required to build it at the end.

-
-
-
Hierarchical dependencies
-

If the module is in a hierarchical group like MPI, you must specify the modules required for this group. For modules in the group

-
-
-
    -
  • -

    Compiler a compiler must be specified

    -
    • -
  • -

    MPI a compiler and a MPI implementation must be specified

    -
    • -
  • -

    HDF5 a compiler, a MPI implementation and a HDF5 module must be specified

    -
    • -
  • -

    …​

    -
    • -
-
-
-
-
-

Note: The order of these dependencies is relevant since the modules are loaded in the given order. Example: before a MPI module is available a compiler must be loaded. So a compiler module must be listed first!

-
-
-
-
-
Run-time dependencies
-

are automatically loaded before the module is loaded with the module load command. Run-time dependencies should be specified even if they are not required to build the module.

-
-
-
Build dependencies
-

are loaded before the actual build starts. Build dependencies are only required tp build the module. They are not automatically loaded together with the module. Build dependencies must be prefixed with b:.

-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/writing-build-scripts-for-binary-packages.html b/doc/html/build-system/writing-build-scripts-for-binary-packages.html deleted file mode 100644 index b977720..0000000 --- a/doc/html/build-system/writing-build-scripts-for-binary-packages.html +++ /dev/null @@ -1,37 +0,0 @@ - - - - - - - -Build-blocks for modules build from binary packages - - - - - -
-
-

Build-blocks for modules build from binary packages

-
-
-

It is strongly recommended to write build-blocks for modules build from binary packages the same way as for modules build from source. Document each step in a README.md. If possible, try to script the installation.

-
-
-

For more details and to get an idea please have a look at the -mxm module in the System group as example.

-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build-system/writing-build-scripts.html b/doc/html/build-system/writing-build-scripts.html deleted file mode 100644 index 56b0d9d..0000000 --- a/doc/html/build-system/writing-build-scripts.html +++ /dev/null @@ -1,272 +0,0 @@ - - - - - - - -Writing build-scripts - - - - - -
-
-

Writing build-scripts

-
-
-

Introduction

-
-

Building a module consists of the following steps

-
-
-
-
setup
-
-

Setting up the environment includes

-
-
    -
  • -

    name the group of the module.

    -
    • -
  • -

    specify the download location(s).

    -
    • -
  • -

    specify required patches.

    -
    • -
  • -

    set arguments for the configuration step - either autotools or CMake.

    -
    • -
  • -

    define additional files to install, like license, copyright etc.

    -
    • -
-
-
-
prepare
-
-

Download, unpack the sources and apply patches.

-
-
configure
-
-

Run autotools or CMake script or whatever is required to setup.

-
-
compile
-
-

Compile everything.

-
-
install
-
-

Install software and setup module environment.

-
-
-
-
-

Except for the setup, the implementation of the steps is in many cases -almost identical. The prep step requires locations from where to -download files. In some cases patches have to be applied. The -configure step usually requires some additional arguments: what -features should be enabled, paths to required software etc. In most -cases the compile and install steps are the same - just calling -make and make install.

-
-
-

The Pmodules build-system provides functions to set up the build -environment and default functions for all build-steps. It is -possible to hook into each build-step before and after the default functions -are called. In cases where hooks are not sufficient to get the default function doing their job, the build-script must define functions for the corresponding step overwriting the default function.

-
-
-
-

Before you begin

-
-

The most challenging part in building a module is to compile the software in the right way. As soon as you know this, it is pretty easy to build a module.

-
-
-

What you should have in mind when writing a build-script

-
-
-
    -
  • -

    a "standard" module for Linux should run on RHEL6 and 7 and other modern Linux distribution.

    -
    • -
  • -

    which feature are required?

    -
    • -
  • -

    which dependencies do we have to system libraries?

    -
    • -
  • -

    which dependencies do we have to other modules? Maybe we have to build these dependencies first.

    -
    • -
  • -

    be aware of the problems with (shared) libraries

    -
    -
      -
    • -

      if you copy them, another version from another module might be used!

      -
      • -
    • -

      more than one version might be used: library X is using version libfoo.so.1.0 and library Y use using libfoo.so.1.42.

      -
      • -
    • -

      do not mix shared and static versions of the same library

      -
      • -
    • -

      ..

      -
      • -
    -
    -
    • -
-
-
-

Recommendations

-
-
-
    -
  • -

    reduce dependencies be using (and building) static libraries

    -
    • -
  • -

    build static libraries with -fPIC!

    -
    • -
  • -

    if static libraries are not available or not usable, think about copying/installing these shared libraries in the module

    -
    • -
-
-
-
-

Executing the build-script

-
-

Build-scripts are BASH scripts executed by modbuild - which is itself a bash script. The following shebang must be used for build-scripts:

-
-
-
-
#!/usr/bin/env modbuild
-
-
-
-

The build-script must be called with the version number of the module you want to build.

-
-
-
Example 1. Calling build-script to build gnuplot 5.2.4
-
-
-
-
./build 5.2.4
-
-
-
-
-
-

In cases where several variants are available for the same version but with different compilers and/or MPI implementations, the compiler etc. must be specified on the command line.

-
-
-
Example 2. Calling build-script for HDF5 1.10.3 with certain GCC and MPI implementation/version:
-
-
-
-
./build 1.10.3 --with=gcc/7.3.0 --with=openmpit/3.1.2
-
-
-
-
-
-
-

The master build-function

-
-

The build-system provides a master build function, which is -called after the build-script has been sourced. It executes the steps -prepare, configure, compile and install in sequential -order. The build-system provides default functions for each step:

-
-
-
    -
  • -

    pbuild::prep for preparing

    -
    • -
  • -

    pbuild::configure for configuring

    -
    • -
  • -

    pbuild::compile for compiling

    -
    • -
  • -

    pbuild::install for installing

    -
    • -
-
-
-

In many cases the default step-functions can be used. Sometime it is required to hook into a step before/after the default step-function is/has been called. Pre- and post-processing can be implemented with hooks. In more complicated cases the step-functions must be implemented in the build-script.

-
-
-

Each build-step consist of the following sub-steps:

-
-
-
    -
  • -

    an OS/system specific pre hook

    -
    • -
  • -

    a generic pre hook

    -
    • -
  • -

    the main step-function

    -
    • -
  • -

    an OS/system specific post hook

    -
    • -
  • -

    a generic post hook

    -
    • -
-
-
-
Example 3. ParMETIS pre- and post-install hooks
-
-
-
-
pbuild::pre_install() {
-        mkdir -p "${PREFIX}/include/metis"
-        mkdir -p "${PREFIX}/lib"
-}
-
-pbuild::post_install() {
-        case ${V_MAJOR} in
-        3 )
-                cd "${SRC_DIR}"
-                cp *.h $PREFIX/include
-                cp METISLib/*.h $PREFIX/include/metis
-                cp lib*.a $PREFIX/lib
-                ;;
-        4 )
-                LIBMETIS_A=$(find . -name libmetis.a)
-                METIS_H=$(find "${SRC_DIR}" -name metis.h)
-
-                install -m 0644 $METIS_H    $PREFIX/include
-                install -m 0644 $LIBMETIS_A $PREFIX/lib
-                ;;
-        esac
-}
-
-
-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/build.html b/doc/html/build.html deleted file mode 100644 index 69f38e6..0000000 --- a/doc/html/build.html +++ /dev/null @@ -1,2199 +0,0 @@ - - - - - - - -BUILDING PMODULES - - - - - -
-
-

Introduction

-
-
-

In the simplest case adding a Pmodule can be done by adding a modulefile to a certain directory. Below is an example of a "do nothing" modulefile in the group Sandbox.

-
-
-
Example: /opt/psi/Sandbox/modulefiles/null/1.0.0
-
-
#%Pmodule
-
-module-whatis           "does absolutely nothing"
-module-maintainer       "Achim Gsell <achim.gsell@psi.ch>"
-module-license          "MIT"
-
-module-help     "
-This is a do nothing module.
-"
-
-
-
-

In addition to the modulefile a corresponding configuration file - defining for example the release stage - should be installed in the same directory as the modulefile. See next section for a detailed documentation of configuration files.

-
-
-
Example: configuration file /opt/psi/Sandbox/modulefiles/null/.release-1.0.0 for the null/1.0.0 module
-
-
stable
-
-
-
-

Modulefiles are written in the Tool Command Language (Tcl). See section [modulefiles] for a detailed documentation. In Pmodules version 1.1.16 and newer modulefiles written in Lua are also supported but with some limitations.

-
-
-

The above example doesn’t provide any software. In the following example we show a simple 'HelloWorld' module with a 'Hello, world!' program.

-
-
-
Example: modulefile /opt/psi/Sandbox/modulefiles/HelloWorld/1.0.0:
-
-
#%Pmodule
-
-module-whatis           "'Hello, world!' module"
-module-maintainer       "Achim Gsell <achim.gsell@psi.ch>"
-module-license          "MIT"
-module-url              "http://pmodules.gitpages.psi.ch"
-
-module-help     "
-The module provides a 'Hello, world!' program.
-"
-
-
-
-
Example: configuration file /opt/psi/Sandbox/modulefiles/HelloWorld/.release-1.0.0 for the HelloWorld/1.0.0 module
-
-
unstable
-
-
-
-
Example: /opt/psi/Sandbox/HelloWorld/1.0.0/bin/hello:
-
-
#!/usr/bin/env python3
-
-print("Hello, world!")
-
-
-
-

In principal, it is possible to install modules 'by hand' by installing the software, module- and configuration files at the right place. For reproducibility, documentation and re-usability it is highly recommended to write build-recipes for each module or - at least - a README and host everything on a PSI Gitlab server.

-
-
-

Overall the main cases for building modules are:

-
-
-
    -
  • -

    Building a module from source. This is the most common case. Examples: git, -gnuplot, openmpi, hdf5, …​
    -In this case it is highly recommended to code each step - usually download, configure, compile and install - in a script, write a modulefile and a configuration file.

    -
    • -
  • -

    Building a module with a binary package. Examples: Intel compiler, Matlab, -ANSYS, Mathematica, …​
    -In this case best practice is to install the package by hand and write a "dummy" build script, a modulefile and a configuration file. If it is possible and simple to script the installation, code this in the build script. If you cannot easily script the installation, document each step in a README file.

    -
    • -
-
-
- - - - - -
- - -
-

In any case: keep everything in a Git repository on either gitlab.psi.ch or git.psi.ch. -The Git repository for the groups Tool, Programming, Compiler, HDF5, HDF_serial and System is Pmodules/buildblock. Other groups can be hosted anywhere. But to keep everything together a project in Pmodules might be a good choice.

-
-
-
-
-

Many modules for the Pmodules environment have to be build from -source. The building plan of a module is coded in a so called -build-block. A build-block consists at least of a build-script with instruction how to download, compile and install a dedicated piece of -software, a modulefile and a configuration file.

-
-
-

To avoid problems with dependencies to system libraries or installed software it is best practice to build modules on dedicated systems. At PSI:

-
-
-
    -
  • -

    For modules which should be able to run on all RHEL7 and newer systems, use the system pmod7.psi.ch. If you need access to the system please contact achim.gsell@psi.ch.

    -
    • -
  • -

    Merlin6 specific modules - like openmpi, mpich and modules depending on them - must be compiled on a Merlin6 login node.

    -
    • -
  • -

    Modules specific for a beamline should be compiled on a Ra login node with RHEL8 or a dedicated RHEL8 beamline system.

    -
    • -
-
-
- - - - - -
- - -
-

If you build a module on RHEL7, it might not run on RHEL8 due to newer versions of system libraries. In must cases this can be solved by installing these system libraries in the module itself and setting the RPATH. The recommended path in this case is $PREFIX/lib/system whereby $PREFIX is the installation prefix of the software.

-
-
-
-
-

In the next section we describe how to write build recipes.

-
-
-
-
-

Predefined variables

-
-
-

Since we use BASH for our build-scripts and Tcl for modulefiles, we use BASH/Tcl syntax for variables in this documentation. So, if VARIABLE is the name of a variable, $VARIABLE the value of it.

-
-
-

In modulefiles and build-scripts the following variables are predefined:

-
-
-
-
P
-
-

the name of the module

-
-
V
-
-

the module version. The version number consists of a major- and a minor version number, a patch-level and a release number. All numbers but the major version number are optional. Major-, minor number and patch-level are separated by dots, the release number by a minus. Example: 1.0.3-2

-
-
V_MAJOR
-
-

the major version number. Example: 1

-
-
V_MINOR
-
-

the minor version number. Example: 0

-
-
V_PATCHLVL
-
-

the patch-level. Example: 3

-
-
V_RELEASE
-
-

the release number. Example: 2

-
-
V_PKG
-
-

version number without release.

-
-
GROUP
-
-

group the module is in.

-
-
PREFIX
-
-

installation prefix of the module.

-
-
PMODULES_ROOT
-
-

root of Pmodules installation. At PSI this is /opt/psi.

-
-
-
-
-

In build-scripts the following variables are predefined too:

-
-
-
-
TEMP_DIR
-
-

directory for temporary files.

-
-
SRC_DIR
-
-

directory of unpacked sources, set to $PMODULES_TMPDIR/$P-$V/src

-
-
BUILD_DIR
-
-

build directory, set to $PMODULES_TMPDIR/$P-$V/build

-
-
BUILDBLOCK_DIR
-
-

Directory where the build-script is in.

-
-
BUILD_SCRIPT
-
-

Name of the build script.

-
-
SYSTEM,OS
-
-

Can be set with the --system option. The value defaults to the string returned by uname -s. The use of OS is obsolete.

-
-
-
-
-

In modulefiles the following variables are predefined too:

-
-
-
-
name
-
-

Same as P (obsolete, for historical reasons).

-
-
version
-
-

Same as V (obsolete, for historical reasons).

-
-
group
-
-

The group the module is member of.

-
-
-
-
-
-
-

Build scripts

-
-
-

TBW

-
-
-

Examples

-
-

TBW

-
-
-
-

Setup functions

-
-

pbuild::add_configure_args: Set configuration options

-
-
Synopsis
-
-
-
pbuild::add_configure_args arg...
-
-
-
-
-
Description
-
-

Add arguments/options to the call of configure or cmake.

-
-
-
-
Example
-
-

Excerpt from libtasn1 build-script (autotools):

-
-
-
-
pbuild::add_configure_args "--disable-shared"
-pbuild::add_configure_args "CFLAGS=-fPIC"
-
-
-
-

Excerpt from ParMETIS build-script (CMake):

-
-
-
-
pbuild::add_configure_args "-DMETIS_PATH=${SRC_DIR}/metis"
-pbuild::add_configure_args "-DGKLIB_PATH=${SRC_DIR}/metis/GKlib"
-
-
-
-
-
-

pbuild::add_patch: Adding patches to be applied

-
-
Synopsis
-
-
-
pbuild::add_patch patch_fname [strip_num_dirs]
-
-
-
-
-
Description
-
-

Apply a patch to the unpacked sources. The argument patch_fname must be a relative file-name to the build-block directory. The argument strip_num_dirs is optional and defaults to 1. Please read the patch(1) manual page for more details. The patches are applied inside the source directory with the command:

-
-
-
-
patch --strip=strip_num_dirs < "${BUILDBLOCK_DIR}/patch_fname"
-
-
-
-
-
Example
-
-

Excerpt from ioapi build-script:

-
-
-
-
pbuild::add_patch 'files/Makefile.pncf.sed.patch'
-
-
-
-
-
-

pbuild::add_to_group: Define the group of a module

-
-
Synopsis
-
-
-
pbuild::add_to_group GROUP
-
-
-
-
-
Description
-
-

Define the group the module will be installed in. Sometimes it is not obvious in which group a module should go. If in doubt, Tools might be the best.

-
-
-

A (incomplete) list of available groups:

-
-
-
-
Tools
-
-

Group for tools like Gnuplot, Git, vim, Emacs, openssl. This group is visible by default.

-
-
Programming
-
-

Group for compilers, scripting languages and tools used for programming, like GCC, Python, CMake, autotools, Matlab. This group is visible by default.

-
-
Compiler
-
-

Hierarchical group for modules compiled with a certain compiler module. Examples: open-mpi, MPICH, serial HDF5.

-
-
HDF5_serial
-
-

Hierarchical group for modules compiled with a certain compiler and serial HDF5 module. Examples: netCDF, H5hut.

-
-
MPI
-
-

Hierarchical group for modules compiled with a certain compiler and MPI module. Examples: parallel Boost, parallel HDF5, ParMETIS, Gromacs.

-
-
HDF5
-
-

Hierarchical group for modules compiled with a certain compiler, MPI and parallel HDF5 module. Examples: netCDF, H5hut, Trilinos.

-
-
System
-
-

Group for system tools. This group is not visible by default. Examples: filebench, fsstress, nmap, patchelf.

-
-
Libraries
-
-

Group for libraries required to compile other modules but not providing (useful) tools. This group is not visible by default. Examples: GMP, MPC, MPFR

-
-
MX
-
-

Group for special tools used at the MX beam-line. This group is visible only on dedicated systems.

-
-
EM
-
-

Group for Ra specific software. This group is only visible and available on Ra.

-
-
-
-
-
-
Example
-
-
Example 1. Define the group for the Gnuplot module:
-
-
-
-
pbuild::add_to_group 'Tools'
-
-
-
-
-
-
-
-

pbuild::set_download_url: Set download URL

-
-
Synopsis
-
-
-
pbuild::set_download_url URL [fname]
-
-
-
-
-
Description
-
-

Tell the build system where to download the required (source-)files. If fname is passed, it will be used as the output file-name of the download.

-
-
-

In some cases software must be downloaded from a Git repository on Github, Bitbucket or Gitlab.

-
-
-

To download a certain tag/version from Github, Bitbucket or Gitlab use:

-
-
-
-
https://github.com/OWNER/PROJECT/archive/${V_PKG}/$P-${V_PKG}.tar.gz
-https://bitbucket.org/OWNER/PROJECT/get/${V_PKG}.tar.gz#/$P-%{V_PKG}.tar.gz
-https://gitlab.com/OWNER/PROJECT/-/archive/${V_PKG}/$P-${V_PKG}.tar.gz
-
-
-
-
-
Examples
-
-

Excerpt from Trilinos build-script:

-
-
-
-
pbuild::set_download_url \
-        "https://github.com/$P/$P/tarball/$P-release-${V//./-}" \
-        "$P-$V.tar.gz"
-
-
-
-
-
-
-

Build functions

-
-

pbuild::prep: Download and unpack

-
-
Synopsis
-
-
-
pbuild::pre_prep_${SYSTEM}
-pbuild::pre_prep
-pbuild::prep
-pbuild::post_prep_${SYSTEM}
-pbuild::post_prep
-
-
-
-
-
Description
-
-

Functions to prepare the sources. This includes

-
-
-
    -
  • -

    downloading required files a verifying the checksums

    -
    • -
  • -

    unpacking

    -
    • -
  • -

    applying patches

    -
    • -
-
-
-

Before the prep-functions are called, the build-system changes to the source -directory (${SRC_DIR}).

-
-
-

In the most uses cases the default function pbuild::prep provided by -the build-system can be used and nothing must be implemented in the -build-script. In some rare cases pre- or post-hooks are required to -make the default function feasible. One use case with autotools for a post-hook is to create the configure scripts, if only configure.ac is shipped with the software.

-
-
-

The default hooks provided by the build system are only stubs and do -nothing.

-
-
-

If the default function cannot be used, it must be implemented in the build-script.

-
-
-
-
Example
-
-

The source distribution of the IOAPI library contains object files! These files must be removed after unpacking:

-
-
-
-
pbuild::post_prep() {
-        find "${SRC_DIR}" -name "*.mod" -exec rm {} \;
-        find "${SRC_DIR}" -name "*.o" -exec rm {} \;
-}
-
-
-
-
-
-

pbuild::configure: Configure software

-
-
Synopsis
-
-
-
pbuild::pre_configure_${SYSTEM}
-pbuild::pre_configure
-pbuild::configure
-pbuild::post_configure_${SYSTEM}
-pbuild::post_configure
-
-
-
-
-
Description
-
-

Configure the software for compilation.

-
-
-

Before these functions are called, the build-system changes to the -build directory (${BUILD_DIR}).

-
-
-

In the most uses cases the default function pbuild::configure provided by -the build-system can be used and nothing must be implemented in the -build-script.

-
-
-

The default function first searches whether the software can be -configured with autotools. If yes, configuration with autotools will -be performed. Otherwise the existence of a CMake script will be -checked. If found, configuration will be done via CMake. If scripts -for both configuration tools exist, the to be used tool can be -selected with pbuild::use_autotools or -pbuild::use_cmake. Arguments to configure or -cmake can be set with -pbuild::add_configure_args.

-
-
-

A common use case for the pre-configure hooks is to define arguments -passed to autotools or CMake by the default function.

-
-
-

If the default function cannot be used, the pbuild::configure -function must be implemented in the build-script.

-
-
-
-
Examples
-
-

Excerpt from the parallel HDF5 build-script

-
-
-
-
pbuild::pre_configure() {
-        pbuild::add_configure_args "CC=${MPICC}"
-        pbuild::add_configure_args "CXX=${MPICXX}"
-
-        pbuild::add_configure_args "--enable-shared"
-        pbuild::add_configure_args "--enable-parallel"
-        pbuild::add_configure_args "--enable-cxx"
-        pbuild::add_configure_args "--enable-unsupported"
-        #pbuild::add_configure_args "--enable-threadsafe"
-        pbuild::add_configure_args "--with-pic"
-
-        local enable_fortran='yes'
-
-        case "${COMPILER}" in
-                clang-macos )
-                        enable_fortran='no'
-                        # we do not have Fortran in Xcode
-                        ;;
-                pgi )
-                        # PGI uses GCC's include files, some object files and
-                        # the STL implementation!
-                        # The PGI C pre-processor is broken and doesn't work
-                        # for HDF5. We use the pre-processor of the underlying
-                        # GCC...
-                        # This is a bit hackish!
-                        #
-                        # The following eval sets GCCDIR! Which is something
-                        # like:
-                        # /opt/psi/Programming/gcc/7.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.0
-                        #
-                        eval $(pgcc -show 2>/dev/null | \
-                                awk '/^GCCDIR[[:space:]]*=/{gsub(/[[:space:]]/,""); print $0}')
-                        pbuild::add_configure_args "CPP=${GCCDIR%%/..*}/cpp"
-                        pbuild::add_configure_args "CFLAGS=-fPIC"
-                        pbuild::add_configure_args "CXXFLAGS=-fPIC"
-                        pbuild::add_configure_args "FCFLAGS=-fPIC"
-                        ;;
-        esac
-
-        if [[ "${enable_fortran}" ===== 'yes' ]]; then
-                pbuild::add_configure_args "F77=${MPIF77}"
-                pbuild::add_configure_args "F90=${MPIF90}"
-                pbuild::add_configure_args "FC=${MPIFC}"
-                pbuild::add_configure_args "FORTRAN=${MPIFORTRAN}"
-                pbuild::add_configure_args "--enable-fortran"
-        fi
-
-
-
-

Simplified excerpt from the OpenBLAS build-script

-
-
-
-
pbuild::configure() {
-        case ${COMPILER} in
-        gcc )
-                CC='gcc'
-                ;;
-        intel )
-                CC='icc'
-                ;;
-        clang-macos )
-                CC='gcc'
-                ;;
-        * )
-                die 3 "Oops: unknown compiler: ${COMPILER}"
-                ;;
-        esac
-        cat <<EOF > "${SRC_DIR}/make.inc"
-SHELL = /bin/sh
-PLAT =
-DRVOPTS  = \$(NOOPT)
-ARCHFLAGS= -ru
-EOF
-        echo "USE_SIMPLE_THREADED_LEVEL3 = 1" >> "${SRC_DIR}/Makefile.rule"
-        echo "NO_AVX = 1" >> "${SRC_DIR}/Makefile.rule"
-        echo "NO_AVX2 = 1" >> "${SRC_DIR}/Makefile.rule"
-        if pbuild::use_flag "omp"; then
-                echo "USE_THREAD = 1" >> "${SRC_DIR}/Makefile.rule"
-        else
-                echo "USE_THREAD = 0" >> "${SRC_DIR}/Makefile.rule"
-        fi
-}
-
-pbuild::post_configure_Darwin() {
-        sed -i.bak "s/MACOSX_DEPLOYMENT_TARGET=.*/MACOSX_DEPLOYMENT_TARGET=$MACOSX_DEPLOYMENT_TARGET/" \
-                "${SRC_DIR}/Makefile.system"
-}
-
-
-
-
-
-

pbuild::compile: Compile software

-
-
Synopsis
-
-
-
pbuild::pre_compile_${SYSTEM}
-pbuild::pre_compile
-pbuild::compile
-pbuild::post_compile_${SYSTEM}
-pbuild::post_compile
-
-
-
-
-
Description
-
-

Compile the software.

-
-
-

Before these functions are called, the build-system changes to the -build directory (${BUILD_DIR}).

-
-
-

In the most uses cases the default function pbuild::compile provided by -the build-system can be used and nothing must be implemented in the -build-script. The pre- and post-hooks might be useful in cases where

-
-
-
    -
  • -

    to run other make targets than all

    -
    • -
  • -

    multiple packages must be compiled into one module

    -
    • -
  • -

    to compile a dependency required by the main package.

    -
    • -
-
-
-

If the default function cannot be used, the pbuild::compile -function must be implemented in the build-script.

-
-
-
-
Example
-
-

Excerpt from perl build-script

-
-
-
-
pbuild::post_compile() {
-        make test
-}
-
-
-
-
-
-

pbuild::install: Install software

-
-
Synopsis
-
-
-
pbuild::pre_install_${SYSTEM}
-pbuild::pre_install
-pbuild::install
-pbuild::post_install_${SYSTEM}
-pbuild::post_install
-
-
-
-
-
Description
-
-

Compile the software.

-
-
-

Before these functions are called, the build-system changes to the -build directory (${BUILD_DIR}).

-
-
-

In the many uses cases the default function pbuild::install provided by -the build-system can be used and nothing must be implemented in the -build-script. A typical use case for the post-install hook is to install required libraries from other modules or the system to reduce or eliminate run-time dependencies

-
-
-

If the default function cannot be used, the pbuild::install -function must be implemented in the build-script.

-
-
-
-
Example
-
-
-
pbuild::
-
-
-
-
-
-
-

Other functions

-
-

pbuild::compile_in_sourcetree

-
-
Synopsis
-
-
-
pbuild::compile_in_sourcetree
-
-
-
-
-
Description
-
-

By default the build-system compiles software in a separate build-directory. This is not possible with all software. With the function pbuild::compile_in_sourcetree the build-directory is set to the source-directory.

-
-
-
-
Example
-
-
-
pbuild::compile_in_sourcetree
-
-
-
-
-
-

pbuild::install_docfiles: Set documentation files to be installed

-
-
Synopsis
-
-
-
pbuild::install_docfiles fname...
-
-
-
-
-
Description
-
-

Install the passed files into $PREFIX/share/doc/$P. At least the file containing the license and copyright should be installed.

-
-
-
-
Example
-
-

Excerpt from parallel-netcdf build-script:

-
-
-
-
pbuild::add_docfiles 'AUTHORS' 'CREDITS'
-pbuild::add_docfiles 'COPYING' 'COPYRIGHT'
-pbuild::add_docfiles 'ChangeLog' 'NEWS'
-pbuild::add_docfiles 'RELEASE_NOTES'
-
-
-
-
-
-

pbuild::set_sha256sum: Pass SHA256 hash sum to build-system

-
-
Synopsis
-
-
-
pbuild::set_sha256sum SHA256_HASH
-
-
-
-
-
Description
-
-

Tell the build-system which SHA256 hash sum a file must have. The format of the argument is file-name:hash-sum.

-
-
-
-
Examples
-
-

Excerpt from Trilinos build-script:

-
-
-
-
pbuild::set_sha256sum \
-	"trilinos-12.12.1.tar.gz:c8f2029fa36230b9f384c56139aaa33111227bcf653e73f7daf3c9efdecc1d2d"
-
-
-
-
-
-

pbuild::set_supported_compilers

-
-
Synopsis
-
-
-
pbuild::supported_compilers STRING...
-
-
-
-
-
Description
-
-

Set list of compiler which can be used to compile the module.

-
-
-
-
Example
-
-
-
pbuild::
-
-
-
-
-
-

pbuild::supported_systems

-
-
Synopsis
-
-
-
pbuild::supported_system STRING...
-
-
-
-
-
Description
-
-

Some modules can be build only for dedicated operating systems. This is particularly the case for operating system specific tools like patchelf.

-
-
-
-
-

pbuild::use_autotools

-
-
Synopsis
-
-
-
pbuild::use_autotools
-
-
-
-
-
Description
-
-

Force the use of autotools.

-
-
-
-
Example
- -
-
-
-

pbuild::use_cmake

-
-
Synopsis
-
-
-
pbuild::use_cmake
-
-
-
-
-
Description
-
-

Force the use of CMake.

-
-
-
-
Example
- -
-
-
-
-
-
-

Build configuration files

-
-
-

"legacy" configuration files in Pmodules 1.0

-
- - - - - -
- - -
-

These type of configuration file is deprecated in version 1.1 and -newer. Starting with version 1.2 the use of YAML configuration files -documented in the next section is recommended.

-
-
-
-
-

In the Pmodules 1.0 configuration files the following properties are -defined per version:

-
-
-
    -
  • -

    module name and version

    -
    • -
  • -

    release stage

    -
    • -
  • -

    dependencies

    -
    • -
-
-
-

Each definition must be on a single line.

-
-
-

Configuration filenames and search order

-
-

Configuration files are searched in the following order:

-
-
-
    -
  1. -

    build-recipe-dir/files/variants.system

    -
    2. -
  2. -

    build-recipe-dir/files/variants.OS

    -
    3. -
  3. -

    build-recipe-dir/files/variants

    -
    4. -
-
-
-

Whereby

-
-
-
-
system
-
-

If the build script is called with the option --system=sytem, this configuration file is used.

-
-
OS
-
-

Is the operating system/kernel name returned by uname --s. On Linux this is Linux on macOS this is Darwin.

-
-
-
-
-
-

Format

-
-

A line in a configuration file is either

-
-
-
    -
  • -

    a comment line starting with #

    -
    • -
  • -

    a empty line or a with white-space only

    -
    • -
  • -

    a definition of a variant

    -
    • -
-
-
-
-

Variant specifications

-
-

The form of a variant specification is

-
-
-

module-name release_stage dependencies

-
-
-

Whereby:

-
-
-
-
module-name
-
-

Is the name of the module including the version, an -optional release number and an optional suffix. The general form is

-
-

P/V[-V_RELEASE][_SUFFIX]

-
-
-
release_stage
-
-

Defines the release stage of this module -variant. Allowed values are unstable, stable, deprecated, -remove and removed. If the release stage is remove or removed, -this module variant will be removed (if not already removed).

-
-
dependencies
-
-

Defines the module dependencies. Dependencies can -be either a hierarchical dependency, a runtime dependency or a build -dependency. Hierarchical and runtime dependencies are loaded before -a module itself. Build dependencies are only loaded during build-time -and must be prefixed with b:.

-
-

Dependencies are loaded in the specified order. It is recommended to -specify the dependencies of a the (hierarchical) group first, then -additional modules required at run-time and the modules required to -build it at the end.

-
-
-

If the module is in a hierarchical group like MPI, you must specify -the modules required for this group. For modules in the group

-
-
-
    -
  • -

    Compiler a compiler must be specified.

    -
    • -
  • -

    MPI a compiler and a MPI implementation must be specified.

    -
    • -
  • -

    HDF5 a compiler, a MPI implementation and a parallel HDF5 module -must be specified.

    -
    • -
  • -

    HDF5_serial a compiler and a serial HDF5 module -must be specified.

    -
    • -
-
-
-
-
-
-
Example
-
-
parmetis/4.0.3  stable gcc/7.3.0 openmpi/3.0.0  b:cmake/3.6.3
-
-
-
-
-
-
-

YAML configuration files in Pmodules 1.1 and newer

-
- - - - - -
- - -
-

Pmodules 1.1 and newer are supporting configuration files in YAML -format. For backward compatibility the build-systems supports both -types of configuration files with the YAML configuration file as -default.

-
-
-
-
-

The old format of the variants file is simple but very limited and -almost impossible to extend for new features. To overcome the -limitations a new format using YAML for variants files has been -introduced. For the time being both format are supported. But it is -highly recommended to use the YAML format for new modules and to -migrate existing variants files in the old format to the new.

-
-
-

Path to configuration file

-
-

The path to the configuration file is

-
-
-

build-recipe-dir/files/config.yaml

-
-
-
-

Format

-
-
-
format: 1
-module-name-1:
-  defaults:                                       # optional
-    config-block
-  shasums:                                        # optional
-    filename-1: sha256sum-1
-    ...
-  versions:
-    version-keys-1:
-      config:                                     # optional
-        config-block
-      variants:                                   # optional
-        - config-block-1
-        - ...
-    ...
-module-name-2:
-  ...
-
-
- ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field-NameTypeDescription

format

unsigned int

Format version of the YAML configuration file. For now it must be 1

module-name-N

config-block

Configuration for the Pmodule module-name-N. Example: openmpi

defaults

config-block

Default configuration. This block is optional.

shasums

MAP of string

SHA256 hash sums of source files. Keys are filenames, the value the
- corresponding SHA256 hash sum. This block is optional. A warning is - printed if a hash-sum is missing for a required file.

versions

MAP of configurations for different version keys

A version key is a semicolon separated string of version - numbers. Version numbers can be specified with shell brace - expansion. Example:
- 5.4.{0,1,2,3,4,5,8,9};5.2.{0,4,6,7,8};5.0.0;4.6.3

config

config-block

Optional, version specific configuration block. Configurations - specified here are overriding the defaults.

variants

map of config-block

Variants can be used to compile the some software with different

-
-
-

Configuration blocks

-
- - - - - -
- - -
-

In configuration blocks everything is optional!

-
-
-
-
-
config-block
-
-
build_requires: [build-req-1, ...]
-compile_in_sourcetree: bool
-configure_with: auto|autotools|cmake
-default_variant: variant
-docfiles: [file-1, ...]
-group: group
-group_deps:
-  compilers:
-    cpmpiler-1: [version-1, ...]
-  mpi:
-    mpi-implemation-1: [version-1, ...]
-  hdf5:
-    hdf5: [version-1, ...]
-  hdf5_serial:
-    hdf5[_serial]: [_version-1, ...]
-overlay: overlay
-relstage: release-stage
-runtime_deps: [rt-dep-1, ...]
-suffix: suffix
-systems: [system-1, ...]
-urls:
-  - url: link
-    name: filename
-  - ...
-variant: [variant-1, ...]
-
-
- ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field-NameTypeDescription

build_requires

array of string

Modules required to build this module

compile_in_sourcetree

boolean

Compile in source tree or in a dedicate build directory.

configure_with

string

Choose software configuration system. Allowed values are:
- auto: use autotools if available
- autotools: use autotools
- cmake: use cmake

default_variant

string

(opt) Specifies the default variant to build if no variant is specified

docfiles

array of string

Array with documentation files to be installed in share/doc/

group

string

Group of the module

group_deps

group-deps-object

Group/hierarchical dependencies like compiler, MPI, HDF5 modules

overlay

string

Overlay of the module

relstage

string

Release stage of the module. Allowed values are:
-unstable: the module is still under development
-stable: the module is ready to be used
-deprecated: the module is deprecated
-remove: the module is deprecated and marked to be removed
-removed: the module has been removed

runtime_deps

sequence of strings

Module to be loaded at runtime

suffix

string

This string will be added to the version of the module

systems

sequence of strings

A 'system' is either a hostname or OS name like rhel8. For
- hostnames shell glob pattern matching like merlin-* can be used.

urls

sequence of links and optional file-names

Software which must be downloaded to build a specific module.
- url: Download link
- name: optional output filename. The filename defaults the last - component of the url.
- Default URLs can be defined by using the variables P, V, - V_PKG, V_MAJOR, V_MINOR and V_PATCHLVL. Example:
- https://sourceforge.net/projects/gnuplot/files/$P/$V/$P-${V_PKG}.tar.gz

variant

sequence of strings

Sequence of synonyms for a variant.

-
-
-

Examples

-
-
Example: Gnuplot
-
-
format: 1
-gnuplot:
-  defaults:                                             (1)
-    group: Tools                                        (2)
-    overlay: base                                       (3)
-    relstage: stable                                    (4)
-    systems: [rhel8, rhel7, rhel6]                      (5)
-    docfiles: [Copyright, NEWS, README]                 (6)
-    urls:                                               (7)
-      - url: https://sourceforge.net/projects/gnuplot/files/$P/$V/$P-${V_PKG}.tar.gz
-  shasums:                                              (8)
-    gnuplot-5.4.10.tar.gz: 975d8c1cc2c41c7cedc4e323aff035d977feb9a97f0296dd2a8a66d197a5b27c
-    gnuplot-5.4.9.tar.gz: a328a021f53dc05459be6066020e9a71e8eab6255d3381e22696120d465c6a97
-    gnuplot-5.4.8.tar.gz: 931279c7caad1aff7d46cb4766f1ff41c26d9be9daf0bcf0c79deeee3d91f5cf
-    gnuplot-5.4.5.tar.gz: 66f679115dd30559e110498fc94d926949d4d370b4999a042e724b8e910ee478
-    gnuplot-5.4.4.tar.gz: 372300b7867f5b3538b25fc5d0ac7734af6e3fe0d202b6db926e4369913f0902
-    gnuplot-5.4.3.tar.gz: 51f89bbab90f96d3543f95235368d188eb1e26eda296912256abcd3535bd4d84
-    gnuplot-5.4.2.tar.gz: e57c75e1318133951d32a83bcdc4aff17fed28722c4e71f2305cfc2ae1cae7ba
-    gnuplot-5.4.1.tar.gz: 6b690485567eaeb938c26936e5e0681cf70c856d273cc2c45fabf64d8bc6590e
-    gnuplot-5.4.0.tar.gz: eb4082f03a399fd1e9e2b380cf7a4f785e77023d8dcc7e17570c1b5570a49c47
-    gnuplot-5.2.8.tar.gz: 60a6764ccf404a1668c140f11cc1f699290ab70daa1151bb58fed6139a28ac37
-    gnuplot-5.2.7.tar.gz: 97fe503ff3b2e356fe2ae32203fc7fd2cf9cef1f46b60fe46dc501a228b9f4ed
-    gnuplot-5.2.6.tar.gz: 35dd8f013139e31b3028fac280ee12d4b1346d9bb5c501586d1b5a04ae7a94ee
-    gnuplot-5.2.4.tar.gz: 1515f000bd373aaa53b16183f274189d4f5e0ae47d22f434857933d16a4770cb
-    gnuplot-5.0.0.tar.gz: 417d4bc5bc914a60409bb75cf18dd14f48b07f53c6ad3c4a4d3cd9a8d7370faf
-    gnuplot-4.6.3.tar.gz: df5ffafa25fb32b3ecc0206a520f6bca8680e6dcc961efd30df34c0a1b7ea7f5
-  versions:
-    5.4.{0,1,2,3,4,5,8,9};5.2.{0,4,6,7,8};5.0.0;4.6.3:  (9)
-    5.4.10:                                             (10)
-      config:
-        relstage: unstable
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1Configuration is for gnuplot
2will be installed in the group Tools
3will be installed in the base overlay (/opt/psi)
4the default release stage is stable
5the module is available on these systems
6install these files to $PREFIX/share/doc/gnuplot
7download via this link
8SHA256 hash sums for all available versions
9no specific configuration required for these versions
10release stage of version 5.4.10 is still unstable, override -default release stage. ----
-
-
-
Example: HDF5
-
-
---
-# yamllint disable rule:line-length             (1)
-format: 1
-hdf5:                                           (2)
-  defaults:
-    group: MPI                                  (3)
-    overlay: base                               (4)
-    relstage: stable                            (5)
-    systems: [rhel7, rhel8, rhel9]              (6)
-    urls:                                       (7)
-      - url: https://support.hdfgroup.org/ftp/HDF5/releases/$P-${V_MAJOR}.${V_MINOR}/$P-${V_PKG}/src/$P-${V_PKG}.tar.bz2
-  shasums:                                      (8)
-    hdf5-1.8.10-patch1.tar.bz2: 292afb3615ad9e68f4d5d18ebb11e4a73f2aece39f2da3875a457ff1e109fc41
-    hdf5-1.8.12.tar.bz2: 10a369a4fc207bb09245f57c758e587420e06dfc0e445e337a58b0848b75a949
-    ...
-    hdf5-1.13.1.tar.bz2: e16973ec893e2d5aa9c8dc73e196db9b99a605578e7317b421c713936f8bf57d
-
-  versions:
-    1.8.12:
-      config:
-        relstage: deprecated                    (9)
-      variants:
-        -
-          group_deps:
-            compiler: {gcc: [4.7.4, 4.8.3, 4.8.4, 4.9.2]}
-            mpi: {openmpi: [1.6.5, 1.8.2, 1.8.4]}
-        -
-          group_deps:
-            compiler: {gcc: [4.8.2]}
-            mpi: {openmpi: [1.6.5]}
-        ...
-        -
-          group_deps:
-            compiler: {gcc: [5.1.0], intel: [15.2, 15.3]}
-            mpi: {openmpi: [1.8.4]}
-    ...
-    1.10.8_slurm:
-      variants:
-        -
-          group_deps:                           (10)
-            compiler: {gcc: [10.4.0]}
-            mpi: {openmpi: [4.1.4_slurm]}
-        -
-          relstage: unstable                    (11)
-          group_deps:
-            compiler: {gcc: [9.5.0, 10.4.0, 11.4.0, 12.3.0, 13.1.0]}
-            mpi: {openmpi: [4.1.5_slurm]}
-    ...
-    1.12.0:
-      variants:
-        -
-          group_deps:                           (12)
-            compiler: {gcc: [7.5.0, 8.4.0, 9.3.0, 10.2.0]}
-            mpi: {openmpi: [4.0.5]}
-        -
-          relstage: unstable                    (13)
-          group_deps:
-            compiler: {pgi: [21.5]}
-            mpi: {pgi-mpi: [21.5]}
-
-    1.13.1:
-      variants:
-        -
-          suffix: _slurm                        (14)
-          variant: [_slurm]
-          relstage: unstable
-          group_deps:
-            compiler: {gcc: [11.2.0]}
-            mpi: {openmpi: [4.1.3_slurm]}
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1disable rule to check line length in yamllint. Default is 80.
2this configuration is for HDF5
3TBW
4TBW
5TBW
6TBW
7TBW
8TBW
9TBW
10TBW
11TBW
12TBW
13TBW
14TBW
-
-
-
-
-
-
-

modulefiles

-
-
-

modulefiles

-
-

NAME

-
-

modulefile - files containing Tcl code for the Modules package

-
-
-
-

DESCRIPTION

-
-

modulefiles are written in the Tool Command Language, Tcl(n) and are -interpreted by the modulecmd program via the module(1) user -interface. modulefiles can be loaded, unloaded, or switched on-the-fly -while the user is working; and can be used to implement site policies -regarding the access and use of applications.

-
-
-

A modulefile begins with the shebang, ‘#%Pmodule’ or -‘#%Module’. The shebang ‘#%Pmodule’ should be used in modulefiles -using the Pmodules extension. A version number may be placed after -this string. The version number is useful as the modulefile format may -change. If a version number doesn’t exist, then modulecmd will assume -the modulefile is compatible with the latest version. The current -modulefile version is 1.0. Files without the magic cookie will not be -interpreted by modulecmd.

-
-
-

Each modulefile contains the changes to a user’s environment needed to -access an application. Tcl is a simple programming language which -permits modulefiles to be arbitrarily complex, depending upon the -application’s and the modulefile writer’s needs.

-
-
-

A typical modulefiles is a simple bit of code that set or add entries -to the PATH, MANPATH, or other environment variables. Tcl has -conditional statements that are evaluated when the modulefile is -loaded. This is very effective for managing path or environment -changes due to different OS releases or architectures. The user -environment information is encapsulated into a single modulefile kept -in a central location. The same modulefile is used by every user on -any machine. So, from the user’s perspective, starting an application -is exactly the same irrespective of the machine or platform they are -on.

-
-
-

modulefiles also hide the notion of different types of shells. From -the user’s perspective, changing the environment for one shell looks -exactly the same as changing the environment for another shell. This -is useful for new or novice users and eliminates the need for -statements such as "if you’re using the C Shell do this …​, otherwise -if you’re using the Bourne shell do this …​". Announcing and -accessing new software is uniform and independent of the user’s -shell. From the modulefile writer’s perspective, this means one set of -information will take care of every type of shell.

-
-
-
Module specific commands
-
-

The Pmodules Package uses commands which are extensions to the "standard" Tool Command Language Tcl(n) package.

-
-
- - - - - -
- - -
-

The following commands are Pmodules extensions:

-
-
-
    -
  • -

    module-addgroup

    -
    • -
  • -

    module-url

    -
    • -
  • -

    module-license

    -
    • -
  • -

    module-maintainer

    -
    • -
-
-
-
-
-

Unless otherwise specified, the Module commands return the empty string. Some commands behave differently when a modulefile is loaded or unloaded. The command descriptions assume the modulefile is being loaded.

-
-
-
-
break
-
-

This is not a Modules-specific command, it’s actually part of Tcl, which has been overloaded similar to the continue and exit commands to have the effect of causing the module not to be listed as loaded and not affect other modules being loaded concurrently. All non-environment commands within the module will be performed up to this point and processing will continue on to the next module on the command line. The break command will only have this effect if not used within a Tcl loop though.

-
-

An example: Suppose that a full selection of modulefiles are needed for various different architectures, but some of the modulefiles are not needed and the user should be alerted. Having the unnecessary modulefile be a link to the following notavail modulefile will perform the task as required.

-
-
-
-
#%Module1.0
-## notavail modulefile
-##
-proc ModulesHelp { } {
-            puts stderr "This module does nothing but alert the user"
-            puts stderr "that the [module-info name] module is not available"
-}
-
-module-whatis "Notifies user that module is not available."
-set curMod [module-info name]
-if { [ module-info mode load ] } {
-            puts stderr "Note: '$curMod' is not available for [uname sysname]."
-}
-break
-
-
-
-
chdir directory
-
-

Set the current working directory to directory.

-
-
continue
-
-

This is not a modules specific command but another overloaded Tcl command and is similar to the break or exit commands except the module will be listed as loaded as well as performing any environment or Tcl commands up to this point and then continuing on to the next module on the command line. The continue command will only have this effect if not used within a Tcl loop though.

-
-
exit [N]
-
-

This is not a modules specific command but another overloaded Tcl command and is similar to the break or continue commands. However, this command will cause the immediate cessation of this module and any additional ones on the command line. This module and the subsequent modules will not be listed as loaded. No environment commands will be performed in the current module.

-
-
setenv variable value
-
-

Set environment variable to value. The setenv command will also change the process' environment. A reference using Tcl’s env associative array will reference changes made with the setenv command. Changes made using Tcl’s env associative array will NOT change the user’s environment variable like the setenv command. An environment change made this way will only affect the module parsing process. The setenv command is also useful for changing the environment prior to the exec or system command. When a modulefile is unloaded, setenv becomes unsetenv. If the environment variable had been defined it will be overwritten while loading the modulefile. A subsequent unload will unset the environment variable - the previous value cannot be restored! (Unless you handle it explicitly …​ see below.)

-
-
unsetenv variable [value]
-
-

Unsets environment variable. However, if there is an optional value, then when unloading a module, it will set variable to value. The unsetenv command changes the process' environment like setenv.

-
-
append-path|prepend-path [-d C|--delim C|--delim=C] variable value
-
-

Append or prepend value to environment variable. The variable is a colon, or delimiter, separated list such as PATH=directory:directory:directory. The default delimiter is a colon ':', but an arbitrary one can be given by the --delim option. For example a space can be used instead (which will need to be handled in the Tcl specially by enclosing it in " " or { }). A space, however, can not be specified by the --delim=C form.

-
-

If the variable is not set, it is created. When a modulefile is unloaded, append-path and prepend-path become remove-path.

-
-
-
remove-path [-d C|--delim C|--delim=C] variable value
-
-

Remove value from the colon, or delimiter, separated list in variable. See prepend-path or append-path for further explanation of using an arbitrary delimiter. Every string between colons, or delimiters, in variable is compared to value. If the two match, value is removed from variable.

-
-
prereq|conflict modulefile…​
-
-

prereq and conflict control whether or not the modulefile will be loaded. The prereq command lists modulefiles which must have been previously loaded before the current modulefile will be loaded. Similarly, the conflict command lists modulefiles which conflict with the current modulefile. If a list contains more than one modulefile, then each member of the list acts as a Boolean OR operation. Multiple prereq and conflict commands may be used to create a Boolean AND operation. If one of the requirements have not been satisfied, an error is reported and the current modulefile makes no changes to the user’s environment.

-
-
-
-
-

If an argument for prereq is a directory and any modulefile from the directory has been loaded, then the prerequisite is met. For example, specifying X11 as a prereq means that any version of X11, X11/R4 or X11/R5, must be loaded before proceeding.

-
-
-

If an argument for conflict is a directory and any other modulefile from that directory has been loaded, then a conflict will occur. For example, specifying X11 as a conflict will stop X11/R4 and X11/R5 from being loaded at the same time.

-
-
-
-
is-loaded modulefile…​
-
-

The is-loaded command returns a true value if any of the listed modulefiles has been loaded. If a list contains more than one modulefile, then each member acts as a boolean OR operation. If an argument for is-loaded is a directory and any modulefile from the directory has been loaded is-loaded would return a true value.

-
-
module [sub-command] [sub-command-args]
-
-

Contains the same sub-commands as described in the module(1) man page in the Module Sub-Commands section. This command permits a modulefile to load or unload other modulefiles. No checks are made to ensure that the modulefile does not try to load itself. Often it is useful to have a single modulefile that performs a number of module load commands. For example, if every user on the system requires a basic set of applications loaded, then a core modulefile would contain the necessary -module load commands.

-
-
module-info mode [modetype]
-
-

Returns the current modulecmd’s mode as a string if no modetype is given.

-
-

Returns 1 if modulecmd’s mode is modetype. modetype can be: load, unload, remove, switch, display, help, test or whatis.

-
-
-
module-info name
-
-

Return the name of the modulefile. This is not the full pathname for modulefile. See the Modules Variables section for information on the full pathname.

-
-
module-info specified
-
-

Return the name of the modulefile specified on the command line.

-
-
module-info shell [shellname]
-
-

Return the current shell under which modulecmd.tcl was invoked if no shellname is given. The current shell is the first parameter of modulecmd.tcl, which is normally hidden by the module alias.

-
-

If a shellname is given, returns 1 if modulecmd.tcl’s current shell is shellname, returns 0 elsewhere. shellname can be: sh, bash, ksh, zsh, csh, tcsh, fish, tcl, perl, python, ruby, lisp, cmake, r.

-
-
-
module-info shelltype [shelltypename]
-
-

Return the family of the shell under which modulefile was invoked if no shelltypename is given. As of module-info shell this depends on the first parameter of modulecmd.tcl. The output reflects a shell type determining the shell syntax of the commands produced by modulecmd.tcl.

-
-

If a shelltypename is given, returns 1 if modulecmd.tcl’s current shell type is shelltypename, returns 0 elsewhere. shelltypename can be: sh, csh, fish, tcl, perl, python, ruby, lisp, cmake, r.

-
-
-
module-info alias name
-
-

Returns the full modulefile name to which the modulefile alias name is assigned

-
-
module-info version modulefile
-
-

Returns the physical module name and version of the passed symbolic version modulefile. The parameter modulefile might either be a full qualified modulefile with name and version, another symbolic modulefile name or a modulefile alias.

-
-
module-info symbols modulefile
-
-

Returns a list of all symbolic versions assigned to the passed modulefile. The parameter modulefile might either be a full qualified modulefile with name and version, another symbolic modulefile name or a modulefile alias.

-
-
module-version modulefile version-name…​
-
-

Assigns the symbolic version-name to the modulefile. This command should be placed in one of the modulecmd.tcl rc files in order to provide shorthand invocations of frequently used modulefile names.

-
-

The special version-name default specifies the default version to be used for module commands, if no specific version is given. This replaces the definitions made in the .version file in former modulecmd releases.

-
-
-

The parameter modulefile may be either -* a fully or partially qualified modulefile with name / version. If name is '.' then the current directory name is assumed to be the module name. (Use this for deep modulefile directories.) -* a symbolic modulefile name -* another modulefile alias

-
-
-
module-alias name modulefile
-
-

Assigns the modulefile to the alias name. This command should be placed in one of the modulecmd rc files in order to provide shorthand invocations of frequently used modulefile names.

-
-

The parameter modulefile may be either

-
-
-
    -
  • -

    a fully qualified modulefile with name and version

    -
    • -
  • -

    a symbolic modulefile name

    -
    • -
  • -

    another modulefile alias

    -
    • -
-
-
-
module-whatis string
-
-

Defines a string which is displayed in case of the invocation of the module whatis command. There may be more than one module-whatis line in a modulefile. This command takes no actions in case of load, display, etc. invocations of modulecmd.

-
-

The string parameter has to be enclosed in double-quotes if there’s more than one word specified. Words are defined to be separated by white-space characters (space, tab, cr).

-
-
-
module-url url
-
-

Sets an URL which is displayed in case of the invocation of the module help command. The URL should point to the home-page of the software loaded by the module if any.

-
-
module-license string
-
-

Defines a string which is displayed in case of the invocation of the module help command. The string should either be the name of a well known license (like GPL V2) or a filename with the license text installed in the module.

-
-
module-maintainer email
-
-

Defines a string which is displayed in case of the invocation of the module help command. The -string should be the email address of the module maintainer.

-
-
module-addgroup group
-
-

Add the hierarchical group group to MODULEPATH.

-
-
set-alias alias-name alias-string
-
-

Sets an alias or function with the name alias-name in the user’s environment to the string alias-string. For some shells, aliases are not possible and the command has no effect. When a modulefile is unloaded, set-alias becomes unset-alias.

-
-
unset-alias alias-name
-
-

Unsets an alias with the name alias-name in the user’s environment.

-
-
system string
-
-

Pass string to the Tcl built-in command exec(n). For the exec(n) call modulecmd redirects stdout to stderr since stdout would be parsed by the evaluating shell. The exit status of the executed command is returned.

-
-
uname field
-
-

Provide lookup of system information. Most field information are retrieved from the tcl_platform array (see tclvars(n) man page). Uname will return the string "unknown" if information is unavailable for the field.

-
-

uname will invoke uname(1) command in order to get the operating system version and domainname(1) to figure out the name of the domain.

-
-
-

field values are: -* sysname: the operating system name -* nodename: the hostname -* domain: the name of the domain -* release: the operating system release -* version: the operating system version -* machine: a standard name that identifies the system’s hardware

-
-
-
x-resource [resource-string|filename]
-
-

Merge resources into the X11 resource database. The resources are used to control look and behavior of X11 applications. The command will attempt to read resources from filename. If the argument isn’t a valid file name, then string will be interpreted as a resource. Either filename or resource-string is then passed down to be xrdb(1) command.

-
-

modulefiles that use this command, should in most cases contain one or more x-resource lines, each defining one X11 resource. The DISPLAY environment variable should be properly set and the X11 server should be accessible. If x-resource can’t manipulate the X11 resource database, the modulefile will exit with an error message.

-
-
-

Examples:

-
-
-
-
-
-
-
x-resource /u2/staff/leif/.xres/Ileaf
-
-
-
-

The content of the Ileaf file is merged into the X11 resource database.

-
-
-
-
x-resource [glob ~/.xres/ileaf]
-
-
-
-

The Tcl glob function is used to have the modulefile read different resource files for different users.

-
-
-
-
x-resource {Ileaf.popup.saveUnder: True}
-
-
-
-

Merge the Ileaf resource into the X11 resource database.

-
-
-
-
Modules Variables
-
-

The ModulesCurrentModulefile variable contains the full pathname of the modulefile being interpreted.

-
-
-
-
Locating Modulefiles
-
-

Every directory in MODULEPATH is searched to find the modulefile. A directory in MODULEPATH can have an arbitrary number of sub-directories. If the user names a modulefile to be loaded which is actually a directory, the directory is opened and a search begins for an actual modulefile. First, modulecmd looks for a file with the name .modulerc in the directory. If this file exists, its contents will be evaluated as if it was a modulefile to be loaded. You may place module-version and module-alias commands inside this file.

-
-
-

Additionally, before seeking for .modulerc files in the module directory, the global modulerc file is sourced, too. If a named version default now exists for the modulefile to be loaded, the assigned modulefile now will be sourced. Otherwise the file .version is looked up in the directory.

-
-
-

If the .version file exists, it is opened and interpreted as Tcl code and takes precedence over a .modulerc file in the same directory. If the Tcl variable ModulesVersion is set by the .version file, modulecmd will use the name as if it specifies a modulefile in the directory. This will become the default modulefile in this case.

-
-
-

If ModulesVersion is a directory, the search begins anew down that directory. If the name does not match any files located in the current directory, the search continues through the remaining directories in MODULEPATH.

-
-
-

Every .version and .modulerc file found is Tcl interpreted. The difference is that .version only applies to the current directory, and the .modulerc applies to the current directory and all subdirectories. Changes made in these files will affect the subsequently interpreted modulefile.

-
-
-

If no default version may be figured out, then the highest numerically sorted modulefile or module alias under the directory will be used. The dictionary comparison method of the lsort(n) Tcl command is used to achieve this sort. If highest numerically sorted element is an alias, search continues on its modulefile target.

-
-
-

For example, it is possible for a user to have a directory named X11 which simply contains a .version file specifying which version of X11 is to be loaded. Such a file would look like:

-
-
-
-
#%Module1.0
-##
-##  The desired version of X11
-##
-set ModulesVersion "R4"
-
-
-
-

The equivalent .modulerc would look like:

-
-
-
-
#%Module1.0
-##
-##  The desired version of X11
-##
-module-version "./R4" default
-
-
-
-

If user names a modulefile that cannot be found in the first modulepath directory, modulefile will be searched in next modulepath directory and so on until a matching modulefile is found. If search goes through a module alias or a symbolic version, this alias or symbol is resolved by first looking at the modulefiles in the modulepath where this alias or symbol is defined. If not found, resolution looks at the other modulepaths in their definition order.

-
-
-

When locating modulefiles, if a .modulerc, a .version, a directory or a modulefile cannot be read during the search it is simply ignored with no error message produced. Visibility of modulefiles can thus be adapted to the rights the user has been granted. Exception is made when trying to directly access a directory or a modulefile. In this case, the access issue is returned as an error message.

-
-
-

A modulefile whose name or element in its name starts with a '.' dot is considered hidden. Hidden modulefile is not displayed or taken into account except if it is explicitly named. By inheritance, a symbolic version-name assigned to a hidden modulefile is displayed or taken into account only if explicitly named. Module alias targeting a hidden modulefile appears like any other module alias.

-
-
-
-
Modulefile Specific Help
-
-

Users can request help about a specific modulefile through the module(1) command. The modulefile can print helpful information or start help oriented programs by defining a ModulesHelp subroutine. The subroutine will be called when the module help modulefile command is used.

-
-
-
-
Modulefile Specific Test
-
-

Users can request test of a specific modulefile through the module(1) command. The modulefile can perform some sanity checks on its definition or on its underlying programs by defining a ModulesTest subroutine. The subroutine will be called when the module test modulefile command is used. The subroutine should return 1 in case of success. If no or any other value is returned, test is considered failed.

-
-
-
-
Modulefile Display
-
-

The module display modulefile command will detail all changes that will be made to the environment. After displaying all of the environment changes modulecmd.tcl will call the ModulesDisplay subroutine. The ModulesDisplay subroutine is a good place to put additional descriptive information about the modulefile.

-
-
-
-
-

ENVIRONMENT

-
-
-
MODULEPATH
-
-

Path of directories containing modulefiles.

-
-
-
-
-
-

SEE ALSO

-
-

module(1), Tcl(n), TclX(n), xrdb(1), exec(n), uname(1), domainname(1), tclvars(n), lsort(n)

-
-
-
-

NOTES

-
-

Tcl was developed by John Ousterhout at the University of California at Berkeley.

-
-
-

TclX was developed by Karl Lehenbauer and Mark Diekhans.

-
-
-

Modules is covered by the GNU General Public License, version 2 and the GNU Lesser General Public License, version 2.1. Copyright © 1996-1999 John L. Furlani & Peter W. Osel, © 1998-2017 R.K.Owen, © 2002-2004 Mark Lakata, © 2004-2017 Kent Mein, © 2016-2017 Xavier Delaruelle. All rights reserved. Trademarks used are the property of their respective owners.

-
-
-
-
-
-
-

Runtime configuration files

-
-
-

Table of Contents
-Pmodules 1.0 configuration file .release-version
-Pmodules 1.1 and newer configuration file .config-version

-
-
- - - - - -
- - -
-

The runtime configuration files are evaluated only for modules inside -the Pmodules hierarchy. If you use modbuild these files are created -automatically. Otherwise you have to create them by hand.

-
-
-
-
-

Pmodules 1.0: .release-version

-
-

In .release-version the release stage of a module is -defined. The file must be in the same directory as the modulefile. The -content is a single line defining the release stage. Allowed text is

-
-
-
    -
  • -

    unstable

    -
    • -
  • -

    stable

    -
    • -
  • -

    deprecated

    -
    • -
-
-
-

If the file doesn’t exist and the module is inside the Pmodule -hierarchy unstable. All modules outside the Pmodules hierarchy are -considered as stable.

-
-
- - - - - -
- - -
-

This configuration file is deprecated in version 1.1 and newer. Please -see next section.

-
-
-
-
-
-

Pmodules 1.1 and newer: .config-version

-
-

In .config-version the following properties of a module can be -configured:

-
-
-
    -
  • -

    the release stage

    -
    • -
  • -

    the systems on which a module is available

    -
    • -
  • -

    the systems on which a module is unavailable

    -
    • -
-
-
-

The format of the file is YAML.

-
-
-
-
relstage
-
-

The release stage of the module. Allowed values are -unstable, stable and deprecated.

-
-
systems
-
-

Sequence of systems on which the module is available. Systems -can be hostnames with shell style glob pattern or OS names like -(rhel7, rhel8).

-
-
blocklist
-
-

Sequence of systems on which the module is no -available. Systems can be hostnames with shell style glob patterns or -OS names.

-
-
-
-
-

Example:

-
-
-
-
relstage: unstable
-systems: [merlin-*, ra-*]
-blocklist: []
-
-
-
-
-
-
- - - \ No newline at end of file diff --git a/doc/html/index.html b/doc/html/index.html index e172fb6..434140d 100644 --- a/doc/html/index.html +++ b/doc/html/index.html @@ -4,7 +4,7 @@ - + Pmodules - an improved environment modules system @@ -61,33 +61,28 @@

Pmodules - an improved environment modules system

Table of Contents
@@ -98,289 +93,197 @@

Pmodules - an improved environment modules system

1. INTRODUCTION

-

Pmodules is the environment modules system at PSI. Since it uses AFS as storage backend it is an easy and convinient solution for software distribution.

+

Pmodules is the environment modules system at PSI.

-

It is available for all PSI supported Linux systems including

+

It is available on PSI’s HPC systems Ra, Merlin7 and Merlin6 (and maybe on other systems too).

-
-
    -
  • -

    login.psi.ch (llc.psi.ch)

    -
    • -
  • -

    Merlin6

    -
    • -
  • -

    Ra

    -
    • -
-
-
-

A list of available modules and changes is avail here.

-
-
- - - - - -
- -
-

Some parts of this documentation has been copied from the documentation -of Environment Modules and -Lmod.

-
-
+

In this document we explain how to build modules for the Pmodules system.

-

2. PMODULES IN A NUTSHELL

+

2. TUTORIALS

-
-

Before reading this section you should be familiar with an environment module system - either Environment Modules or Lmod.

-
-
-

Pmodules organizes modules in groups like Tools, Programming, Libraries, System etc. for a clear arrangement. Groups of modules can easily be added to the available modules. Read section Module groups for more details about module groups.

-
-
-

One issue with Environment Modules is the flat naming scheme. Pmodules and Lmod solves the issue by organizing the modules hierarchically. Providing modules for a toolkit like parallel HDF5 ends up in dozen of modules. One user wants to use GCC 4.8.4 and OpenMPI 1.6.5 another Intel C 15 and MPICH 3.1.4, a third user requires GCC 4.9.2 with MPICH 3.1.4. After a couple of month, some users want new versions. In a flat naming scheme you see all installed versions, even if you just want to see what is available for particular compiler. The solution to this problem is a hierarchical organization of the modules. In section Module hierarchies we describe how to load and search for modules in a module hierarchy.

-
-
-

Neither Lmod nor Environment Modules provides something like a life cycle management. A module is either available or not. There is no way to inform the users, whether a module is still unstable or already deprecated. Pmodules solves this problem by introducing releases like unstable, stable and deprecated. In section Module lifecycle we explain what this means to the user.

-
-
-

2.1. Motivation

-
-

Environment module systems provide a solution for the dynamic -modification of a user’s environment by loading special files named -'modulefiles'.

-
-
-

Each modulefile contains the information needed to configure the shell -for an application or library. The environment can be modified on a -per-module basis using the module command which interprets -modulefiles. Typically modulefiles instruct the module command to -alter or set shell environment variables such as PATH, MANPATH -etc. modulefiles may be shared by many users on a system and users may -have their own collection to supplement or replace the shared -modulefiles.

-
-
-

Environment module systems are widely used on HPC systems to provide -multiple compilers and multiple versions of the same library or API -implementations to the users. The -Environment Modules system is the -most widely used implementation. Another - more recent - -implementation is -Lmod. Lmod -addresses some weaknesses of the Environment Modules, but solves only -some of them.

-
-
-

One issue with the Environment Modules is the flat naming scheme. The -Lmod system and Pmodules solves the problem by organizing the modules -hierarchically. What is the problem with a flat naming scheme? Provide -different versions of the same library, like openmpi 1.6.5/1.8.4, -compiled with different (versions) of compilers, like gcc -4.7.4/4.8.4/4.9.2 and Intel 14.0.2/15.2, the number of modules is -growing quite fast. Providing dozens of libraries will end up in -hundreds of modules - not very clear to the users.

-
-
-

Neither Environment Modules nor Lmod have build-in support for phasing -out modules or marking modules as unstable. Pmodules solves this -problem by introducing 'releases' like stable, unstable and -deprecated. A user will be warned while loading a non-stable module.

-
-
-

With Environment Modules and Lmod everything must be coded in the -modulefile - even things which are obvious. If a bin directory -exists, why not adding this directory to the PATH variable -automatically? The same can be done for MANPATH, LD_LIBRARY_PATH -and other environment variables.

-
-
-

Usually modules are installed on a network file-systems. In some cases -it is convenient or even required to install modules locally. Pmodules -provides a tool to install all or a sub-set of the modules from any -location to another location.

-
-
-

Pmodules has its own (simple) build environment. For a new module you -have to write a build script and a modulefile. Updating an existing -modules is very simple. In most cases it’s downloading the new version -and calling the build script. Anyway, nobody forces you to use this -build environment, but in most cases it is very handy.

-
-
-
-

2.2. Module groups

-
-

Pmodules organizes modules in groups. By default only the groups -Tools and Programming are visible. To get a list of 'used' and -'unused' groups, run the command module use:

-
+

2.1. Step-by-step guide to build a 'Hello, world!' module

+
+
    +
  1. +

    Download a stub for a new build-block

    -
    $ module use
-Used groups:
-	Tools
-	Programming
-
-Unused groups:
-	Libraries
-	System
-...
    +
    wget --output-document=stub.tgz https://github.com/Pmodules/buildblock_stub/archive/refs/tags/1.0.0.tar.gz
    -
    -

    To make the modules in a given group available, run the command

    -
    +
    2. +
  2. +

    Unpack the stub into the directory hello_world

    -
    $ module use GROUP
    +
    mkdir hello_world && cd $_
+tar --strip-components 1 -xvf ../stub.tgz
+chmod 0755 build
    -
    -
    -
    Example
    -
    -
    +
    3. +
  3. +

    Edit files/config.yaml

    -
    $ module use System
-$ module avail
---------------------------------------------- System ---------------------------------------------
-
-fsstress/1.0.0  nmap/6.46
-
---------------------------------------------- Tools ---------------------------------------------
-
-Eclipse/4.4.2   Firefox/31.0    Opera/23.0      Thunderbird/31.0                emacs/24.4
-global/6.3.1    gnuplot/4.6.3
+
    ---
+format: 1
+hello_world:                           (1)
+  defaults:                            (2)
+    group: Tools                       (3)
+    relstage: stable                   (4)
+    compile_in_sourcetree: true        (5)
+    urls:                              (6)
+      - url: https://github.com/Pmodules/$P/archive/refs/tags/$V.tar.gz
+        name: $P-$V.tar.gz
 
------------------------------------------- Programming ------------------------------------------
+  shasums:                             (7)
+    hello_world-1.0.0.tar.gz: bc1cfd90ac55e9f3babab0a426ed4b3c7edf15266363ab1b595d234797fbce7b
 
-Python/3.4.0    Python/3.4.3    autoconf/2.69   automake/1.14   cmake/2.8.12.2  gcc/4.7.4
-gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       libtool/2.4.2   m4/1.4.17
    
+  versions:
+    1.0.0:
+      config:                          (8)
+        relstage: unstable             (9)
    -
    -

    To make groups unavailable, run the command

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    1The name of the module.
    2Default configuration for all version. This can be overwritten in the 'versions' section.
    3The group the module will be installed in.
    4If not otherwise specified in the version specific configuration, the release stage is set to stable.
    5Usually the software is compiled in a dedicated build directory. Here we have to compile in the source tree.
    6Download URL and filename. $P will be substituted by the module name and $V by the version.
    7SHA256 hash sums for each source file. Hash sums are optional but recommended. Therefor you can start without the hash sum and add it later. If the hash sum is missing, you get a warning. If the hash sum is wrong, the build process aborts.
    8Configuration for version 1.0.0.
    9Overwrite the default release stage.
    -
    -
    -
    $ module unuse GROUP
    +
    4. +
+
+ + + + + +
+ + +
+

For linting YAML files use the tool yamlint or an on-line linter like yaml-validator.

-
-
-
Example
-
-

Make modules in the groups System and Programming unavailable:

-
-
+
+
+
    +
  1. +

    Edit the build script

    -
    $ module unuse System Programming
-$ module avail
---------------------------------------------- Tools ---------------------------------------------
+
    #!/usr/bin/env modbuild
 
-Eclipse/4.4.2   Firefox/31.0    Opera/23.0      Thunderbird/31.0                dialog/1.2.1(u)
-emacs/24.4      emacs/24.5(u)   git/2.3.3(u)    global/6.3.1    gnuplot/4.6.3   gnuplot/5.0.0(u)
    
-
    +pbuild::configure() { (1) + : +} + +pbuild::install() { (2) + mkdir -p "${PREFIX}/bin" + install --mode=0755 "${SRC_DIR}/hello" "${PREFIX}/bin" +}
    -
-
-

2.3. Module hierarchies

-
-

Unstructured, flat naming schemes are confusing. Why? Lets assume we have to -provide modules for the compilers gcc-4.8.4, gcc-4.9.2, intel-15.2, -the MPI implementations openmpi-1.6.5, openmpi-1.8.4, mpich-3.1.4 -and parallel versions of hdf5-1.8.10 and hdf5-1.8.14 compiled with -all compiler/MPI combinations. So, we have to provide 30(!) modules:

+
+ + + + + + + + + +
1Don’t use the default pbuild::configure()` function! +There is nothing to configure. :)
2The Makefile doesn’t have an 'install' target. Therefore we have to code it ourself.
-
-
    -
  • -

    3 compiler modules

  • -

    9 MPI modules

    -
    • -
  • -

    18 hdf5 modules

    -
    • -
-
-
-

Even with a reasonable naming convention this is quite confusing. In a flat naming scheme a listing of available modules might look like:

-
+

Build the module

-
$ module avail
-gcc-4.8.4
-gcc-4.9.2
-hdf5-1.8.10-mpi-3.1.4-gcc-4.8.4
-hdf5-1.8.10-mpi-3.1.4-gcc-4.9.2
-hdf5-1.8.10-mpi-3.1.4-intel-15.2
-hdf5-1.8.10-openmpi-1.6.5-gcc-4.8.4
-hdf5-1.8.10-openmpi-1.6.5-gcc-4.9.2
-hdf5-1.8.10-openmpi-1.6.5-intel-15.2
-hdf5-1.8.10-openmpi-1.8.4-gcc-4.8.4
-hdf5-1.8.10-openmpi-1.8.4-gcc-4.9.2
-hdf5-1.8.10-openmpi-1.8.4-intel-15.2
-hdf5-1.8.14-mpi-3.1.4-gcc-4.8.4
-hdf5-1.8.14-mpi-3.1.4-gcc-4.9.2
-hdf5-1.8.14-mpi-3.1.4-intel-15.2
-hdf5-1.8.14-openmpi-1.6.5-gcc-4.8.4
-hdf5-1.8.14-openmpi-1.6.5-intel-15.2
-hdf5-1.8.14-openmpi-1.8.4-gcc-4.8.4
-hdf5-1.8.14-openmpi-1.8.4-gcc-4.9.2
-hdf5-1.8.14-openmpi-1.8.4-intel-15.2
-intel-15.3
-mpi-3.1.4-gcc-4.8.4
-mpi-3.1.4-gcc-4.9.2
-mpi-3.1.4-intel-15.2
-openmpi-1.6.5-gcc-4.8.4
-openmpi-1.6.5-gcc-4.9.2
-openmpi-1.6.5-intel-15.2
-openmpi-1.8.4-gcc-4.8.4
-openmpi-1.8.4-gcc-4.9.2
-openmpi-1.8.4-intel-15.2
-
+
./build 1.0.0
-
-

Got it? One combination is missing. But which one?

-
-
-

Actually we have to provide more compilers than the three mentioned above: while writing this documentation the number is already seven(!): five GCC versions and two Intel C versions.

+ +
  • +

    Release module as 'stable'

    -

    Another issue with a flat naming scheme is, that all modules are listed independent of already loaded modules. But listing a module providing hdf5 1.8.14 compiled with Intel 15.2 and mpich 3.1.4 makes not much sense if modules for gcc 4.9.2 and openmpi 1.8.4 are already loaded. A solution to these issues is a to structure the modules hierarchically.

    +

    Remove the line relstage: unstable in the config section of version 1.0.0:

    -
                      ... _________________________________________|________________________________________...
-                     /                                         |                                        \
-                    gcc                                       gcc                                      intel
-                   4.8.4                                     4.9.2                                     15.2
-        _____________|_____________               _____________|_____________               _____________|_____________
-       /             |             \             /             |             \             /             |             \
-    openmpi       openmpi        mpich        openmpi       openmpi        mpich        openmpi       openmpi        mpich
-     1.6.5         1.8.4         3.1.4         1.6.5         1.8.4         3.1.4         1.6.5         1.8.4         3.1.4
-     __|__         __|__         __|__         __|__         __|__         __|__         __|__         __|__         __|__
-    /     \       /     \       /     \       /     \       /     \       /     \       /     \       /     \       /     \
-  hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5   hdf5
- 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14 1.8.10 1.8.14
    +
    ---
+format: 1
+hello_world:
+  defaults:
+    group: Tools
+    relstage: stable
+    compile_in_sourcetree: true
+    urls:
+      - url: https://github.com/Pmodules/$P/archive/refs/tags/$V.tar.gz
+        name: $P-$V.tar.gz
+
+  shasums:
+    hello_world-1.0.0.tar.gz: bc1cfd90ac55e9f3babab0a426ed4b3c7edf15266363ab1b595d234797fbce7b
+
+  versions:
+    1.0.0:                   (1)
    +
    +
    +
    + + + + + +
    1Since the config section is empty after removing the line relstage: unstable the entire section can be removed.
    +
    • +
    @@ -389,122 +292,225 @@

    2.3. Module hierarchies

    -In a hierarchical structured module environment the command module -avail does '''not''' reveal all modules. Modules like openmpi and -hdf5 are not listed as long as the dependencies are not loaded. +
    +

    To change the release stage run the build-script again: ./build 1.0.0

    +
    -
    -
    -
    Example
    -
    -

    Before you can load a hdf5 module, you must first

    +
    +
    +

    2.2. Add new version, build with autotools

    +
    +

    In version 2.0.0 the author added autotools files. Let’s add this version to our build-block.

    +
    +
    +
      +
    1. +

      Edit files/config.yaml

      +
      +
      +
      ---
+format: 1
+hello_world:
+  defaults:
+    group: Tools
+    relstage: stable
+    urls:
+      - url: https://github.com/Pmodules/$P/archive/refs/tags/$V.tar.gz
+        name: $P-$V.tar.gz
+
+  shasums:
+    hello_world-1.0.0.tar.gz: bc1cfd90ac55e9f3babab0a426ed4b3c7edf15266363ab1b595d234797fbce7b
+    hello_world-2.0.0.tar.gz: cd4ef1a7581fd4306f9b045b4bb9d722e1a978be3f93c709e0e8436347e38cf4
+
+  versions:
+    1.0.0:
+      config:                          (1)
+        compile_in_sourcetree: true
+        build_functions:
+          prep: [pbuild::prep]
+          compile: [pbuild::compile]
+          install: [install-1]
+    2.0.0:                             (2)
+      config:
+        relstage: unstable
      +
      +
      +
      + + + + + + + + + +
      1Various changes are necessary in the config section:
      • -

        load a particular compiler module,

        +

        With autotools the software can be compiled outside the sources. This is recommended and the default for autotools and CMake.

      • -

        than a particular MPI module

        +

        The build function must now be defined:

        +
        +
          +
        • +

          In version 1.x the default configure step must be skipped.

        • -

          and then the desired hdf5 module.

          +

          The default installation function cannot be used for version 1.x.

        - - +
        • +
      +
      2Configuration for version 2.0.0.
      +
      2. +
    2. +

      Edit ./build

      -
      $ module list
-No Modulefiles Currently Loaded.
-$ module avail
- ------------------------------------------ Programming ------------------------------------------
+
      #!/usr/bin/env modbuild
+
+pbuild::pre_configure(){
+        ./autogen.sh
+}
 
-autoconf/2.69   automake/1.14   binutils/2.25(u)                cmake/2.8.12.2  cmake/3.1.3
-gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/5.1.0(u)    intel/14.0.3
-intel/15.2(u)   libtool/2.4.2   m4/1.4.17       psi-python27/2.1.0(u)
-psi-python34/2.1.0(u)           Python/3.4.3    Tcl/8.6.3(u)    Tcl/8.6.4(u)    Tk/8.6.4(u)
      
+# we need this function major version 1!
+install-1() {
+        mkdir -p "${PREFIX}/bin"
+        install --mode=0755 "${SRC_DIR}/hello" "${PREFIX}/bin"
+}
      -
      -

      After loading the module gcc/4.9.2 we see the available MPI implementations compiled with this compiler:

      +
      3. +
    +
    +
    +

    2.3. Deprecate old version, make current version stable

    +
    +
      +
    1. +

      Edit files/config.yaml

      -
      $ module load gcc/4.9.2
-$ module avail
------------------------------------------- Programming ------------------------------------------
-
-autoconf/2.69   automake/1.14   binutils/2.25(u)                cmake/2.8.12.2  cmake/3.1.3
-gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/5.1.0(u)    intel/14.0.3
-intel/15.2(u)   libtool/2.4.2   m4/1.4.17       psi-python27/2.1.0(u)
-psi-python34/2.1.0(u)           Python/3.4.3    Tcl/8.6.3(u)    Tcl/8.6.4(u)    Tk/8.6.4(u)
+
      ---
+format: 1
+hello_world:
+  defaults:
+    group: Tools
+    relstage: stable
+    urls:
+      - url: https://github.com/Pmodules/$P/archive/refs/tags/$V.tar.gz
+        name: $P-$V.tar.gz
 
---------------------------------------- Compiler/gcc/4.9.2 ---------------------------------------
+  shasums:
+    hello_world-1.0.0.tar.gz: bc1cfd90ac55e9f3babab0a426ed4b3c7edf15266363ab1b595d234797fbce7b
+    hello_world-2.0.0.tar.gz: cd4ef1a7581fd4306f9b045b4bb9d722e1a978be3f93c709e0e8436347e38cf4
 
-boost/1.55.0    boost/1.57.0    gsl/1.15        hdf5_serial/1.8.12              hdf5_serial/1.8.13
-hdf5_serial/1.8.14              mpich/3.1.4(u)  OpenBLAS/0.2.9  OpenBLAS_OMP/0.2.9
-openmpi/1.6.5   openmpi/1.8.2   openmpi/1.8.4   root/5.34.19    root/5.34.26    SuperLU/4.3
-UMFPACK/5.6.2   vtk/5.10.1
      
+  versions:
+    1.0.0:
+      config:                          (1)
+        compile_in_sourcetree: true
+        relstage: deprecated
+        build_functions:
+          prep: [pbuild::prep]
+          compile: [pbuild::compile]
+          install: [install-1]
+    2.0.0:                             (2)
      +
      +
      +
      2. +
    +
    +
    +
    +

    3. BUILDING PMODULES

    +
    +
    +

    3.1. Introduction

    -

    Next step is loading a MPI module:

    +

    In the simplest case adding a Pmodule can be done by adding a modulefile to a certain directory. Below is an example of a "do nothing" modulefile in the group Sandbox.

    +
    Example: /opt/psi/Sandbox/modulefiles/null/1.0.0
    -
    $ module load openmpi/1.8.4
-$ module avail
------------------------------------------- Programming ------------------------------------------
-
-autoconf/2.69   automake/1.14   binutils/2.25(u)                cmake/2.8.12.2  cmake/3.1.3
-gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/5.1.0(u)    intel/14.0.3
-intel/15.2(u)   libtool/2.4.2   m4/1.4.17       psi-python27/2.1.0(u)
-psi-python34/2.1.0(u)           Python/3.4.3    Tcl/8.6.3(u)    Tcl/8.6.4(u)    Tk/8.6.4(u)
-
---------------------------------------- Compiler/gcc/4.9.2 ---------------------------------------
-
-boost/1.55.0    boost/1.57.0    gsl/1.15        hdf5_serial/1.8.12              hdf5_serial/1.8.13
-hdf5_serial/1.8.14              mpich/3.1.4(u)  OpenBLAS/0.2.9  OpenBLAS_OMP/0.2.9
-openmpi/1.6.5   openmpi/1.8.2   openmpi/1.8.4   root/5.34.19    root/5.34.26    SuperLU/4.3
-UMFPACK/5.6.2   vtk/5.10.1
+
    #%Pmodule
 
----------------------------------- MPI/gcc/4.9.2/openmpi/1.8.4 ----------------------------------
+module-whatis           "does absolutely nothing"
+module-maintainer       "Achim Gsell <achim.gsell@psi.ch>"
+module-license          "MIT"
 
-BoxLib/2014-02-28               hdf5/1.8.12     hdf5/1.8.13     hdf5/1.8.14     ippl/1.1.4
-parmetis/3.2.0  SuperLU_DIST/3.3                trilinos/11.10.2                trilinos/11.12.1
-trilinos/11.14.1
    
+module-help     "
+This is a do nothing module.
+"
    -

    Now you can load the HDF5 module:

    +

    In addition to the modulefile a corresponding configuration file - defining for example the release stage - should be installed in the same directory as the modulefile. See next section for a detailed documentation of configuration files.

    +
    Example: configuration file /opt/psi/Sandbox/modulefiles/null/.release-1.0.0 for the null/1.0.0 module
    -
    $ module load hdf5/1.8.14
    +
    stable
    -

    Instead of

    +

    Modulefiles are written in the Tool Command Language (Tcl). See section [modulefiles] for a detailed documentation. In Pmodules version 1.1.16 and newer modulefiles written in Lua are also supported but with some limitations.

    -
    -
    -
    $ module load gcc/4.9.2
-$ module load openmpi/1.8.4
-$ module load hdf5/1.8.14
    +
    +

    The above example doesn’t provide any software. In the following example we show a simple 'HelloWorld' module with a 'Hello, world!' program.

    +
    +
    Example: modulefile /opt/psi/Sandbox/modulefiles/HelloWorld/1.0.0:
    +
    +
    #%Pmodule
+
+module-whatis           "'Hello, world!' module"
+module-maintainer       "Achim Gsell <achim.gsell@psi.ch>"
+module-license          "MIT"
+module-url              "http://pmodules.gitpages.psi.ch"
+
+module-help     "
+The module provides a 'Hello, world!' program.
+"
    -
    -

    you can also execute

    +
    Example: /opt/psi/Sandbox/HelloWorld/1.0.0/bin/hello:
    -
    $ module load gcc/4.9.2 openmpi/1.8.4 hdf5/1.8.14
    +
    #!/usr/bin/env python3
+
+print("Hello, world!")
    +
    +
    +
    +

    In principal, it is possible to install modules 'by hand' by installing the software, module- and configuration files at the right place. For reproducibility, documentation and re-usability it is highly recommended to write build-recipes for each module or - at least - a README and host everything on a PSI Gitlab server.

    +
    +
    +

    Overall the main cases for building modules are:

    +
    +
      +
    • +

      Building a module from source. This is the most common case. Examples: git, +gnuplot, openmpi, hdf5, …​
      +In this case it is highly recommended to code each step - usually download, configure, compile and install - in a script, write a modulefile and a configuration file.

      +
      • +
    • +

      Building a module with a binary package. Examples: Intel compiler, Matlab, +ANSYS, Mathematica, …​
      +In this case best practice is to install the package by hand and write a "dummy" build script, a modulefile and a configuration file. If it is possible and simple to script the installation, code this in the build script. If you cannot easily script the installation, document each step in a README file.

      +
      • +
    @@ -513,306 +519,179 @@

    2.3. Module hierarchies

    -Modules marked with (u) are unstable. ---- +
    +

    In any case: keep everything in a Git repository on either gitlab.psi.ch or git.psi.ch. +The Git repository for the groups Tool, Programming, Compiler, HDF5, HDF_serial and System is Pmodules/buildblock. Other groups can be hosted anywhere. But to keep everything together a project in Pmodules might be a good choice.

    +
    +
    +

    Many modules for the Pmodules environment have to be build from +source. The building plan of a module is coded in a so called +build-block. A build-block consists at least of a build-script with instruction how to download, compile and install a dedicated piece of +software, a modulefile and a configuration file.

    +
    +
    +

    In the next section we describe how to write build recipes.

    +
    -

    2.4. Searching the module hierarchy

    +

    3.2. Predefined variables

    +
    +

    Since we use BASH for our build-scripts and Tcl for modulefiles, we use BASH/Tcl syntax for variables in this documentation. So, if VARIABLE is the name of a variable, $VARIABLE the value of it.

    +
    -

    Now you may ask: How do I know which hdf5 (or Trilinos, boost…​) modules are really available? To get an answer to this question you can run the module search command.

    +

    In modulefiles and build-scripts the following variables are predefined:

    -
    Example
    +
    P
    +
    +

    the name of the module

    +
    +
    V
    +
    +

    the module version. The version number consists of a major- and a minor version number, a patch-level and a release number. All numbers but the major version number are optional. Major-, minor number and patch-level are separated by dots, the release number by a minus. Example: 1.0.3-2

    +
    +
    V_MAJOR
    +
    +

    the major version number. Example: 1

    +
    +
    V_MINOR
    +
    +

    the minor version number. Example: 0

    +
    +
    V_PATCHLVL
    +
    +

    the patch-level. Example: 3

    +
    +
    V_RELEASE
    +
    +

    the release number. Example: 2

    +
    +
    V_PKG
    +
    +

    version number without release.

    +
    +
    GROUP
    +
    +

    group the module is in.

    +
    +
    PREFIX
    +
    +

    installation prefix of the module.

    +
    +
    PMODULES_ROOT
    -

    To get a list of all installed hdf5 modules run

    +

    root of Pmodules installation. At PSI this is /opt/psi.

    -
    -
    -
    $ module search hdf5 --all-releases
-Module               Release    Group        Requires
-------------------------------------------------------------
-hdf5/1.8.12          unstable   MPI          gcc/4.7.4 mpich/3.1.4
-hdf5/1.8.12          stable     MPI          gcc/4.7.4 openmpi/1.6.5
-hdf5/1.8.12          stable     MPI          gcc/4.7.4 openmpi/1.8.2
-hdf5/1.8.12          stable     MPI          gcc/4.7.4 openmpi/1.8.4
-hdf5/1.8.12          stable     MPI          gcc/4.8.3 openmpi/1.6.5
-hdf5/1.8.12          stable     MPI          gcc/4.8.3 openmpi/1.8.2
-hdf5/1.8.12          stable     MPI          gcc/4.8.3 openmpi/1.8.4
-hdf5/1.8.12          unstable   MPI          gcc/4.8.4 mpich/3.1.4
-hdf5/1.8.12          stable     MPI          gcc/4.8.4 openmpi/1.6.5
-hdf5/1.8.12          stable     MPI          gcc/4.8.4 openmpi/1.8.2
-hdf5/1.8.12          stable     MPI          gcc/4.8.4 openmpi/1.8.4
-hdf5/1.8.12          unstable   MPI          gcc/4.9.2 mpich/3.1.4
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5/1.8.12          unstable   MPI          gcc/5.1.0 mpich/3.1.4
-hdf5/1.8.12          unstable   MPI          gcc/5.1.0 openmpi/1.6.5
-hdf5/1.8.12          unstable   MPI          gcc/5.1.0 openmpi/1.8.4
-hdf5/1.8.12          unstable   MPI          intel/15.2 mpich/3.1.4
-hdf5/1.8.12          unstable   MPI          intel/15.2 openmpi/1.6.5
-hdf5/1.8.12          unstable   MPI          intel/15.2 openmpi/1.8.4
-hdf5/1.8.13          stable     MPI          gcc/4.7.4 openmpi/1.6.5
-hdf5/1.8.13          stable     MPI          gcc/4.7.4 openmpi/1.8.2
-hdf5/1.8.13          stable     MPI          gcc/4.7.4 openmpi/1.8.4
-hdf5/1.8.13          stable     MPI          gcc/4.8.3 openmpi/1.6.5
-hdf5/1.8.13          stable     MPI          gcc/4.8.3 openmpi/1.8.2
-hdf5/1.8.13          stable     MPI          gcc/4.8.3 openmpi/1.8.4
-hdf5/1.8.13          stable     MPI          gcc/4.8.4 openmpi/1.6.5
-hdf5/1.8.13          stable     MPI          gcc/4.8.4 openmpi/1.8.2
-hdf5/1.8.13          stable     MPI          gcc/4.8.4 openmpi/1.8.4
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          gcc/4.7.4 mpich/3.1.4
-hdf5/1.8.14          stable     MPI          gcc/4.7.4 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.7.4 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.7.4 openmpi/1.8.4
-hdf5/1.8.14          stable     MPI          gcc/4.8.3 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.8.3 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.8.3 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          gcc/4.8.4 mpich/3.1.4
-hdf5/1.8.14          stable     MPI          gcc/4.8.4 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.8.4 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.8.4 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          gcc/4.9.2 mpich/3.1.4
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          gcc/5.1.0 mpich/3.1.4
-hdf5/1.8.14          unstable   MPI          gcc/5.1.0 openmpi/1.6.5
-hdf5/1.8.14          unstable   MPI          gcc/5.1.0 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          intel/15.2 mpich/3.1.4
-hdf5/1.8.14          unstable   MPI          intel/15.2 openmpi/1.6.5
-hdf5/1.8.14          unstable   MPI          intel/15.2 openmpi/1.8.4
-hdf5_serial/1.8.12   stable     Compiler     gcc/4.7.4
-hdf5_serial/1.8.12   stable     Compiler     gcc/4.8.3
-hdf5_serial/1.8.12   stable     Compiler     gcc/4.8.4
-hdf5_serial/1.8.12   stable     Compiler     gcc/4.9.2
-hdf5_serial/1.8.12   unstable   Compiler     intel/15.2
-hdf5_serial/1.8.14   stable     Compiler     gcc/4.7.4
-hdf5_serial/1.8.14   stable     Compiler     gcc/4.8.3
-hdf5_serial/1.8.14   stable     Compiler     gcc/4.8.4
-hdf5_serial/1.8.14   stable     Compiler     gcc/4.9.2
-hdf5_serial/1.8.14   unstable   Compiler     intel/15.2
    -
    +
    +

    In build-scripts the following variables are predefined too:

    -
    Example
    +
    TEMP_DIR
    +
    +

    directory for temporary files.

    +
    +
    SRC_DIR
    +
    +

    directory of unpacked sources, set to $PMODULES_TMPDIR/$P-$V/src

    +
    +
    BUILD_DIR
    +
    +

    build directory, set to $PMODULES_TMPDIR/$P-$V/build

    +
    +
    BUILDBLOCK_DIR
    +
    +

    Directory where the build-script is in.

    +
    +
    BUILD_SCRIPT
    +
    +

    Name of the build script.

    +
    +
    SYSTEM,OS
    -

    To get a list of all installed hdf5 modules compiled with GCC 4.9.2, run

    +

    Can be set with the --system option. The value defaults to the string returned by uname -s. The use of OS is obsolete.

    -
    -
    -
    $ module search hdf5 --with=gcc/4.9.2 --all-releases
-Module               Release    Group        Requires
-------------------------------------------------------------
-hdf5/1.8.12          unstable   MPI          gcc/4.9.2 mpich/3.1.4
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.12          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.13          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5/1.8.14          unstable   MPI          gcc/4.9.2 mpich/3.1.4
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.4
-hdf5_serial/1.8.12   stable     Compiler     gcc/4.9.2
-hdf5_serial/1.8.13   stable     Compiler     gcc/4.9.2
-hdf5_serial/1.8.14   stable     Compiler     gcc/4.9.2
    -
    +
    +

    In modulefiles the following variables are predefined too:

    -
    Example
    +
    name
    +
    +

    Same as P (obsolete, for historical reasons).

    +
    +
    version
    +
    +

    Same as V (obsolete, for historical reasons).

    +
    +
    group
    -

    To get a list of all installed modules providing (parallel) HDF5 1.8.14, execute

    +

    The group the module is member of.

    -
    -
    -
    $ module search hdf5/1.8.14 --with=gcc/4.9.2 --all-releases
-Module               Release    Group        Requires
-------------------------------------------------------------
-hdf5/1.8.14          unstable   MPI          gcc/4.9.2 mpich/3.1.4
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.6.5
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.2
-hdf5/1.8.14          stable     MPI          gcc/4.9.2 openmpi/1.8.4
    -
    -
    -
    - - - - - -
    - - -Without the option --all-releases, only modules of "used" releases are listed. -
    -
    -
    -

    2.5. Module lifecycle

    -
    -

    Pmodules supports a simple lifecycle management. This solves the -problem of introducing new modules, which are still in development or -considered to be unstable and it supports phasing out old and -deprecated modules. The lifecycle of a module is unstable → -stable → deprecated. By default only stable modules are -visible. If you want to use unstable or deprecated modules, you have -to run

    -
    -
    -
    -
    $ module use unstable
    -
    -
    +

    3.3. Building a Pmodule

    -

    or

    -
    -
    -
    -
    $ module use deprecated
    -
    -
    -
    -

    first.

    -
    -
    -

    All modules start as unstable. This implies something like "use on -your on risk". Unstable modules may be changed without warning or even -be removed. If you load an unstable module, a warning will be printed.

    +

    Perform the following steps for a new Pmodule:

    -
    -

    A stable module is, well, stable. It will not be changed during the -remaining life time and the provided software is considered to be -stable.

    +
    +
      +
    1. +

      Create a directory with the name of the module.

      +
      2. +
    2. +

      Write the configuration file. See section Writing build configuration files.

      +
      3. +
    3. +

      Write the modulefile. See section [sec-modulefiles].

      +
      4. +
    4. +

      Code all required steps to install a software in a script. If it is not possible to script everything, code as much as possible and document additional steps in a README file. See section Writing build scripts.

      +
      5. +
    -

    A deprecated module should not be used any more. Deprecated modules -might be removed without further warning. While loading a deprecated -module, a warning will be printed. Kind module developers might add an -end of life message with more detailed information.

    -
    +

    The first - and sometimes also to most challenging - step in building a Pmodule from source is to learn how to download, configure, compile and install a software package and dependencies the package has. The next steps are writing a configuration file, a modulefile and a script to download, configure, compile and install it.

    -
    -

    2.6. Overlays

    -

    TBW

    -
    -
    +

    In general the following steps needs to be performed:

    +
    +
    +
    prepare
    +
    +

    Download, unpack, apply patches (optional). Downloading the software might not be scriptable due to password protection or other measurements.

    +
    +
    configure
    +
    +

    (only for software distributed as source code) This step heavily depends on the software itself. In many cases autotools or CMake is used, in some cases you have to deal with Makefiles or other tools.

    +
    +
    build
    +
    +

    (only for software distributed as source code) compile/build everything

    +
    +
    install
    +
    +

    Install everything in the target directory. In case of a binary package this might not be scriptable.

    +
    +
    -
    -

    3. THE module COMMAND

    -
    -
    -

    Table of Content
    -The module-command: module
    -List available modules: module avail
    -Clear list of loaded modules: module clear
    -Display information about chances in environment when loaded: module display
    -Print sub-command or module-specific help: module help
    -Add or remove modules from shell’s initialization file: module initcmds
    -Search for keywords in 'whatis': [module-keyword]
    -List loaded modules: module list
    -Load and unload modules: module load|unload
    -Purge all loaded modules: module purge
    -Refresh loaded modules: module refresh
    -Search installed modules: module search
    -Replace a loaded module by another: module swap
    -Manipulate module path, used releases, groups and overlays: module use
    -Search for keywords in 'whatis': module whatis|keyword

    -

    3.1. module - using Pmodules

    -
    -

    NAME

    -
    -

    module - command line interface to the Pmodules package

    -
    -
    +

    3.4. Writing build configuration files

    -

    SYNOPSIS

    -
    -

    module [ switches ] [ sub-command ] [ sub-command-args ]

    -
    -
    -
    -

    DESCRIPTION

    -
    -

    Environment Modules provide a convenient way to dynamically change the -users' environment through modulefiles. This includes easily adding or -removing directories to the PATH environment variable. -A modulefile contains the necessary information to allow a user to run -a particular application or provide access to a particular -library. All of this can be done dynamically without logging out and -back in. Modulefiles for applications modify the user’s shell -environment to make access easy. Modulefiles for Library packages -provide environment variables that specify where the library and -header files can be found. -Packages can be loaded and unloaded cleanly through the module command.

    -
    -
    -

    Available sub-commands are:

    -
    -
    -

    List available modules: module avail

    -
    -
    -

    Clear list of loaded modules: module clear

    -
    -
    -

    Display information about chances in environment when loaded: module display

    -
    -
    -

    Print sub-command or module-specific help: module help

    -
    -
    -

    Add or remove modules from shell’s initialization file: module initcmds

    -
    -
    -

    Search for keywords in 'whatis': [module-keyword]

    -
    -
    -

    List loaded modules: module list

    -
    -
    -

    Load and unload modules: module load|unload

    -
    -
    -

    Purge all loaded modules: module purge

    -
    -
    -

    Refresh loaded modules: module refresh

    -
    -
    -

    Search installed modules: module search

    -
    -
    -

    Replace a loaded module by another: module swap

    -
    -
    -

    Manipulate module path, used releases, groups and overlays: module use

    -
    -
    -

    Search for keywords in 'whatis': module whatis|keyword

    -
    +

    3.4.1. YAML configuration files in Pmodules 1.1 and newer

    @@ -821,3910 +700,1136 @@

    DESCRIPTION

    -

    For the time being Pmodules supports bash, tcsh and zsh only.

    +

    Pmodules 1.1 and newer are supporting configuration files in YAML +format. For backward compatibility the build-systems supports both +types of configuration files with the YAML configuration file as +default.
    +
    +

    The old format of the variants file is simple but very limited and +almost impossible to extend for new features. To overcome the +limitations a new format using YAML for variants files has been +introduced. For the time being both format are supported. But it is +highly recommended to use the YAML format for new modules and to +migrate existing variants files in the old format to the new.

    -
    -
    -

    3.2. Sub-commands

    -
    -

    3.2.1. List available/loadable modules

    -
    NAME
    +
    3.4.1.1. Path to configuration file
    -

    module avail - list loadable modules

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module avail [OPTIONS] [string…​]

    -
    -
    -
    -
    DESCRIPTION
    -
    -

    List all available module in the current MODULEPATH. If an argument is given, then each directory in the MODULEPATH is searched for modules whose pathname match the argument.

    +

    The path to the configuration file is

    -

    This command does not display all installed modules on the system. Only loadable modules are listed. To get a list of all installed modules use the command module search.

    -
    -
    -

    The list of available modules may change either by loading other modules, e.g. a compiler, or by using/accepting unstable or deprecated modules. For the later read the description of module use.

    -
    -
    -

    With the switches you can change the output format. The default output format is 'human' (readable). For the time being terse and long output are identical.

    -
    -
    -
    -
    OPTIONS
    -
    -
    -
    -a
    -
    -

    List loadable modules in all release-stages. Unstable modules are marked with (u), -deprecated modules with (d).

    -
    -
    -t | --terse
    -
    -

    Terse output.

    -
    -
    -h | --human
    -
    -

    Human readable output. This is the default.

    -
    -
    -l | --long
    -
    -

    Long output.

    -
    -
    +

    build-recipe-dir/files/config.yaml

    -
    EXAMPLES
    +
    3.4.1.2. Format
    -
    $ module avail git
------------------------------------------ Tools -----------------------------------------
-
-ygit/2.3.3       git/2.8.1       git/2.21.0      git/2.22.0      git/2.30.0      git/2.33.1
-
-$ module avail -a gcc
--------------------------------------- Programming --------------------------------------
-
-gcc/4.7.4       gcc/4.8.2       gcc/4.8.3       gcc/4.8.4       gcc/4.8.5       gcc/4.9.2
-gcc/4.9.3       gcc/4.9.4       gcc/5.1.0(d)    gcc/5.2.0(d)    gcc/5.3.0       gcc/5.4.0
-gcc/5.5.0       gcc/6.1.0       gcc/6.2.0       gcc/6.3.0       gcc/6.4.0       gcc/6.5.0
-gcc/7.1.0       gcc/7.2.0       gcc/7.3.0       gcc/7.4.0       gcc/7.5.0       gcc/8.1.0
-gcc/8.2.0       gcc/8.3.0       gcc/8.4.0       gcc/8.5.0       gcc/9.1.0       gcc/9.2.0
-gcc/9.3.0       gcc/9.5.0       gcc/10.1.0      gcc/10.2.0      gcc/10.3.0      gcc/11.2.0
-gcc/11.3.0      gcc/12.1.0
    -
    -
    -
    -
    SEE ALSO
    -
    -

    module list, -module load|unload, -module search, -module use, -[module-unuse]

    -
    -
    -
    -
    -
    -

    3.2.2. Clear list of loaded modules

    -
    -
    NAME
    -
    -

    module clear - clear list of loaded modules.

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module clear

    -
    +
    format: 1
+module-name-1:
+  defaults:                                       # optional
+    config-block
+  shasums:                                        # optional
+    filename-1: sha256sum-1
+    ...
+  versions:
+    version-keys-1:
+      config:                                     # optional
+        config-block
+      variants:                                   # optional
+        - config-block-1
+        - ...
+    ...
+module-name-2:
+  ...
    -
    -
    DESCRIPTION
    -
    -

    Force the Pmodules package to believe that no modules are currently loaded. The sub-command clear does not unload the loaded modules! In other words: changes made to the shell’s environment by loaded modules are not reverted.

    + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Field-NameTypeDescription

    format

    unsigned int

    Format version of the YAML configuration file. For now it must be 1

    module-name-N

    config-block

    Configuration for the Pmodule module-name-N. Example: openmpi

    defaults

    config-block

    Default configuration. This block is optional.

    shasums

    MAP of string

    SHA256 hash sums of source files. Keys are filenames, the value the
    + corresponding SHA256 hash sum. This block is optional. A warning is + printed if a hash-sum is missing for a required file.

    versions

    MAP of configurations for different version keys

    A version key is a semicolon separated string of version + numbers. Version numbers can be specified with shell brace + expansion. Example:
    + 5.4.{0,1,2,3,4,5,8,9};5.2.{0,4,6,7,8};5.0.0;4.6.3

    config

    config-block

    Optional, version specific configuration block. Configurations + specified here are overriding the defaults.

    variants

    map of config-block

    Variants can be used to compile the some software with different + options. Example: openmpi` with and without Slurm support are + variants of the same software.

    -
    EXAMPLES
    +
    3.4.1.3. Configuration blocks
    +
    + + + + + +
    + +
    -

    After loading the module for gcc/4.9.2 the following environment variables are set:

    -
    -
    -
    -
    $ env | grep ^GCC
-GCC_HOME=/opt/psi/Programming/gcc/4.9.2
-GCC_DIR=/opt/psi/Programming/gcc/4.9.2
-GCC_PREFIX=/opt/psi/Programming/gcc/4.9.2
-GCC_VERSION=4.9.2
-GCC_INCLUDE_DIR=/opt/psi/Programming/gcc/4.9.2/include
-GCC_LIBRARY_DIR=/opt/psi/Programming/gcc/4.9.2/lib
    -
    +

    In configuration blocks everything is optional!

    -
    -

    After clearing the list of loaded modules the environment variables set by the GCC module are still set

    +
    +
    config-block
    -
    $ module clear
-$ module list
-No Modulefiles Currently Loaded.
-$ env | grep ^GCC
-GCC_HOME=/opt/psi/Programming/gcc/4.9.2
-GCC_DIR=/opt/psi/Programming/gcc/4.9.2
-GCC_PREFIX=/opt/psi/Programming/gcc/4.9.2
-GCC_VERSION=4.9.2
-GCC_INCLUDE_DIR=/opt/psi/Programming/gcc/4.9.2/include
-GCC_LIBRARY_DIR=/opt/psi/Programming/gcc/4.9.2/lib
    -
    -
    -
    -
    -
    SEE ALSO
    -
    -

    module purge, module load|unload

    -
    -
    -
    -
    -

    3.2.3. Display information about a module

    -
    -
    NAME
    -
    -

    module display\|show - display information about chances in environment

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module display modulefile…​
    -module show modulefile…​

    -
    +
    build_requires: [build-req-1, ...]
+compile_in_sourcetree: bool
+configure_with: auto|autotools|cmake
+default_variant: variant
+docfiles: [file-1, ...]
+group: group
+group_deps:
+  compilers:
+    cpmpiler-1: [version-1, ...]
+  mpi:
+    mpi-implemation-1: [version-1, ...]
+  hdf5:
+    hdf5: [version-1, ...]
+  hdf5_serial:
+    hdf5[_serial]: [_version-1, ...]
+overlay: overlay
+relstage: release-stage
+runtime_deps: [rt-dep-1, ...]
+suffix: suffix
+systems: [system-1, ...]
+urls:
+  - url: link
+    name: filename
+  - ...
+variant: [variant-1, ...]
    -
    -
    DESCRIPTION
    -
    -

    Display information about modulefile(s). The display sub-command will list the full path of the modulefile(s) and all of the environment changes the modulefile(s) will make if loaded. (It will not display any environment changes found within conditional statements.)

    + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Field-NameTypeDescription

    build_requires

    array of string

    Modules required to build this module

    compile_in_sourcetree

    boolean

    Compile in source tree or in a dedicate build directory.

    configure_with

    string

    Choose software configuration system. Allowed values are:
    + auto: use autotools if available
    + autotools: use autotools
    + cmake: use cmake

    default_variant

    string

    (opt) Specifies the default variant to build if no variant is specified

    docfiles

    array of string

    Array with documentation files to be installed in share/doc/

    group

    string

    Group of the module

    group_deps

    group-deps-object

    Group/hierarchical dependencies like compiler, MPI, HDF5 modules

    overlay

    string

    Overlay of the module

    relstage

    string

    Release stage of the module. Allowed values are:
    +unstable: the module is still under development
    +stable: the module is ready to be used
    +deprecated: the module is deprecated
    +remove: the module is deprecated and marked to be removed
    +removed: the module has been removed

    runtime_deps

    sequence of strings

    Module to be loaded at runtime

    suffix

    string

    This string will be added to the version of the module

    systems

    sequence of strings

    A 'system' is either a hostname or OS name like rhel8. For
    + hostnames shell glob pattern matching like merlin-* can be used.

    urls

    sequence of links and optional file-names

    Software which must be downloaded to build a specific module.
    + url: Download link
    + name: optional output filename. The filename defaults the last + component of the url.
    + Default URLs can be defined by using the variables P, V, + V_PKG, V_MAJOR, V_MINOR and V_PATCHLVL. Example:
    + https://sourceforge.net/projects/gnuplot/files/$P/$V/$P-${V_PKG}.tar.gz

    variant

    sequence of strings

    Sequence of synonyms for a variant.

    -
    EXAMPLES
    -
    -

    Display chances the module gcc/5.4.0 will make to the environment if loaded:

    -
    +
    3.4.1.4. Examples
    +
    Example: Gnuplot
    -
    $ module display gcc/5.4.0
--------------------------------------------------------------------
-/opt/psi/Programming/modulefiles/gcc/5.4.0:
-
-module-whatis	 GNU Compiler Collection
-conflict	 gcc
-setenv		 GCC_VERSION 5.4.0
-setenv		 GCC_PREFIX /opt/psi/Programming/gcc/5.4.0
-setenv		 GCC_DIR /opt/psi/Programming/gcc/5.4.0
-setenv		 GCC_HOME /opt/psi/Programming/gcc/5.4.0
-prepend-path	 PATH /opt/psi/Programming/gcc/5.4.0/bin
-prepend-path	 MANPATH /opt/psi/Programming/gcc/5.4.0/share/man
-prepend-path	 C_INCLUDE_PATH /opt/psi/Programming/gcc/5.4.0/include
-prepend-path	 CPLUS_INCLUDE_PATH /opt/psi/Programming/gcc/5.4.0/include
-setenv		 GCC_INCLUDE_DIR /opt/psi/Programming/gcc/5.4.0/include
-prepend-path	 LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib
-prepend-path	 LD_LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib
-setenv		 GCC_LIBRARY_DIR /opt/psi/Programming/gcc/5.4.0/lib
-prepend-path	 LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib64
-prepend-path	 LD_LIBRARY_PATH /opt/psi/Programming/gcc/5.4.0/lib64
-setenv		 GCC_LIBRARY_DIR /opt/psi/Programming/gcc/5.4.0/lib64
-append-path	 PMODULES_LOADED_PROGRAMMING gcc/5.4.0
-remove-path	 PMODULES_LOADED_PROGRAMMING --APPMARKER--
-setenv		 COMPILER gcc
-setenv		 COMPILER_VERSION 5.4.0
-setenv		 CC /opt/psi/Programming/gcc/5.4.0/bin/gcc
-setenv		 CXX /opt/psi/Programming/gcc/5.4.0/bin/g++
-setenv		 F77 /opt/psi/Programming/gcc/5.4.0/bin/gfortran
-setenv		 F90 /opt/psi/Programming/gcc/5.4.0/bin/gfortran
-setenv		 FC /opt/psi/Programming/gcc/5.4.0/bin/gfortran
-setenv		 FORTRAN /opt/psi/Programming/gcc/5.4.0/bin/gfortran
--------------------------------------------------------------------
    -
    -
    -
    -
    -
    SEE ALSO
    -
    -

    module help

    -
    -
    -
    -
    -

    3.2.4. Print sub-command or module-specific help

    -
    -
    NAME
    -
    -

    module help - print sub-command or module-specific help

    +
    format: 1
+gnuplot:
+  defaults:                                             (1)
+    group: Tools                                        (2)
+    overlay: base                                       (3)
+    relstage: stable                                    (4)
+    systems: [rhel8, rhel7, rhel6]                      (5)
+    docfiles: [Copyright, NEWS, README]                 (6)
+    urls:                                               (7)
+      - url: https://sourceforge.net/projects/gnuplot/files/$P/$V/$P-${V_PKG}.tar.gz
+  shasums:                                              (8)
+    gnuplot-5.4.10.tar.gz: 975d8c1cc2c41c7cedc4e323aff035d977feb9a97f0296dd2a8a66d197a5b27c
+    gnuplot-5.4.9.tar.gz: a328a021f53dc05459be6066020e9a71e8eab6255d3381e22696120d465c6a97
+    gnuplot-5.4.8.tar.gz: 931279c7caad1aff7d46cb4766f1ff41c26d9be9daf0bcf0c79deeee3d91f5cf
+    gnuplot-5.4.5.tar.gz: 66f679115dd30559e110498fc94d926949d4d370b4999a042e724b8e910ee478
+    gnuplot-5.4.4.tar.gz: 372300b7867f5b3538b25fc5d0ac7734af6e3fe0d202b6db926e4369913f0902
+    gnuplot-5.4.3.tar.gz: 51f89bbab90f96d3543f95235368d188eb1e26eda296912256abcd3535bd4d84
+    gnuplot-5.4.2.tar.gz: e57c75e1318133951d32a83bcdc4aff17fed28722c4e71f2305cfc2ae1cae7ba
+    gnuplot-5.4.1.tar.gz: 6b690485567eaeb938c26936e5e0681cf70c856d273cc2c45fabf64d8bc6590e
+    gnuplot-5.4.0.tar.gz: eb4082f03a399fd1e9e2b380cf7a4f785e77023d8dcc7e17570c1b5570a49c47
+    gnuplot-5.2.8.tar.gz: 60a6764ccf404a1668c140f11cc1f699290ab70daa1151bb58fed6139a28ac37
+    gnuplot-5.2.7.tar.gz: 97fe503ff3b2e356fe2ae32203fc7fd2cf9cef1f46b60fe46dc501a228b9f4ed
+    gnuplot-5.2.6.tar.gz: 35dd8f013139e31b3028fac280ee12d4b1346d9bb5c501586d1b5a04ae7a94ee
+    gnuplot-5.2.4.tar.gz: 1515f000bd373aaa53b16183f274189d4f5e0ae47d22f434857933d16a4770cb
+    gnuplot-5.0.0.tar.gz: 417d4bc5bc914a60409bb75cf18dd14f48b07f53c6ad3c4a4d3cd9a8d7370faf
+    gnuplot-4.6.3.tar.gz: df5ffafa25fb32b3ecc0206a520f6bca8680e6dcc961efd30df34c0a1b7ea7f5
+  versions:
+    5.4.{0,1,2,3,4,5,8,9};5.2.{0,4,6,7,8};5.0.0;4.6.3:  (9)
+    5.4.10:                                             (10)
+      config:
+        relstage: unstable
    -
    -
    SYNOPSIS
    -
    -

    module help [module|sub-command…​]

    -
    -
    -
    -
    DESCRIPTION
    -
    -

    Print help for specific modules, sub-commands or the module command itself.

    -
    -
    -
    -
    EXAMPLES
    -
    -

    Get help for the module git/2.3.3:

    -
    -
    -
    -
    $ module help git/2.3.3
-
------------ Module Specific Help for 'git/2.3.3' ------------------
-
-distributed version control system
-Version:    2.3.3
-Homepage:   http://git-scm.com/
-License:    GNU GPL v2
-Maintainer: Achim Gsell <achim.gsell@psi.ch>
-
-Git is a free and open source distributed version control system
-designed to handle everything from small to very large projects
-with speed and efficiency.
-
-Git is easy to learn and has a tiny footprint with lightning fast
-performance. It outclasses SCM tools like Subversion, CVS, Perforce,
-and ClearCase with features like cheap local branching, convenient
-staging areas, and multiple workflows.
    -
    -
    -
    -

    Print help for the sub-command load:

    -
    -
    -
    -
    $ module help load
-
-USAGE:
-        module add     modulefile...
-        module load    modulefile...
-                Load modulefile(s) into the shell environment. Loading a
-		'group-head' will extend the MODULEPATH. E.g.: loading a
-		compiler makes additional modules like openmpi and libraries
-		compiled with this compiler available.
    -
    -
    -
    -
    -
    SEE ALSO
    -
    -

    module whatis|keyword

    -
    -
    -
    -
    -

    3.2.5. Manipulate shell’s initialization file

    -
    -
    NAME
    -
    -

    module initadd|initprepend|initrm|initswitch|initrm|initlist|initclear - add or remove modules from shell’s initialization file

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module initadd module…​
    -module initprepend module…​
    -module initrm module…​
    -module initswitch module1 module2
    -module initlist
    -module initclear

    -
    -
    -
    -
    DESCRIPTION
    -
    -

    Add modulefile(s) to, list modulefile(s) in or remove modulefile(s) from the shell’s initialization file in the user’s home directory. The startup files checked (in order) are:

    -
    -
    -
    -
    csh
    -
    -

    .modules, .cshrc(.ext), .csh_variables, and .login(.ext)

    -
    -
    tcsh
    -
    -

    .modules, .tcshrc, .cshrc(.ext), .csh_variables, and .login(.ext)

    -
    -
    bash
    -
    -

    .modules, .bash_profile, .bash_login, .profile(.ext), and .bashrc(.ext)

    -
    -
    zsh
    -
    -

    .modules, .zcshrc(.ext), .zshenv(.ext), and .zlogin(.ext)

    -
    -
    module initadd module…​
    -
    -

    If a module load line is found in any of these files, the modulefile(s) is(are) appended to any existing list of modulefiles. The module load line must be located in at least one of the files listed above for any of the init sub-commands to work properly. If the module load line is found in multiple shell initialization files, all of the lines are changed.

    -
    -
    module initprepend module…​
    -
    -

    Does the same as initadd but prepends the given modules to the beginning of the list.

    -
    -
    module initrm module…​
    -
    -

    Remove modulefile(s) from the shell’s initialization files.

    -
    -
    module initswitch module1 module2
    -
    -

    Switch module1 with module2 in the shell’s initialization files.

    -
    -
    module initlist
    -
    -

    List all of the module(s) loaded from the shell’s initialization file.

    -
    -
    module initclear
    -
    -

    Clear all of the module(s) from the shell’s initialization files.

    -
    -
    -
    -
    -
    -
    SEE ALSO
    -
    -

    module load|unload, module load|unload, [module-switch]

    -
    -
    -
    -
    -

    3.2.6. List loaded modules

    -
    -
    NAME
    -
    -

    module list - list loaded modules

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module list [OPTIONS]

    -
    -
    -
    -
    DESCRIPTION
    -
    -

    List loaded modules.

    -
    -
    -
    -
    OPTIONS
    -
    -
    -
    -t | --terse
    -
    -

    Terse output.

    -
    -
    -h | --human
    -
    -

    Human readable output. This is the default.

    -
    -
    -l | --long
    -
    -

    Long output.

    -
    -
    -
    -
    -
    -
    EXAMPLES
    -
    -

    Assuming the modules gcc/4.8.3, openmpi/1.8.2 and hdf5/1.8.12. List with default (human readable) output:

    -
    -
    -
    -
    $ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.8.3       2) openmpi/1.8.2   3) hdf5/1.8.12
    -
    -
    -
    -

    List in terse output:

    -
    -
    -
    -
    $ module list -t
-Currently Loaded Modulefiles:
-gcc/4.8.3
-openmpi/1.8.2
-hdf5/1.8.12
    -
    -
    -
    -

    Long listing:

    -
    -
    -
    -
    $ module list -l
-- Package -----------------------------+- Versions -+- Last mod. ------
-Currently Loaded Modulefiles:
-gcc/4.8.3                                            2014/12/05 17:39:24
-openmpi/1.8.2                                        2014/11/25  8:15:40
-hdf5/1.8.12                                          2014/11/25  8:15:40
    -
    -
    -
    -
    -
    SEE ALSO
    -
    -

    module load|unload, module avail

    -
    -
    -
    -
    -

    3.2.7. Load and unloading a module

    -
    -
    NAME
    -
    -

    module add|load - load modules
    -module rm|unload - unload modules

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module add [OPTIONS] modulefile…​
    -module load [OPTIONS] modulefile…​
    -module rm modulefile…​
    -module unload modulefile…​

    -
    -
    -
    -
    DESCRIPTION
    -
    -

    Load modulefile(s) into shell environment. Loading a group-head will extend the MODULEPATH. E.g.: loading a compiler makes additional modules like openmpi and other libraries/packages compiled with this compiler available.

    -
    -
    -

    If you try to load a module which is not available in the current MODULEPATH but installed in the module hierarchy, a message will be printed showing prerequisite modules.

    -
    -
    -

    If you load a deprecated or unstable module, a warning will be printed.

    -
    -
    -

    You can change the verbosity of the load sub-command by setting the environment variable PMODULES_VERBOSITY to silent, warn or verbose.

    -
    -
    -
    -
    silent
    -
    -

    Print error messages only.

    -
    -
    warn
    -
    -

    Print a warning message, when loading a deprecated or unstable module.

    -
    -
    verbose
    -
    -

    Print warning messages and print prerequisite modules if the module to load is not available, but installed in hierarchy.

    -
    -
    -
    -
    -
    -
    OPTIONS / FLAGS
    -
    -
    -
    -f | --force
    -
    -

    Force active dependency resolution. This will result in modules found on a prereq command inside a module file being load automatically. Unloading module files using this switch will result in all required modules which have been loaded automatically using the -f switch being unload. This switch is experimental at the moment.

    -
    -
    -v | --verbose
    -
    -

    Set verbosity level to verbose.

    -
    -
    -w | --warn
    -
    -

    Set verbosity level to warn.

    -
    -
    -s | --silent
    -
    -

    Set verbosity level to silent.

    -
    -
    -
    -
    -
    -
    EXAMPLES (add|load)
    -
    -

    Loading the modules gcc/4.9.2, openmpi/1.8.4 and hdf5/1.8.14:

    -
    -
    -
    -
    $ module load gcc/4.9.2
-$ module load openmpi/1.8.4
-$ module load hdf5/1.8.14
-$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2       2) openmpi/1.8.4   3) hdf5/1.8.14
    -
    -
    -
    -

    or

    -
    -
    -
    -
    $ module load gcc/4.9.2 openmpi/1.8.4 hdf5/1.8.14
    -
    -
    -
    -

    If you try to load hdf5/1.8.14 without the prerequisite modules, some "hints" will be printed, if the default verbosity level is set:

    -
    -
    -
    -
    $ module purge
-$ module load hdf5/1.8.14
-The module 'hdf5/1.8.14' cannot be loaded!
-Try with one of the following command(s):
-
-module load gcc/4.7.4 openmpi/1.6.5 hdf5/1.8.14
-module load gcc/4.7.4 openmpi/1.8.2 hdf5/1.8.14
-module load gcc/4.7.4 openmpi/1.8.4 hdf5/1.8.14
-module load gcc/4.8.3 openmpi/1.6.5 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.3 openmpi/1.8.2 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.3 openmpi/1.8.4 hdf5/1.8.14
-module load gcc/4.8.4 openmpi/1.6.5 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.4 openmpi/1.8.2 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.4 openmpi/1.8.4 hdf5/1.8.14
-module use deprecated; module load gcc/4.8.4 openmpi/1.8.8 hdf5/1.8.14
-module use deprecated; module load gcc/4.9.2 openmpi/1.6.5 hdf5/1.8.14
-module use deprecated; module load gcc/4.9.2 openmpi/1.8.2 hdf5/1.8.14
-module use deprecated; module load gcc/4.9.2 openmpi/1.8.4 hdf5/1.8.14
    -
    -
    -
    -

    Use verbosity level warn to suppress the hints:

    -
    -
    -
    -
    $ module load hdf5/1.8.14 --warn
-module load: module unavailable -- hdf5/1.8.14
    -
    -
    -
    -

    Loading an unstable module:

    -
    -
    -
    -
    $ module use unstable
-$ module load cmake/3.1.3
-Warning: the unstable module 'cmake/3.1.3' has been loaded.
    -
    -
    -
    -

    To supress the warning, use the --silent option.

    -
    -
    -
    -
    EXAMPLES (rm|unload)
    -
    -
    -
    $ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2       2) openmpi/1.8.4   3) hdf5/1.8.14
-$ module rm openmpi/1.8.4
-$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2
    -
    -
    -
    -

    The module hdf5/1.8.14 is unloaded as a dependency of openmpi/1.8.4.

    -
    -
    -
    -
    SEE ALSO
    -
    -

    module use, module load|unload, module purge, module swap, module list

    -
    -
    -
    -
    -

    3.2.8. Purge all loaded modules

    -
    -
    NAME
    -
    -

    module purge - purge all loaded modules

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module purge

    -
    -
    -
    -
    DESCRIPTION
    -
    -

    Unload all loaded module and reset everything to original state.

    -
    -
    -
    -
    EXAMPLES
    -
    -

    List loaded modules:

    -
    -
    -
    -
    $ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.8.3       2) openmpi/1.8.2   3) gnuplot/4.6.3
    -
    -
    -
    -

    Now we purge everything and list the loaded modules again:

    -
    -
    -
    -
    $ module purge
-$ module list
-No Modulefiles Currently Loaded.
    -
    -
    -
    -
    -
    SEE ALSO
    -
    -

    module load|unload, module load|unload, module clear

    -
    -
    -
    -
    -

    3.2.9. Refresh loaded modules

    -
    -
    NAME
    -
    -

    module refresh - refresh loaded modules

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module refresh

    -
    -
    -
    -
    DESCRIPTION
    -
    -

    Force a refresh of all non-persistent components of currently loaded modules. This should be used on derived shells where aliases need to be reinitialized but the environment variables have already been set by the currently loaded modules.

    -
    -
    -
    -
    SEE ALSO
    -
    -

    module load|unload

    -
    -
    -
    -
    - -
    -
    NAME
    -
    -

    module search - search installed modules

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module search [switches] string…​

    -
    -
    -
    -
    DESCRIPTION
    -
    -

    List all modules in the current MODULEPATH and the module hierarchy. If an argument is given, search for modules whose name match the argument. -Options

    -
    -
    -
    -
    OPTIONS
    -
    -
    -
    --no-header
    -
    -

    Suppress output of a header.

    -
    -
    --release=RELEASE
    -
    -

    Search for modules within this release. You can specify this switch multiple times. Without this switch, the used releases will be searched.

    -
    -
    -a|--all-releases
    -
    -

    Search within all releases.

    -
    -
    --with=STRING
    -
    -

    Search for modules compiled with modules matching string. The command. See example below.

    -
    -
    --src=dir
    -
    -

    Search module hierarchy in dir. -Eine Textbeschreibung der Funktionsweise des Befehls oder der Funktion. (Üblicherweise jedoch nicht der Benutzung, siehe unten.)

    -
    -
    -
    -
    -
    -
    EXAMPLES
    -
    -

    Get list of all installed GCC:

    -
    -
    -
    -
    $ module search --all-releases gcc
-Module               Release    Group        Requires
-------------------------------------------------------------
-gcc/4.7.4            stable     Programming
-gcc/4.8.2            stable     Programming
-gcc/4.8.3            stable     Programming
-gcc/4.8.4            stable     Programming
-gcc/4.8.5            stable     Programming
-gcc/4.9.2            stable     Programming
-gcc/4.9.3            stable     Programming
-gcc/4.9.4            stable     Programming
-gcc/5.1.0            deprecated Programming
-gcc/5.2.0            deprecated Programming
-gcc/5.3.0            stable     Programming
-gcc/5.4.0            stable     Programming
-gcc/6.1.0            stable     Programming
-gcc/6.2.0            stable     Programming
-gcc/6.3.0            stable     Programming
-gcc/6.4.0            stable     Programming
-gcc/7.1.0            stable     Programming
-gcc/7.2.0            stable     Programming
    -
    -
    -
    -

    Get list of all open-mpi versions compiled with GCC 5.4.0:

    -
    -
    -
    -
    $ module search --all-releases openmpi --with=gcc/5.4.0
-Module               Release    Group        Requires
-------------------------------------------------------------
-openmpi/1.10.2       stable     Compiler     gcc/5.4.0
-openmpi/1.10.4       stable     Compiler     gcc/5.4.0
-openmpi/2.0.1        stable     Compiler     gcc/5.4.0
    -
    -
    -
    -
    -
    SEE ALSO
    -
    -

    module avail

    -
    -
    -
    -
    -

    3.2.11. Swapping modules

    -
    -
    NAME
    -
    -

    module swap|switch - replace a loaded module by another

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module swap [modulefile1] modulefile2
    -module switch [modulefile1] modulefile2

    -
    -
    -
    -
    DESCRIPTION
    -
    -

    Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified, then it is assumed to be the currently loaded module with the same root name as modulefile2.

    -
    -
    -
    -
    OPTIONS / FLAGS
    -
    -

    None

    -
    -
    -
    -
    EXAMPLES
    -
    -
    -
    $ module load gcc/4.8.4
-$ module swap gcc/4.9.2
-$ module list
-Currently Loaded Modulefiles:
-  1) gcc/4.9.2
    -
    -
    -
    -
    -
    BUGS
    -
    -

    You can only swap between different version. The following commands are working (assuming that gcc/4.8.2 is loaded):

    -
    -
    -
    -
    $ module swap gcc/4.9.2
-$ module swap gcc/4.9.2 gcc/5.4.0
    -
    -
    -
    -

    The following command does not working as expected:

    -
    -
    -
    -
    $ module swap gcc/4.8.2 intel/15.0
    -
    -
    -
    -

    This command does not work with the Tcl implementation (environment variable PMOUDLE_PURETCL set).

    -
    -
    -
    -
    SEE ALSO
    -
    -

    module load|unload, module load|unload, module list

    -
    -
    -
    -
    -

    3.2.12. Manipulate module path, used releases, groups or overlays

    -
    -
    NAME
    -
    -

    module use|unuse - manipulate module path, used releases or groups

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module use [OPTIONS] [string…​]

    -
    -
    -

    module unuse string…​

    -
    -
    -
    -
    DESCRIPTION
    -
    -

    If called without arguments, print a summary about used groups, releases and additional directories in MODULEPATH.

    -
    -
    -

    If string is a directory, append, prepend or remove this directory to/from MODULEPATH.

    -
    -
    -

    If string is a group name, append, prepend or remove the corresponding directory to/from MODULEPATH.

    -
    -
    -

    If string is a releases name, make all modules with this release available/unavailable. Known releases are;

    -
    -
    -
    -
    stable
    -
    -

    Modules released as stable are considered to be production ready. The files of a stable module will never change.

    -
    -
    unstable
    -
    -

    These modules are still unstable. They may not be ready for production use. The files of unstable modules may change to fix bugs or add functionality. Use at your own risk.

    -
    -
    deprecated
    -
    -

    Deprecated modules should not be used any more and may be removed without further notice.

    -
    -
    -
    -
    -

    If string matches flag=[-_a-zA-Z0-9]* the RHS will be interpreted as use-flag.

    -
    -
    -
    -
    OPTIONS / FLAGS
    -
    -
    -
    -a | --append
    -
    -

    append directory or group to MODULEPATH.

    -
    -
    -p | --prepend
    -
    -

    prepend directory or group to MODULEPATH.

    -
    -
    -
    -
    -
    -
    EXAMPLES
    -
    -

    List used/unused groups, releases and additional directories in MODULEPATH:

    -
    -
    -
    -
    $ module use
-Used groups:
-	Tools
-	Programming
-	Compiler
-
-Unused groups:
-	Legacy
-	Libraries
-	System
-
-Used releases:
-	stable
-	unstable
-
-Unused releases:
-	deprecated
-
-Used flags:
-	omp
-
-Additonal directories in MODULEPATH:
-	none
    -
    -
    -
    -

    Adding the 'System' group

    -
    -
    -
    -
    $ module use System
-$ module avail
--------------------------------------------- System:  --------------------------------------------
-
-filebench/1.4.9.1               fsstress/1.0.0  nmap/6.46       patchelf/0.8.1
-
--------------------------------------------- Tools:  --------------------------------------------
-
-ANSYS/18.2      emacs/24.4      git/2.3.3       global/6.3.1    gnuplot/4.6.3   gnuplot/5.0.0
-...
-
------------------------------------------ Programming:  -----------------------------------------
-
-autoconf/2.69   automake/1.14   automake/1.15   binutils/2.25   cmake/2.8.12.2  cmake/3.1.3
-cmake/3.6.3     gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/4.8.5
-...
    -
    -
    -
    -

    Adding a directory to MODULEPATH

    -
    -
    -
    -
    $ module use /afs/psi.ch/project/amas/modulefiles
-$ module avail
------------------------------------ /afs/psi.ch/project/amas:  -----------------------------------
-
-H5hut_parallel-toolchain/2.0    H5hut_serial-toolchain/2.0      OPAL/1.6        OPAL/1.6.0rc5
-opal-toolschain/1.6             opal-toolschain/2.0
-
--------------------------------------------- Tools:  --------------------------------------------
-
-ANSYS/18.2      emacs/24.4      git/2.3.3       global/6.3.1    gnuplot/4.6.3   gnuplot/5.0.0
-...
------------------------------------------ Programming:  -----------------------------------------
-
-autoconf/2.69   automake/1.14   automake/1.15   binutils/2.25   cmake/2.8.12.2  cmake/3.1.3
-cmake/3.6.3     gcc/4.7.4       gcc/4.8.3       gcc/4.8.4       gcc/4.9.2       gcc/4.8.5
-...
    -
    -
    -
    -
    -
    $ module unuse /afs/psi.ch/project/amas/modulefiles
-$ module unuse System
-$ module unuse unstable
    -
    -
    -
    -
    -
    SEE ALSO
    -
    -

    [module-unuse], module avail, module search

    -
    -
    -
    -
    -

    3.2.13. Show/search 'what is' information

    -
    -
    NAME
    -
    -

    module whatis - print one-line information about module -module keyword|apropos - search for keywords in 'whatis'

    -
    -
    -
    -
    SYNOPSIS
    -
    -

    module whatis [module…​]
    -module apropos string…​
    -module keyword string…​

    -
    -
    -
    -
    DESCRIPTION
    -
    -
    -
    whatis
    -
    -

    Display the information set up by the module-whatis commands inside -the specified modulefile(s). If no modulefile is specified, all whatis -lines will be shown.

    -
    -
    keyword|apropos
    -
    -

    Search through the 'whatis' informations of all modulefiles for the -specified string. All whatis informations matching the string will be -displayed.

    -
    -
    -
    -
    -
    -
    EXAMPLES
    -
    -

    Get whatis for all available Git modules

    -
    -
    -
    -
    $ module  whatis git
------------ /opt/psi/Tools/modulefiles -------------
-           git/2.3.3: distributed version control system
-           git/2.5.2: distributed version control system
-           git/2.8.1: distributed version control system
-          git/2.11.1: distributed version control system
------------ /opt/psi/Programming/modulefiles -------------
    -
    -
    -
    -
    -
    SEE ALSO
    -
    -

    module help

    -
    -
    -
    -
    -
    -
    -
    -

    4. BUILDING PMODULES

    -
    -
    -

    4.1. Introduction

    -
    -

    In the simplest case adding a Pmodule can be done by adding a modulefile to a certain directory. Below is an example of a "do nothing" modulefile in the group Sandbox.

    -
    -
    -
    Example: /opt/psi/Sandbox/modulefiles/null/1.0.0
    -
    -
    #%Pmodule
-
-module-whatis           "does absolutely nothing"
-module-maintainer       "Achim Gsell <achim.gsell@psi.ch>"
-module-license          "MIT"
-
-module-help     "
-This is a do nothing module.
-"
    -
    -
    -
    -

    In addition to the modulefile a corresponding configuration file - defining for example the release stage - should be installed in the same directory as the modulefile. See next section for a detailed documentation of configuration files.

    -
    -
    -
    Example: configuration file /opt/psi/Sandbox/modulefiles/null/.release-1.0.0 for the null/1.0.0 module
    -
    -
    stable
    -
    -
    -
    -

    Modulefiles are written in the Tool Command Language (Tcl). See section [modulefiles] for a detailed documentation. In Pmodules version 1.1.16 and newer modulefiles written in Lua are also supported but with some limitations.

    -
    -
    -

    The above example doesn’t provide any software. In the following example we show a simple 'HelloWorld' module with a 'Hello, world!' program.

    -
    -
    -
    Example: modulefile /opt/psi/Sandbox/modulefiles/HelloWorld/1.0.0:
    -
    -
    #%Pmodule
-
-module-whatis           "'Hello, world!' module"
-module-maintainer       "Achim Gsell <achim.gsell@psi.ch>"
-module-license          "MIT"
-module-url              "http://pmodules.gitpages.psi.ch"
-
-module-help     "
-The module provides a 'Hello, world!' program.
-"
    -
    -
    -
    -
    Example: configuration file /opt/psi/Sandbox/modulefiles/HelloWorld/.release-1.0.0 for the HelloWorld/1.0.0 module
    -
    -
    unstable
    -
    -
    -
    -
    Example: /opt/psi/Sandbox/HelloWorld/1.0.0/bin/hello:
    -
    -
    #!/usr/bin/env python3
-
-print("Hello, world!")
    -
    -
    -
    -

    In principal, it is possible to install modules 'by hand' by installing the software, module- and configuration files at the right place. For reproducibility, documentation and re-usability it is highly recommended to write build-recipes for each module or - at least - a README and host everything on a PSI Gitlab server.

    -
    -
    -

    Overall the main cases for building modules are:

    -
    -
    -
      -
    • -

      Building a module from source. This is the most common case. Examples: git, -gnuplot, openmpi, hdf5, …​
      -In this case it is highly recommended to code each step - usually download, configure, compile and install - in a script, write a modulefile and a configuration file.

      -
      • -
    • -

      Building a module with a binary package. Examples: Intel compiler, Matlab, -ANSYS, Mathematica, …​
      -In this case best practice is to install the package by hand and write a "dummy" build script, a modulefile and a configuration file. If it is possible and simple to script the installation, code this in the build script. If you cannot easily script the installation, document each step in a README file.

      -
      • -
    -
    -
    - - - - - -
    - - -
    -

    In any case: keep everything in a Git repository on either gitlab.psi.ch or git.psi.ch. -The Git repository for the groups Tool, Programming, Compiler, HDF5, HDF_serial and System is Pmodules/buildblock. Other groups can be hosted anywhere. But to keep everything together a project in Pmodules might be a good choice.

    -
    -
    -
    -
    -

    Many modules for the Pmodules environment have to be build from -source. The building plan of a module is coded in a so called -build-block. A build-block consists at least of a build-script with instruction how to download, compile and install a dedicated piece of -software, a modulefile and a configuration file.

    -
    -
    -

    To avoid problems with dependencies to system libraries or installed software it is best practice to build modules on dedicated systems. At PSI:

    -
    -
    -
      -
    • -

      For modules which should be able to run on all RHEL7 and newer systems, use the system pmod7.psi.ch. If you need access to the system please contact achim.gsell@psi.ch.

      -
      • -
    • -

      Merlin6 specific modules - like openmpi, mpich and modules depending on them - must be compiled on a Merlin6 login node.

      -
      • -
    • -

      Modules specific for a beamline should be compiled on a Ra login node with RHEL8 or a dedicated RHEL8 beamline system.

      -
      • -
    -
    -
    - - - - - -
    - - -
    -

    If you build a module on RHEL7, it might not run on RHEL8 due to newer versions of system libraries. In must cases this can be solved by installing these system libraries in the module itself and setting the RPATH. The recommended path in this case is $PREFIX/lib/system whereby $PREFIX is the installation prefix of the software.

    -
    -
    -
    -
    -

    In the next section we describe how to write build recipes.

    -
    -
    -
    -

    4.2. Predefined variables

    -
    -

    Since we use BASH for our build-scripts and Tcl for modulefiles, we use BASH/Tcl syntax for variables in this documentation. So, if VARIABLE is the name of a variable, $VARIABLE the value of it.

    -
    -
    -

    In modulefiles and build-scripts the following variables are predefined:

    -
    -
    -
    -
    P
    -
    -

    the name of the module

    -
    -
    V
    -
    -

    the module version. The version number consists of a major- and a minor version number, a patch-level and a release number. All numbers but the major version number are optional. Major-, minor number and patch-level are separated by dots, the release number by a minus. Example: 1.0.3-2

    -
    -
    V_MAJOR
    -
    -

    the major version number. Example: 1

    -
    -
    V_MINOR
    -
    -

    the minor version number. Example: 0

    -
    -
    V_PATCHLVL
    -
    -

    the patch-level. Example: 3

    -
    -
    V_RELEASE
    -
    -

    the release number. Example: 2

    -
    -
    V_PKG
    -
    -

    version number without release.

    -
    -
    GROUP
    -
    -

    group the module is in.

    -
    -
    PREFIX
    -
    -

    installation prefix of the module.

    -
    -
    PMODULES_ROOT
    -
    -

    root of Pmodules installation. At PSI this is /opt/psi.

    -
    -
    -
    -
    -

    In build-scripts the following variables are predefined too:

    -
    -
    -
    -
    TEMP_DIR
    -
    -

    directory for temporary files.

    -
    -
    SRC_DIR
    -
    -

    directory of unpacked sources, set to $PMODULES_TMPDIR/$P-$V/src

    -
    -
    BUILD_DIR
    -
    -

    build directory, set to $PMODULES_TMPDIR/$P-$V/build

    -
    -
    BUILDBLOCK_DIR
    -
    -

    Directory where the build-script is in.

    -
    -
    BUILD_SCRIPT
    -
    -

    Name of the build script.

    -
    -
    SYSTEM,OS
    -
    -

    Can be set with the --system option. The value defaults to the string returned by uname -s. The use of OS is obsolete.

    -
    -
    -
    -
    -

    In modulefiles the following variables are predefined too:

    -
    -
    -
    -
    name
    -
    -

    Same as P (obsolete, for historical reasons).

    -
    -
    version
    -
    -

    Same as V (obsolete, for historical reasons).

    -
    -
    group
    -
    -

    The group the module is member of.

    -
    -
    -
    -
    -
    -

    4.3. Building a Pmodule

    -
    -

    To simplify the building of modules, Pmodules has a simple build system. The build system of Pmodules is far less powerful than the build system of Spack or NixOS, but fulfills its purpose for many modules.

    -
    -
    -

    Perform the following steps for a new Pmodule:

    -
    -
    -
      -
    1. -

      Create a directory with the name of the module.

      -
      2. -
    2. -

      Write the configuration file. See section Writing build configuration files.

      -
      3. -
    3. -

      Write the modulefile. See section Writing modulefiles.

      -
      4. -
    4. -

      Code all required steps to install a software in a script. If it is not possible to script everything, code as much as possible and document additional steps in a README file. See section Writing build scripts.

      -
      5. -
    -
    -
    -

    The first - and sometimes also to most challenging - step in building a Pmodule from source is to learn how to download, configure, compile and install a software package and dependencies the package has. The next steps are writing a configuration file, a modulefile and a script to download, configure, compile and install it.

    -
    -
    -

    In general the following steps needs to be performed:

    -
    -
    -
    -
    prepare
    -
    -

    Download, unpack, apply patches (optional). Downloading the software might not be scriptable due to password protection or other measurements.

    -
    -
    configure
    -
    -

    (only for software distributed as source code) This step heavily depends on the software itself. In many cases autotools or CMake is used, in some cases you have to deal with Makefiles or other tools.

    -
    -
    build
    -
    -

    (only for software distributed as source code) compile/build everything

    -
    -
    install
    -
    -

    Install everything in the target directory. In case of a binary package this might not be scriptable.

    -
    -
    -
    -
    -

    4.3.1. Writing a build configuration file

    -
    - - - - - -
    - - -
    -

    In Pmodules 1.1.22 and newer support for the old ("legacy") -configuration files has been dropped. In the appendix you find the -documentation of tje legacy configuration files for Pmodules 1.0

    -
    -
    -
    -
    -
    -

    4.3.2. The build configuration file

    -
    -

    The build configuration file is written in the YAML format. In the file -most information required to build a module is defined. This includes

    -
    -
    -
      -
    • -

      which versions to build

      -
      • -
    • -

      dependencies to build and run the software in the module

      -
      • -
    • -

      where to download the software

      -
      • -
    • -

      options/arguments how to configure the software for compilation

      -
      • -
    • -

      sub-packages which have to be build and installed in the module -(like git-lfs in the Git module)

      -
      • -
    • -

      the release stage

      -
      • -
    • -

      …​

      -
      • -
    -
    -
    -

    The default path to the configuration file is

    -
    -
    -

    build-recipe-dir/files/config.yaml

    -
    -
    -

    This can be overwritten with the command line option --config-file.

    -
    -
    -
    -

    4.3.3. Format

    -
    -

    The general format of the YAML configuration file is:

    -
    -
    -
    -
    format: 1                              (1)
-name-1:
-  type: module | sub_package           (2)
-  defaults:                            (3)
-    config-block
-  shasums:                             (4)
-    filename-1: sha256sum-1
-    ...
-  versions:
-    version-key-1:
-      config:                          (5)
-        config-block
-      variants:                        (6)
-        - config-block-1
-        - ...
-    ...
-name-N:
-  ...
    -
    -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - -
    1For now the format must be set to 1.
    2Required if type is sub_package.
    3Optional.
    4Optional, but highly recommended!
    5Optional, but then defaults have to be set.
    6Required if there is more than one variant.
    -
    -
    -

    The top-level format of the configuration file is pretty simple:

    -
    -
    -
    -
    format: 1
-name-1:
-  config for module 1
-name-2:
-  config for module 2
-...
-name-N:
-  config for module N
    -
    -
    - ---- - - - - - - - - - - - - - - - - -
    Field-NameDescription
    -
    -
    format: 1
-name_i:
-  configuration_i
    -
    -
    -

    Format version of the YAML configuration file. For now it must be 1

    -
    -
    -
    format: 1
-name_i:
-  configuration_i
    -
    -
    -

    Configuration for the Pmodule name-i. It is good practice to - have one configuration file per module.
    - Example: openmpi

    -
    -
    -

    On the second level of the YAML configuration file is the per module -configuration with the following keys:

    -
    -
    -
    -
      type: module | sub_package
-  defaults:
-    config-block
-  shasums:
-    filename-1: sha256sum-1
-    ...
-  versions:
-    map with configurations for different versions
    -
    -
    - ---- - - - - - - - - - - - - - - - - - - - - - - - - -
    Field-NameDescription
    -
    -
      type: module|sub_package
-  defaults:
-    default_config
-  shasums:
-    SHA256 sums
-  versions:
-    ...
    -
    -
    -

    Type of configuration, either module or sub_package.
    - Optional if type is module.

    -
    -
    -
      type: module|sub_package
-  defaults:
-    default_config
-  shasums:
-    SHA256 sums
-  versions:
-    ...
    -
    -
    -

    Default configuration.
    - Optional, but useful to define defaults for the release stage, download URL etc.

    -
    -
    -
      type: module|sub_package
-  defaults:
-    default_config
-  shasums:
-    SHA256 sums
-  versions:
-    ...
    -
    -
    -

    SHA256 hash sums of source files. Keys are filenames, the value the
    - corresponding SHA256 hash sum. This block is optional. A warning is - printed if a hash-sum is missing for a required file.
    - Optional, but highly recommended!

    -
    -
    -
      type: module|sub_package
-  defaults:
-    default_config
-  shasums:
-    SHA256 sums
-  versions:
-    ...
    -
    -
    -

    Configurations for different versions. See table Table 3 - documentation.

    -
    -
    -

    TBW

    -
    - - ---- - - - - - - - - - - - - - - - - - - - - -
    Table 3 YAML structure to define and configure versions
    Field-NameDescription
    -
    -
    versions:
-   version_i:
-    config:
-      config for version i
-    variants:
-      - config for first variant
-      ...
-      - config for last variant
    -
    -
    -

    Configurations for this version keys - A version key is a semicolon separated string of version - numbers. Version numbers can be specified with shell brace - expansion. Example:
    - 5.4.{0,1,2,3,4,5,8,9};5.2.{0,4,6,7,8};5.0.0;4.6.3

    -
    -
    -
    versions:
-  version_i:
-    config:
-      config for version i
-    variants:
-      - config for first variant
-      ...
-      - config for last variant
    -
    -
    -

    Optional, version specific configuration block. Configurations - specified here are overriding the defaults.
    - Optional.

    -
    -
    -
    versions:
-  version_i:
-    config:
-      config for version i
-    variants:
-      - config for first variant
-      ...
-      - config for last variant
    -
    -
    -

    Variants can be used to compile the some software with different - options. Example: openmpi` with and without Slurm support are - variants of the same software.
    - Optional.

    -
    -
    -
    -

    4.3.4. Configuration blocks

    -
    - - - - - -
    - - -
    -

    In configuration blocks everything is optional!

    -
    -
    -
    -
    -
    config-block
    -
    -
    build_requires: [build-req-1, ...]
-compile_in_sourcetree: bool
-configure_with: auto|autotools|cmake
-default_variant: variant
-docfiles: [file-1, ...]
-group: group
-group_deps:
-  compilers:
-    cpmpiler-1: [version-1, ...]
-  mpi:
-    mpi-implemation-1: [version-1, ...]
-  hdf5:
-    hdf5: [version-1, ...]
-  hdf5_serial:
-    hdf5[_serial]: [_version-1, ...]
-overlay: overlay
-relstage: release-stage
-runtime_deps: [rt-dep-1, ...]
-suffix: suffix
-systems: [system-1, ...]
-urls:
-  - url: link
-    name: filename
-  - ...
-variant: [variant-1, ...]
    -
    -
    - ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Field-NameTypeDescription

    build_requires

    sequence of string

    -

    Modules required to build this module

    -
    -
    -
    Example
    -
    -
    build_requires:
-  - pmix/5.0.3
-  - hwloc/2.11.1
-  - patchelf/0.14.5
    -
    -

    build_functions

    map

    -

    Functions to build the module. The functions must be defined either in the build script or available. The following keys are allowed:

    -
    -
    -
    -
    prep, configure, comile, install
    -
    -

    sequence of function for each target.

    -
    -
    Default
    -
    -
    prep:
-  - pbuild::pre_prep
-  - pbuild::prep
-  - pbuild::post_prep
-configure:
-  - pbuild::pre_configure
-  - pbuild::configure
-  - pbuild::post_configure
-compile:
-  - pbuild::pre_compile
-  - pbuild::compile
-  - pbuild::post_compile
-install:
-  - pbuild::pre_install
-  - pbuild::install
-  - pbuild::post_install
    -
    -
    -
    -
    -
    -
    -
    Example
    -
    -
    build_functions:
-  install:
-    - pbuild::post_install
-    - post_install_no_slurm
    -
    -

    build_variants

    sequence of strings

    compile_in_sourcetree

    boolean

    -

    Compile in source tree or in a dedicate build directory. The default is false.

    -
    -
    -
    Example
    -
    -
    compile_in_sourcetree: true
    -
    -

    configure_with

    string

    -

    Choose software configuration system. Allowed values are:
    - auto: use autotools if available
    - autotools: use autotools
    - cmake: use cmake
    - Using this key is only required if both configuration systems are supported by the software and you don’t want to use the default (i.e. autotools).

    -
    -
    -
    Example
    -
    -
    configure_with: cmake
    -
    -

    configure_args
    - configure_args+

    sequence of strings

    docfiles
    - docfiles+

    sequence of string

    -

    Array with documentation files to be installed in share/doc/

    -
    -
    -
    Example
    -
    -
    docfiles:
-  - AUtHORS
-  - LICENSE
-  - NEWS
-  - README
    -
    -

    download_dir

    string

    group

    string

    -

    Group of the module

    -

    group_deps

    group-deps-object

    -

    Group/hierarchical dependencies like compiler, MPI, HDF5 modules

    -

    kernels

    string

    overlay

    string

    -

    Overlay of the module

    -

    patch_files
    - patch_files+

    sequence of strings

    relstage

    string

    -

    Release stage of the module. Allowed values are:
    -unstable: the module is still under development
    -stable: the module is ready to be used
    -deprecated: the module is deprecated
    -remove: the module is deprecated and marked to be removed
    -removed: the module has been removed

    -

    runtime_deps

    sequence of strings

    -

    Module to be loaded at runtime

    -

    suffix

    string

    -

    This string will be added to the version of the module

    -

    systems

    sequence of strings

    -

    A 'system' is either a hostname or OS name like rhel8. For
    - hostnames shell glob pattern matching like merlin-* can be used.

    -

    sub_packages

    map

    target_cpus

    urls

    sequence of links and optional file-names

    -

    Software which must be downloaded to build a specific module.
    - url: Download link
    - name: optional output filename. The filename defaults the last - component of the url.
    - Default URLs can be defined by using the variables P, V, - V_PKG, V_MAJOR, V_MINOR and V_PATCHLVL. Example:
    - https://sourceforge.net/projects/gnuplot/files/$P/$V/$P-${V_PKG}.tar.gz

    -

    use_flags

    sequence of strings

    use_overlays

    sequence of strings

    -
    -
    -

    4.3.5. Examples

    -
    -
    Example: Gnuplot
    -
    -
    format: 1
-gnuplot:
-  defaults:                                             (1)
-    group: Tools                                        (2)
-    overlay: base                                       (3)
-    relstage: stable                                    (4)
-    systems: [rhel8, rhel7, rhel6]                      (5)
-    docfiles: [Copyright, NEWS, README]                 (6)
-    urls:                                               (7)
-      - url: https://sourceforge.net/projects/gnuplot/files/$P/$V/$P-${V_PKG}.tar.gz
-  shasums:                                              (8)
-    gnuplot-5.4.10.tar.gz: 975d8c1cc2c41c7cedc4e323aff035d977feb9a97f0296dd2a8a66d197a5b27c
-    gnuplot-5.4.9.tar.gz: a328a021f53dc05459be6066020e9a71e8eab6255d3381e22696120d465c6a97
-    gnuplot-5.4.8.tar.gz: 931279c7caad1aff7d46cb4766f1ff41c26d9be9daf0bcf0c79deeee3d91f5cf
-    gnuplot-5.4.5.tar.gz: 66f679115dd30559e110498fc94d926949d4d370b4999a042e724b8e910ee478
-    gnuplot-5.4.4.tar.gz: 372300b7867f5b3538b25fc5d0ac7734af6e3fe0d202b6db926e4369913f0902
-    gnuplot-5.4.3.tar.gz: 51f89bbab90f96d3543f95235368d188eb1e26eda296912256abcd3535bd4d84
-    gnuplot-5.4.2.tar.gz: e57c75e1318133951d32a83bcdc4aff17fed28722c4e71f2305cfc2ae1cae7ba
-    gnuplot-5.4.1.tar.gz: 6b690485567eaeb938c26936e5e0681cf70c856d273cc2c45fabf64d8bc6590e
-    gnuplot-5.4.0.tar.gz: eb4082f03a399fd1e9e2b380cf7a4f785e77023d8dcc7e17570c1b5570a49c47
-    gnuplot-5.2.8.tar.gz: 60a6764ccf404a1668c140f11cc1f699290ab70daa1151bb58fed6139a28ac37
-    gnuplot-5.2.7.tar.gz: 97fe503ff3b2e356fe2ae32203fc7fd2cf9cef1f46b60fe46dc501a228b9f4ed
-    gnuplot-5.2.6.tar.gz: 35dd8f013139e31b3028fac280ee12d4b1346d9bb5c501586d1b5a04ae7a94ee
-    gnuplot-5.2.4.tar.gz: 1515f000bd373aaa53b16183f274189d4f5e0ae47d22f434857933d16a4770cb
-    gnuplot-5.0.0.tar.gz: 417d4bc5bc914a60409bb75cf18dd14f48b07f53c6ad3c4a4d3cd9a8d7370faf
-    gnuplot-4.6.3.tar.gz: df5ffafa25fb32b3ecc0206a520f6bca8680e6dcc961efd30df34c0a1b7ea7f5
-  versions:
-    5.4.{0,1,2,3,4,5,8,9};5.2.{0,4,6,7,8};5.0.0;4.6.3:  (9)
-    5.4.10:                                             (10)
-      config:
-        relstage: unstable
    -
    -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    1Configuration is for gnuplot
    2will be installed in the group Tools
    3will be installed in the base overlay (/opt/psi)
    4the default release stage is stable
    5the module is available on these systems
    6install these files to $PREFIX/share/doc/gnuplot
    7download via this link
    8SHA256 hash sums for all available versions
    9no specific configuration required for these versions
    10release stage of version 5.4.10 is still unstable, override -default release stage. ----
    -
    -
    -
    Example: HDF5
    -
    -
    ---
-# yamllint disable rule:line-length             (1)
-format: 1
-hdf5:                                           (2)
-  defaults:
-    group: MPI                                  (3)
-    overlay: base                               (4)
-    relstage: stable                            (5)
-    systems: [rhel7, rhel8, rhel9]              (6)
-    urls:                                       (7)
-      - url: https://support.hdfgroup.org/ftp/HDF5/releases/$P-${V_MAJOR}.${V_MINOR}/$P-${V_PKG}/src/$P-${V_PKG}.tar.bz2
-  shasums:                                      (8)
-    hdf5-1.8.10-patch1.tar.bz2: 292afb3615ad9e68f4d5d18ebb11e4a73f2aece39f2da3875a457ff1e109fc41
-    hdf5-1.8.12.tar.bz2: 10a369a4fc207bb09245f57c758e587420e06dfc0e445e337a58b0848b75a949
-    ...
-    hdf5-1.13.1.tar.bz2: e16973ec893e2d5aa9c8dc73e196db9b99a605578e7317b421c713936f8bf57d
-
-  versions:
-    1.8.12:
-      config:
-        relstage: deprecated                    (9)
-      variants:
-        -
-          group_deps:
-            compiler: {gcc: [4.7.4, 4.8.3, 4.8.4, 4.9.2]}
-            mpi: {openmpi: [1.6.5, 1.8.2, 1.8.4]}
-        -
-          group_deps:
-            compiler: {gcc: [4.8.2]}
-            mpi: {openmpi: [1.6.5]}
-        ...
-        -
-          group_deps:
-            compiler: {gcc: [5.1.0], intel: [15.2, 15.3]}
-            mpi: {openmpi: [1.8.4]}
-    ...
-    1.10.8_slurm:
-      variants:                                (10)
-        -
-          group_deps:
-            compiler: {gcc: [10.4.0]}
-            mpi: {openmpi: [4.1.4_slurm]}
-        -
-          relstage: unstable
-          group_deps:
-            compiler: {gcc: [9.5.0, 10.4.0, 11.4.0, 12.3.0, 13.1.0]}
-            mpi: {openmpi: [4.1.5_slurm]}
-    ...
-    1.12.0:
-      variants:
-        -
-          group_deps:
-            compiler: {gcc: [7.5.0, 8.4.0, 9.3.0, 10.2.0]}
-            mpi: {openmpi: [4.0.5]}
-        -
-          relstage: unstable
-          group_deps:
-            compiler: {pgi: [21.5]}
-            mpi: {pgi-mpi: [21.5]}
-
-    1.13.1:
-      variants:
-        -
-          suffix: _slurm                        (11)
-          variant: [_slurm]
-          relstage: unstable
-          group_deps:
-            compiler: {gcc: [11.2.0]}
-            mpi: {openmpi: [4.1.3_slurm]}
    -
    -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    1disable rule to check line length in yamllint. Default is 80.
    2this configuration is for HDF5
    3default group is MPI.
    4default overlay is base
    5default release stage is stable
    6this build-block can be used on RHEL7, RHEL8 and RHEL9
    7download via this link
    8SHA256 hash sums for all available versions
    9all variants of version 1.8.12 are deprecated
    10hdf5/1.10.8_slurm has two variants. The first variant compiled with GCC 10.4.0 and openmpi/4.1.4_slurm. The second variant is unstable and compiled with with GCC 9.5.0, 10.4.0, 11.4.0, 12.3.0, 13.1.0 and openmpi/4.1.5_slurm.
    11TBW
    -
    -
    -
    -
    -
    -

    4.4. Writing modulefiles

    -
    -

    4.4.1. modulefiles

    -
    -
    4.4.1.1. NAME
    -
    -

    modulefile - files containing Tcl code for the Modules package

    -
    -
    -
    -
    4.4.1.2. DESCRIPTION
    -
    -

    modulefiles are written in the Tool Command Language, Tcl(n) and are -interpreted by the modulecmd program via the module(1) user -interface. modulefiles can be loaded, unloaded, or switched on-the-fly -while the user is working; and can be used to implement site policies -regarding the access and use of applications.

    -
    -
    -

    A modulefile begins with the shebang, ‘#%Pmodule’ or -‘#%Module’. The shebang ‘#%Pmodule’ should be used in modulefiles -using the Pmodules extension. A version number may be placed after -this string. The version number is useful as the modulefile format may -change. If a version number doesn’t exist, then modulecmd will assume -the modulefile is compatible with the latest version. The current -modulefile version is 1.0. Files without the magic cookie will not be -interpreted by modulecmd.

    -
    -
    -

    Each modulefile contains the changes to a user’s environment needed to -access an application. Tcl is a simple programming language which -permits modulefiles to be arbitrarily complex, depending upon the -application’s and the modulefile writer’s needs.

    -
    -
    -

    A typical modulefiles is a simple bit of code that set or add entries -to the PATH, MANPATH, or other environment variables. Tcl has -conditional statements that are evaluated when the modulefile is -loaded. This is very effective for managing path or environment -changes due to different OS releases or architectures. The user -environment information is encapsulated into a single modulefile kept -in a central location. The same modulefile is used by every user on -any machine. So, from the user’s perspective, starting an application -is exactly the same irrespective of the machine or platform they are -on.

    -
    -
    -

    modulefiles also hide the notion of different types of shells. From -the user’s perspective, changing the environment for one shell looks -exactly the same as changing the environment for another shell. This -is useful for new or novice users and eliminates the need for -statements such as "if you’re using the C Shell do this …​, otherwise -if you’re using the Bourne shell do this …​". Announcing and -accessing new software is uniform and independent of the user’s -shell. From the modulefile writer’s perspective, this means one set of -information will take care of every type of shell.

    -
    -
    -
    Module specific commands
    -
    -

    The Pmodules Package uses commands which are extensions to the "standard" Tool Command Language Tcl(n) package.

    -
    -
    - - - - - -
    - - -
    -

    The following commands are Pmodules extensions:

    -
    -
    -
      -
    • -

      module-addgroup

      -
      • -
    • -

      module-url

      -
      • -
    • -

      module-license

      -
      • -
    • -

      module-maintainer

      -
      • -
    -
    -
    -
    -
    -

    Unless otherwise specified, the Module commands return the empty string. Some commands behave differently when a modulefile is loaded or unloaded. The command descriptions assume the modulefile is being loaded.

    -
    -
    -
    -
    break
    -
    -

    This is not a Modules-specific command, it’s actually part of Tcl, which has been overloaded similar to the continue and exit commands to have the effect of causing the module not to be listed as loaded and not affect other modules being loaded concurrently. All non-environment commands within the module will be performed up to this point and processing will continue on to the next module on the command line. The break command will only have this effect if not used within a Tcl loop though.

    -
    -

    An example: Suppose that a full selection of modulefiles are needed for various different architectures, but some of the modulefiles are not needed and the user should be alerted. Having the unnecessary modulefile be a link to the following notavail modulefile will perform the task as required.

    -
    -
    -
    -
    #%Module1.0
-## notavail modulefile
-##
-proc ModulesHelp { } {
-            puts stderr "This module does nothing but alert the user"
-            puts stderr "that the [module-info name] module is not available"
-}
-
-module-whatis "Notifies user that module is not available."
-set curMod [module-info name]
-if { [ module-info mode load ] } {
-            puts stderr "Note: '$curMod' is not available for [uname sysname]."
-}
-break
    -
    -
    -
    -
    chdir directory
    -
    -

    Set the current working directory to directory.

    -
    -
    continue
    -
    -

    This is not a modules specific command but another overloaded Tcl command and is similar to the break or exit commands except the module will be listed as loaded as well as performing any environment or Tcl commands up to this point and then continuing on to the next module on the command line. The continue command will only have this effect if not used within a Tcl loop though.

    -
    -
    exit [N]
    -
    -

    This is not a modules specific command but another overloaded Tcl command and is similar to the break or continue commands. However, this command will cause the immediate cessation of this module and any additional ones on the command line. This module and the subsequent modules will not be listed as loaded. No environment commands will be performed in the current module.

    -
    -
    setenv variable value
    -
    -

    Set environment variable to value. The setenv command will also change the process' environment. A reference using Tcl’s env associative array will reference changes made with the setenv command. Changes made using Tcl’s env associative array will NOT change the user’s environment variable like the setenv command. An environment change made this way will only affect the module parsing process. The setenv command is also useful for changing the environment prior to the exec or system command. When a modulefile is unloaded, setenv becomes unsetenv. If the environment variable had been defined it will be overwritten while loading the modulefile. A subsequent unload will unset the environment variable - the previous value cannot be restored! (Unless you handle it explicitly …​ see below.)

    -
    -
    unsetenv variable [value]
    -
    -

    Unsets environment variable. However, if there is an optional value, then when unloading a module, it will set variable to value. The unsetenv command changes the process' environment like setenv.

    -
    -
    append-path|prepend-path [-d C|--delim C|--delim=C] variable value
    -
    -

    Append or prepend value to environment variable. The variable is a colon, or delimiter, separated list such as PATH=directory:directory:directory. The default delimiter is a colon ':', but an arbitrary one can be given by the --delim option. For example a space can be used instead (which will need to be handled in the Tcl specially by enclosing it in " " or { }). A space, however, can not be specified by the --delim=C form.

    -
    -

    If the variable is not set, it is created. When a modulefile is unloaded, append-path and prepend-path become remove-path.

    -
    -
    -
    remove-path [-d C|--delim C|--delim=C] variable value
    -
    -

    Remove value from the colon, or delimiter, separated list in variable. See prepend-path or append-path for further explanation of using an arbitrary delimiter. Every string between colons, or delimiters, in variable is compared to value. If the two match, value is removed from variable.

    -
    -
    prereq|conflict modulefile…​
    -
    -

    prereq and conflict control whether or not the modulefile will be loaded. The prereq command lists modulefiles which must have been previously loaded before the current modulefile will be loaded. Similarly, the conflict command lists modulefiles which conflict with the current modulefile. If a list contains more than one modulefile, then each member of the list acts as a Boolean OR operation. Multiple prereq and conflict commands may be used to create a Boolean AND operation. If one of the requirements have not been satisfied, an error is reported and the current modulefile makes no changes to the user’s environment.

    -
    -
    -
    -
    -

    If an argument for prereq is a directory and any modulefile from the directory has been loaded, then the prerequisite is met. For example, specifying X11 as a prereq means that any version of X11, X11/R4 or X11/R5, must be loaded before proceeding.

    -
    -
    -

    If an argument for conflict is a directory and any other modulefile from that directory has been loaded, then a conflict will occur. For example, specifying X11 as a conflict will stop X11/R4 and X11/R5 from being loaded at the same time.

    -
    -
    -
    -
    is-loaded modulefile…​
    -
    -

    The is-loaded command returns a true value if any of the listed modulefiles has been loaded. If a list contains more than one modulefile, then each member acts as a boolean OR operation. If an argument for is-loaded is a directory and any modulefile from the directory has been loaded is-loaded would return a true value.

    -
    -
    module [sub-command] [sub-command-args]
    -
    -

    Contains the same sub-commands as described in the module(1) man page in the Module Sub-Commands section. This command permits a modulefile to load or unload other modulefiles. No checks are made to ensure that the modulefile does not try to load itself. Often it is useful to have a single modulefile that performs a number of module load commands. For example, if every user on the system requires a basic set of applications loaded, then a core modulefile would contain the necessary -module load commands.

    -
    -
    module-info mode [modetype]
    -
    -

    Returns the current modulecmd’s mode as a string if no modetype is given.

    -
    -

    Returns 1 if modulecmd’s mode is modetype. modetype can be: load, unload, remove, switch, display, help, test or whatis.

    -
    -
    -
    module-info name
    -
    -

    Return the name of the modulefile. This is not the full pathname for modulefile. See the Modules Variables section for information on the full pathname.

    -
    -
    module-info specified
    -
    -

    Return the name of the modulefile specified on the command line.

    -
    -
    module-info shell [shellname]
    -
    -

    Return the current shell under which modulecmd.tcl was invoked if no shellname is given. The current shell is the first parameter of modulecmd.tcl, which is normally hidden by the module alias.

    -
    -

    If a shellname is given, returns 1 if modulecmd.tcl’s current shell is shellname, returns 0 elsewhere. shellname can be: sh, bash, ksh, zsh, csh, tcsh, fish, tcl, perl, python, ruby, lisp, cmake, r.

    -
    -
    -
    module-info shelltype [shelltypename]
    -
    -

    Return the family of the shell under which modulefile was invoked if no shelltypename is given. As of module-info shell this depends on the first parameter of modulecmd.tcl. The output reflects a shell type determining the shell syntax of the commands produced by modulecmd.tcl.

    -
    -

    If a shelltypename is given, returns 1 if modulecmd.tcl’s current shell type is shelltypename, returns 0 elsewhere. shelltypename can be: sh, csh, fish, tcl, perl, python, ruby, lisp, cmake, r.

    -
    -
    -
    module-info alias name
    -
    -

    Returns the full modulefile name to which the modulefile alias name is assigned

    -
    -
    module-info version modulefile
    -
    -

    Returns the physical module name and version of the passed symbolic version modulefile. The parameter modulefile might either be a full qualified modulefile with name and version, another symbolic modulefile name or a modulefile alias.

    -
    -
    module-info symbols modulefile
    -
    -

    Returns a list of all symbolic versions assigned to the passed modulefile. The parameter modulefile might either be a full qualified modulefile with name and version, another symbolic modulefile name or a modulefile alias.

    -
    -
    module-version modulefile version-name…​
    -
    -

    Assigns the symbolic version-name to the modulefile. This command should be placed in one of the modulecmd.tcl rc files in order to provide shorthand invocations of frequently used modulefile names.

    -
    -

    The special version-name default specifies the default version to be used for module commands, if no specific version is given. This replaces the definitions made in the .version file in former modulecmd releases.

    -
    -
    -

    The parameter modulefile may be either -* a fully or partially qualified modulefile with name / version. If name is '.' then the current directory name is assumed to be the module name. (Use this for deep modulefile directories.) -* a symbolic modulefile name -* another modulefile alias

    -
    -
    -
    module-alias name modulefile
    -
    -

    Assigns the modulefile to the alias name. This command should be placed in one of the modulecmd rc files in order to provide shorthand invocations of frequently used modulefile names.

    -
    -

    The parameter modulefile may be either

    -
    -
    -
      -
    • -

      a fully qualified modulefile with name and version

      -
      • -
    • -

      a symbolic modulefile name

      -
      • -
    • -

      another modulefile alias

      -
      • -
    -
    -
    -
    module-whatis string
    -
    -

    Defines a string which is displayed in case of the invocation of the module whatis command. There may be more than one module-whatis line in a modulefile. This command takes no actions in case of load, display, etc. invocations of modulecmd.

    -
    -

    The string parameter has to be enclosed in double-quotes if there’s more than one word specified. Words are defined to be separated by white-space characters (space, tab, cr).

    -
    -
    -
    module-url url
    -
    -

    Sets an URL which is displayed in case of the invocation of the module help command. The URL should point to the home-page of the software loaded by the module if any.

    -
    -
    module-license string
    -
    -

    Defines a string which is displayed in case of the invocation of the module help command. The string should either be the name of a well known license (like GPL V2) or a filename with the license text installed in the module.

    -
    -
    module-maintainer email
    -
    -

    Defines a string which is displayed in case of the invocation of the module help command. The -string should be the email address of the module maintainer.

    -
    -
    module-addgroup group
    -
    -

    Add the hierarchical group group to MODULEPATH.

    -
    -
    set-alias alias-name alias-string
    -
    -

    Sets an alias or function with the name alias-name in the user’s environment to the string alias-string. For some shells, aliases are not possible and the command has no effect. When a modulefile is unloaded, set-alias becomes unset-alias.

    -
    -
    unset-alias alias-name
    -
    -

    Unsets an alias with the name alias-name in the user’s environment.

    -
    -
    system string
    -
    -

    Pass string to the Tcl built-in command exec(n). For the exec(n) call modulecmd redirects stdout to stderr since stdout would be parsed by the evaluating shell. The exit status of the executed command is returned.

    -
    -
    uname field
    -
    -

    Provide lookup of system information. Most field information are retrieved from the tcl_platform array (see tclvars(n) man page). Uname will return the string "unknown" if information is unavailable for the field.

    -
    -

    uname will invoke uname(1) command in order to get the operating system version and domainname(1) to figure out the name of the domain.

    -
    -
    -

    field values are: -* sysname: the operating system name -* nodename: the hostname -* domain: the name of the domain -* release: the operating system release -* version: the operating system version -* machine: a standard name that identifies the system’s hardware

    -
    -
    -
    x-resource [resource-string|filename]
    -
    -

    Merge resources into the X11 resource database. The resources are used to control look and behavior of X11 applications. The command will attempt to read resources from filename. If the argument isn’t a valid file name, then string will be interpreted as a resource. Either filename or resource-string is then passed down to be xrdb(1) command.

    -
    -

    modulefiles that use this command, should in most cases contain one or more x-resource lines, each defining one X11 resource. The DISPLAY environment variable should be properly set and the X11 server should be accessible. If x-resource can’t manipulate the X11 resource database, the modulefile will exit with an error message.

    -
    -
    -

    Examples:

    -
    -
    -
    -
    -
    -
    -
    x-resource /u2/staff/leif/.xres/Ileaf
    -
    -
    -
    -

    The content of the Ileaf file is merged into the X11 resource database.

    -
    -
    -
    -
    x-resource [glob ~/.xres/ileaf]
    -
    -
    -
    -

    The Tcl glob function is used to have the modulefile read different resource files for different users.

    -
    -
    -
    -
    x-resource {Ileaf.popup.saveUnder: True}
    -
    -
    -
    -

    Merge the Ileaf resource into the X11 resource database.

    -
    -
    -
    -
    Modules Variables
    -
    -

    The ModulesCurrentModulefile variable contains the full pathname of the modulefile being interpreted.

    -
    -
    -
    -
    Locating Modulefiles
    -
    -

    Every directory in MODULEPATH is searched to find the modulefile. A directory in MODULEPATH can have an arbitrary number of sub-directories. If the user names a modulefile to be loaded which is actually a directory, the directory is opened and a search begins for an actual modulefile. First, modulecmd looks for a file with the name .modulerc in the directory. If this file exists, its contents will be evaluated as if it was a modulefile to be loaded. You may place module-version and module-alias commands inside this file.

    -
    -
    -

    Additionally, before seeking for .modulerc files in the module directory, the global modulerc file is sourced, too. If a named version default now exists for the modulefile to be loaded, the assigned modulefile now will be sourced. Otherwise the file .version is looked up in the directory.

    -
    -
    -

    If the .version file exists, it is opened and interpreted as Tcl code and takes precedence over a .modulerc file in the same directory. If the Tcl variable ModulesVersion is set by the .version file, modulecmd will use the name as if it specifies a modulefile in the directory. This will become the default modulefile in this case.

    -
    -
    -

    If ModulesVersion is a directory, the search begins anew down that directory. If the name does not match any files located in the current directory, the search continues through the remaining directories in MODULEPATH.

    -
    -
    -

    Every .version and .modulerc file found is Tcl interpreted. The difference is that .version only applies to the current directory, and the .modulerc applies to the current directory and all subdirectories. Changes made in these files will affect the subsequently interpreted modulefile.

    -
    -
    -

    If no default version may be figured out, then the highest numerically sorted modulefile or module alias under the directory will be used. The dictionary comparison method of the lsort(n) Tcl command is used to achieve this sort. If highest numerically sorted element is an alias, search continues on its modulefile target.

    -
    -
    -

    For example, it is possible for a user to have a directory named X11 which simply contains a .version file specifying which version of X11 is to be loaded. Such a file would look like:

    -
    -
    -
    -
    #%Module1.0
-##
-##  The desired version of X11
-##
-set ModulesVersion "R4"
    -
    -
    -
    -

    The equivalent .modulerc would look like:

    -
    -
    -
    -
    #%Module1.0
-##
-##  The desired version of X11
-##
-module-version "./R4" default
    -
    -
    -
    -

    If user names a modulefile that cannot be found in the first modulepath directory, modulefile will be searched in next modulepath directory and so on until a matching modulefile is found. If search goes through a module alias or a symbolic version, this alias or symbol is resolved by first looking at the modulefiles in the modulepath where this alias or symbol is defined. If not found, resolution looks at the other modulepaths in their definition order.

    -
    -
    -

    When locating modulefiles, if a .modulerc, a .version, a directory or a modulefile cannot be read during the search it is simply ignored with no error message produced. Visibility of modulefiles can thus be adapted to the rights the user has been granted. Exception is made when trying to directly access a directory or a modulefile. In this case, the access issue is returned as an error message.

    -
    -
    -

    A modulefile whose name or element in its name starts with a '.' dot is considered hidden. Hidden modulefile is not displayed or taken into account except if it is explicitly named. By inheritance, a symbolic version-name assigned to a hidden modulefile is displayed or taken into account only if explicitly named. Module alias targeting a hidden modulefile appears like any other module alias.

    -
    -
    -
    -
    Modulefile Specific Help
    -
    -

    Users can request help about a specific modulefile through the module(1) command. The modulefile can print helpful information or start help oriented programs by defining a ModulesHelp subroutine. The subroutine will be called when the module help modulefile command is used.

    -
    -
    -
    -
    Modulefile Specific Test
    -
    -

    Users can request test of a specific modulefile through the module(1) command. The modulefile can perform some sanity checks on its definition or on its underlying programs by defining a ModulesTest subroutine. The subroutine will be called when the module test modulefile command is used. The subroutine should return 1 in case of success. If no or any other value is returned, test is considered failed.

    -
    -
    -
    -
    Modulefile Display
    -
    -

    The module display modulefile command will detail all changes that will be made to the environment. After displaying all of the environment changes modulecmd.tcl will call the ModulesDisplay subroutine. The ModulesDisplay subroutine is a good place to put additional descriptive information about the modulefile.

    -
    -
    -
    -
    -
    4.4.1.3. ENVIRONMENT
    -
    -
    -
    MODULEPATH
    -
    -

    Path of directories containing modulefiles.

    -
    -
    -
    -
    -
    -
    4.4.1.4. SEE ALSO
    -
    -

    module(1), Tcl(n), TclX(n), xrdb(1), exec(n), uname(1), domainname(1), tclvars(n), lsort(n)

    -
    -
    -
    -
    4.4.1.5. NOTES
    -
    -

    Tcl was developed by John Ousterhout at the University of California at Berkeley.

    -
    -
    -

    TclX was developed by Karl Lehenbauer and Mark Diekhans.

    -
    -
    -

    Modules is covered by the GNU General Public License, version 2 and the GNU Lesser General Public License, version 2.1. Copyright © 1996-1999 John L. Furlani & Peter W. Osel, © 1998-2017 R.K.Owen, © 2002-2004 Mark Lakata, © 2004-2017 Kent Mein, © 2016-2017 Xavier Delaruelle. All rights reserved. Trademarks used are the property of their respective owners.

    -
    -
    -
    -
    -
    -
    -

    4.5. Writing build scripts

    -
    -

    Pmodules has it’s own 'interpreter' to run build-scripts written in Bash. The name of the interpreter is modbuild. Thus the first line (the so called 'shebang') of a build-script must be

    -
    -
    -
    -
    #!/usr/bin/env modbuild
    -
    -
    -
    -

    As already mentioned the four steps 'prepare', 'configure', 'build' and 'install' has to be performed to build a Pmodule. These steps maps to the functions:

    -
    -
    -
    -
    prepare
    -
    -

    pbuild::pre_prep()
    -pbuild::prep()
    -pbuild::post_prep()

    -
    -
    configure
    -
    -

    pbuild::pre_configure()
    -pbuild::configure()
    -pbuild::post_configure()

    -
    -
    compile
    -
    -

    pbuild::pre_compile()
    -pbuild::compile()
    -pbuild::post_compile()

    -
    -
    install
    -
    -

    pbuild::pre_install()
    -pbuild::install()
    -pbuild::post_install()

    -
    -
    -
    -
    -

    In many cases you don’t have to implement the the functions pbuild::prep(), pbuild::configure(), pbuild::compile() and pbuild::install() or at least not all of them. The build-system provides default implementations for these functions. In the simplest case, the build script consists only of the shebang line (only for Pmodules >= 1.1). In this case all further information for building the module is in the configuration file. For software that uses autotools or CMake for configuration and creation of Makefiles, the standard functions can practically always be used. The functions pbuild::pre_STEP and pbuild::post_STEP can be used to hook into each step before and after the default function has been called. For example pbuild::pre_configure() can be used to set arguments for autotools or CMake as in the build-script for Gnuplot:

    -
    -
    -
    Example: build script for Gnuplot
    -
    -
    #!/usr/bin/env modbuild
-
-pbuild::pre_configure() {
-        pbuild::add_configure_args '--with-latex=no'
-        pbuild::add_configure_args '--with-qt=no'
-}
    -
    -
    -
    -

    4.5.1. Overloading the default implementations

    -
    -

    If the build-system of the software package isn’t autotools or CMake you have to overload the default implementation of pbuild::configure.

    -
    -
    -
    -
    pbuild::configure(){
-        # add code to configure the software package
-}
    -
    -
    -
    -

    In case where no configuration is required, overload the default function with

    -
    -
    -
    -
    pbuild::configure(){
-        : # do nothing
-}
    -
    -
    -
    -

    You can do the same with the other default implementation.

    -
    -
    -
    -

    4.5.2. Modules from binary packages

    -
    -

    If you have a binary package like Matlab, Mathematica, ANSYS, it might not be possible to script the installation. In this case you should use a dummy build-script like below and document the installation in a README.md:

    -
    -
    -
    -
    #!/usr/bin/env modbuild
-
-pbuild::prep() { :; }
-pbuild::configure() { :; }
-pbuild::compile() { :; }
-pbuild::install() { :; }
    -
    -
    -
    -

    If the installation can be scripted, code this in the function pbuild::install.

    -
    -
    -
    -
    #!/usr/bin/env modbuild
-
-pbuild::prep() { :; }
-pbuild::configure() { :; }
-pbuild::compile() { :; }
-pbuild::install() {
-        # add code to call the installer here
-}
    -
    -
    -
    -
    -

    4.5.3. Calling the build-script

    -
    -

    To call the build-script, cd into the directory of the script and run

    -
    -
    -
    -
    ./build VERSION_TO_BE_BUILD
    -
    -
    -
    -
    Example with output
    -
    -
    pmod7:~/HelloWorld$ ./build 1.0.0
-Using YAML configuration file - /afs/psi.ch/user/g/gsell/HelloWorld/files/config.yaml
-HelloWorld/1.0.0: building ...
-HelloWorld/1.0.0:
-HelloWorld/1.0.0: start building ...
-HelloWorld/1.0.0: preparing sources ...
-HelloWorld/1.0.0: configuring ...
-HelloWorld/1.0.0: compiling ...
-HelloWorld/1.0.0: installing ...
-HelloWorld/1.0.0: running post-installation for Linux ...
-HelloWorld/1.0.0: Installing documentation to /opt/psi/Sandbox/HelloWorld/1.0.0/share/doc/HelloWorld
-HelloWorld/1.0.0: adding modulefile to overlay 'base' ...
-HelloWorld/1.0.0: Cleaning up '/var/tmp/gsell/HelloWorld-1.0.0/build'...
-HelloWorld/1.0.0: Cleaning up '/var/tmp/gsell/HelloWorld-1.0.0/src'...
-HelloWorld/1.0.0: Done ...
-* * * * *
-
-pmod7:~/HelloWorld$
    -
    -
    -
    -

    You can run

    -
    -
    -
    -
    ./build --help
    -
    -
    -
    -

    to get a list of all option with a description. The most common option are

    -
    -
    -
    -
    -f
    -
    -

    to force a rebuild.

    -
    -
    --clean-install
    -
    -

    remove everything in the build directory and the module itself - if already exists - as first step.

    -
    -
    --verbose
    -
    -

    to see more verbose output.

    -
    -
    --debug
    -
    -

    to get a full debug trace.

    -
    -
    -
    -
    -
    -

    4.5.4. Setup functions

    -
    -
    4.5.4.1. Adding patches to be applied: pbuild::add_patch
    -
    -
    Synopsis
    -
    -
    -
    pbuild::add_patch patch_fname [strip_num_dirs]
    -
    -
    -
    -
    -
    Description
    -
    -

    Apply a patch to the unpacked sources. The argument patch_fname must be a relative file-name to the build-block directory. The argument strip_num_dirs is optional and defaults to 1. Please read the patch(1) manual page for more details. The patches are applied inside the source directory with the command:

    -
    -
    -
    -
    patch --strip=strip_num_dirs < "${BUILDBLOCK_DIR}/patch_fname"
    -
    -
    -
    -
    -
    Example
    -
    -
    -
    pbuild::pre_prep(){
-        pbuild::add_patch 'files/Makefile.pncf.sed.patch'
-}
    -
    -
    -
    -
    -
    -
    -
    4.5.4.2. Set configuration options: pbuild::add_configure_args
    -
    -
    Synopsis
    -
    -
    -
    pbuild::add_configure_args arg...
    -
    -
    -
    -
    -
    Description
    -
    -

    Add arguments/options to the call of configure or cmake.

    -
    -
    -
    -
    Example
    -
    -

    autotools:

    -
    -
    -
    -
    pbuild::pre_configure(){
-        pbuild::add_configure_args "--disable-shared"
-        pbuild::add_configure_args "CFLAGS=-fPIC"
-}
    -
    -
    -
    -

    CMake:

    -
    -
    -
    -
    pbuild::pre_configure(){
-        pbuild::add_configure_args "-DMETIS_PATH=${SRC_DIR}/metis"
-        pbuild::add_configure_args "-DGKLIB_PATH=${SRC_DIR}/metis/GKlib"
-}
    -
    -
    -
    -
    -
    -
    -
    -

    4.5.5. Functions to compare versions

    -
    -
    4.5.5.1. Compare two versions: pbuild::version_compare
    -
    -
    Synopsis
    -
    -
    -
    pbuild::version_compare VERSION1 VERSION2
-pbuild::version_lt VERSION1 VERSION2
-pbuild::version_le VERSION1 VERSION2
-pbuild::version_gt VERSION1 VERSION2
-pbuild::version_ge VERSION1 VERSION2
-pbuild::version_eq VERSION1 VERSION2
    -
    -
    -
    -
    -
    Description
    -
    -

    The function splits the version strings at the dots an compares each component. If a component is a number the comparison is numerical otherwise lexical.

    -
    -
    -

    pbuild::version_compare VERSION1 VERSION2 returns
    - 0 if the versions are equal
    - 1 if VERSION1 is higher then VERSION2
    - 2 if VERSION1 is lower then VERSION2

    -
    -
    -

    pbuild::version_lt VERSION1 VERSION2 returns
    -0 if VERSION1 is lower then VERSION2 otherwise a values greater than zero.

    -
    -
    -

    pbuild::version_le VERSION1 VERSION2 returns
    -0 if VERSION1 is lower then or equal to VERSION2 otherwise a values greater than zero.

    -
    -
    -

    pbuild::version_gt VERSION1 VERSION2 returns
    -0 if VERSION1 is higher then VERSION2 otherwise a values greater than zero.

    -
    -
    -

    pbuild::version_ge VERSION1 VERSION2 returns
    -0 if VERSION1 is higher then or equal to VERSION2 otherwise a values greater than zero.

    -
    -
    -

    pbuild::version_eq VERSION1 VERSION2 returns
    -0 if VERSION1 is equal to VERSION2 otherwise a values greater than zero.

    -
    -
    -
    -
    Example
    -
    -
    -
    pbuild::version_lt '1.1.0' '1.2.2'  # result is 0
-pbuild::version_ge '9.1.2' '10.0.0' # result is greater zero
    -
    -
    -
    -
    -
    -
    -

    4.5.6. Build functions

    -
    -
    4.5.6.1. Download and unpack: pbuild::prep
    -
    -
    Synopsis
    -
    -
    -
    pbuild::pre_prep
-pbuild::prep
-pbuild::post_prep
    -
    -
    -
    -
    -
    Description
    -
    -

    Functions to prepare the sources. This includes

    -
    -
    -
      -
    • -

      downloading required files a verifying the checksums

      -
      • -
    • -

      unpacking

      -
      • -
    • -

      applying patches

      -
      • -
    -
    -
    -

    Before the prep-functions are called, the build-system changes to the source -directory (${SRC_DIR}).

    -
    -
    -

    In the most uses cases the default function pbuild::prep provided by -the build-system can be used and nothing must be implemented in the -build-script. In some rare cases pre- or post-hooks are required to -make the default function feasible. One use case with autotools for a post-hook is to create the configure scripts, if only configure.ac is shipped with the software.

    -
    -
    -

    The default hooks provided by the build system are only stubs and do -nothing.

    -
    -
    -

    If the default function cannot be used, it must be implemented in the build-script.

    -
    -
    -
    -
    Example
    -
    -

    The source distribution of the IOAPI library contains object files! These files must be removed after unpacking:

    -
    -
    -
    -
    pbuild::post_prep() {
-        find "${SRC_DIR}" -name "*.mod" -exec rm {} \;
-        find "${SRC_DIR}" -name "*.o" -exec rm {} \;
-}
    -
    -
    -
    -
    -
    -
    -
    4.5.6.2. Configure software: pbuild::configure
    -
    -
    Synopsis
    -
    -
    -
    pbuild::pre_configure
-pbuild::configure
-pbuild::post_configure
    -
    -
    -
    -
    -
    Description
    -
    -

    Configure the software for compilation.

    -
    -
    -

    Before these functions are called, the build-system changes to the -build directory (${BUILD_DIR}).

    -
    -
    -

    In the most uses cases the default function pbuild::configure provided by -the build-system can be used and nothing must be implemented in the -build-script.

    -
    -
    -

    The default function first searches whether the software can be -configured with autotools. If yes, configuration with autotools will -be performed. Otherwise the existence of a CMake script will be -checked. If found, configuration will be done via CMake. If scripts -for both configuration tools exist, the to be used tool can be -selected with pbuild::use_autotools or -pbuild::use_cmake. Arguments to configure or -cmake can be set with -pbuild::add_configure_args.

    -
    -
    -

    A common use case for the pre-configure hooks is to define arguments -passed to autotools or CMake by the default function.

    -
    -
    -

    If the default function cannot be used, the pbuild::configure -function must be implemented in the build-script.

    -
    -
    -
    -
    Examples
    -
    -

    Excerpt from the parallel HDF5 build-script

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    1Configuration is for gnuplot
    2will be installed in the group Tools
    3will be installed in the base overlay (/opt/psi)
    4the default release stage is stable
    5the module is available on these systems
    6install these files to $PREFIX/share/doc/gnuplot
    7download via this link
    8SHA256 hash sums for all available versions
    9no specific configuration required for these versions
    10release stage of version 5.4.10 is still unstable, override +default release stage. +---
    +
    Example: HDF5
    -
    pbuild::pre_configure() {
-        pbuild::add_configure_args "CC=${MPICC}"
-        pbuild::add_configure_args "CXX=${MPICXX}"
-
-        pbuild::add_configure_args "--enable-shared"
-        pbuild::add_configure_args "--enable-parallel"
-        pbuild::add_configure_args "--enable-cxx"
-        pbuild::add_configure_args "--enable-unsupported"
-        #pbuild::add_configure_args "--enable-threadsafe"
-        pbuild::add_configure_args "--with-pic"
-
-        local enable_fortran='yes'
+
    ---
+# yamllint disable rule:line-length             (1)
+format: 1
+hdf5:                                           (2)
+  defaults:
+    group: MPI                                  (3)
+    overlay: base                               (4)
+    relstage: stable                            (5)
+    systems: [rhel7, rhel8, rhel9]              (6)
+    urls:                                       (7)
+      - url: https://support.hdfgroup.org/ftp/HDF5/releases/$P-${V_MAJOR}.${V_MINOR}/$P-${V_PKG}/src/$P-${V_PKG}.tar.bz2
+  shasums:                                      (8)
+    hdf5-1.8.10-patch1.tar.bz2: 292afb3615ad9e68f4d5d18ebb11e4a73f2aece39f2da3875a457ff1e109fc41
+    hdf5-1.8.12.tar.bz2: 10a369a4fc207bb09245f57c758e587420e06dfc0e445e337a58b0848b75a949
+    ...
+    hdf5-1.13.1.tar.bz2: e16973ec893e2d5aa9c8dc73e196db9b99a605578e7317b421c713936f8bf57d
 
-        case "${COMPILER}" in
-                clang-macos )
-                        enable_fortran='no'
-                        # we do not have Fortran in Xcode
-                        ;;
-                pgi )
-                        # PGI uses GCC's include files, some object files and
-                        # the STL implementation!
-                        # The PGI C pre-processor is broken and doesn't work
-                        # for HDF5. We use the pre-processor of the underlying
-                        # GCC...
-                        # This is a bit hackish!
-                        #
-                        # The following eval sets GCCDIR! Which is something
-                        # like:
-                        # /opt/psi/Programming/gcc/7.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.0
-                        #
-                        eval $(pgcc -show 2>/dev/null | \
-                                awk '/^GCCDIR[[:space:]]*=/{gsub(/[[:space:]]/,""); print $0}')
-                        pbuild::add_configure_args "CPP=${GCCDIR%%/..*}/cpp"
-                        pbuild::add_configure_args "CFLAGS=-fPIC"
-                        pbuild::add_configure_args "CXXFLAGS=-fPIC"
-                        pbuild::add_configure_args "FCFLAGS=-fPIC"
-                        ;;
-        esac
+  versions:
+    1.8.12:
+      config:
+        relstage: deprecated                    (9)
+      variants:
+        -
+          group_deps:
+            compiler: {gcc: [4.7.4, 4.8.3, 4.8.4, 4.9.2]}
+            mpi: {openmpi: [1.6.5, 1.8.2, 1.8.4]}
+        -
+          group_deps:
+            compiler: {gcc: [4.8.2]}
+            mpi: {openmpi: [1.6.5]}
+        ...
+        -
+          group_deps:
+            compiler: {gcc: [5.1.0], intel: [15.2, 15.3]}
+            mpi: {openmpi: [1.8.4]}
+    ...
+    1.10.8_slurm:
+      variants:                                (10)
+        -
+          group_deps:
+            compiler: {gcc: [10.4.0]}
+            mpi: {openmpi: [4.1.4_slurm]}
+        -
+          relstage: unstable
+          group_deps:
+            compiler: {gcc: [9.5.0, 10.4.0, 11.4.0, 12.3.0, 13.1.0]}
+            mpi: {openmpi: [4.1.5_slurm]}
+    ...
+    1.12.0:
+      variants:
+        -
+          group_deps:
+            compiler: {gcc: [7.5.0, 8.4.0, 9.3.0, 10.2.0]}
+            mpi: {openmpi: [4.0.5]}
+        -
+          relstage: unstable
+          group_deps:
+            compiler: {pgi: [21.5]}
+            mpi: {pgi-mpi: [21.5]}
 
-        if [[ "${enable_fortran}" ===== 'yes' ]]; then
-                pbuild::add_configure_args "F77=${MPIF77}"
-                pbuild::add_configure_args "F90=${MPIF90}"
-                pbuild::add_configure_args "FC=${MPIFC}"
-                pbuild::add_configure_args "FORTRAN=${MPIFORTRAN}"
-                pbuild::add_configure_args "--enable-fortran"
-        fi
    
-
    -
    -
    -

    Simplified excerpt from the OpenBLAS build-script

    + 1.13.1: + variants: + - + suffix: _slurm (11) + variant: [_slurm] + relstage: unstable + group_deps: + compiler: {gcc: [11.2.0]} + mpi: {openmpi: [4.1.3_slurm]}
    -
    -
    -
    pbuild::configure() {
-        case ${COMPILER} in
-        gcc )
-                CC='gcc'
-                ;;
-        intel )
-                CC='icc'
-                ;;
-        clang-macos )
-                CC='gcc'
-                ;;
-        * )
-                die 3 "Oops: unknown compiler: ${COMPILER}"
-                ;;
-        esac
-        cat <<EOF > "${SRC_DIR}/make.inc"
-SHELL = /bin/sh
-PLAT =
-DRVOPTS  = \$(NOOPT)
-ARCHFLAGS= -ru
-EOF
-        echo "USE_SIMPLE_THREADED_LEVEL3 = 1" >> "${SRC_DIR}/Makefile.rule"
-        echo "NO_AVX = 1" >> "${SRC_DIR}/Makefile.rule"
-        echo "NO_AVX2 = 1" >> "${SRC_DIR}/Makefile.rule"
-        if pbuild::use_flag "omp"; then
-                echo "USE_THREAD = 1" >> "${SRC_DIR}/Makefile.rule"
-        else
-                echo "USE_THREAD = 0" >> "${SRC_DIR}/Makefile.rule"
-        fi
-}
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    1disable rule to check line length in yamllint. Default is 80.
    2this configuration is for HDF5
    3default group is MPI.
    4default overlay is base
    5default release stage is stable
    6this build-block can be used on RHEL7, RHEL8 and RHEL9
    7download via this link
    8SHA256 hash sums for all available versions
    9all variants of version 1.8.12 are deprecated
    10hdf5/1.10.8_slurm has two variants. The first variant compiled with GCC 10.4.0 and openmpi/4.1.4_slurm. The second variant is unstable and compiled with with GCC 9.5.0, 10.4.0, 11.4.0, 12.3.0, 13.1.0 and openmpi/4.1.5_slurm.
    11TBW
    -
    -
    4.5.6.3. Compile software: pbuild::compile
    -
    -
    Synopsis
    +
    +
    +

    3.5. Writing build scripts

    +
    +

    Pmodules has it’s own 'interpreter' to run build-scripts written in Bash. The name of the interpreter is modbuild. Thus the first line (the so called 'shebang') of a build-script must be

    +
    -
    pbuild::pre_compile
-pbuild::compile
-pbuild::post_compile
    -
    +
    #!/usr/bin/env modbuild
    -
    -
    Description
    -

    Compile the software.

    +

    As already mentioned the four steps 'prepare', 'configure', 'build' and 'install' has to be performed to build a Pmodule. These steps maps to the functions:

    -
    -

    Before these functions are called, the build-system changes to the -build directory (${BUILD_DIR}).

    +
    +
    +
    prepare
    +
    +

    pbuild::pre_prep()
    +pbuild::prep()
    +pbuild::post_prep()

    +
    +
    configure
    +
    +

    pbuild::pre_configure()
    +pbuild::configure()
    +pbuild::post_configure()

    +
    +
    compile
    +
    +

    pbuild::pre_compile()
    +pbuild::compile()
    +pbuild::post_compile()

    +
    +
    install
    +
    +

    pbuild::pre_install()
    +pbuild::install()
    +pbuild::post_install()

    +
    +
    -

    In the most uses cases the default function pbuild::compile provided by -the build-system can be used and nothing must be implemented in the -build-script. The pre- and post-hooks might be useful in cases where

    -
    -
    -
      -
    • -

      to run other make targets than all

      -
      • -
    • -

      multiple packages must be compiled into one module

      -
      • -
    • -

      to compile a dependency required by the main package.

      -
      • -
    +

    In many cases you don’t have to implement the the functions pbuild::prep(), pbuild::configure(), pbuild::compile() and pbuild::install() or at least not all of them. The build-system provides default implementations for these functions. In the simplest case, the build script consists only of the shebang line (only for Pmodules >= 1.1). In this case all further information for building the module is in the configuration file. For software that uses autotools or CMake for configuration and creation of Makefiles, the standard functions can practically always be used. The functions pbuild::pre_STEP and pbuild::post_STEP can be used to hook into each step before and after the default function has been called. For example pbuild::pre_configure() can be used to set arguments for autotools or CMake as in the build-script for Gnuplot:

    -
    -

    If the default function cannot be used, the pbuild::compile -function must be implemented in the build-script.

    +
    +
    Example: build script for Gnuplot
    +
    +
    #!/usr/bin/env modbuild
+
+pbuild::pre_configure() {
+        pbuild::add_configure_args '--with-latex=no'
+        pbuild::add_configure_args '--with-qt=no'
+}
    -
    -
    Example
    +
    +

    3.5.1. Overloading the default implementations

    -

    Excerpt from perl build-script

    +

    If the build-system of the software package isn’t autotools or CMake you have to overload the default implementation of pbuild::configure.

    -
    pbuild::post_compile() {
-        make test
+
    pbuild::configure(){
+        # add code to configure the software package
 }
    -
    -
    +
    +

    In case where no configuration is required, overload the default function with

    -
    -
    4.5.6.4. Install software: pbuild::install
    -
    -
    Synopsis
    -
    pbuild::pre_install
-pbuild::install
-pbuild::post_install
    -
    -
    +
    pbuild::configure(){
+        : # do nothing
+}
    -
    -
    Description
    -
    -

    Compile the software.

    -

    Before these functions are called, the build-system changes to the -build directory (${BUILD_DIR}).

    +

    You can do the same with the other default implementation.

    -
    -

    In the many uses cases the default function pbuild::install provided by -the build-system can be used and nothing must be implemented in the -build-script. A typical use case for the post-install hook is to install required libraries from other modules or the system to reduce or eliminate run-time dependencies

    +
    +

    3.5.2. Modules from binary packages

    -

    If the default function cannot be used, the pbuild::install -function must be implemented in the build-script.

    -
    +

    If you have a binary package like Matlab, Mathematica, ANSYS, it might not be possible to script the installation. In this case you should use a dummy build-script like below and document the installation in a README.md:

    -
    -
    Example
    -
    TBW
    -
    -
    -
    -
    +
    #!/usr/bin/env modbuild
+
+pbuild::prep() { :; }
+pbuild::configure() { :; }
+pbuild::compile() { :; }
+pbuild::install() { :; }
    -
    -

    4.6. Runtime configuration files

    -

    Table of Contents
    -Pmodules 1.0 configuration file .release-version
    -Pmodules 1.1 and newer configuration file .config-version

    +

    If the installation can be scripted, code this in the function pbuild::install.

    +
    +
    +
    +
    #!/usr/bin/env modbuild
+
+pbuild::prep() { :; }
+pbuild::configure() { :; }
+pbuild::compile() { :; }
+pbuild::install() {
+        # add code to call the installer here
+}
    -
    - - - - - -
    - - -
    -

    The runtime configuration files are evaluated only for modules inside -the Pmodules hierarchy. If you use modbuild these files are created -automatically. Otherwise you have to create them by hand.

    -
    -

    4.6.1. Pmodules 1.0: .release-version

    +

    3.5.3. Calling the build-script

    -

    In .release-version the release stage of a module is -defined. The file must be in the same directory as the modulefile. The -content is a single line defining the release stage. Allowed text is

    -
    -
    -
      -
    • -

      unstable

      -
      • -
    • -

      stable

      -
      • -
    • -

      deprecated

      -
      • -
    +

    To call the build-script, cd into the directory of the script and run

    -
    -

    If the file doesn’t exist and the module is inside the Pmodule -hierarchy unstable. All modules outside the Pmodules hierarchy are -considered as stable.

    +
    +
    +
    ./build VERSION_TO_BE_BUILD
    -
    - - - - - -
    - - -
    -

    This configuration file is deprecated in version 1.1 and newer. Please -see next section.

    -
    +
    +
    Example with output
    +
    +
    pmod7:~/HelloWorld$ ./build 1.0.0
+Using YAML configuration file - /afs/psi.ch/user/g/gsell/HelloWorld/files/config.yaml
+HelloWorld/1.0.0: building ...
+HelloWorld/1.0.0:
+HelloWorld/1.0.0: start building ...
+HelloWorld/1.0.0: preparing sources ...
+HelloWorld/1.0.0: configuring ...
+HelloWorld/1.0.0: compiling ...
+HelloWorld/1.0.0: installing ...
+HelloWorld/1.0.0: running post-installation for Linux ...
+HelloWorld/1.0.0: Installing documentation to /opt/psi/Sandbox/HelloWorld/1.0.0/share/doc/HelloWorld
+HelloWorld/1.0.0: adding modulefile to overlay 'base' ...
+HelloWorld/1.0.0: Cleaning up '/var/tmp/gsell/HelloWorld-1.0.0/build'...
+HelloWorld/1.0.0: Cleaning up '/var/tmp/gsell/HelloWorld-1.0.0/src'...
+HelloWorld/1.0.0: Done ...
+* * * * *
+
+pmod7:~/HelloWorld$
    -
    -

    4.6.2. Pmodules 1.1 and newer: .config-version

    -

    In .config-version the following properties of a module can be -configured:

    +

    You can run

    +
    +
    +
    +
    ./build --help
    -
    -
      -
    • -

      the release stage

      -
      • -
    • -

      the systems on which a module is available

      -
      • -
    • -

      the systems on which a module is unavailable

      -
      • -
    -

    The format of the file is YAML.

    +

    to get a list of all option with a description. The most common option are

    -
    relstage
    -
    -

    The release stage of the module. Allowed values are -unstable, stable and deprecated.

    -
    -
    systems
    +
    -f
    -

    Sequence of systems on which the module is available. Systems -can be hostnames with shell style glob pattern or OS names like -(rhel7, rhel8).

    +

    to force a rebuild

    -
    blocklist
    +
    --verbose
    -

    Sequence of systems on which the module is no -available. Systems can be hostnames with shell style glob patterns or -OS names.

    +

    to get a full debug trace.

    -
    -

    Example:

    +
    +

    3.5.4. Functions to compare versions

    +
    +
    3.5.4.1. Compare two versions: pbuild::version_compare
    +
    +
    Synopsis
    -
    relstage: unstable
-systems: [merlin-*, ra-*]
-blocklist: []
    +
    pbuild::version_compare VERSION1 VERSION2
+pbuild::version_lt VERSION1 VERSION2
+pbuild::version_le VERSION1 VERSION2
+pbuild::version_gt VERSION1 VERSION2
+pbuild::version_ge VERSION1 VERSION2
+pbuild::version_eq VERSION1 VERSION2
    +
    +
    Description
    +
    +

    The function splits the version strings at the dots an compares each component. If a component is a number the comparison is numerical otherwise lexical.

    -
    -

    Appendix A: "legacy" configuration files in Pmodules 1.0

    -
    - - - - - -
    - -
    -

    These type of configuration file is deprecated in version 1.1 and -newer. Starting with version 1.2 the use of YAML configuration files -documented in the next section is recommended.

    +

    pbuild::version_compare VERSION1 VERSION2 returns
    + 0 if the versions are equal
    + 1 if VERSION1 is higher then VERSION2
    + 2 if VERSION1 is lower then VERSION2

    -
    +
    +

    pbuild::version_lt VERSION1 VERSION2 returns
    +0 if VERSION1 is lower then VERSION2 otherwise a values greater than zero.

    -

    In the Pmodules 1.0 configuration files the following properties are -defined per version:

    +

    pbuild::version_le VERSION1 VERSION2 returns
    +0 if VERSION1 is lower then or equal to VERSION2 otherwise a values greater than zero.

    -
    -
      -
    • -

      module name and version

      -
      • -
    • -

      release stage

      -
      • -
    • -

      dependencies

      -
      • -
    +
    +

    pbuild::version_gt VERSION1 VERSION2 returns
    +0 if VERSION1 is higher then VERSION2 otherwise a values greater than zero.

    -

    Each definition must be on a single line.

    +

    pbuild::version_ge VERSION1 VERSION2 returns
    +0 if VERSION1 is higher then or equal to VERSION2 otherwise a values greater than zero.

    -
    -

    4.A.1. Configuration filenames and search order

    -

    Configuration files are searched in the following order:

    +

    pbuild::version_eq VERSION1 VERSION2 returns
    +0 if VERSION1 is equal to VERSION2 otherwise a values greater than zero.

    +
    +
    +
    +
    Example
    +
    +
    +
    pbuild::version_lt '1.1.0' '1.2.2'  # result is 0
+pbuild::version_ge '9.1.2' '10.0.0' # result is greater zero
    -
    -
      -
    1. -

      build-recipe-dir/files/variants.system

      -
      2. -
    2. -

      build-recipe-dir/files/variants.OS

      -
      3. -
    3. -

      build-recipe-dir/files/variants

      -
      4. -
    -
    -

    Whereby

    -
    -
    -
    system
    -
    -

    If the build script is called with the option --system=sytem, this configuration file is used.

    -
    -
    OS
    -
    -

    Is the operating system/kernel name returned by uname --s. On Linux this is Linux on macOS this is Darwin.

    -
    -
    -

    4.A.2. Format

    +

    3.5.5. Build functions

    +
    +
    3.5.5.1. Download and unpack: pbuild::prep
    +
    +
    Synopsis
    +
    +
    +
    pbuild::pre_prep
+pbuild::prep
+pbuild::post_prep
    +
    +
    +
    +
    +
    Description
    -

    A line in a configuration file is either

    +

    Functions to prepare the sources. This includes

    • -

      a comment line starting with #

      +

      downloading required files a verifying the checksums

    • -

      a empty line or a with white-space only

      +

      unpacking

    • -

      a definition of a variant

      +

      applying patches

    -
    -
    -

    4.A.3. Variant specifications

    -

    The form of a variant specification is

    +

    Before the prep-functions are called, the build-system changes to the source +directory (${SRC_DIR}).

    -

    module-name release_stage dependencies

    +

    In the most uses cases the default function pbuild::prep provided by +the build-system can be used and nothing must be implemented in the +build-script. In some rare cases pre- or post-hooks are required to +make the default function feasible. One use case with autotools for a post-hook is to create the configure scripts, if only configure.ac is shipped with the software.

    -

    Whereby:

    +

    The default hooks provided by the build system are only stubs and do +nothing.

    -
    -
    -
    module-name
    -
    -

    Is the name of the module including the version, an -optional release number and an optional suffix. The general form is

    -

    P/V[-V_RELEASE][_SUFFIX]

    +

    If the default function cannot be used, it must be implemented in the build-script.

    -
    -
    release_stage
    -
    -

    Defines the release stage of this module -variant. Allowed values are unstable, stable, deprecated, -remove and removed. If the release stage is remove or removed, -this module variant will be removed (if not already removed).

    -
    -
    dependencies
    -
    -

    Defines the module dependencies. Dependencies can -be either a hierarchical dependency, a runtime dependency or a build -dependency. Hierarchical and runtime dependencies are loaded before -a module itself. Build dependencies are only loaded during build-time -and must be prefixed with b:.

    -
    -

    Dependencies are loaded in the specified order. It is recommended to -specify the dependencies of a the (hierarchical) group first, then -additional modules required at run-time and the modules required to -build it at the end.

    +
    +
    Example
    -

    If the module is in a hierarchical group like MPI, you must specify -the modules required for this group. For modules in the group

    -
    -
    -
      -
    • -

      Compiler a compiler must be specified.

      -
      • -
    • -

      MPI a compiler and a MPI implementation must be specified.

      -
      • -
    • -

      HDF5 a compiler, a MPI implementation and a parallel HDF5 module -must be specified.

      -
      • -
    • -

      HDF5_serial a compiler and a serial HDF5 module -must be specified.

      -
      • -
    -
    -
    -
    +

    The source distribution of the IOAPI library contains object files! These files must be removed after unpacking:

    -
    Example
    -
    parmetis/4.0.3  stable gcc/7.3.0 openmpi/3.0.0  b:cmake/3.6.3
    +
    pbuild::post_prep() {
+        find "${SRC_DIR}" -name "*.mod" -exec rm {} \;
+        find "${SRC_DIR}" -name "*.o" -exec rm {} \;
+}
    -
    -

    Appendix B: Legacy build function (Pmodules version 1.0)

    -
    - - - - - -
    - - -
    -

    These functions are deprecated in Pmodules 1.1 and newer!

    -
    -
    -
    -
    -

    4.B.1. Define the group of a module: pbuild::add_to_group

    -
    4.B.1.1. Synopsis
    +
    3.5.5.2. Configure software: pbuild::configure
    +
    +
    Synopsis
    -
    pbuild::add_to_group GROUP
    +
    pbuild::pre_configure
+pbuild::configure
+pbuild::post_configure
    -
    -
    4.B.1.2. Description
    +
    +
    Description
    -

    Define the group the module will be installed in. Sometimes it is not obvious in which group a module should go. If in doubt, Tools might be the best.

    +

    Configure the software for compilation.

    -

    A (incomplete) list of available groups:

    +

    Before these functions are called, the build-system changes to the +build directory (${BUILD_DIR}).

    -
    -
    -
    Tools
    -
    -

    Group for tools like Gnuplot, Git, vim, Emacs, openssl. This group is visible by default.

    -
    -
    Programming
    -
    -

    Group for compilers, scripting languages and tools used for programming, like GCC, Python, CMake, autotools, Matlab. This group is visible by default.

    -
    -
    Compiler
    -
    -

    Hierarchical group for modules compiled with a certain compiler module. Examples: open-mpi, MPICH, serial HDF5.

    -
    -
    HDF5_serial
    -
    -

    Hierarchical group for modules compiled with a certain compiler and serial HDF5 module. Examples: netCDF, H5hut.

    -
    -
    MPI
    -
    -

    Hierarchical group for modules compiled with a certain compiler and MPI module. Examples: parallel Boost, parallel HDF5, ParMETIS, Gromacs.

    -
    -
    HDF5
    -
    -

    Hierarchical group for modules compiled with a certain compiler, MPI and parallel HDF5 module. Examples: netCDF, H5hut, Trilinos.

    -
    -
    System
    -
    -

    Group for system tools. This group is not visible by default. Examples: filebench, fsstress, nmap, patchelf.

    -
    -
    Libraries
    -
    -

    Group for libraries required to compile other modules but not providing (useful) tools. This group is not visible by default. Examples: GMP, MPC, MPFR

    -
    -
    MX
    -
    -

    Group for special tools used at the MX beam-line. This group is visible only on dedicated systems.

    -
    -
    EM
    -
    -

    Group for Ra specific software. This group is only visible and available on Ra.

    -
    -
    +
    +

    In the most uses cases the default function pbuild::configure provided by +the build-system can be used and nothing must be implemented in the +build-script.

    +
    +
    +

    The default function first searches whether the software can be +configured with autotools. If yes, configuration with autotools will +be performed. Otherwise the existence of a CMake script will be +checked. If found, configuration will be done via CMake. If scripts +for both configuration tools exist, the to be used tool can be +selected with pbuild::use_autotools or +pbuild::use_cmake. Arguments to configure or +cmake can be set with +pbuild::add_configure_args.

    +
    +
    +

    A common use case for the pre-configure hooks is to define arguments +passed to autotools or CMake by the default function.

    +
    +
    +

    If the default function cannot be used, the pbuild::configure +function must be implemented in the build-script.

    +
    +
    +
    +
    Examples
    +
    +

    Excerpt from the parallel HDF5 build-script

    +
    +
    +
    +
    pbuild::pre_configure() {
+        pbuild::add_configure_args "CC=${MPICC}"
+        pbuild::add_configure_args "CXX=${MPICXX}"
+
+        pbuild::add_configure_args "--enable-shared"
+        pbuild::add_configure_args "--enable-parallel"
+        pbuild::add_configure_args "--enable-cxx"
+        pbuild::add_configure_args "--enable-unsupported"
+        #pbuild::add_configure_args "--enable-threadsafe"
+        pbuild::add_configure_args "--with-pic"
+
+        local enable_fortran='yes'
+
+        case "${COMPILER}" in
+                clang-macos )
+                        enable_fortran='no'
+                        # we do not have Fortran in Xcode
+                        ;;
+                pgi )
+                        # PGI uses GCC's include files, some object files and
+                        # the STL implementation!
+                        # The PGI C pre-processor is broken and doesn't work
+                        # for HDF5. We use the pre-processor of the underlying
+                        # GCC...
+                        # This is a bit hackish!
+                        #
+                        # The following eval sets GCCDIR! Which is something
+                        # like:
+                        # /opt/psi/Programming/gcc/7.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.0
+                        #
+                        eval $(pgcc -show 2>/dev/null | \
+                                awk '/^GCCDIR[[:space:]]*=/{gsub(/[[:space:]]/,""); print $0}')
+                        pbuild::add_configure_args "CPP=${GCCDIR%%/..*}/cpp"
+                        pbuild::add_configure_args "CFLAGS=-fPIC"
+                        pbuild::add_configure_args "CXXFLAGS=-fPIC"
+                        pbuild::add_configure_args "FCFLAGS=-fPIC"
+                        ;;
+        esac
+
+        if [[ "${enable_fortran}" ===== 'yes' ]]; then
+                pbuild::add_configure_args "F77=${MPIF77}"
+                pbuild::add_configure_args "F90=${MPIF90}"
+                pbuild::add_configure_args "FC=${MPIFC}"
+                pbuild::add_configure_args "FORTRAN=${MPIFORTRAN}"
+                pbuild::add_configure_args "--enable-fortran"
+        fi
    -
    -
    4.B.1.3. Example
    -
    -
    Example 1. Define the group for the Gnuplot module:
    -
    +
    +

    Simplified excerpt from the OpenBLAS build-script

    +
    -
    pbuild::add_to_group 'Tools'
    -
    -
    +
    pbuild::configure() {
+        case ${COMPILER} in
+        gcc )
+                CC='gcc'
+                ;;
+        intel )
+                CC='icc'
+                ;;
+        clang-macos )
+                CC='gcc'
+                ;;
+        * )
+                die 3 "Oops: unknown compiler: ${COMPILER}"
+                ;;
+        esac
+        cat <<EOF > "${SRC_DIR}/make.inc"
+SHELL = /bin/sh
+PLAT =
+DRVOPTS  = \$(NOOPT)
+ARCHFLAGS= -ru
+EOF
+        echo "USE_SIMPLE_THREADED_LEVEL3 = 1" >> "${SRC_DIR}/Makefile.rule"
+        echo "NO_AVX = 1" >> "${SRC_DIR}/Makefile.rule"
+        echo "NO_AVX2 = 1" >> "${SRC_DIR}/Makefile.rule"
+        if pbuild::use_flag "omp"; then
+                echo "USE_THREAD = 1" >> "${SRC_DIR}/Makefile.rule"
+        else
+                echo "USE_THREAD = 0" >> "${SRC_DIR}/Makefile.rule"
+        fi
+}
    -
    -

    4.B.2. Set download URL: pbuild::set_download_url

    -
    4.B.2.1. Synopsis
    +
    3.5.5.3. Compile software: pbuild::compile
    +
    +
    Synopsis
    -
    pbuild::set_download_url URL [fname]
    +
    pbuild::pre_compile
+pbuild::compile
+pbuild::post_compile
    -
    -
    4.B.2.2. Description
    +
    +
    Description
    -

    Tell the build system where to download the required (source-)files. If fname is passed, it will be used as the output file-name of the download.

    +

    Compile the software.

    -

    In some cases software must be downloaded from a Git repository on Github, Bitbucket or Gitlab.

    +

    Before these functions are called, the build-system changes to the +build directory (${BUILD_DIR}).

    -

    To download a certain tag/version from Github, Bitbucket or Gitlab use:

    -
    -
    -
    -
    https://github.com/OWNER/PROJECT/archive/${V_PKG}/$P-${V_PKG}.tar.gz
-https://bitbucket.org/OWNER/PROJECT/get/${V_PKG}.tar.gz#/$P-%{V_PKG}.tar.gz
-https://gitlab.com/OWNER/PROJECT/-/archive/${V_PKG}/$P-${V_PKG}.tar.gz
    -
    +

    In the most uses cases the default function pbuild::compile provided by +the build-system can be used and nothing must be implemented in the +build-script. The pre- and post-hooks might be useful in cases where

    +
    +
      +
    • +

      to run other make targets than all

      +
      • +
    • +

      multiple packages must be compiled into one module

      +
      • +
    • +

      to compile a dependency required by the main package.

      +
      • +
    -
    -
    4.B.2.3. Examples
    -

    Excerpt from Trilinos build-script:

    -
    -
    -
    -
    pbuild::set_download_url \
-        "https://github.com/$P/$P/tarball/$P-release-${V//./-}" \
-        "$P-$V.tar.gz"
    -
    -
    -
    -
    -
    4.B.2.4. Compile in source tree: pbuild::compile_in_sourcetree (Pmodules 1.0)
    -
    -
    Synopsis
    -
    -
    -
    pbuild::compile_in_sourcetree
    -
    +

    If the default function cannot be used, the pbuild::compile +function must be implemented in the build-script.

    -
    Description
    +
    Example
    -

    By default the build-system compiles software in a separate build-directory. This is not possible with all software. With the function pbuild::compile_in_sourcetree the build-directory is set to the source-directory.

    -
    +

    Excerpt from perl build-script

    -
    -
    Example
    -
    pbuild::compile_in_sourcetree
    +
    pbuild::post_compile() {
+        make test
+}
    -
    4.B.2.5. Set documentation files to be installed: pbuild::install_docfiles (Pmodules 1.0)
    +
    3.5.5.4. Install software: pbuild::install
    -
    Synopsis
    +
    Synopsis
    -
    pbuild::install_docfiles fname...
    +
    pbuild::pre_install
+pbuild::install
+pbuild::post_install
    -
    Description
    +
    Description
    -

    Install the passed files into $PREFIX/share/doc/$P. At least the file containing the license and copyright should be installed.

    -
    +

    Compile the software.

    -
    -
    Example
    -

    Excerpt from parallel-netcdf build-script:

    -
    -
    -
    -
    pbuild::add_docfiles 'AUTHORS' 'CREDITS'
-pbuild::add_docfiles 'COPYING' 'COPYRIGHT'
-pbuild::add_docfiles 'ChangeLog' 'NEWS'
-pbuild::add_docfiles 'RELEASE_NOTES'
    -
    -
    -
    -
    -
    -
    -
    4.B.2.6. Pass SHA256 hash sum to build-system: pbuild::set_sha256sum (Pmodules 1.0)
    -
    -
    Synopsis
    -
    -
    -
    pbuild::set_sha256sum SHA256_HASH
    -
    -
    +

    Before these functions are called, the build-system changes to the +build directory (${BUILD_DIR}).

    -
    -
    Description
    -

    Tell the build-system which SHA256 hash sum a file must have. The format of the argument is file-name:hash-sum.

    -
    +

    In the many uses cases the default function pbuild::install provided by +the build-system can be used and nothing must be implemented in the +build-script. A typical use case for the post-install hook is to install required libraries from other modules or the system to reduce or eliminate run-time dependencies

    -
    -
    Examples
    -

    Excerpt from Trilinos build-script:

    -
    -
    -
    -
    pbuild::set_sha256sum \
-	"trilinos-12.12.1.tar.gz:c8f2029fa36230b9f384c56139aaa33111227bcf653e73f7daf3c9efdecc1d2d"
    -
    -
    -
    +

    If the default function cannot be used, the pbuild::install +function must be implemented in the build-script.

    -
    -
    4.B.2.7. Supported compilers: pbuild::set_supported_compilers (Pmodules 1.0)
    -
    Synopsis
    +
    Example
    -
    pbuild::supported_compilers STRING...
    -
    +
    TBW
    -
    -
    Description
    -
    -

    Set list of compiler which can be used to compile the module.

    -
    -
    Example
    -
    -
    -
    pbuild::supported_compilers gcc clang
    -
    +
    +

    3.6. Runtime configuration files

    +
    +

    Table of Contents
    +Pmodules 1.0 configuration file .release-version
    +Pmodules 1.1 and newer configuration file .config-version

    +
    + + + + + +
    + + +
    +

    The runtime configuration files are evaluated only for modules inside +the Pmodules hierarchy. If you use modbuild these files are created +automatically. Otherwise you have to create them by hand.

    -
    -
    4.B.2.8. Set which OS are supported: pbuild::supported_systems (Pmodules 1.0)
    -
    -
    Synopsis
    -
    -
    -
    pbuild::supported_system STRING...
    +
    +
    +

    3.6.1. Pmodules 1.0: .release-version

    +
    +

    In .release-version the release stage of a module is +defined. The file must be in the same directory as the modulefile. The +content is a single line defining the release stage. Allowed text is

    +
    +
      +
    • +

      unstable

      +
      • +
    • +

      stable

      +
      • +
    • +

      deprecated

      +
      • +
    -
    -
    Description
    -

    Some modules can be build only for dedicated operating systems. This is particularly the case for operating system specific tools like patchelf.

    +

    If the file doesn’t exist and the module is inside the Pmodule +hierarchy unstable. All modules outside the Pmodules hierarchy are +considered as stable.

    -
    +
    + + + + + +
    + + +
    +

    This configuration file is deprecated in version 1.1 and newer. Please +see next section.

    +
    -
    -
    4.B.2.9. Forece use of autotools: pbuild::use_autotools (Pmodules 1.0)
    -
    -
    Synopsis
    -
    -
    -
    pbuild::use_autotools
    +
    +

    3.6.2. Pmodules 1.1 and newer: .config-version

    +
    +

    In .config-version the following properties of a module can be +configured:

    +
    +
      +
    • +

      the release stage

      +
      • +
    • +

      the systems on which a module is available

      +
      • +
    • +

      the systems on which a module is unavailable

      +
      • +
    -
    -
    Description
    -

    Force the use of autotools.

    +

    The format of the file is YAML.

    -
    +
    +
    +
    relstage
    +
    +

    The release stage of the module. Allowed values are +unstable, stable and deprecated.

    +
    +
    systems
    +
    +

    Sequence of systems on which the module is available. Systems +can be hostnames with shell style glob pattern or OS names like +(rhel7, rhel8).

    +
    +
    blocklist
    +
    +

    Sequence of systems on which the module is no +available. Systems can be hostnames with shell style glob patterns or +OS names.

    +
    +
    +
    +

    Example:

    -
    -
    4.B.2.10. Force use of CMake: pbuild::use_cmake
    -
    -
    Synopsis
    -
    pbuild::use_cmake
    -
    -
    +
    relstage: unstable
+systems: [merlin-*, ra-*]
+blocklist: []
    -
    -
    Description
    -
    -

    Force the use of CMake.

    +
    +

    4. LINKS

    +
    -

    Appendix C: Links

    -
    -

    4.C.1. Other implementation of environment module systems

    +

    4.1. Other implementation of environment module systems

    • @@ -4736,8 +1841,8 @@

      4.C.1. Other implem

    -
    -

    4.C.2. Articles

    +
    +

    4.2. Articles

    • @@ -4750,8 +1855,8 @@

      4.C.2. Articles

    -
    -

    4.C.3. Talks

    +
    +

    4.3. Talks

    • @@ -4766,7 +1871,6 @@

      4.C.3. Talks

    -