基本設定¶
Spack's basic configuration options are set in config.yaml
. You can
see the default settings by looking at
etc/spack/defaults/config.yaml
:
# -------------------------------------------------------------------------
# This is the default spack configuration file.
#
# Settings here are versioned with Spack and are intended to provide
# sensible defaults out of the box. Spack maintainers should edit this
# file to keep it current.
#
# Users can override these settings by editing the following files.
#
# Per-spack-instance settings (overrides defaults):
# $SPACK_ROOT/etc/spack/config.yaml
#
# Per-user settings (overrides default and site settings):
# ~/.spack/config.yaml
# -------------------------------------------------------------------------
config:
# This is the path to the root of the Spack install tree.
# You can use $spack here to refer to the root of the spack instance.
install_tree: $spack/opt/spack
# Locations where templates should be found
template_dirs:
- $spack/share/spack/templates
# Default directory layout
install_path_scheme: "${ARCHITECTURE}/${COMPILERNAME}-${COMPILERVER}/${PACKAGE}-${VERSION}-${HASH}"
# Locations where different types of modules should be installed.
module_roots:
tcl: $spack/share/spack/modules
lmod: $spack/share/spack/lmod
dotkit: $spack/share/spack/dotkit
# Temporary locations Spack can try to use for builds.
#
# Spack will use the first one it finds that exists and is writable.
# You can use $tempdir to refer to the system default temp directory
# (as returned by tempfile.gettempdir()).
#
# A value of $spack/var/spack/stage indicates that Spack should run
# builds directly inside its install directory without staging them in
# temporary space.
#
# The build stage can be purged with `spack clean --stage`.
build_stage:
- $tempdir
- $spack/var/spack/stage
# Cache directory for already downloaded source tarballs and archived
# repositories. This can be purged with `spack clean --downloads`.
source_cache: $spack/var/spack/cache
# Cache directory for miscellaneous files, like the package index.
# This can be purged with `spack clean --misc-cache`
misc_cache: ~/.spack/cache
# If this is false, tools like curl that use SSL will not verify
# certifiates. (e.g., curl will use use the -k option)
verify_ssl: true
# If set to true, Spack will attempt to build any compiler on the spec
# that is not already available. If set to False, Spack will only use
# compilers already configured in compilers.yaml
install_missing_compilers: False
# If set to true, Spack will always check checksums after downloading
# archives. If false, Spack skips the checksum step.
checksum: true
# If set to true, `spack install` and friends will NOT clean
# potentially harmful variables from the build environment. Use wisely.
dirty: false
# The language the build environment will use. This will produce English
# compiler messages by default, so the log parser can highlight errors.
# If set to C, it will use English (see man locale).
# If set to the empty string (''), it will use the language from the
# user's environment.
build_language: C
# When set to true, concurrent instances of Spack will use locks to
# avoid modifying the install tree, database file, etc. If false, Spack
# will disable all locking, but you must NOT run concurrent instances
# of Spack. For filesystems that don't support locking, you should set
# this to false and run one Spack at a time, but otherwise we recommend
# enabling locks.
locks: true
# The default number of jobs to use when running `make` in parallel.
# If set to 4, for example, `spack install` will run `make -j4`.
# If not set, all available cores are used by default.
# build_jobs: 4
# If set to true, Spack will use ccache to cache C compiles.
ccache: false
# How long to wait to lock the Spack installation database. This lock is used
# when Spack needs to manage its own package metadata and all operations are
# expected to complete within the default time limit. The timeout should
# therefore generally be left untouched.
db_lock_timeout: 120
# How long to wait when attempting to modify a package (e.g. to install it).
# This value should typically be 'null' (never time out) unless the Spack
# instance only ever has a single user at a time, and only if the user
# anticipates that a significant delay indicates that the lock attempt will
# never succeed.
package_lock_timeout: null
These settings can be overridden in etc/spack/config.yaml
or
~/.spack/config.yaml
. See Configuration Scopes for details.
install_tree
¶
The location where Spack will install packages and their dependencies.
Default is $spack/opt/spack
.
install_hash_length
and install_path_scheme
¶
The default Spack installation path can be very long and can create
problems for scripts with hardcoded shebangs. There are two parameters
to help with that. Firstly, the install_hash_length
parameter can
set the length of the hash in the installation path from 1 to 32. The
default path uses the full 32 characters.
Secondly, it is
also possible to modify the entire installation scheme. By default
Spack uses
{architecture}/{compiler.name}-{compiler.version}/{name}-{version}-{hash}
where the tokens that are available for use in this directive are the
same as those understood by the Spec.format
method. Using this parameter it
is possible to use a different package layout or reduce the depth of
the installation paths. For example
config: install_path_scheme: '{name}/{version}/{hash:7}'
would install packages into sub-directories using only the package name, version and a hash length of 7 characters.
When using either parameter to set the hash length it only affects the representation of the hash in the installation directory. You should be aware that the smaller the hash length the more likely naming conflicts will occur. These parameters are independent of those used to configure module names.
警告
Modifying the installation hash length or path scheme after packages have been installed will prevent Spack from being able to find the old installation directories.
module_roots
¶
Controls where Spack installs generated module files. You can customize the location for each type of module. e.g.:
module_roots:
tcl: $spack/share/spack/modules
lmod: $spack/share/spack/lmod
dotkit: $spack/share/spack/dotkit
See モジュール for details.
build_stage
¶
Spack is designed to run out of a user home directory, and on many systems the home directory is a (slow) network file system. On most systems, building in a temporary file system results in faster builds than building in the home directory. Usually, there is also more space available in the temporary location than in the home directory. So, Spack tries to create build stages in temporary space.
By default, Spack's build_stage
is configured like this:
build_stage:
- $tempdir
- $spack/var/spack/stage
This is an ordered list of paths that Spack should search when trying to
find a temporary directory for the build stage. The list is searched in
order, and Spack will use the first directory to which it has write access.
See Config File Variables for more on $tempdir
and $spack
.
When Spack builds a package, it creates a temporary directory within the
build_stage
, and it creates a symbolic link to that directory in
$spack/var/spack/stage
. This is used to track the temporary
directory. After the package is successfully installed, Spack deletes
the temporary directory it used to build. Unsuccessful builds are not
deleted, but you can manually purge them with spack clean --stage.
注釈
The last item in the list is $spack/var/spack/stage
. If this is the
only writable directory in the build_stage
list, Spack will build
directly in $spack/var/spack/stage
and will not link to temporary
space.
source_cache
¶
Location to cache downloaded tarballs and repositories. By default these
are stored in $spack/var/spack/cache
. These are stored indefinitely
by default. Can be purged with spack clean --downloads.
misc_cache
¶
Temporary directory to store long-lived cache files, such as indices of
packages available in repositories. Defaults to ~/.spack/cache
. Can
be purged with spack clean --misc-cache.
verify_ssl
¶
When set to true
(default) Spack will verify certificates of remote
hosts when making ssl
connections. Set to false
to disable, and
tools like curl
will use their --insecure
options. Disabling
this can expose you to attacks. Use at your own risk.
checksum
¶
When set to true
, Spack verifies downloaded source code using a
checksum, and will refuse to build packages that it cannot verify. Set
to false
to disable these checks. Disabling this can expose you to
attacks. Use at your own risk.
locks
¶
When set to true
, concurrent instances of Spack will use locks to
avoid modifying the install tree, database file, etc. If false, Spack
will disable all locking, but you must not run concurrent instances
of Spack. For file systems that don't support locking, you should set
this to false
and run one Spack at a time, but otherwise we recommend
enabling locks.
dirty
¶
By default, Spack unsets variables in your environment that can change
the way packages build. This includes LD_LIBRARY_PATH
, CPATH
,
LIBRARY_PATH
, DYLD_LIBRARY_PATH
, and others.
By default, builds are clean
, but on some machines, compilers and
other tools may need custom LD_LIBRARY_PATH
settings to run. You can
set dirty
to true
to skip the cleaning step and make all builds
"dirty" by default. Be aware that this will reduce the reproducibility
of builds.
build_jobs
¶
Unless overridden in a package or on the command line, Spack builds all
packages in parallel. For a build system that uses Makefiles, this means
running make -j<build_jobs>
, where build_jobs
is the number of
threads to use.
The default parallelism is equal to the number of cores on your machine.
If you work on a shared login node or have a strict ulimit, it may be
necessary to set the default to a lower value. By setting build_jobs
to 4, for example, commands like spack install
will run make -j4
instead of hogging every core.
To build all software in serial, set build_jobs
to 1.
ccache
¶
When set to true
Spack will use ccache to cache compiles. This is
useful specifically in two cases: (1) when using spack setup
, and (2)
when building the same package with many different variants. The default is
false
.
When enabled, Spack will look inside your PATH
for a ccache
executable and stop if it is not found. Some systems come with
ccache
, but it can also be installed using spack install
ccache
. ccache
comes with reasonable defaults for cache size
and location. (See the Configuration settings section of man
ccache
to learn more about the default settings and how to change
them). Please note that we currently disable ccache's hash_dir
feature to avoid an issue with the stage directory (see
https://github.com/LLNL/spack/pull/3761#issuecomment-294352232).