800ed16e7a
The concretizer is going to grow to have many more configuration, and we really need some structured config for that. * We have the `config:concretizer` option that chooses the solver, but extending that is awkward (we'd need to replace a string with a `dict`) and the solver choice will be deprecated eventually. * We have the `concretization` option in environments, but it's not a top-level config section -- it's just for environments, and it also only admits a string right now. To avoid overlapping with either of these and to allow the most extensibility in the future, this adds a new `concretizer` config section that can be used in and outside of environments. There is only one option right now: `reuse`. This can expand to include other options later. Likely, we will soon deprecate `config:concretizer` and warn when the user doesn't use `clingo`, and we will eventually (sometime later) move the `together` / `separately` options from `concretization` into the top-level `concretizer` section. This commit just adds the new section and schema. Fully wiring it up is TBD.
200 lines
8 KiB
YAML
200 lines
8 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:
|
|
root: $spack/opt/spack
|
|
projections:
|
|
all: "${ARCHITECTURE}/${COMPILERNAME}-${COMPILERVER}/${PACKAGE}-${VERSION}-${HASH}"
|
|
# install_tree can include an optional padded length (int or boolean)
|
|
# default is False (do not pad)
|
|
# if padded_length is True, Spack will pad as close to the system max path
|
|
# length as possible
|
|
# if padded_length is an integer, Spack will pad to that many characters,
|
|
# assuming it is higher than the length of the install_tree root.
|
|
# padded_length: 128
|
|
|
|
|
|
# Locations where templates should be found
|
|
template_dirs:
|
|
- $spack/share/spack/templates
|
|
|
|
# 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 `$user_cache_path/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
|
|
- $user_cache_path/stage
|
|
# - $spack/var/spack/stage
|
|
|
|
# Directory in which to run tests and store test results.
|
|
# Tests will be stored in directories named by date/time and package
|
|
# name/hash.
|
|
test_stage: $user_cache_path/test
|
|
|
|
# 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: $user_cache_path/cache
|
|
|
|
|
|
# Timeout in seconds used for downloading sources etc. This only applies
|
|
# to the connection phase and can be increased for slow connections or
|
|
# servers. 0 means no timeout.
|
|
connect_timeout: 10
|
|
|
|
|
|
# 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
|
|
|
|
|
|
# Suppress gpg warnings from binary package verification
|
|
# Only suppresses warnings, gpg failure will still fail the install
|
|
# Potential rationale to set True: users have already explicitly trusted the
|
|
# gpg key they are using, and may not want to see repeated warnings that it
|
|
# is self-signed or something of the sort.
|
|
suppress_gpg_warnings: false
|
|
|
|
|
|
# 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 will fetch deprecated versions without warning.
|
|
# If false, Spack will raise an error when trying to install a deprecated version.
|
|
deprecated: false
|
|
|
|
|
|
# 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 url fetch method to use.
|
|
# If set to 'curl', Spack will require curl on the user's system
|
|
# If set to 'urllib', Spack will use python built-in libs to fetch
|
|
url_fetch_method: urllib
|
|
|
|
# The maximum number of jobs to use for the build system (e.g. `make`), when
|
|
# the -j flag is not given on the command line. Defaults to 16 when not set.
|
|
# Note that the maximum number of jobs is limited by the number of cores
|
|
# available, taking thread affinity into account when supported. For instance:
|
|
# - With `build_jobs: 16` and 4 cores available `spack install` will run `make -j4`
|
|
# - With `build_jobs: 16` and 32 cores available `spack install` will run `make -j16`
|
|
# - With `build_jobs: 2` and 4 cores available `spack install -j6` will run `make -j6`
|
|
# build_jobs: 16
|
|
|
|
|
|
# If set to true, Spack will use ccache to cache C compiles.
|
|
ccache: false
|
|
|
|
|
|
# The concretization algorithm to use in Spack. Options are:
|
|
#
|
|
# 'clingo': Uses a logic solver under the hood to solve DAGs with full
|
|
# backtracking and optimization for user preferences. Spack will
|
|
# try to bootstrap the logic solver, if not already available.
|
|
#
|
|
# 'original': Spack's original greedy, fixed-point concretizer. This
|
|
# algorithm can make decisions too early and will not backtrack
|
|
# sufficiently for many specs. This will soon be deprecated in
|
|
# favor of clingo.
|
|
#
|
|
# See `concretizer.yaml` for more settings you can fine-tune when
|
|
# using clingo.
|
|
concretizer: clingo
|
|
|
|
|
|
# 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: 3
|
|
|
|
|
|
# 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
|
|
|
|
|
|
# Control whether Spack embeds RPATH or RUNPATH attributes in ELF binaries.
|
|
# Has no effect on macOS. DO NOT MIX these within the same install tree.
|
|
# See the Spack documentation for details.
|
|
shared_linking: 'rpath'
|
|
|
|
|
|
# Set to 'false' to allow installation on filesystems that doesn't allow setgid bit
|
|
# manipulation by unprivileged user (e.g. AFS)
|
|
allow_sgid: true
|
|
|
|
# Whether to set the terminal title to display status information during
|
|
# building and installing packages. This gives information about Spack's
|
|
# current progress as well as the current and total number of packages.
|
|
terminal_title: false
|