Intel oneAPI 环境变量设置
因工作需要，需要在linux系统配置多个不同环境的库，需要使用environment-modules工具管理环境变量，为保持配置方法的一致性，也使用modulefile文件加载Intel oneAPI软件。
以下参考自 https://software.intel.com/content/www/us/en/develop/documentation/oneapi-programming-guide/top/oneapi-development-environment-setup/use-modulefiles-with-linux.html
使用Linux的modulefile配置oneAPI开放环境
大多数组件工具文件夹包含一个或多个modulefile脚本，它们配置该组件环境变量。modulefile可以替代setvars.sh脚本去设置环境变量。
由于moudlefile不支持参数，对于支持多个配置（如32位和64位）的oneAPI工具和库，有多个modulefile
注意：Intel oneAPI工具提供的modulefile与Tcl Environment Modules (Tmod)和Lua Environment Modules (Lmod)兼容。以下是支持的最低版本
- Tmod 4.1
- Tcl version 8.4
- Lmod version 8.2.10
输入以下命令，查看测试系统安装了哪个版本的文件：
module --version
每一个modulefile都可以自动验证系统的Tcl版本是否支持
oneAPI modulefile脚本存放在每个组件文件夹的moudulefiles文件夹下。例如，对于默认安装，ipp的modulefile脚本存放在 /opt/intel/ipp/latest/modulefiles/ 目录。
由于oneAPI组件文件夹在磁盘中的组织方式，直接在安装oneAPI模块文件的位置使用它们可能会很困难。oneAPI安装文件夹中提供了一个特殊的modulefiles-setup.sh脚本，以便于使用oneAPI modulefile。在默认安装中，该安装脚本位于此处：/opt/intel/oneapi/modulefiles-setup.sh
modulefile-setup.sh脚本查找oneAPI安装中的所有modulefile脚本，并将它们组织到单个文件夹目录中。这些文件夹是为包含一个或多个ModuleFile的每个已安装oneAPI组件命名的。
每个名为文件夹的组件都包含指向该oneAPI组件提供的所有modulefile的符号链接。这些符号链接被组织为版本化的modulefile文件。每个组件文件夹都包含（至少）一个“最新”版本的modulefile，默认情况下，在加载组件modulefile而不指定版本标签时将选中该文件。
oneAPI modulefiles顶级目录的默认名称为modulefiles，位于oneAPI安装文件夹中。例如：/opt/intel/oneapi/modulefile
创建modulefiles目录
运行modulefiles-setup.sh脚本
etvars.sh脚本去设置环境变量。
由于moudlefile不支持参数，对于支持多个配置（如32位和64位）的oneAPI工具和库，有多个modulefile：
注意：默认情况下，modulefiles-setup.sh脚本在oneAPI工具安装的目录下创建了一个名为modulefiles的文件夹。如果你的oneAPI安装文件夹不具有写权限，使用--output-dir=<path-to-folder>选项去在一个具有写权限的位置创建modulefiles文件夹。输入modulefiles-setup.sh --help查看更多信息。
在modulefiles-setup.sh脚本运行后，在modulefiles文件夹下创建了如下组织形式的文件。
[oneapi_root]
- [modulefiles]
- - [compiler]
- - - [1.0] -> [oneapi_root/compiler/1.0/modulefiles/compiler] # symlink named 1.0 points to compiler modulefile
- - [compiler32]
- - - [1.0] -> [oneapi_root/compiler/1.0/modulefiles/compiler32] # symlink named 1.0 points to compiler32 modulefile
- - [ipp]
- - - [1.1] -> [oneapi_root/ipp/1.1/modulefiles/ipp]
- - - [1.2] -> [oneapi_root/ipp/1.2/modulefiles/ipp]
- - [ipp32]
- - - [1.1] -> [oneapi_root/ipp/1.1/modulefiles/ipp32]
- - - [1.2] -> [oneapi_root/ipp/1.2/modulefiles/ipp32]
etc…
现在，可以将MODULEFILESPATH进行更新，从而指向新的modulefiles目录。
在你的系统中安装module工具
以下指导可以帮助你迅速熟悉Ubuntu*环境下的Environment Modules 工具。想要关于module工具安装的完整细节，参见http://modules.sourceforge.net/.
$ sudo apt update $ sudo apt install tcl $ sudo apt install environment-modules
确保本地的tclsh的版本足够新（截止文章写的时候，需要8.4以上的版本）
$ tclsh % puts $tcl_version 8.6 % exit
测试module安装，module别名
$ source /usr/share/modules/init/sh $ module
注意：Bourne兼容Shell的初始化应使用上面显示的源命令。/usr/share/modules/init/文件夹中提供了其他特定shell的init 脚本。有关更多详细信息，请参阅man模块中的该文件夹和初始化部分。
包括sourcing module别名初始化脚本 ( .../modules/init/sh) 在以下设置脚本中，用以确保module命令通常可用。之后，系统可以准备好使用module命令了。
modulefiles-setup.sh脚本入门
- 在Linux开发系统中安装了tclsh
- 在系统中安装了Environment Modules工具 (i.e., module)
- 已经sourced了.../modules/init/sh (或等价的) module 初始化命令
-
安装了oneAPI开发所需的oneAPI工具包
$ cd <oneapi-root-folder> # cd to the oneapi_root install directory $ ./modulefiles-setup.sh # run the modulefiles setup script $ module use modulefiles # use the modulefiles folder created above $ module avail # will show tbb/X.Y, etc. $ module load tbb # loads tbb/X.Y module $ module list # should list the tbb/X.Y module you just loaded $ module unload tbb # removes tbb/X.Y changes from the environment $ module list # should no longer list the tbb/X.Y env var module
在unload步骤之前，使用env命令检查环境并查找您加载的modulefile所做的更改。例如，如果加载了tbb modulefile，该命令将显示该modulefile所做的一些环境更改（检查modulefile以查看它将进行的所有更改）：
$ env | grep -i "intel"
注意：modulefile是一个脚本，但它不需要设置“x”（可执行）权限，因为它由最终用户安装和维护的“模块”解释器加载和解释。oneAPI产品的安装不包括modulefile解释器。它必须单独安装。同样，ModuleFile不要求设置“w”权限，但必须可读（理想情况下，为所有用户设置“r”权限）。
Versioning
oneAPI工具包安装程序将version文件夹应用于各个oneAPI工具和库，其形式为每个工具或库的顶级目录中的版本化的子目录。这些版本化组件文件夹用于创建版本化模块文件。这就是modulefiles-setup.sh脚本的基本功能；它将在顶级$（ONEAPI_ROOT）/modulefiles文件夹中创建的符号链接组织为<modulefile name>/version，因此在使用module命令时，可以按版本引用相应的modulefile。
$ module avail ---------------- modulefiles ----------------- ipp/1.1 ipp/1.2 compiler/1.0 compiler32/1.0
多个modulefiles
一个工具或库可以在其modulefiles文件夹中提供多个modulefiles。每个模块都成为可加载的模块。将根据提取它们的零部件文件夹为它们分配一个版本。
了解使用oneAPI时如何编写模块文件
modulefiles-setup.sh脚本使用符号链接将所有可用的工具和库modulefiles收集到oneAPI的一个顶级modulefiles文件夹中。这意味着不会移动或触摸oneAPI的ModuleFile。作为这种方法的结果，${ModulesCurrentModulefile}变量指向每个modulefile的符号链接，而不是指向各个安装文件夹中的实际modulefile。因此，由于符号链接，这些模块文件无法引用模块文件的组件文件夹中的其他文件夹或文件。
因此，oneAPI的每个modulefile都使用如下语句以获取对相应安装目录中原始modulefile的引用：
[ file readlink ${ModulesCurrentModulefile} ]
为了更好地理解，请查看安装附带的模块文件。大多数注释包括解释如何解析对真实文件的符号链接引用，以及解析版本号（和版本目录）。它们还包括检查以确保安装的TCL是适当的版本级别，并包括检查以防止您无意中加载同一modulefile的两个版本。
通过ModuleFile使用module load命令
几个modulefile使用module load命令来确保也加载了所有必需的依赖模块。没有尝试指定这些依赖ModuleFile的版本。这意味着，在加载需要依赖模块的模块之前，可以手动预加载特定的依赖模块。如果未预加载从属模块，则会加载最新的可用版本。
这是设计的，因为它提供了控制环境的灵活性。例如，您可能已经安装了一个库的更新版本，您希望根据以前版本的编译器进行测试。也许更新后的库有一个bug修复，而您对更改构建中任何其他库的版本不感兴趣。如果依赖ModuleFile被硬编码为需要此库的特定依赖版本，则无法执行此类测试。
注意：如果无法满足从属模块加载，则当前加载的模块文件将被终止，并且不会对您的环境进行任何更改。
