1db6cd5d16
* Make -j flag less exceptional The -j flag in spack behaves differently from make, ctest, ninja, etc, because it caps the number of jobs to an arbitrary number 16. Spack will behave like other tools if `spack install` uses a reasonable default, and `spack install -j <num>` *overrides* that default. This will be particularly useful for Spack usage outside of a traditional HPC context and for HPC centers that encourage users to compile on login nodes with many cores instead of on compute nodes, which has become increasingly common as individual nodes have more cores. This maintains the existing default value of min(num_cpus, 16). However, as it is right now, Spack does a poor job at determining the number of cpus on linux, since it doesn't take cgroups into account. This is particularly problematic when using distributed builds with slurm. This PR also introduces `spack.util.cpus.cpus_available()` to consolidate knowledge on determining the number of available cores, and improves core detection for linux. This should also improve core detection for Docker/ Kubernetes, which also use cgroups.
196 lines
7.6 KiB
YAML
196 lines
7.6 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
|
|
|
|
|
|
# Locations where different types of modules should be installed.
|
|
module_roots:
|
|
tcl: $spack/share/spack/modules
|
|
lmod: $spack/share/spack/lmod
|
|
|
|
|
|
# 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
|
|
|
|
# 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: ~/.spack/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: ~/.spack/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 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:
|
|
#
|
|
# 'original': Spack's original greedy, fixed-point concretizer. This
|
|
# algorithm can make decisions too early and will not backtrack
|
|
# sufficiently for many specs.
|
|
#
|
|
# 'clingo': Uses a logic solver under the hood to solve DAGs with full
|
|
# backtracking and optimization for user preferences.
|
|
#
|
|
# 'clingo' currently requires the clingo ASP solver to be installed and
|
|
# built with python bindings. 'original' is built in.
|
|
concretizer: original
|
|
|
|
|
|
# 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
|