Glossary

Each term appears a single time on this page, and any chapter may reference it in situ. Thus, encountering versionsuffix in One easyconfig, many installs does not require this page, while a reader requiring the complete vocabulary can obtain it here. Definitions are presented mechanically rather than descriptively: they specify what the entity is in the code and what alterations occur when it changes.

The recipe

termeasyconfig

A Python file, conventionally named <name>-<version>[-<toolchain>][<versionsuffix>].eb, whose top-level assignments are read as parameters. EasyBuild 5.3.1 defines 110 of them in eight categories; five are enforced as mandatory (name, version, homepage, description, toolchain).

It is executed, not parsed as data, which is why an easyconfig can compute a value and why a variable EasyBuild does not recognise has to be named local_*.

An easyconfig is Python.

termeasyblock

The Python class that carries out a build. Chosen by the easyblock parameter, or computed from name when that parameter is absent: EB_<name> with characters escaped (- to _minus_, _ to _underscore_, space to _), in a module file whose name is lowercased with dashes turned to underscores.

EasyBuild 5.3.1 ships 82 generic classes in 47 modules and 282 software-specific ones. Generic ones carry no EB_ prefix. configure_step, build_step and install_step raise NotImplementedError on the abstract base, so every easyblock supplies those three or inherits them.

Writing an easyblock.

termtoolchain

A named set of compilers and libraries, and the thing that decides which dependencies a build may see. foss/2025a is GCC, OpenMPI, OpenBLAS, FFTW and ScaLAPACK at one generation; its subtoolchains are gompi/2025a, GCC/14.2.0, GCCcore/14.2.0 and the system toolchain.

A dependency built with a subtoolchain of yours is usable; one built with a sibling or a parent is not, and the check fires in the prepare step before anything is unpacked.

A toolchain is a hierarchy.

termversionsuffix

A string appended to the module’s version. It is part of the installation’s identity rather than a label on it. -CUDA-12.9.1 in a module name means the module tree, the install directory and the $EBROOT* variable all differ from the same software without it. Two installations differing only in versionsuffix are two different installations that can both exist.

A versionsuffix is part of the name.

termstart_dir

The directory a build runs in, relative to the guessed top of the unpacked source rather than to the extraction directory.

The guess is find_base_dir, which descends while a directory has exactly one entry, ignoring dotfiles and a directory named easybuild. So an archive containing only pkg-1.0/src/ starts in pkg-1.0/src, and a start_dir correct for a git checkout can be silently wrong for a release tarball of the same software.

Reading a failed build.

termexts_list

A list of things installed inside one installation rather than as modules of their own: Python packages, R packages, Perl modules. Entries are a bare name, a (name, version) tuple, or a (name, version, {options}) tuple. Handled by the extensions step, which is the tenth of the eighteen.

One easyconfig, many installs.

The run

termthe eighteen steps

In order: fetch, ready, extract, patch, prepare, configure, build, test, install, extensions, postiter, postproc, sanitycheck, cleanup, module, permissions, package, testcases.

ready through extensions are the iterated block, repeated once per entry when a parameter like configopts is a list. Every easyconfig parameter belongs to one step, and most error messages name one.

How a build executes.

termthe robot

Dependency resolution. --robot walks the dependency graph, finds an easyconfig for each unmet dependency by constructing its filename, and installs in order. It resolves exact versions: a dependency line is a pin, not a minimum.

The robot.

termsanity check

The step that decides whether an installation exists. sanity_check_paths takes files and dirs, both keys required and at least one non-empty, and asserts they are there. sanity_check_commands runs commands, which means the check executes the software. An RPATH check runs alongside, exempting libcuda.so, libcuda.so.1, libnvidia-ml.so and libnvidia-ml.so.1 belong to the driver.

What “installed” means.

termhook

A Python function a site registers to run before or after any step: pre_fetch_hook through post_testcases_hook, plus parse and module hooks. Hooks change builds without changing easyconfigs, which is why a recipe can be correct and produce something the file did not name, and why eb --show-config is the first thing to read on somebody else’s machine.

A hook changes a file you are not reading.

termoptarch

The toolchain option, on by default, that tells the compiler to optimise for the microarchitecture it is running on. It is why binaries are not interchangeable between node types and why sites keep one install tree per architecture. toolchainopts = {'optarch': False} turns it off for one package; --optarch sets a site-wide baseline.

What a toolchain injects.

termRPATH

