path: root/etc/spack/defaults/config.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}/{compiler.name}-{compiler.version}/{name}-{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

  # Directory where licenses should be located
  license_dir: $spack/etc/spack/licenses

  # 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 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.
  #
  # 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


  ## Directory where spack managed environments are created and stored
  # environments_root: $spack/var/spack/environments


  # 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: 60


  # 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 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


  # 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 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

  # Number of seconds a buildcache's index.json is cached locally before probing
  # for updates, within a single Spack invocation. Defaults to 10 minutes.
  binary_index_ttl: 600

  flags:
    # Whether to keep -Werror flags active in package builds.
    keep_werror: 'none'

  # 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