|
From: Xavier D. <xav...@gm...> - 2022-03-19 13:19:24
|
Hi Michael and Nick,
Virtual modules [1] seem a good solution for this situation. The idea is to
dynamically define the available modulefiles based on the software
directories found under the current $ARCH directory.
Instead of having a modulefile per software-version couple, you could just
have a single file that adapts its evaluation based on the name it has been
called (use [module-info name] in modulefile to fetch the name of the
module currently being evaluated).
$ tree software/modules/modulefiles/
software/modules/modulefiles/
├── clang
└── gcc
Then create a specific modulepath directory containing only a .modulerc
file containing the code that evaluate the available software installation
for current ARCH and then define virtual modules with the module-virtual
modulefile command:
$ tree -a software/modules/modulepath/
software/modules/modulepath/
└── .modulerc
0 directories, 1 file
$ cat software/modules/modulepath/.modulerc
#%Module
set archdir ../../$env(ARCH)/
foreach softdir [glob ${archdir}*/*] {
set mod [string range $softdir [string length $archdir] end]
set modname [file dirname $mod]
module-virtual $mod ../modulefiles/$modname
}
Once files have been set, just enable the modulepath and set the ARCH
variable:
$ tree software/{aarch64,x86_64}
software/aarch64
├── clang
│ └── 12.0.0
└── gcc
└── 10.1.0
software/x86_64
├── clang
│ └── 13.0.0
└── gcc
└── 9.2.0
8 directories, 0 files
$ module use software/modules/modulepath
$ export ARCH=x86_64
$ module avail
---- /path/to/software/modules/modulepath ----
clang/13.0.0 gcc/9.2.0
$ export ARCH=aarch64
$ module avail
---- /path/to/software/modules/modulepath ----
clang/12.0.0 gcc/10.1.0
Regards,
Xavier
[1]
https://modules.readthedocs.io/en/latest/modulefile.html#mfcmd-module-virtual
Le sam. 19 mars 2022 à 10:21, Nick Papior <nic...@gm...> a écrit :
> One solution would be to duplicate the module files for each arch, then a
> presetup determines the path of modules to be enabled and you won't have to
> make specific checks in module files. Of course this will duplicate module
> files, but it will also allow easier debugging and changing global
> variables per arch. I find this more convenient.
>
> On Sat, 19 Mar 2022, 08:44 Michael Klemm, <mi...@do...> wrote:
>
>> Folks,
>>
>> I have the following setup:
>>
>> /net/software/{x86_64,aarch64,armv7l,riscv} contains all software on
>> shared storage. /net/software/modules/modulefiles contains the
>> corresponding module files for these software packages, e.g.,
>> clang/13.0.0, gcc/9.2.0, etc. The module files use the $ARCH
>> environment variable to setup the environment for the software.
>>
>> Since I do not have all software packages compiled for all systems, I
>> was wondering what would be the best way to avoid loading (or even
>> better hide) modules that do not have the software package for a
>> particular architecture?
>>
>> I have come up with either checking in the module file, if the software
>> exists and if not throw some sort of error. I could also have
>> $ARCH-specific module locations and use "module use" on these locations,
>> depending on the machine I'm on. But is there a better way to automate
>> all this w/o too much duplication of module files or code in the module
>> files?
>>
>> I'm using Modules Release 4.4.1 (2020-01-03), all systems are Ubuntu
>> systems.
>>
>> Kind regards,
>> -michael
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>
|