A list of library search paths recorded inside a binary. EasyBuild’s --rpath writes the dependencies’ library directories into every binary it links, so a module does not need $LD_LIBRARY_PATH to work.

On a heterogeneous system an RPATH containing a per-node symlink such as /sw/arch/... resolves against the node the command runs on, which is why ldd on a login node can report zero missing libraries for a binary that is broken on a GPU node.

Four things that actually happened.

What comes out

termmodulefile

The generated Lua or Tcl file a user loads. Nothing writes it by hand: help and whatis come from description and homepage, conflict from the name, depends_on from dependencies, and the prepend_path lines from the directories that exist in the install.

It always sets $EBROOT<NAME>, $EBVERSION<NAME> and $EBDEVEL<NAME>, with the name uppercased and stripped of non-alphanumerics.

What a module exports.

termdevel module

A second modulefile, generated for every install, at <installdir>/easybuild/<name>-<version>-easybuild-devel and named by $EBDEVEL<NAME>. Loading it reproduces the environment the build had, Including $PATH and the modules tool’s own bookkeeping variables. It cannot be unloaded through $EBDEVELNAME.

Standing where the build stood.

termreprod/

A directory inside every installation, at <installdir>/easybuild/reprod/, holding the easyconfig as parsed, a shell script that recreates the build environment, and the source of the easyblock that ran, including component and extension easyblocks. It is written before the steps run, and it is what makes an installation self-describing a year later.

Standing where the build stood.

termmodule naming scheme

The rule mapping an installation to a module name and path. The default is EasyBuildMNS, flat: name/version-toolchain-versionsuffix in one directory. CategorizedModuleNamingScheme files those under moduleclass. HierarchicalMNS moves the toolchain out of the name and into MODULEPATH, so loading a compiler reveals the modules built with it.

A site decision made once: changing it renames every module the site has.

What a module exports.

Delivery

termCernVM-FS

A read-only filesystem delivered over plain HTTP, with content-addressed immutable objects, SQLite file catalogs, and a signed manifest at the root. Files are fetched on demand and cached locally, and the whole tree is verifiable from one signature.

Reading a stack off the wire: CernVM-FS.

termStratum 0 and Stratum 1

The Stratum 0 is the single writer: a release manager machine where cvmfs_server transaction and publish turn changes into content-addressed objects, atomically. A Stratum 1 is a web server mirroring those objects and the signed manifest, kept current by cvmfs_server snapshot. Clients talk to Stratum 1s, usually through a Squid forward proxy.

Reading a stack off the wire: CernVM-FS.

termvariant symlink

A symlink whose stored target is a variable reference, expanded by the CernVM-FS client from its own configuration: $(VAR) or $(VAR:-/a/default). What is signed is the string, so a site can point the link elsewhere without invalidating the repository signature. EESSI’s host_injections is stored as $(EESSI_HOST_INJECTIONS:-/opt/eessi).

The same stack somewhere else.

termEESSI

Three layers: CernVM-FS for delivery, a Gentoo Prefix compatibility layer so the host distribution stops mattering, and an EasyBuild software layer built per microarchitecture. The host still provides the kernel, the drivers, the filesystem clients and the scheduler.

EESSI, somebody else’s stack and The same stack somewhere else.

termarchdetect

eessi_archdetect.sh, the shell script EESSI uses by default to pick which build a host gets. -a cpupath returns an ordered colon-separated list from most specific to most generic, and the initialisation script takes the first entry that exists on disk. The selected value lands in $EESSI_SOFTWARE_SUBDIR; $EESSI_CPU_FAMILY is only uname -m.

The same stack somewhere else.

Testing

termReFrame

A Python framework for HPC regression and performance tests. A test is a decorated class. The configuration file describes the machine. The framework generates the job script and runs a six-stage pipeline (setup, compile, run, sanity, performance, cleanup). It does not look at the process exit code; a sanity function is the verdict.

A ReFrame test is a class and The pipeline has six stages.

termpartition (ReFrame)

A scheduler, a launcher and a list of programming environments inside a ReFrame system. valid_systems matches system:partition. Processor counts, features and max_jobs live here, not in the test.

The configuration file is the machine.

termEESSI mixin

A ReFrame mixin that replaces hardcoded core counts, module strings and system names with hooks that read the configuration and find_modules. A test states device_type and compute_unit; the mixin sets num_tasks.

A portable test leaves the machine in the config.