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.
|
2020-09-26 00:15:49 +08:00
|
|
|
install_tree:
|
|
|
|
root: $spack/opt/spack
|
|
|
|
projections:
|
2022-11-29 02:03:49 +08:00
|
|
|
all: "{architecture}/{compiler.name}-{compiler.version}/{name}-{version}-{hash}"
|
2020-11-13 08:08:55 +08:00
|
|
|
# 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
|
2016-10-28 01:57:27 +08:00
|
|
|
|
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
|
|
|
|
2022-05-19 09:26:42 +08:00
|
|
|
# Directory where licenses should be located
|
|
|
|
license_dir: $spack/etc/spack/licenses
|
|
|
|
|
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
|
config: overrides for caches and system and user scopes (#26735)
Spack's `system` and `user` scopes provide ways for administrators and
users to set global defaults for all Spack instances, but for use cases
where one wants a clean Spack installation, these scopes can be undesirable.
For example, users may want to opt out of global system configuration, or
they may want to ignore their own home directory settings when running in
a continuous integration environment.
Spack also, by default, keeps various caches and user data in `~/.spack`,
but users may want to override these locations.
Spack provides three environment variables that allow you to override or
opt out of configuration locations:
* `SPACK_USER_CONFIG_PATH`: Override the path to use for the
`user` (`~/.spack`) scope.
* `SPACK_SYSTEM_CONFIG_PATH`: Override the path to use for the
`system` (`/etc/spack`) scope.
* `SPACK_DISABLE_LOCAL_CONFIG`: set this environment variable to completely
disable *both* the system and user configuration directories. Spack will
only consider its own defaults and `site` configuration locations.
And one that allows you to move the default cache location:
* `SPACK_USER_CACHE_PATH`: Override the default path to use for user data
(misc_cache, tests, reports, etc.)
With these settings, if you want to isolate Spack in a CI environment, you can do this:
export SPACK_DISABLE_LOCAL_CONFIG=true
export SPACK_USER_CACHE_PATH=/tmp/spack
This is a stop-gap approach until we have figured out how to deal with
the system and user config scopes more generally, as there are plans to
potentially / eventually get rid of them.
**User config**
Spack is a bit of a pain when you have:
- a shared $HOME folder across different systems.
- multiple Spack versions on the same system.
**System config**
- On shared systems with a versioned programming environment / toolkit,
system administrators want to provide config for each version (e.g.
21.09, 21.10) of the programming environment, and the user Spack
instance should be able to pick this up without a steep learning
curve.
- On shared systems the user should be able to opt out of the
hard-coded config scope in /etc/spack, since it may be incompatible
with their particular instance. Currently Spack can only opt out of all
config scopes through overrides with `"config:":`, `"packages:":`, but that
also drops the defaults config, which would have to be repeated, which
is undesirable, especially the lengthy packages.yaml.
An example use case is: having config in this folder:
```
/path/to/programming/environment/{version}/{compilers,packages}.yaml
```
and have `module load spack-system-config` set the variable
```
SPACK_SYSTEM_CONFIG_PATH=/path/to/programming/environment/{version}
```
where the user no longer has to worry about what `{version}` they are
on.
**Continuous integration**
Finally, there is the use case of continuous integration, which may
clone an arbitrary Spack version, which optimally should not pick up
system or user config from the previous run (like may happen in
classical bare metal non-containerized filesystem side effect ridden
jenkins pipelines). In fact this is very similar to how spack itself
tries to avoid picking up system dependencies during builds...
**But environments solve this?**
- You could do `include`s in environment files to get similar behavior
to the spack_system_config_path example, but environments require you
to:
1) require paths to individual config files, not directories.
2) fail if the listed config file does not exist
- They allow you to override config scopes, but this is generally too
rigurous, as it requires you to repeat the default config, in
particular packages.yaml, and just defies the point of layered config.
Co-authored-by: Tom Scogland <tscogland@llnl.gov>
Co-authored-by: Tim Fuller <tjfulle@sandia.gov>
Co-authored-by: Steve Leak <sleak@lbl.gov>
Co-authored-by: Todd Gamblin <tgamblin@llnl.gov>
2021-09-29 22:36:28 +08:00
|
|
|
# to specify `$user_cache_path/stage`, which ensures each user builds in their
|
|
|
|
# home directory.
|
2019-08-20 01:31:24 +08:00
|
|
|
#
|
|
|
|
# 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.
|
|
|
|
#
|
2023-01-17 17:06:00 +08:00
|
|
|
# In Spack environment files, chaining onto existing system Spack
|
|
|
|
# installations, the $env variable can be used to download, cache and build
|
|
|
|
# into user-writable paths that are relative to the currently active
|
|
|
|
# environment.
|
|
|
|
#
|
2019-09-04 07:31:27 +08:00
|
|
|
# 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
|
config: overrides for caches and system and user scopes (#26735)
Spack's `system` and `user` scopes provide ways for administrators and
users to set global defaults for all Spack instances, but for use cases
where one wants a clean Spack installation, these scopes can be undesirable.
For example, users may want to opt out of global system configuration, or
they may want to ignore their own home directory settings when running in
a continuous integration environment.
Spack also, by default, keeps various caches and user data in `~/.spack`,
but users may want to override these locations.
Spack provides three environment variables that allow you to override or
opt out of configuration locations:
* `SPACK_USER_CONFIG_PATH`: Override the path to use for the
`user` (`~/.spack`) scope.
* `SPACK_SYSTEM_CONFIG_PATH`: Override the path to use for the
`system` (`/etc/spack`) scope.
* `SPACK_DISABLE_LOCAL_CONFIG`: set this environment variable to completely
disable *both* the system and user configuration directories. Spack will
only consider its own defaults and `site` configuration locations.
And one that allows you to move the default cache location:
* `SPACK_USER_CACHE_PATH`: Override the default path to use for user data
(misc_cache, tests, reports, etc.)
With these settings, if you want to isolate Spack in a CI environment, you can do this:
export SPACK_DISABLE_LOCAL_CONFIG=true
export SPACK_USER_CACHE_PATH=/tmp/spack
This is a stop-gap approach until we have figured out how to deal with
the system and user config scopes more generally, as there are plans to
potentially / eventually get rid of them.
**User config**
Spack is a bit of a pain when you have:
- a shared $HOME folder across different systems.
- multiple Spack versions on the same system.
**System config**
- On shared systems with a versioned programming environment / toolkit,
system administrators want to provide config for each version (e.g.
21.09, 21.10) of the programming environment, and the user Spack
instance should be able to pick this up without a steep learning
curve.
- On shared systems the user should be able to opt out of the
hard-coded config scope in /etc/spack, since it may be incompatible
with their particular instance. Currently Spack can only opt out of all
config scopes through overrides with `"config:":`, `"packages:":`, but that
also drops the defaults config, which would have to be repeated, which
is undesirable, especially the lengthy packages.yaml.
An example use case is: having config in this folder:
```
/path/to/programming/environment/{version}/{compilers,packages}.yaml
```
and have `module load spack-system-config` set the variable
```
SPACK_SYSTEM_CONFIG_PATH=/path/to/programming/environment/{version}
```
where the user no longer has to worry about what `{version}` they are
on.
**Continuous integration**
Finally, there is the use case of continuous integration, which may
clone an arbitrary Spack version, which optimally should not pick up
system or user config from the previous run (like may happen in
classical bare metal non-containerized filesystem side effect ridden
jenkins pipelines). In fact this is very similar to how spack itself
tries to avoid picking up system dependencies during builds...
**But environments solve this?**
- You could do `include`s in environment files to get similar behavior
to the spack_system_config_path example, but environments require you
to:
1) require paths to individual config files, not directories.
2) fail if the listed config file does not exist
- They allow you to override config scopes, but this is generally too
rigurous, as it requires you to repeat the default config, in
particular packages.yaml, and just defies the point of layered config.
Co-authored-by: Tom Scogland <tscogland@llnl.gov>
Co-authored-by: Tim Fuller <tjfulle@sandia.gov>
Co-authored-by: Steve Leak <sleak@lbl.gov>
Co-authored-by: Todd Gamblin <tgamblin@llnl.gov>
2021-09-29 22:36:28 +08:00
|
|
|
- $user_cache_path/stage
|
2019-09-04 07:31:27 +08:00
|
|
|
# - $spack/var/spack/stage
|
2016-10-28 01:57:27 +08:00
|
|
|
|
spack test (#15702)
Users can add test() methods to their packages to run smoke tests on
installations with the new `spack test` command (the old `spack test` is
now `spack unit-test`). spack test is environment-aware, so you can
`spack install` an environment and then run `spack test run` to run smoke
tests on all of its packages. Historical test logs can be perused with
`spack test results`. Generic smoke tests for MPI implementations, C,
C++, and Fortran compilers as well as specific smoke tests for 18
packages.
Inside the test method, individual tests can be run separately (and
continue to run best-effort after a test failure) using the `run_test`
method. The `run_test` method encapsulates finding test executables,
running and checking return codes, checking output, and error handling.
This handles the following trickier aspects of testing with direct
support in Spack's package API:
- [x] Caching source or intermediate build files at build time for
use at test time.
- [x] Test dependencies,
- [x] packages that require a compiler for testing (such as library only
packages).
See the packaging guide for more details on using Spack testing support.
Included is support for package.py files for virtual packages. This does
not change the Spack interface, but is a major change in internals.
Co-authored-by: Tamara Dahlgren <dahlgren1@llnl.gov>
Co-authored-by: wspear <wjspear@gmail.com>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
2020-11-18 18:39:02 +08:00
|
|
|
# Directory in which to run tests and store test results.
|
|
|
|
# Tests will be stored in directories named by date/time and package
|
|
|
|
# name/hash.
|
config: overrides for caches and system and user scopes (#26735)
Spack's `system` and `user` scopes provide ways for administrators and
users to set global defaults for all Spack instances, but for use cases
where one wants a clean Spack installation, these scopes can be undesirable.
For example, users may want to opt out of global system configuration, or
they may want to ignore their own home directory settings when running in
a continuous integration environment.
Spack also, by default, keeps various caches and user data in `~/.spack`,
but users may want to override these locations.
Spack provides three environment variables that allow you to override or
opt out of configuration locations:
* `SPACK_USER_CONFIG_PATH`: Override the path to use for the
`user` (`~/.spack`) scope.
* `SPACK_SYSTEM_CONFIG_PATH`: Override the path to use for the
`system` (`/etc/spack`) scope.
* `SPACK_DISABLE_LOCAL_CONFIG`: set this environment variable to completely
disable *both* the system and user configuration directories. Spack will
only consider its own defaults and `site` configuration locations.
And one that allows you to move the default cache location:
* `SPACK_USER_CACHE_PATH`: Override the default path to use for user data
(misc_cache, tests, reports, etc.)
With these settings, if you want to isolate Spack in a CI environment, you can do this:
export SPACK_DISABLE_LOCAL_CONFIG=true
export SPACK_USER_CACHE_PATH=/tmp/spack
This is a stop-gap approach until we have figured out how to deal with
the system and user config scopes more generally, as there are plans to
potentially / eventually get rid of them.
**User config**
Spack is a bit of a pain when you have:
- a shared $HOME folder across different systems.
- multiple Spack versions on the same system.
**System config**
- On shared systems with a versioned programming environment / toolkit,
system administrators want to provide config for each version (e.g.
21.09, 21.10) of the programming environment, and the user Spack
instance should be able to pick this up without a steep learning
curve.
- On shared systems the user should be able to opt out of the
hard-coded config scope in /etc/spack, since it may be incompatible
with their particular instance. Currently Spack can only opt out of all
config scopes through overrides with `"config:":`, `"packages:":`, but that
also drops the defaults config, which would have to be repeated, which
is undesirable, especially the lengthy packages.yaml.
An example use case is: having config in this folder:
```
/path/to/programming/environment/{version}/{compilers,packages}.yaml
```
and have `module load spack-system-config` set the variable
```
SPACK_SYSTEM_CONFIG_PATH=/path/to/programming/environment/{version}
```
where the user no longer has to worry about what `{version}` they are
on.
**Continuous integration**
Finally, there is the use case of continuous integration, which may
clone an arbitrary Spack version, which optimally should not pick up
system or user config from the previous run (like may happen in
classical bare metal non-containerized filesystem side effect ridden
jenkins pipelines). In fact this is very similar to how spack itself
tries to avoid picking up system dependencies during builds...
**But environments solve this?**
- You could do `include`s in environment files to get similar behavior
to the spack_system_config_path example, but environments require you
to:
1) require paths to individual config files, not directories.
2) fail if the listed config file does not exist
- They allow you to override config scopes, but this is generally too
rigurous, as it requires you to repeat the default config, in
particular packages.yaml, and just defies the point of layered config.
Co-authored-by: Tom Scogland <tscogland@llnl.gov>
Co-authored-by: Tim Fuller <tjfulle@sandia.gov>
Co-authored-by: Steve Leak <sleak@lbl.gov>
Co-authored-by: Todd Gamblin <tgamblin@llnl.gov>
2021-09-29 22:36:28 +08:00
|
|
|
test_stage: $user_cache_path/test
|
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
|
|
|
|
|
|
|
|
|
2023-02-22 08:37:14 +08:00
|
|
|
## Directory where spack managed environments are created and stored
|
|
|
|
# environments_root: $spack/var/spack/environments
|
|
|
|
|
|
|
|
|
2016-10-28 01:57:27 +08:00
|
|
|
# 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`
|
config: overrides for caches and system and user scopes (#26735)
Spack's `system` and `user` scopes provide ways for administrators and
users to set global defaults for all Spack instances, but for use cases
where one wants a clean Spack installation, these scopes can be undesirable.
For example, users may want to opt out of global system configuration, or
they may want to ignore their own home directory settings when running in
a continuous integration environment.
Spack also, by default, keeps various caches and user data in `~/.spack`,
but users may want to override these locations.
Spack provides three environment variables that allow you to override or
opt out of configuration locations:
* `SPACK_USER_CONFIG_PATH`: Override the path to use for the
`user` (`~/.spack`) scope.
* `SPACK_SYSTEM_CONFIG_PATH`: Override the path to use for the
`system` (`/etc/spack`) scope.
* `SPACK_DISABLE_LOCAL_CONFIG`: set this environment variable to completely
disable *both* the system and user configuration directories. Spack will
only consider its own defaults and `site` configuration locations.
And one that allows you to move the default cache location:
* `SPACK_USER_CACHE_PATH`: Override the default path to use for user data
(misc_cache, tests, reports, etc.)
With these settings, if you want to isolate Spack in a CI environment, you can do this:
export SPACK_DISABLE_LOCAL_CONFIG=true
export SPACK_USER_CACHE_PATH=/tmp/spack
This is a stop-gap approach until we have figured out how to deal with
the system and user config scopes more generally, as there are plans to
potentially / eventually get rid of them.
**User config**
Spack is a bit of a pain when you have:
- a shared $HOME folder across different systems.
- multiple Spack versions on the same system.
**System config**
- On shared systems with a versioned programming environment / toolkit,
system administrators want to provide config for each version (e.g.
21.09, 21.10) of the programming environment, and the user Spack
instance should be able to pick this up without a steep learning
curve.
- On shared systems the user should be able to opt out of the
hard-coded config scope in /etc/spack, since it may be incompatible
with their particular instance. Currently Spack can only opt out of all
config scopes through overrides with `"config:":`, `"packages:":`, but that
also drops the defaults config, which would have to be repeated, which
is undesirable, especially the lengthy packages.yaml.
An example use case is: having config in this folder:
```
/path/to/programming/environment/{version}/{compilers,packages}.yaml
```
and have `module load spack-system-config` set the variable
```
SPACK_SYSTEM_CONFIG_PATH=/path/to/programming/environment/{version}
```
where the user no longer has to worry about what `{version}` they are
on.
**Continuous integration**
Finally, there is the use case of continuous integration, which may
clone an arbitrary Spack version, which optimally should not pick up
system or user config from the previous run (like may happen in
classical bare metal non-containerized filesystem side effect ridden
jenkins pipelines). In fact this is very similar to how spack itself
tries to avoid picking up system dependencies during builds...
**But environments solve this?**
- You could do `include`s in environment files to get similar behavior
to the spack_system_config_path example, but environments require you
to:
1) require paths to individual config files, not directories.
2) fail if the listed config file does not exist
- They allow you to override config scopes, but this is generally too
rigurous, as it requires you to repeat the default config, in
particular packages.yaml, and just defies the point of layered config.
Co-authored-by: Tom Scogland <tscogland@llnl.gov>
Co-authored-by: Tim Fuller <tjfulle@sandia.gov>
Co-authored-by: Steve Leak <sleak@lbl.gov>
Co-authored-by: Todd Gamblin <tgamblin@llnl.gov>
2021-09-29 22:36:28 +08:00
|
|
|
misc_cache: $user_cache_path/cache
|
2016-10-28 01:57:27 +08:00
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2024-04-02 02:11:13 +08:00
|
|
|
# This is where custom certs for proxy/firewall are stored.
|
|
|
|
# It can be a path or environment variable. To match ssl env configuration
|
|
|
|
# the default is the environment variable SSL_CERT_FILE
|
|
|
|
ssl_certs: $SSL_CERT_FILE
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2021-02-10 02:51:18 +08:00
|
|
|
# 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
|
|
|
|
|
|
|
|
|
2016-10-28 01:57:27 +08:00
|
|
|
# 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
|
|
|
|
|
2021-10-11 23:54:59 +08:00
|
|
|
# The default url fetch method to use.
|
2021-08-02 16:30:25 +08:00
|
|
|
# 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
|
2018-05-19 05:41:03 +08:00
|
|
|
|
Make -j flag less exceptional (#22360)
* 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.
2021-03-31 03:03:50 +08:00
|
|
|
# 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`
|
2019-05-28 21:42:04 +08:00
|
|
|
# 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
|
|
|
|
|
|
|
# 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.
|
2023-02-17 15:42:41 +08:00
|
|
|
db_lock_timeout: 60
|
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
|
|
|
|
2020-06-08 02:09:18 +08:00
|
|
|
|
2022-11-04 07:34:00 +08:00
|
|
|
# Control how shared libraries are located at runtime on Linux. See the
|
|
|
|
# the Spack documentation for details.
|
|
|
|
shared_linking:
|
|
|
|
# Spack automatically embeds runtime search paths in ELF binaries for their
|
|
|
|
# dependencies. Their type can either be "rpath" or "runpath". For glibc, rpath is
|
|
|
|
# inherited and has precedence over LD_LIBRARY_PATH; runpath is not inherited
|
|
|
|
# and of lower precedence. DO NOT MIX these within the same install tree.
|
|
|
|
type: rpath
|
|
|
|
|
|
|
|
|
|
|
|
# (Experimental) Embed absolute paths of dependent libraries directly in ELF
|
|
|
|
# binaries to avoid runtime search. This can improve startup time of
|
|
|
|
# executables with many dependencies, in particular on slow filesystems.
|
|
|
|
bind: false
|
2020-05-08 08:21:53 +08:00
|
|
|
|
2020-06-08 02:09:18 +08:00
|
|
|
|
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)
|
2020-05-26 00:49:35 +08:00
|
|
|
allow_sgid: true
|
2021-10-11 23:54:59 +08:00
|
|
|
|
2023-07-12 14:54:45 +08:00
|
|
|
# Whether to show 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. Information is shown both in the terminal
|
|
|
|
# title and inline.
|
|
|
|
install_status: true
|
2022-10-19 23:36:27 +08:00
|
|
|
|
|
|
|
# Number of seconds a buildcache's index.json is cached locally before probing
|
|
|
|
# for updates, within a single Spack invocation. Defaults to 10 minutes.
|
Control Werror by converting to Wno-error (#30882)
Using `-Werror` is good practice for development and testing, but causes us a great
deal of heartburn supporting multiple compiler versions, especially as newer compiler
versions add warnings for released packages. This PR adds support for suppressing
`-Werror` through spack's compiler wrappers. There are currently three modes for
the `flags:keep_werror` setting:
* `none`: (default) cancel all `-Werror`, `-Werror=*` and `-Werror-*` flags by
converting them to `-Wno-error[=]*` flags
* `specific`: preserve explicitly selected warnings as errors, such as
`-Werror=format-truncation`, but reverse the blanket `-Werror`
* `all`: keeps all `-Werror` flags
These can be set globally in config.yaml, through the config command-line flags, or
overridden by a particular package (some packages use Werror as a proxy for determining
support for other compiler features). We chose to use this approach because:
1. removing `-Werror` flags entirely broke *many* build systems, especially autoconf
based ones, because of things like checking `-Werror=feature` and making the
assumption that if that did not error other flags related to that feature would also work
2. Attempting to preserve `-Werror` in some phases but not others caused similar issues
3. The per-package setting came about because some packages, even with all these
protections, still use `-Werror` unsafely. Currently there are roughly 3 such packages
known.
2022-11-24 04:29:17 +08:00
|
|
|
binary_index_ttl: 600
|
|
|
|
|
|
|
|
flags:
|
|
|
|
# Whether to keep -Werror flags active in package builds.
|
|
|
|
keep_werror: 'none'
|
2023-11-07 06:37:46 +08:00
|
|
|
|
|
|
|
# A mapping of aliases that can be used to define new commands. For instance,
|
|
|
|
# `sp: spec -I` will define a new command `sp` that will execute `spec` with
|
|
|
|
# the `-I` argument. Aliases cannot override existing commands.
|
|
|
|
aliases:
|
|
|
|
concretise: concretize
|
|
|
|
containerise: containerize
|
|
|
|
rm: remove
|