c141e99e06
* When cleaning the stage root, only remove directories that appear to be used for staging Spack packages. Previously Spack was clearing all directories in the stage root, which could remove content not related to Spack if the user chose a staging root which contains files/directories not managed by Spack. * The documentation is updated with warnings about choosing a stage directory that is only managed by Spack (although generally the check added in this PR for "spack clean" should avoid removing content that was not created by Spack) * The default stage directory (in config.yaml) is now $tempdir/$user/spack-stage and the logic is updated to omit the $user portion of this path if $tempdir already contains a $user directory. * When creating stage root assign user read/write permissions to all directories in the path under $user. Previously Spack was assigning the permissions of the first existing parent directory
142 lines
5.3 KiB
YAML
142 lines
5.3 KiB
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.
|
|
#
|
|
# Recommended options are given below.
|
|
#
|
|
# Builds can be faster in temporary directories on some (e.g., HPC) systems.
|
|
# Specifying `$tempdir` will ensure use of the default temporary directory
|
|
# (i.e., ``$TMP` or ``$TMPDIR``).
|
|
#
|
|
# Another option that prevents conflicts and potential permission issues is
|
|
# to specify `~/.spack/stage`, which ensures each user builds in their home
|
|
# directory.
|
|
#
|
|
# A more traditional path uses the value of `$spack/var/spack/stage`, which
|
|
# builds directly inside Spack's instance without staging them in a
|
|
# temporary space. Problems with specifying a path inside a Spack instance
|
|
# are that it precludes its use as a system package and its ability to be
|
|
# pip installable.
|
|
#
|
|
# In any case, if the username is not already in the path, Spack will append
|
|
# the value of `$user` in an attempt to avoid potential conflicts between
|
|
# users in shared temporary spaces.
|
|
#
|
|
# The build stage can be purged with `spack clean --stage` and
|
|
# `spack clean -a`, so it is important that the specified directory uniquely
|
|
# identifies Spack staging to avoid accidentally wiping out non-Spack work.
|
|
build_stage:
|
|
- $tempdir/$user/spack-stage
|
|
- ~/.spack/stage
|
|
# - $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 maximum number of jobs to use when running `make` in parallel,
|
|
# always limited by the number of cores available. For instance:
|
|
# - If set to 16 on a 4 cores machine `spack install` will run `make -j4`
|
|
# - If set to 16 on a 18 cores machine `spack install` will run `make -j16`
|
|
# If not set, Spack will use all available cores up to 16.
|
|
# build_jobs: 16
|
|
|
|
|
|
# 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
|