2016-10-28 01:57:27 +08:00
|
|
|
# -------------------------------------------------------------------------
|
|
|
|
# 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
|
|
|
|
|
2018-05-19 05:41:03 +08:00
|
|
|
|
2017-09-20 03:34:20 +08:00
|
|
|
# Locations where templates should be found
|
|
|
|
template_dirs:
|
2018-03-24 14:16:37 +08:00
|
|
|
- $spack/share/spack/templates
|
2016-10-28 01:57:27 +08:00
|
|
|
|
2018-05-19 05:41:03 +08:00
|
|
|
|
2018-11-12 13:10:05 +08:00
|
|
|
# Default directory layout
|
2018-10-11 09:54:58 +08:00
|
|
|
install_path_scheme: "${ARCHITECTURE}/${COMPILERNAME}-${COMPILERVER}/${PACKAGE}-${VERSION}-${HASH}"
|
2018-03-24 03:05:07 +08:00
|
|
|
|
2018-05-19 05:41:03 +08:00
|
|
|
|
2016-10-28 14:32:42 +08:00
|
|
|
# Locations where different types of modules should be installed.
|
|
|
|
module_roots:
|
|
|
|
tcl: $spack/share/spack/modules
|
|
|
|
lmod: $spack/share/spack/lmod
|
|
|
|
|
|
|
|
|
2016-10-28 01:57:27 +08:00
|
|
|
# Temporary locations Spack can try to use for builds.
|
|
|
|
#
|
2019-08-20 01:31:24 +08:00
|
|
|
# Recommended options are given below.
|
2016-10-28 01:57:27 +08:00
|
|
|
#
|
2019-08-20 01:31:24 +08:00
|
|
|
# Builds can be faster in temporary directories on some (e.g., HPC) systems.
|
2019-09-04 07:31:27 +08:00
|
|
|
# Specifying `$tempdir` will ensure use of the default temporary directory
|
|
|
|
# (i.e., ``$TMP` or ``$TMPDIR``).
|
2019-08-20 01:31:24 +08:00
|
|
|
#
|
|
|
|
# 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
|
2019-09-04 07:31:27 +08:00
|
|
|
# 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.
|
2016-10-28 15:57:51 +08:00
|
|
|
#
|
2019-08-20 01:31:24 +08:00
|
|
|
# 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.
|
2016-10-28 01:57:27 +08:00
|
|
|
build_stage:
|
2019-09-04 07:31:27 +08:00
|
|
|
- $tempdir/$user/spack-stage
|
|
|
|
- ~/.spack/stage
|
|
|
|
# - $spack/var/spack/stage
|
2016-10-28 01:57:27 +08:00
|
|
|
|
|
|
|
|
2018-11-12 13:10:05 +08:00
|
|
|
# Cache directory for already downloaded source tarballs and archived
|
2018-03-25 21:49:55 +08:00
|
|
|
# repositories. This can be purged with `spack clean --downloads`.
|
2016-10-28 01:57:27 +08:00
|
|
|
source_cache: $spack/var/spack/cache
|
|
|
|
|
|
|
|
|
|
|
|
# Cache directory for miscellaneous files, like the package index.
|
2018-03-25 21:49:55 +08:00
|
|
|
# This can be purged with `spack clean --misc-cache`
|
2016-10-28 01:57:27 +08:00
|
|
|
misc_cache: ~/.spack/cache
|
|
|
|
|
|
|
|
|
2020-02-25 23:42:12 +08:00
|
|
|
# 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
|
|
|
|
|
|
|
|
|
2016-10-28 01:57:27 +08:00
|
|
|
# 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
|
|
|
|
|
|
|
|
|
2019-11-15 08:22:01 +08:00
|
|
|
# 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
|
|
|
|
|
|
|
|
|
2019-03-08 09:30:48 +08:00
|
|
|
# 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
|
|
|
|
|
|
|
|
|
2016-10-28 01:57:27 +08:00
|
|
|
# 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
|
2017-04-15 23:31:00 +08:00
|
|
|
|
|
|
|
|
2018-10-19 03:55:58 +08:00
|
|
|
# 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
|
|
|
|
|
|
|
|
|
2018-05-19 05:41:03 +08:00
|
|
|
# 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
|
|
|
|
|
|
|
|
|
2019-05-28 21:42:04 +08:00
|
|
|
# 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
|
2018-07-10 05:06:10 +08:00
|
|
|
|
|
|
|
|
2018-11-12 13:10:05 +08:00
|
|
|
# If set to true, Spack will use ccache to cache C compiles.
|
2018-07-10 05:06:10 +08:00
|
|
|
ccache: false
|
2018-09-26 09:58:51 +08:00
|
|
|
|
2018-11-12 13:10:05 +08:00
|
|
|
|
2018-09-26 09:58:51 +08:00
|
|
|
# How long to wait to lock the Spack installation database. This lock is used
|
2018-11-12 13:10:05 +08:00
|
|
|
# when Spack needs to manage its own package metadata and all operations are
|
2018-09-26 09:58:51 +08:00
|
|
|
# expected to complete within the default time limit. The timeout should
|
|
|
|
# therefore generally be left untouched.
|
Distributed builds (#13100)
Fixes #9394
Closes #13217.
## Background
Spack provides the ability to enable/disable parallel builds through two options: package `parallel` and configuration `build_jobs`. This PR changes the algorithm to allow multiple, simultaneous processes to coordinate the installation of the same spec (and specs with overlapping dependencies.).
The `parallel` (boolean) property sets the default for its package though the value can be overridden in the `install` method.
Spack's current parallel builds are limited to build tools supporting `jobs` arguments (e.g., `Makefiles`). The number of jobs actually used is calculated as`min(config:build_jobs, # cores, 16)`, which can be overridden in the package or on the command line (i.e., `spack install -j <# jobs>`).
This PR adds support for distributed (single- and multi-node) parallel builds. The goals of this work include improving the efficiency of installing packages with many dependencies and reducing the repetition associated with concurrent installations of (dependency) packages.
## Approach
### File System Locks
Coordination between concurrent installs of overlapping packages to a Spack instance is accomplished through bottom-up dependency DAG processing and file system locks. The runs can be a combination of interactive and batch processes affecting the same file system. Exclusive prefix locks are required to install a package while shared prefix locks are required to check if the package is installed.
Failures are communicated through a separate exclusive prefix failure lock, for concurrent processes, combined with a persistent store, for separate, related build processes. The resulting file contains the failing spec to facilitate manual debugging.
### Priority Queue
Management of dependency builds changed from reliance on recursion to use of a priority queue where the priority of a spec is based on the number of its remaining uninstalled dependencies.
Using a queue required a change to dependency build exception handling with the most visible issue being that the `install` method *must* install something in the prefix. Consequently, packages can no longer get away with an install method consisting of `pass`, for example.
## Caveats
- This still only parallelizes a single-rooted build. Multi-rooted installs (e.g., for environments) are TBD in a future PR.
Tasks:
- [x] Adjust package lock timeout to correspond to value used in the demo
- [x] Adjust database lock timeout to reduce contention on startup of concurrent
`spack install <spec>` calls
- [x] Replace (test) package's `install: pass` methods with file creation since post-install
`sanity_check_prefix` will otherwise error out with `Install failed .. Nothing was installed!`
- [x] Resolve remaining existing test failures
- [x] Respond to alalazo's initial feedback
- [x] Remove `bin/demo-locks.py`
- [x] Add new tests to address new coverage issues
- [x] Replace built-in package's `def install(..): pass` to "install" something
(i.e., only `apple-libunwind`)
- [x] Increase code coverage
2020-02-19 16:04:22 +08:00
|
|
|
db_lock_timeout: 3
|
2018-09-26 09:58:51 +08:00
|
|
|
|
2018-11-12 13:10:05 +08:00
|
|
|
|
2018-09-26 09:58:51 +08:00
|
|
|
# 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
|
2019-10-24 04:22:24 +08:00
|
|
|
|
|
|
|
# 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'
|
2020-05-08 08:21:53 +08:00
|
|
|
|
|
|
|
# Set to 'false' to allow installation on filesystems that doesn't allow setgid bit
|
|
|
|
# manipulation by unprivileged user (e.g. AFS)
|
|
|
|
config:allow_sgid: true
|