Update commands auto completion

.codecov.yml

@@ -5,7 +5,7 @@ coverage:
   status:
     project:
       default:
-        threshold: 0.2%
+        threshold: 0.3%
 
 ignore:
   - lib/spack/spack/test/.*
@@ -14,21 +14,3 @@ ignore:
   - share/spack/qa/.*
 
 comment: off
-
-# Inline codecov annotations make the code hard to read, and they add
-# annotations in files that seemingly have nothing to do with the PR.
-github_checks:
-    annotations: false
-
-# Attempt to fix "Missing base commit" messages in the codecov UI.
-# Because we do not run full tests on package PRs, package PRs' merge
-# commits on `develop` don't have coverage info.  It appears that
-# codecov will give you an error if the pseudo-base's coverage data
-# doesn't all apply properly to the real PR base.
-#
-# See here for docs:
-#   https://docs.codecov.com/docs/comparing-commits#pseudo-comparison
-# See here for another potential solution:
-#   https://community.codecov.com/t/2480/15
-codecov:
-  allow_coverage_offsets: true

.coveragerc

@@ -0,0 +1,36 @@
+# -*- conf -*-
+# .coveragerc to control coverage.py
+[run]
+parallel = True
+concurrency = multiprocessing
+branch = True
+source = lib
+omit =
+     lib/spack/spack/test/*
+     lib/spack/docs/*
+     lib/spack/external/*
+     share/spack/qa/*
+
+[report]
+# Regexes for lines to exclude from consideration
+exclude_lines =
+    # Have to re-enable the standard pragma
+    pragma: no cover
+
+    # Don't complain about missing debug-only code:
+    def __repr__
+    if self\.debug
+
+    # Don't complain if tests don't hit defensive assertion code:
+    raise AssertionError
+    raise NotImplementedError
+
+    # Don't complain if non-runnable code isn't run:
+    if 0:
+    if False:
+    if __name__ == .__main__.:
+
+ignore_errors = True
+
+[html]
+directory = htmlcov

.dockerignore

@@ -8,4 +8,4 @@ share/spack/dotkit/*
 share/spack/lmod/*
 share/spack/modules/*
 lib/spack/spack/test/*
-var/spack/cache/*
+

.flake8

@@ -1,56 +1,32 @@
 # -*- conf -*-
-# flake8 settings for Spack.
+# flake8 settings for Spack core files.
 #
 # These exceptions are for Spack core files. We're slightly more lenient
 # with packages.  See .flake8_packages for that.
 #
-# This is the only flake8 rule Spack violates somewhat flagrantly
+# E1: Indentation
+# - E129: visually indented line with same indent as next logical line
+#
+# E2: Whitespace
+# - E221: multiple spaces before operator
+# - E241: multiple spaces after ','
+# - E272: multiple spaces before keyword
+#
+# E7: Statement
 # - E731: do not assign a lambda expression, use a def
 #
-# This is the only flake8 exception needed when using Black.
-# - E203: white space around slice operators can be required, ignore : warn
+# W5: Line break warning
+# - W503: line break before binary operator
+# - W504: line break after binary operator
 #
-# We still allow these in packages (Would like to get rid of them or rely on mypy
-# in the future)
-# - F403: from/import * used; unable to detect undefined names
-# - F405: undefined name or from *
-# - F821: undefined name (needed with from/import *)
+# These are required to get the package.py files to test clean:
+# - F999: syntax error in doctest
+#
+# N8: PEP8-naming
+# - N801: class names should use CapWords convention
+# - N813: camelcase imported as lowercase
+# - N814: camelcase imported as constant
 #
 [flake8]
-#ignore = E129,,W503,W504,F999,N801,N813,N814,F403,F405,E203
-extend-ignore = E731,E203
-max-line-length = 99
-
-# F4: Import
-# - F405: `name` may be undefined, or undefined from star imports: `module`
-#
-# F8: Name
-# - F821: undefined name `name`
-#
-per-file-ignores =
-  var/spack/repos/*/package.py:F403,F405,F821
-  *-ci-package.py:F403,F405,F821
-
-# exclude things we usually do not want linting for.
-# These still get linted when passed explicitly, as when spack flake8 passes
-# them on the command line.
-exclude =
-  .git
-  etc/
-  opt/
-  share/
-  var/spack/cache/
-  var/spack/gpg*/
-  var/spack/junit-report/
-  var/spack/mock-configs/
-  lib/spack/external
-  __pycache__
-  var
-
-format = spack
-
-[flake8:local-plugins]
-report =
-  spack = flake8_formatter:SpackFormatter
-paths =
-  ./share/spack/qa/
+ignore = E129,E221,E241,E272,E731,W503,W504,F999,N801,N813,N814
+max-line-length = 79

.flake8_packages

@@ -0,0 +1,24 @@
+# -*- conf -*-
+# flake8 settings for Spack package files.
+#
+# This should include all the same exceptions that we use for core files.
+#
+# In Spack packages, we also allow the single `from spack import *`
+# wildcard import and dependencies can set globals for their
+# dependents. So we add exceptions for checks related to undefined names.
+#
+# Note that we also add *per-line* exemptions for certain patterns in the
+# `spack flake8` command.  This is where F403 for `from spack import *`
+# is added (beause we *only* allow that wildcard).
+#
+# See .flake8 for regular exceptions.
+#
+# F4: Import
+# - F405: `name` may be undefined, or undefined from star imports: `module`
+#
+# F8: Name
+# - F821: undefined name `name`
+#
+[flake8]
+ignore = E129,E221,E241,E272,E731,W503,W504,F405,F821,F999,N801,N813,N814
+max-line-length = 79

.git-blame-ignore-revs

@@ -1,5 +0,0 @@
-# .git-blame-ignore-revs
-# Formatted entire codebase with black 23
-603569e321013a1a63a637813c94c2834d0a0023
-# Formatted entire codebase with black 22
-f52f6e99dbf1131886a80112b8c79dfc414afb7c

.gitattributes

@@ -1,4 +1 @@
 *.py diff=python
-*.lp linguist-language=Prolog
-lib/spack/external/* linguist-vendored
-*.bat text eol=crlf

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,49 @@
+---
+name: Bug report 
+about: Report a bug in the core of Spack (command not working as expected, etc.) 
+labels: bug
+---
+
+
+*Explain, in a clear and concise way, the command you ran and the result you were trying to achieve.
+Example: "I ran Spack find to list all the installed packages and..."*
+
+
+
+### Steps to reproduce the issue
+
+```console
+$ spack <command1> <spec>
+$ spack <command2> <spec>
+...
+```
+
+### Error Message
+
+If Spack reported an error, provide the error message. If it did not report an error
+but the output appears incorrect, provide the incorrect output. If there was no error
+message and no output but the result is incorrect, describe how it does not match
+what you expect. To provide more information you might re-run the commands with 
+the additional -d/--stacktrace flags:
+```console
+$ spack -d --stacktrace <command1> <spec>
+$ spack -d --stacktrace <command2> <spec>
+...
+```
+that activate the full debug output. 
+
+
+### Information on your system
+
+This includes:
+
+ 1. which platform you are using
+ 2. any relevant configuration detail (custom `packages.yaml` or `modules.yaml`, etc.)
+
+-----
+
+We encourage you to try, as much as possible, to reduce your problem to the minimal example that still reproduces the issue. That would help us a lot in fixing it quickly and effectively!
+
+If you want to ask a question about the tool (how to use it, what it can currently do, etc.), try the `#general` channel on our Slack first. We have a welcoming community and chances are you'll get your reply faster and without opening an issue.
+
+Other than that, thanks for taking the time to contribute to Spack!

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -1,58 +0,0 @@
-name: "\U0001F41E Bug report"
-description: Report a bug in the core of Spack (command not working as expected, etc.)
-labels: [bug, triage]
-body:
-  - type: textarea
-    id: reproduce
-    attributes:
-      label: Steps to reproduce
-      description: |
-        Explain, in a clear and concise way, the command you ran and the result you were trying to achieve.
-        Example: "I ran `spack find` to list all the installed packages and ..."
-      placeholder: |
-        ```console
-        $ spack <command1> <spec>
-        $ spack <command2> <spec>
-        ...
-        ```
-    validations:
-      required: true
-  - type: textarea
-    id: error
-    attributes:
-      label: Error message
-      description: |
-        If Spack reported an error, provide the error message. If it did not report an error but the output appears incorrect, provide the incorrect output. If there was no error message and no output but the result is incorrect, describe how it does not match what you expect.
-      placeholder: |
-        ```console
-        $ spack --debug --stacktrace <command>
-        ```
-  - type: textarea
-    id: information
-    attributes:
-      label: Information on your system
-      description: Please include the output of `spack debug report`
-    validations:
-      required: true
-  - type: markdown
-    attributes:
-      value: |
-        If you have any relevant configuration detail (custom `packages.yaml` or `modules.yaml`, etc.) you can add that here as well.
-  - type: checkboxes
-    id: checks
-    attributes:
-      label: General information
-      options:
-        - label: I have run `spack debug report` and reported the version of Spack/Python/Platform
-          required: true
-        - label: I have searched the issues of this repo and believe this is not a duplicate
-          required: true
-        - label: I have run the failing commands in debug mode and reported the output
-          required: true
-  - type: markdown
-    attributes:
-      value: |
-        We encourage you to try, as much as possible, to reduce your problem to the minimal example that still reproduces the issue. That would help us a lot in fixing it quickly and effectively!
-        If you want to ask a question about the tool (how to use it, what it can currently do, etc.), try the `#general` channel on [our Slack](https://slack.spack.io/) first. We have a welcoming community and chances are you'll get your reply faster and without opening an issue.
-        
-        Other than that, thanks for taking the time to contribute to Spack!

.github/ISSUE_TEMPLATE/build_error.md

@@ -0,0 +1,78 @@
+---
+name: Build error 
+about: Some package in Spack didn't build correctly  
+labels: "build-error"
+---
+
+*Thanks for taking the time to report this build failure. To proceed with the
+report please:*
+1. Title the issue "Installation issue: <name-of-the-package>".
+2. Provide the information required below.
+3. Remove the template instructions before posting the issue.
+
+We encourage you to try, as much as possible, to reduce your problem to the minimal example that still reproduces the issue. That would help us a lot in fixing it quickly and effectively!
+
+
+---
+
+### Steps to reproduce the issue
+
+```console
+$ spack install <spec> # Fill in the exact spec you are using
+... # and the relevant part of the error message
+```
+
+### Platform and user environment
+
+Please report your OS here:
+```commandline
+$ uname -a 
+Linux nuvolari 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
+$ lsb_release -d
+Description:	Ubuntu 18.04.1 LTS
+``` 
+and, if relevant, post or attach:
+
+- `packages.yaml`
+- `compilers.yaml`
+
+to the issue
+
+### Additional information
+
+Sometimes the issue benefits from additional details. In these cases there are
+a few things we can suggest doing. First of all, you can post the full output of:
+```console
+$ spack spec --install-status <spec>
+...
+```
+to show people whether Spack installed a faulty software or if it was not able to
+build it at all. 
+
+If your build didn't make it past the configure stage, Spack as also commands to parse 
+logs and report error and warning messages:
+```console
+$ spack log-parse --show=errors,warnings <file-to-parse>
+```
+You might want to run this command on the `config.log` or any other similar file
+found in the stage directory: 
+```console
+$ spack location -s <spec>
+```
+In case in `config.log` there are other settings that you think might be the cause 
+of the build failure, you can consider attaching the file to this issue.
+
+Rebuilding the package with the following options:
+```console
+$ spack -d install -j 1 <spec>
+...
+```
+will provide additional debug information. After the failure you will find two files in the current directory:
+
+1. `spack-cc-<spec>.in`, which contains details on the command given in input 
+    to Spack's compiler wrapper  
+1. `spack-cc-<spec>.out`, which contains the command used to compile / link the 
+    failed object after Spack's compiler wrapper did its processing 
+
+You can post or attach those files to provide maintainers with more information on what
+is causing the failure.

.github/ISSUE_TEMPLATE/build_error.yml

@@ -1,76 +0,0 @@
-name: "\U0001F4A5 Build error"
-description: Some package in Spack didn't build correctly
-title: "Installation issue: "
-labels: [build-error]
-body:
-  - type: markdown
-    attributes:
-      value: |
-        Thanks for taking the time to report this build failure. To proceed with the report please:
-        1. Title the issue `Installation issue: <name-of-the-package>`.
-        2. Provide the information required below.
-
-        We encourage you to try, as much as possible, to reduce your problem to the minimal example that still reproduces the issue. That would help us a lot in fixing it quickly and effectively!
-  - type: textarea
-    id: reproduce
-    attributes:
-      label: Steps to reproduce the issue
-      description: |
-        Fill in the console output from the exact spec you are trying to build.
-      value: |
-        ```console
-        $ spack spec -I <spec>
-        ...
-        ```
-  - type: textarea
-    id: error
-    attributes:
-      label: Error message
-      description: |
-        Please post the error message from spack inside the `<details>` tag below:
-      value: |
-        <details><summary>Error message</summary>
-
-        <pre>
-        ...
-        </pre></details>
-    validations:
-      required: true
-  - type: textarea
-    id: information
-    attributes:
-      label: Information on your system
-      description: Please include the output of `spack debug report`.
-    validations:
-      required: true
-  - type: markdown
-    attributes:
-      value: |
-        If you have any relevant configuration detail (custom `packages.yaml` or `modules.yaml`, etc.) you can add that here as well.
-  - type: textarea
-    id: additional_information
-    attributes:
-      label: Additional information
-      description: |
-        Please upload the following files:
-        * **`spack-build-out.txt`**
-        * **`spack-build-env.txt`**
-
-        They should be present in the stage directory of the failing build. Also upload any `config.log` or similar file if one exists.
-  - type: markdown
-    attributes:
-      value: |
-        Some packages have maintainers who have volunteered to debug build failures. Run `spack maintainers <name-of-the-package>` and **@mention** them here if they exist.
-  - type: checkboxes
-    id: checks
-    attributes:
-      label: General information
-      options:
-        - label: I have run `spack debug report` and reported the version of Spack/Python/Platform
-          required: true
-        - label: I have run `spack maintainers <name-of-the-package>` and **@mentioned** any maintainers
-          required: true
-        - label: I have uploaded the build log and environment files
-          required: true
-        - label: I have searched the issues of this repo and believe this is not a duplicate
-          required: true

.github/ISSUE_TEMPLATE/config.yml

@@ -1 +0,0 @@
-blank_issues_enabled: true

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,28 @@
+---
+name: Feature request 
+about: Suggest adding a feature that is not yet in Spack  
+labels: feature
+
+---
+
+*Please add a concise summary of your suggestion here.*
+
+### Rationale
+
+*Is your feature request related to a problem? Please describe it!*
+
+### Description
+
+*Describe the solution you'd like and the alternatives you have considered.*
+
+
+### Additional information
+*Add any other context about the feature request here.*
+
+
+-----
+
+
+If you want to ask a question about the tool (how to use it, what it can currently do, etc.), try the `#general` channel on our Slack first. We have a welcoming community and chances are you'll get your reply faster and without opening an issue.
+
+Other than that, thanks for taking the time to contribute to Spack!

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -1,39 +0,0 @@
-name: "\U0001F38A Feature request"
-description: Suggest adding a feature that is not yet in Spack
-labels: [feature]
-body:
-  - type: textarea
-    id: summary
-    attributes:
-      label: Summary
-      description: Please add a concise summary of your suggestion here.
-    validations:
-      required: true
-  - type: textarea
-    id: rationale
-    attributes:
-      label: Rationale
-      description: Is your feature request related to a problem? Please describe it!
-  - type: textarea
-    id: description
-    attributes:
-      label: Description
-      description: Describe the solution you'd like and the alternatives you have considered.
-  - type: textarea
-    id: additional_information
-    attributes:
-      label: Additional information
-      description: Add any other context about the feature request here.
-  - type: checkboxes
-    id: checks
-    attributes:
-      label: General information
-      options:
-        - label: I have searched the issues of this repo and believe this is not a duplicate
-          required: true
-  - type: markdown
-    attributes:
-      value: |
-        If you want to ask a question about the tool (how to use it, what it can currently do, etc.), try the `#general` channel on [our Slack](https://slack.spack.io/) first. We have a welcoming community and chances are you'll get your reply faster and without opening an issue.
-
-        Other than that, thanks for taking the time to contribute to Spack!

.github/ISSUE_TEMPLATE/test_error.yml

@@ -1,64 +0,0 @@
-name: "\U0001F4A5 Tests error"
-description: Some package in Spack had stand-alone tests that didn't pass
-title: "Testing issue: "
-labels: [test-error]
-body:
-  - type: textarea
-    id: reproduce
-    attributes:
-      label: Steps to reproduce the failure(s) or link(s) to test output(s)
-      description: |
-        Fill in the test output from the exact spec that is having stand-alone test failures. Links to test outputs (e.g., CDash) can also be provided.
-      value: |
-        ```console
-        $ spack spec -I <spec>
-        ...
-        ```
-  - type: textarea
-    id: error
-    attributes:
-      label: Error message
-      description: |
-        Please post the error message from spack inside the `<details>` tag below:
-      value: |
-        <details><summary>Error message</summary>
-
-        <pre>
-        ...
-        </pre></details>
-    validations:
-      required: true
-  - type: textarea
-    id: information
-    attributes:
-      label: Information on your system or the test runner
-      description: Please include the output of `spack debug report` for your system.
-    validations:
-      required: true
-  - type: markdown
-    attributes:
-      value: |
-        If you have any relevant configuration detail (custom `packages.yaml` or `modules.yaml`, etc.) you can add that here as well.
-  - type: textarea
-    id: additional_information
-    attributes:
-      label: Additional information
-      description: |
-        Please upload test logs or any additional information about the problem.
-  - type: markdown
-    attributes:
-      value: |
-        Some packages have maintainers who have volunteered to debug build failures. Run `spack maintainers <name-of-the-package>` and **@mention** them here if they exist.
-  - type: checkboxes
-    id: checks
-    attributes:
-      label: General information
-      options:
-        - label: I have reported the version of Spack/Python/Platform/Runner
-          required: true
-        - label: I have run `spack maintainers <name-of-the-package>` and **@mentioned** any maintainers
-          required: true
-        - label: I have uploaded any available logs
-          required: true
-        - label: I have searched the issues of this repo and believe this is not a duplicate
-          required: true

.github/actions/add-maintainers-as-reviewers/Dockerfile

@@ -0,0 +1,6 @@
+FROM python:3.7-alpine
+
+RUN pip install pygithub
+
+ADD entrypoint.py /entrypoint.py
+ENTRYPOINT ["/entrypoint.py"]

.github/actions/add-maintainers-as-reviewers/entrypoint.py

@@ -0,0 +1,85 @@
+#!/usr/bin/env python
+#
+# Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
+# Spack Project Developers. See the top-level COPYRIGHT file for details.
+#
+# SPDX-License-Identifier: (Apache-2.0 OR MIT)
+
+"""Maintainer review action.
+
+This action checks which packages have changed in a PR, and adds their
+maintainers to the pull request for review.
+"""
+
+import json
+import os
+import re
+import subprocess
+
+from github import Github
+
+
+def spack(*args):
+    """Run the spack executable with arguments, and return the output split.
+
+    This does just enough to run `spack pkg` and `spack maintainers`, the
+    two commands used by this action.
+    """
+    github_workspace = os.environ['GITHUB_WORKSPACE']
+    spack = os.path.join(github_workspace, 'bin', 'spack')
+    output = subprocess.check_output([spack] + list(args))
+    split = re.split(r'\s*', output.decode('utf-8').strip())
+    return [s for s in split if s]
+
+
+def main():
+    # get these first so that we'll fail early
+    token = os.environ['GITHUB_TOKEN']
+    event_path = os.environ['GITHUB_EVENT_PATH']
+
+    with open(event_path) as file:
+        data = json.load(file)
+
+    # make sure it's a pull_request event
+    assert 'pull_request' in data
+
+    # only request reviews on open, edit, or reopen
+    action = data['action']
+    if action not in ('opened', 'edited', 'reopened'):
+        return
+
+    # get data from the event payload
+    pr_data             = data['pull_request']
+    base_branch_name    = pr_data['base']['ref']
+    full_repo_name      = pr_data['base']['repo']['full_name']
+    pr_number           = pr_data['number']
+    requested_reviewers = pr_data['requested_reviewers']
+    author              = pr_data['user']['login']
+
+    # get a list of packages that this PR modified
+    changed_pkgs = spack(
+        'pkg', 'changed', '--type', 'ac', '%s...' % base_branch_name)
+
+    # get maintainers for all modified packages
+    maintainers = set()
+    for pkg in changed_pkgs:
+        pkg_maintainers = set(spack('maintainers', pkg))
+        maintainers |= pkg_maintainers
+
+    # remove any maintainers who are already on the PR, and the author,
+    # as you can't review your own PR)
+    maintainers -= set(requested_reviewers)
+    maintainers -= set([author])
+
+    if not maintainers:
+        return
+
+    # request reviews from each maintainer
+    gh = Github(token)
+    repo = gh.get_repo(full_repo_name)
+    pr = repo.get_pull(pr_number)
+    pr.create_review_request(list(maintainers))
+
+
+if __name__ == "__main__":
+    main()

.github/dependabot.yml

@@ -1,12 +0,0 @@
-version: 2
-updates:
-  # Maintain dependencies for GitHub Actions
-  - package-ecosystem: "github-actions"
-    directory: "/"
-    schedule:
-      interval: "daily"
-  # Requirements to build documentation
-  - package-ecosystem: "pip"
-    directory: "/lib/spack/docs"
-    schedule:
-      interval: "daily"

.github/workflows/audit.yaml

@@ -1,47 +0,0 @@
-name: audit
-
-on:
-  workflow_call:
-    inputs:
-      with_coverage:
-        required: true
-        type: string
-      python_version:
-        required: true
-        type: string
-
-concurrency:
-  group: audit-${{inputs.python_version}}-${{github.ref}}-${{github.event.pull_request.number || github.run_number}}
-  cancel-in-progress: true
-
-jobs:
-  # Run audits on all the packages in the built-in repository
-  package-audits:
-    runs-on: ${{ matrix.operating_system }}
-    strategy:
-      matrix:
-        operating_system: ["ubuntu-latest", "macos-latest"]
-    steps:
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # @v2
-    - uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1 # @v2
-      with:
-        python-version: ${{inputs.python_version}}
-    - name: Install Python packages
-      run: |
-        pip install --upgrade pip setuptools pytest coverage[toml]
-    - name: Package audits (with coverage)
-      if: ${{ inputs.with_coverage == 'true' }}
-      run: |
-          . share/spack/setup-env.sh
-          coverage run $(which spack) audit packages
-          coverage combine
-          coverage xml
-    - name: Package audits (without coverage)
-      if: ${{ inputs.with_coverage == 'false' }}
-      run: |
-          . share/spack/setup-env.sh
-          $(which spack) audit packages
-    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d # @v2.1.0
-      if: ${{ inputs.with_coverage == 'true' }}
-      with:
-        flags: unittests,audits

.github/workflows/bootstrap-test.sh

@@ -1,7 +0,0 @@
-#!/bin/bash
-set -ex
-source share/spack/setup-env.sh
-$PYTHON bin/spack bootstrap disable spack-install
-$PYTHON bin/spack -d solve zlib
-tree $BOOTSTRAP/store
-exit 0

.github/workflows/bootstrap.yml

@@ -1,352 +0,0 @@
-name: Bootstrapping
-
-on:
-  # This Workflow can be triggered manually
-  workflow_dispatch:
-  workflow_call:
-  schedule:
-    # nightly at 2:16 AM
-    - cron: '16 2 * * *'
-
-concurrency:
-  group: bootstrap-${{github.ref}}-${{github.event.pull_request.number || github.run_number}}
-  cancel-in-progress: true
-
-jobs:
-  fedora-clingo-sources:
-    runs-on: ubuntu-latest
-    container: "fedora:latest"
-    steps:
-      - name: Install dependencies
-        run: |
-          dnf install -y \
-              bzip2 curl file gcc-c++ gcc gcc-gfortran git gnupg2 gzip \
-              make patch unzip which xz python3 python3-devel tree \
-              cmake bison bison-devel libstdc++-static
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-        with:
-          fetch-depth: 0
-      - name: Setup non-root user
-        run: |
-          # See [1] below
-          git config --global --add safe.directory /__w/spack/spack
-          useradd spack-test && mkdir -p ~spack-test
-          chown -R spack-test . ~spack-test
-      - name: Setup repo
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          git --version
-          . .github/workflows/setup_git.sh
-      - name: Bootstrap clingo
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          source share/spack/setup-env.sh
-          spack bootstrap disable github-actions-v0.4
-          spack bootstrap disable github-actions-v0.3
-          spack external find cmake bison
-          spack -d solve zlib
-          tree ~/.spack/bootstrap/store/
-
-  ubuntu-clingo-sources:
-    runs-on: ubuntu-latest
-    container: "ubuntu:latest"
-    steps:
-      - name: Install dependencies
-        env:
-          DEBIAN_FRONTEND: noninteractive
-        run: |
-          apt-get update -y && apt-get upgrade -y
-          apt-get install -y \
-              bzip2 curl file g++ gcc gfortran git gnupg2 gzip \
-              make patch unzip xz-utils python3 python3-dev tree \
-              cmake bison
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-        with:
-          fetch-depth: 0
-      - name: Setup non-root user
-        run: |
-          # See [1] below
-          git config --global --add safe.directory /__w/spack/spack
-          useradd spack-test && mkdir -p ~spack-test
-          chown -R spack-test . ~spack-test
-      - name: Setup repo
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          git --version
-          . .github/workflows/setup_git.sh
-      - name: Bootstrap clingo
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          source share/spack/setup-env.sh
-          spack bootstrap disable github-actions-v0.4
-          spack bootstrap disable github-actions-v0.3
-          spack external find cmake bison
-          spack -d solve zlib
-          tree ~/.spack/bootstrap/store/
-
-  ubuntu-clingo-binaries-and-patchelf:
-    runs-on: ubuntu-latest
-    container: "ubuntu:latest"
-    steps:
-      - name: Install dependencies
-        env:
-          DEBIAN_FRONTEND: noninteractive
-        run: |
-          apt-get update -y && apt-get upgrade -y
-          apt-get install -y \
-              bzip2 curl file g++ gcc gfortran git gnupg2 gzip \
-              make patch unzip xz-utils python3 python3-dev tree
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-        with:
-          fetch-depth: 0
-      - name: Setup non-root user
-        run: |
-          # See [1] below
-          git config --global --add safe.directory /__w/spack/spack
-          useradd spack-test && mkdir -p ~spack-test
-          chown -R spack-test . ~spack-test
-      - name: Setup repo
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          git --version
-          . .github/workflows/setup_git.sh
-      - name: Bootstrap clingo
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          source share/spack/setup-env.sh
-          spack -d solve zlib
-          tree ~/.spack/bootstrap/store/
-
-  opensuse-clingo-sources:
-    runs-on: ubuntu-latest
-    container: "opensuse/leap:latest"
-    steps:
-      - name: Install dependencies
-        run: |
-          # Harden CI by applying the workaround described here: https://www.suse.com/support/kb/doc/?id=000019505
-          zypper update -y || zypper update -y
-          zypper install -y \
-              bzip2 curl file gcc-c++ gcc gcc-fortran tar git gpg2 gzip \
-              make patch unzip which xz python3 python3-devel tree \
-              cmake bison
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-        with:
-          fetch-depth: 0
-      - name: Setup repo
-        run: |
-          # See [1] below
-          git config --global --add safe.directory /__w/spack/spack
-          git --version
-          . .github/workflows/setup_git.sh
-      - name: Bootstrap clingo
-        run: |
-          source share/spack/setup-env.sh
-          spack bootstrap disable github-actions-v0.4
-          spack bootstrap disable github-actions-v0.3
-          spack external find cmake bison
-          spack -d solve zlib
-          tree ~/.spack/bootstrap/store/
-
-  macos-clingo-sources:
-    runs-on: macos-latest
-    steps:
-      - name: Install dependencies
-        run: |
-          brew install cmake bison@2.7 tree
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-      - name: Bootstrap clingo
-        run: |
-          source share/spack/setup-env.sh
-          export PATH=/usr/local/opt/bison@2.7/bin:$PATH
-          spack bootstrap disable github-actions-v0.4
-          spack bootstrap disable github-actions-v0.3
-          spack external find --not-buildable cmake bison
-          spack -d solve zlib
-          tree ~/.spack/bootstrap/store/
-
-  macos-clingo-binaries:
-    runs-on: ${{ matrix.macos-version }}
-    strategy:
-      matrix:
-        macos-version: ['macos-11', 'macos-12']
-    steps:
-      - name: Install dependencies
-        run: |
-          brew install tree
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-      - name: Bootstrap clingo
-        run: |
-          set -ex
-          for ver in '3.6' '3.7' '3.8' '3.9' '3.10' ; do
-            not_found=1
-            ver_dir="$(find $RUNNER_TOOL_CACHE/Python -wholename "*/${ver}.*/*/bin" | grep . || true)"
-            echo "Testing $ver_dir"
-            if [[ -d "$ver_dir" ]] ; then
-              if $ver_dir/python --version ; then
-                export PYTHON="$ver_dir/python"
-                not_found=0
-                old_path="$PATH"
-                export PATH="$ver_dir:$PATH"
-                ./bin/spack-tmpconfig -b ./.github/workflows/bootstrap-test.sh
-                export PATH="$old_path"
-              fi
-            fi
-            # NOTE: test all pythons that exist, not all do on 12
-          done
-
-  ubuntu-clingo-binaries:
-    runs-on: ubuntu-20.04
-    steps:
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-        with:
-          fetch-depth: 0
-      - name: Setup repo
-        run: |
-          git --version
-          . .github/workflows/setup_git.sh
-      - name: Bootstrap clingo
-        run: |
-          set -ex
-          for ver in '3.6' '3.7' '3.8' '3.9' '3.10' ; do
-            not_found=1
-            ver_dir="$(find $RUNNER_TOOL_CACHE/Python -wholename "*/${ver}.*/*/bin" | grep . || true)"
-            echo "Testing $ver_dir"
-            if [[ -d "$ver_dir" ]] ; then
-              if $ver_dir/python --version ; then
-                export PYTHON="$ver_dir/python"
-                not_found=0
-                old_path="$PATH"
-                export PATH="$ver_dir:$PATH"
-                ./bin/spack-tmpconfig -b ./.github/workflows/bootstrap-test.sh
-                export PATH="$old_path"
-              fi
-            fi
-            if (($not_found)) ; then
-              echo Required python version $ver not found in runner!
-              exit 1
-            fi
-          done
-
-  ubuntu-gnupg-binaries:
-    runs-on: ubuntu-latest
-    container: "ubuntu:latest"
-    steps:
-      - name: Install dependencies
-        env:
-          DEBIAN_FRONTEND: noninteractive
-        run: |
-          apt-get update -y && apt-get upgrade -y
-          apt-get install -y \
-              bzip2 curl file g++ gcc patchelf gfortran git gzip \
-              make patch unzip xz-utils python3 python3-dev tree
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-        with:
-          fetch-depth: 0
-      - name: Setup non-root user
-        run: |
-          # See [1] below
-          git config --global --add safe.directory /__w/spack/spack
-          useradd spack-test && mkdir -p ~spack-test
-          chown -R spack-test . ~spack-test
-      - name: Setup repo
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          git --version
-          . .github/workflows/setup_git.sh
-      - name: Bootstrap GnuPG
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          source share/spack/setup-env.sh
-          spack bootstrap disable spack-install
-          spack -d gpg list
-          tree ~/.spack/bootstrap/store/
-
-  ubuntu-gnupg-sources:
-    runs-on: ubuntu-latest
-    container: "ubuntu:latest"
-    steps:
-      - name: Install dependencies
-        env:
-          DEBIAN_FRONTEND: noninteractive
-        run: |
-          apt-get update -y && apt-get upgrade -y
-          apt-get install -y \
-              bzip2 curl file g++ gcc patchelf gfortran git gzip \
-              make patch unzip xz-utils python3 python3-dev tree \
-              gawk
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-        with:
-          fetch-depth: 0
-      - name: Setup non-root user
-        run: |
-          # See [1] below
-          git config --global --add safe.directory /__w/spack/spack
-          useradd spack-test && mkdir -p ~spack-test
-          chown -R spack-test . ~spack-test
-      - name: Setup repo
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          git --version
-          . .github/workflows/setup_git.sh
-      - name: Bootstrap GnuPG
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          source share/spack/setup-env.sh
-          spack solve zlib
-          spack bootstrap disable github-actions-v0.4
-          spack bootstrap disable github-actions-v0.3
-          spack -d gpg list
-          tree ~/.spack/bootstrap/store/
-
-  macos-gnupg-binaries:
-    runs-on: macos-latest
-    steps:
-      - name: Install dependencies
-        run: |
-          brew install tree
-          # Remove GnuPG since we want to bootstrap it
-          sudo rm -rf /usr/local/bin/gpg
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-      - name: Bootstrap GnuPG
-        run: |
-          source share/spack/setup-env.sh
-          spack bootstrap disable spack-install
-          spack -d gpg list
-          tree ~/.spack/bootstrap/store/
-
-  macos-gnupg-sources:
-    runs-on: macos-latest
-    steps:
-      - name: Install dependencies
-        run: |
-          brew install gawk tree
-          # Remove GnuPG since we want to bootstrap it
-          sudo rm -rf /usr/local/bin/gpg
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-      - name: Bootstrap GnuPG
-        run: |
-          source share/spack/setup-env.sh
-          spack solve zlib
-          spack bootstrap disable github-actions-v0.4
-          spack bootstrap disable github-actions-v0.3
-          spack -d gpg list
-          tree ~/.spack/bootstrap/store/
-
-
-# [1] Distros that have patched git to resolve CVE-2022-24765 (e.g. Ubuntu patching v2.25.1)
-#     introduce breaking behaviorso we have to set `safe.directory` in gitconfig ourselves.
-#     See:
-#     - https://github.blog/2022-04-12-git-security-vulnerability-announced/
-#     - https://github.com/actions/checkout/issues/760
-#     - http://changelogs.ubuntu.com/changelogs/pool/main/g/git/git_2.25.1-1ubuntu3.3/changelog

.github/workflows/build-containers.yml

@@ -1,126 +0,0 @@
-name: Containers
-
-on:
-  # This Workflow can be triggered manually
-  workflow_dispatch:
-  # Build new Spack develop containers nightly.
-  schedule:
-    - cron: '34 0 * * *'
-  # Run on pull requests that modify this file
-  pull_request:
-    branches:
-      - develop
-    paths:
-      - '.github/workflows/build-containers.yml'
-      - 'share/spack/docker/*'
-      - 'share/spack/templates/container/*'
-      - 'lib/spack/spack/container/*'
-  # Let's also build & tag Spack containers on releases.
-  release:
-    types: [published]
-
-concurrency:
-  group: build_containers-${{github.ref}}-${{github.event.pull_request.number || github.run_number}}
-  cancel-in-progress: true
-
-jobs:
-  deploy-images:
-    runs-on: ubuntu-latest
-    permissions:
-      packages: write
-    strategy:
-      # Even if one container fails to build we still want the others
-      # to continue their builds.
-      fail-fast: false
-      # A matrix of Dockerfile paths, associated tags, and which architectures
-      # they support.
-      matrix:
-        # Meaning of the various items in the matrix list
-        # 0: Container name (e.g. ubuntu-bionic)
-        # 1: Platforms to build for
-        # 2: Base image (e.g. ubuntu:18.04)
-        dockerfile: [[amazon-linux, 'linux/amd64,linux/arm64', 'amazonlinux:2'],
-                     [centos7, 'linux/amd64,linux/arm64,linux/ppc64le', 'centos:7'],
-                     [centos-stream, 'linux/amd64,linux/arm64,linux/ppc64le', 'centos:stream'],
-                     [leap15, 'linux/amd64,linux/arm64,linux/ppc64le', 'opensuse/leap:15'],
-                     [ubuntu-bionic, 'linux/amd64,linux/arm64,linux/ppc64le', 'ubuntu:18.04'],
-                     [ubuntu-focal, 'linux/amd64,linux/arm64,linux/ppc64le', 'ubuntu:20.04'],
-                     [ubuntu-jammy, 'linux/amd64,linux/arm64,linux/ppc64le', 'ubuntu:22.04'],
-                     [almalinux8, 'linux/amd64,linux/arm64,linux/ppc64le', 'almalinux:8'],
-                     [almalinux9, 'linux/amd64,linux/arm64,linux/ppc64le', 'almalinux:9'],
-                     [rockylinux8, 'linux/amd64,linux/arm64', 'rockylinux:8'],
-                     [rockylinux9, 'linux/amd64,linux/arm64', 'rockylinux:9'],
-                     [fedora37, 'linux/amd64,linux/arm64,linux/ppc64le', 'fedora:37'],
-                     [fedora38, 'linux/amd64,linux/arm64,linux/ppc64le', 'fedora:38']]
-    name: Build ${{ matrix.dockerfile[0] }}
-    if: github.repository == 'spack/spack'
-    steps:
-      - name: Checkout
-        uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # @v2
-
-      - name: Set Container Tag Normal (Nightly)
-        run: |
-          container="${{ matrix.dockerfile[0] }}:latest"
-          echo "container=${container}" >> $GITHUB_ENV
-          echo "versioned=${container}" >> $GITHUB_ENV
-
-        # On a new release create a container with the same tag as the release.
-      - name: Set Container Tag on Release
-        if: github.event_name == 'release'
-        run: |
-          versioned="${{matrix.dockerfile[0]}}:${GITHUB_REF##*/}"
-          echo "versioned=${versioned}" >> $GITHUB_ENV
-
-      - name: Generate the Dockerfile
-        env:
-          SPACK_YAML_OS: "${{ matrix.dockerfile[2] }}"
-        run: |
-          .github/workflows/generate_spack_yaml_containerize.sh
-          . share/spack/setup-env.sh
-          mkdir -p dockerfiles/${{ matrix.dockerfile[0] }}
-          spack containerize --last-stage=bootstrap | tee dockerfiles/${{ matrix.dockerfile[0] }}/Dockerfile
-          printf "Preparing to build ${{ env.container }} from dockerfiles/${{ matrix.dockerfile[0] }}/Dockerfile"
-          if [ ! -f "dockerfiles/${{ matrix.dockerfile[0] }}/Dockerfile" ]; then
-              printf "dockerfiles/${{ matrix.dockerfile[0] }}/Dockerfile does not exist"
-              exit 1;
-          fi
-
-      - name: Upload Dockerfile
-        uses: actions/upload-artifact@a8a3f3ad30e3422c9c7b888a15615d19a852ae32
-        with:
-          name: dockerfiles
-          path: dockerfiles
-
-      - name: Set up QEMU
-        uses: docker/setup-qemu-action@2b82ce82d56a2a04d2637cd93a637ae1b359c0a7 # @v1
-
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@885d1462b80bc1c1c7f0b00334ad271f09369c55 # @v1
-
-      - name: Log in to GitHub Container Registry
-        uses: docker/login-action@465a07811f14bebb1938fbed4728c6a1ff8901fc # @v1
-        with:
-          registry: ghcr.io
-          username: ${{ github.actor }}
-          password: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Log in to DockerHub
-        if: github.event_name != 'pull_request'
-        uses: docker/login-action@465a07811f14bebb1938fbed4728c6a1ff8901fc # @v1
-        with:
-          username: ${{ secrets.DOCKERHUB_USERNAME }}
-          password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-      - name: Build & Deploy ${{ matrix.dockerfile[0] }}
-        uses: docker/build-push-action@0a97817b6ade9f46837855d676c4cca3a2471fc9 # @v2
-        with:
-          context: dockerfiles/${{ matrix.dockerfile[0] }}
-          platforms: ${{ matrix.dockerfile[1] }}
-          push: ${{ github.event_name != 'pull_request' }}
-          cache-from: type=gha
-          cache-to: type=gha,mode=max
-          tags: |
-            spack/${{ env.container }}
-            spack/${{ env.versioned }}
-            ghcr.io/spack/${{ env.container }}
-            ghcr.io/spack/${{ env.versioned }}

.github/workflows/ci.yaml

@@ -1,86 +0,0 @@
-name: ci
-
-on:
-  push:
-    branches:
-      - develop
-      - releases/**
-  pull_request:
-    branches:
-      - develop
-      - releases/**
-
-concurrency:
-  group: ci-${{github.ref}}-${{github.event.pull_request.number || github.run_number}}
-  cancel-in-progress: true
-
-jobs:
-  prechecks:
-    needs: [ changes ]
-    uses: ./.github/workflows/valid-style.yml
-    with:
-      with_coverage: ${{ needs.changes.outputs.core }}
-  all-prechecks:
-    needs: [ prechecks ]
-    runs-on: ubuntu-latest
-    steps:
-    - name: Success
-      run: "true"
-  # Check which files have been updated by the PR
-  changes:
-    runs-on: ubuntu-latest
-      # Set job outputs to values from filter step
-    outputs:
-      bootstrap: ${{ steps.filter.outputs.bootstrap }}
-      core: ${{ steps.filter.outputs.core }}
-      packages: ${{ steps.filter.outputs.packages }}
-    steps:
-      - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # @v2
-        if: ${{ github.event_name == 'push' }}
-        with:
-          fetch-depth: 0
-            # For pull requests it's not necessary to checkout the code
-      - uses: dorny/paths-filter@4512585405083f25c027a35db413c2b3b9006d50
-        id: filter
-        with:
-          # See https://github.com/dorny/paths-filter/issues/56 for the syntax used below
-          # Don't run if we only modified packages in the
-          # built-in repository or documentation
-          filters: |
-            bootstrap:
-            - 'var/spack/repos/builtin/packages/clingo-bootstrap/**'
-            - 'var/spack/repos/builtin/packages/clingo/**'
-            - 'var/spack/repos/builtin/packages/python/**'
-            - 'var/spack/repos/builtin/packages/re2c/**'
-            - 'lib/spack/**'
-            - 'share/spack/**'
-            - '.github/workflows/bootstrap.yml'
-            - '.github/workflows/ci.yaml'
-            core:
-            - './!(var/**)/**'
-            packages:
-            - 'var/**'
-      # Some links for easier reference:
-      #
-      # "github" context: https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context
-      # job outputs: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idoutputs
-      # setting environment variables from earlier steps: https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#setting-an-environment-variable
-      #
-  bootstrap:
-    if: ${{ github.repository == 'spack/spack' && needs.changes.outputs.bootstrap == 'true' }}
-    needs: [ prechecks, changes ]
-    uses: ./.github/workflows/bootstrap.yml
-  unit-tests:
-    if: ${{ github.repository == 'spack/spack' && needs.changes.outputs.core == 'true' }}
-    needs: [ prechecks, changes ]
-    uses: ./.github/workflows/unit_tests.yaml
-  windows:
-    if: ${{ github.repository == 'spack/spack' && needs.changes.outputs.core == 'true' }}
-    needs: [ prechecks ]
-    uses: ./.github/workflows/windows_python.yml
-  all:
-    needs: [ windows, unit-tests, bootstrap ]
-    runs-on: ubuntu-latest
-    steps:
-    - name: Success
-      run: "true"

.github/workflows/execute_installer.ps1

@@ -1,7 +0,0 @@
-$ proc = Start-Process  ${{ env.spack_installer }}\spack.exe "/install /quiet" -Passthru
-$handle = $proc.Handle # cache proc.Handle
-$proc.WaitForExit();
-
-if ($proc.ExitCode -ne 0) {
-    Write-Warning "$_ exited with status code $($proc.ExitCode)"
-}

.github/workflows/generate_spack_yaml_containerize.sh

@@ -1,9 +0,0 @@
-#!/bin/bash
-    (echo "spack:" \
-&&   echo "  specs: []" \
-&&   echo "  container:" \
-&&   echo "    format: docker" \
-&&   echo "    images:" \
-&&   echo "      os: \"${SPACK_YAML_OS}\"" \
-&&   echo "      spack:" \
-&&   echo "        ref: ${GITHUB_REF}") > spack.yaml

.github/workflows/install_spack.sh

@@ -1,8 +0,0 @@
-#!/usr/bin/env sh
-. share/spack/setup-env.sh
-echo -e "config:\n  build_jobs: 2" > etc/spack/config.yaml
-spack config add "packages:all:target:[x86_64]"
-spack compiler find
-spack compiler info apple-clang
-spack debug report
-spack solve zlib

.github/workflows/linux_build_tests.yaml

@@ -0,0 +1,57 @@
+name: linux builds
+
+on:
+  push:
+    branches:
+    - master
+    - develop
+  pull_request:
+    branches:
+    - master
+    - develop
+    paths-ignore:
+      # Don't run if we only modified packages in the built-in repository
+      - 'var/spack/repos/builtin/**'
+      - '!var/spack/repos/builtin/packages/lz4/**'
+      - '!var/spack/repos/builtin/packages/mpich/**'
+      - '!var/spack/repos/builtin/packages/tut/**'
+      - '!var/spack/repos/builtin/packages/py-setuptools/**'
+      - '!var/spack/repos/builtin/packages/openjpeg/**'
+      - '!var/spack/repos/builtin/packages/r-rcpp/**'
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+    strategy:
+      max-parallel: 4
+      matrix:
+        package: [lz4, mpich, tut, py-setuptools, openjpeg, r-rcpp]
+    steps:
+    - uses: actions/checkout@v1
+    - name: Cache ccache's store
+      uses: actions/cache@v1
+      with:
+        path: ~/.ccache
+        key: ccache-build-${{ matrix.package }}
+        restore-keys: |
+          ccache-build-${{ matrix.package }}
+    - name: Setup Python
+      uses: actions/setup-python@v1
+      with:
+        python-version: 3.8
+    - name: Install System Packages
+      run: |
+        sudo apt-get -yqq install ccache gfortran perl perl-base r-base r-base-core r-base-dev findutils openssl libssl-dev libpciaccess-dev
+        R --version
+        perl --version
+    - name: Copy Configuration
+      run: |
+        ccache -M 300M && ccache -z
+        # Set up external deps for build tests, b/c they take too long to compile
+        cp share/spack/qa/configuration/*.yaml etc/spack/
+    - name: Run the build test
+      run: |
+        . share/spack/setup-env.sh
+        SPEC=${{ matrix.package }} share/spack/qa/run-build-tests
+        ccache -s

.github/workflows/minimum_python_versions.yaml

@@ -0,0 +1,30 @@
+name: python version check
+
+on:
+  push:
+    branches:
+      - master
+      - develop
+  pull_request:
+    branches:
+      - master
+      - develop
+jobs:
+  validate:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v1
+    - name: Setup Python
+      uses: actions/setup-python@v1
+      with:
+        python-version: 3.7
+    - name: Install Python Packages
+      run: |
+        pip install --upgrade pip
+        pip install --upgrade vermin
+    - name: Minimum Version (Spack's Core)
+      run: vermin --backport argparse -t=2.6- -t=3.5- -v lib/spack/spack/ lib/spack/llnl/ bin/
+    - name: Minimum Version (Repositories)
+      run: vermin --backport argparse -t=2.6- -t=3.5- -v var/spack/repos

.github/workflows/nightly-win-builds.yml

@@ -1,31 +0,0 @@
-name: Windows Paraview Nightly
-
-on:
-  schedule:
-    - cron: '0 2 * * *' # Run at 2 am
-
-defaults:
-  run:
-    shell:
-     powershell Invoke-Expression -Command "./share/spack/qa/windows_test_setup.ps1"; {0}
-
-
-jobs:
-  build-paraview-deps:
-    runs-on: windows-latest
-    steps:
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-      with:
-        fetch-depth: 0
-    - uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1
-      with:
-        python-version: 3.9
-    - name: Install Python packages
-      run: |
-          python -m pip install --upgrade pip six pywin32 setuptools coverage
-    - name: Build Test
-      run: |
-        spack compiler find
-        spack external find cmake ninja win-sdk win-wdk wgl msmpi
-        spack -d install -y --cdash-upload-url https://cdash.spack.io/submit.php?project=Spack+on+Windows --cdash-track Nightly --only dependencies paraview
-        exit 0

.github/workflows/setup_git.ps1

@@ -1,10 +0,0 @@
-# (c) 2022 Lawrence Livermore National Laboratory
-
-git config --global user.email "spack@example.com"
-git config --global user.name "Test User"
-git config --global core.longpaths true
-
-if ($(git branch --show-current) -ne "develop")
-{
-    git branch develop origin/develop
-}

.github/workflows/setup_git.sh

@@ -1,8 +0,0 @@
-#!/bin/bash -e
-git config --global user.email "spack@example.com"
-git config --global user.name "Test User"
-
-# create a local pr base branch
-if [[ -n $GITHUB_BASE_REF ]]; then
-    git fetch origin "${GITHUB_BASE_REF}:${GITHUB_BASE_REF}"
-fi

.github/workflows/system_shortcut_check.ps1

@@ -1,4 +0,0 @@
-param ($systemFolder, $shortcut)
-
-$start = [System.Environment]::GetFolderPath("$systemFolder")
-Invoke-Item "$start\Programs\Spack\$shortcut"

.github/workflows/unit_tests.yaml

@@ -1,217 +0,0 @@
-name: unit tests
-
-on:
-  workflow_dispatch:
-  workflow_call:
-
-concurrency:
-  group: unit_tests-${{github.ref}}-${{github.event.pull_request.number || github.run_number}}
-  cancel-in-progress: true
-
-jobs:
-  # Run unit tests with different configurations on linux
-  ubuntu:
-    runs-on: ${{ matrix.os }}
-    strategy:
-      matrix:
-        os: [ubuntu-latest]
-        python-version: ['3.7', '3.8', '3.9', '3.10', '3.11']
-        concretizer: ['clingo']
-        on_develop:
-        - ${{ github.ref == 'refs/heads/develop' }}
-        include:
-        - python-version: '3.11'
-          os: ubuntu-latest
-          concretizer: original
-          on_develop: ${{ github.ref == 'refs/heads/develop' }}
-        - python-version: '3.6'
-          os: ubuntu-20.04
-          concretizer: clingo
-          on_develop: ${{ github.ref == 'refs/heads/develop' }}
-        exclude:
-        - python-version: '3.7'
-          os: ubuntu-latest
-          concretizer: 'clingo'
-          on_develop: false
-        - python-version: '3.8'
-          os: ubuntu-latest
-          concretizer: 'clingo'
-          on_develop: false
-        - python-version: '3.9'
-          os: ubuntu-latest
-          concretizer: 'clingo'
-          on_develop: false
-        - python-version: '3.10'
-          os: ubuntu-latest
-          concretizer: 'clingo'
-          on_develop: false
-
-    steps:
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # @v2
-      with:
-        fetch-depth: 0
-    - uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1 # @v2
-      with:
-        python-version: ${{ matrix.python-version }}
-    - name: Install System packages
-      run: |
-          sudo apt-get -y update
-          # Needed for unit tests
-          sudo apt-get -y install \
-              coreutils cvs gfortran graphviz gnupg2 mercurial ninja-build \
-              cmake bison libbison-dev kcov
-    - name: Install Python packages
-      run: |
-          pip install --upgrade pip setuptools pytest pytest-xdist pytest-cov
-          pip install --upgrade flake8 "isort>=4.3.5" "mypy>=0.900" "click" "black"
-    - name: Setup git configuration
-      run: |
-          # Need this for the git tests to succeed.
-          git --version
-          . .github/workflows/setup_git.sh
-    - name: Bootstrap clingo
-      if: ${{ matrix.concretizer == 'clingo' }}
-      env:
-          SPACK_PYTHON: python
-      run: |
-          . share/spack/setup-env.sh
-          spack bootstrap disable spack-install
-          spack bootstrap now
-          spack -v solve zlib
-    - name: Run unit tests
-      env:
-          SPACK_PYTHON: python
-          SPACK_TEST_SOLVER: ${{ matrix.concretizer }}
-          SPACK_TEST_PARALLEL: 2
-          COVERAGE: true
-          UNIT_TEST_COVERAGE: ${{ matrix.python-version == '3.11' }}
-      run: |
-          share/spack/qa/run-unit-tests
-    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d
-      with:
-        flags: unittests,linux,${{ matrix.concretizer }}
-  # Test shell integration
-  shell:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # @v2
-      with:
-        fetch-depth: 0
-    - uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1 # @v2
-      with:
-        python-version: '3.11'
-    - name: Install System packages
-      run: |
-          sudo apt-get -y update
-          # Needed for shell tests
-          sudo apt-get install -y coreutils kcov csh zsh tcsh fish dash bash
-    - name: Install Python packages
-      run: |
-          pip install --upgrade pip setuptools pytest coverage[toml] pytest-xdist
-    - name: Setup git configuration
-      run: |
-          # Need this for the git tests to succeed.
-          git --version
-          . .github/workflows/setup_git.sh
-    - name: Run shell tests
-      env:
-          COVERAGE: true
-      run: |
-          share/spack/qa/run-shell-tests
-    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d
-      with:
-        flags: shelltests,linux
-
-  # Test RHEL8 UBI with platform Python. This job is run
-  # only on PRs modifying core Spack
-  rhel8-platform-python:
-    runs-on: ubuntu-latest
-    container: registry.access.redhat.com/ubi8/ubi
-    steps:
-    - name: Install dependencies
-      run: |
-          dnf install -y \
-              bzip2 curl file gcc-c++ gcc gcc-gfortran git gnupg2 gzip \
-              make patch tcl unzip which xz
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # @v2
-    - name: Setup repo and non-root user
-      run: |
-          git --version
-          git config --global --add safe.directory /__w/spack/spack
-          git fetch --unshallow
-          . .github/workflows/setup_git.sh
-          useradd spack-test
-          chown -R spack-test .
-    - name: Run unit tests
-      shell: runuser -u spack-test -- bash {0}
-      run: |
-          source share/spack/setup-env.sh
-          spack -d bootstrap now --dev
-          spack unit-test -k 'not cvs and not svn and not hg' -x --verbose
-  # Test for the clingo based solver (using clingo-cffi)
-  clingo-cffi:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # @v2
-      with:
-        fetch-depth: 0
-    - uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1 # @v2
-      with:
-        python-version: '3.11'
-    - name: Install System packages
-      run: |
-          sudo apt-get -y update
-          sudo apt-get -y install coreutils cvs gfortran graphviz gnupg2 mercurial ninja-build kcov
-    - name: Install Python packages
-      run: |
-          pip install --upgrade pip setuptools pytest coverage[toml] pytest-cov clingo pytest-xdist
-          pip install --upgrade flake8 "isort>=4.3.5" "mypy>=0.900" "click" "black"
-    - name: Setup git configuration
-      run: |
-          # Need this for the git tests to succeed.
-          git --version
-          . .github/workflows/setup_git.sh
-    - name: Run unit tests (full suite with coverage)
-      env:
-          COVERAGE: true
-          SPACK_TEST_SOLVER: clingo
-      run: |
-          share/spack/qa/run-unit-tests
-    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d # @v2.1.0
-      with:
-        flags: unittests,linux,clingo
-  # Run unit tests on MacOS
-  macos:
-    runs-on: macos-latest
-    strategy:
-      matrix:
-        python-version: ["3.10"]
-    steps:
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # @v2
-      with:
-        fetch-depth: 0
-    - uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1 # @v2
-      with:
-        python-version: ${{ matrix.python-version }}
-    - name: Install Python packages
-      run: |
-          pip install --upgrade pip setuptools
-          pip install --upgrade pytest coverage[toml] pytest-xdist pytest-cov
-    - name: Setup Homebrew packages
-      run: |
-        brew install dash fish gcc gnupg2 kcov
-    - name: Run unit tests
-      env:
-        SPACK_TEST_SOLVER: clingo
-        SPACK_TEST_PARALLEL: 4
-      run: |
-        git --version
-        . .github/workflows/setup_git.sh
-        . share/spack/setup-env.sh
-        $(which spack) bootstrap disable spack-install
-        $(which spack) solve zlib
-        common_args=(--dist loadfile --tx '4*popen//python=./bin/spack-tmpconfig python -u ./bin/spack python' -x)
-        $(which spack) unit-test --cov --cov-config=pyproject.toml --cov-report=xml:coverage.xml "${common_args[@]}"
-    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d
-      with:
-        flags: unittests,macos

.github/workflows/valid-style.yml

@@ -1,87 +0,0 @@
-name: style
-
-on:
-  workflow_call:
-    inputs:
-      with_coverage:
-        required: true
-        type: string
-
-concurrency:
-  group: style-${{github.ref}}-${{github.event.pull_request.number || github.run_number}}
-  cancel-in-progress: true
-
-
-jobs:
-  # Validate that the code can be run on all the Python versions
-  # supported by Spack
-  validate:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # @v2
-    - uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1 # @v2
-      with:
-        python-version: '3.11'
-        cache: 'pip'
-    - name: Install Python Packages
-      run: |
-        pip install --upgrade pip
-        pip install --upgrade vermin
-    - name: vermin (Spack's Core)
-      run: vermin --backport importlib --backport argparse --violations --backport typing -t=3.6- -vvv lib/spack/spack/ lib/spack/llnl/ bin/
-    - name: vermin (Repositories)
-      run: vermin --backport importlib --backport argparse --violations --backport typing -t=3.6- -vvv var/spack/repos
-  # Run style checks on the files that have been changed
-  style:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # @v2
-      with:
-        fetch-depth: 0
-    - uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1 # @v2
-      with:
-        python-version: '3.11'
-        cache: 'pip'
-    - name: Install Python packages
-      run: |
-        python3 -m pip install --upgrade pip setuptools types-six black==23.1.0 mypy isort clingo flake8
-    - name: Setup git configuration
-      run: |
-        # Need this for the git tests to succeed.
-        git --version
-        . .github/workflows/setup_git.sh
-    - name: Run style tests
-      run: |
-          share/spack/qa/run-style-tests
-  audit:
-    uses: ./.github/workflows/audit.yaml
-    with:
-      with_coverage: ${{ inputs.with_coverage }}
-      python_version: '3.11'
-  # Check that spack can bootstrap the development environment on Python 3.6 - RHEL8
-  bootstrap-dev-rhel8:
-    runs-on: ubuntu-latest
-    container: registry.access.redhat.com/ubi8/ubi
-    steps:
-      - name: Install dependencies
-        run: |
-          dnf install -y \
-              bzip2 curl file gcc-c++ gcc gcc-gfortran git gnupg2 gzip \
-              make patch tcl unzip which xz
-      - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # @v2
-      - name: Setup repo and non-root user
-        run: |
-          git --version
-          git config --global --add safe.directory /__w/spack/spack
-          git fetch --unshallow
-          . .github/workflows/setup_git.sh
-          useradd spack-test
-          chown -R spack-test .
-      - name: Bootstrap Spack development environment
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          source share/spack/setup-env.sh
-          spack debug report
-          spack -d bootstrap now --dev
-          spack style -t black
-          spack unit-test -V

.github/workflows/windows_python.yml

@@ -1,79 +0,0 @@
-name: windows
-
-on:
-  workflow_call:
-
-concurrency:
-  group: windows-${{github.ref}}-${{github.event.pull_request.number || github.run_number}}
-  cancel-in-progress: true
-
-defaults:
-  run:
-    shell:
-     powershell Invoke-Expression -Command "./share/spack/qa/windows_test_setup.ps1"; {0}
-jobs:
-  unit-tests:
-    runs-on: windows-latest
-    steps:
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-      with:
-        fetch-depth: 0
-    - uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1
-      with:
-        python-version: 3.9
-    - name: Install Python packages
-      run: |
-          python -m pip install --upgrade pip pywin32 setuptools pytest-cov clingo
-    - name: Create local develop
-      run: |
-        ./.github/workflows/setup_git.ps1
-    - name: Unit Test
-      run: |
-        spack unit-test -x --verbose --cov --cov-config=pyproject.toml --ignore=lib/spack/spack/test/cmd
-        ./share/spack/qa/validate_last_exit.ps1
-        coverage combine -a
-        coverage xml
-    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d
-      with:
-        flags: unittests,windows
-  unit-tests-cmd:
-    runs-on: windows-latest
-    steps:
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-      with:
-        fetch-depth: 0
-    - uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1
-      with:
-        python-version: 3.9
-    - name: Install Python packages
-      run: |
-          python -m pip install --upgrade pip pywin32 setuptools coverage pytest-cov clingo
-    - name: Create local develop
-      run: |
-        ./.github/workflows/setup_git.ps1
-    - name: Command Unit Test
-      run: |
-        spack unit-test -x --verbose --cov --cov-config=pyproject.toml lib/spack/spack/test/cmd
-        ./share/spack/qa/validate_last_exit.ps1
-        coverage combine -a
-        coverage xml
-    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d
-      with:
-        flags: unittests,windows
-  build-abseil:
-    runs-on: windows-latest
-    steps:
-    - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
-      with:
-        fetch-depth: 0
-    - uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1
-      with:
-        python-version: 3.9
-    - name: Install Python packages
-      run: |
-          python -m pip install --upgrade pip pywin32 setuptools coverage
-    - name: Build Test
-      run: |
-        spack compiler find
-        spack -d external find cmake ninja
-        spack -d install abseil-cpp

.gitignore

@@ -1,515 +1,29 @@
-##########################
-# Spack-specific ignores #
-##########################
-
+/db
 /var/spack/stage
 /var/spack/cache
 /var/spack/environments
 /var/spack/repos/*/index.yaml
 /var/spack/repos/*/lock
+*.pyc
 /opt
+*~
+.DS_Store
+.idea
 # Ignore everything in /etc/spack except /etc/spack/defaults
 /etc/spack/*
 !/etc/spack/defaults
+/etc/spackconfig
+/share/spack/dotkit
 /share/spack/modules
 /share/spack/lmod
-# Debug logs
-spack-db.*
+/TAGS
+*.swp
+/htmlcov
+.coverage
+\#*
+.#*
+lib/spack/spack/test/.cache
+/bin/spackc
 *.in.log
 *.out.log
-
-###########################
-# Python-specific ignores #
-###########################
-
-# Byte-compiled / optimized / DLL files
-__pycache__/
-*.py[cod]
-*$py.class
-
-# C extensions
-*.so
-
-# Distribution / packaging
-.Python
-build/
-develop-eggs/
-dist/
-downloads/
-eggs/
-.eggs/
-#lib/
-#lib64/
-parts/
-sdist/
-#var/
-wheels/
-share/python-wheels/
-*.egg-info/
-.installed.cfg
-*.egg
-MANIFEST
-
-# PyInstaller
-#  Usually these files are written by a python script from a template
-#  before PyInstaller builds the exe, so as to inject date/other infos into it.
-*.manifest
-*.spec
-
-# Installer logs
-pip-log.txt
-pip-delete-this-directory.txt
-
-# Unit test / coverage reports
-htmlcov/
-.tox/
-.nox/
-.coverage
-.coverage.*
-.cache
-nosetests.xml
-coverage.xml
-*.cover
-*.py,cover
-.hypothesis/
-.pytest_cache/
-cover/
-
-# Translations
-*.mo
-*.pot
-
-# Django stuff:
-*.log
-local_settings.py
-db.sqlite3
-db.sqlite3-journal
-
-# Flask stuff:
-instance/
-.webassets-cache
-
-# Scrapy stuff:
-.scrapy
-
-# Sphinx documentation
-docs/_build/
-
-# PyBuilder
-.pybuilder/
-target/
-
-# Jupyter Notebook
-.ipynb_checkpoints
-
-# IPython
-profile_default/
-ipython_config.py
-
-# pyenv
-#   For a library or package, you might want to ignore these files since the code is
-#   intended to run in multiple environments; otherwise, check them in:
-# .python-version
-
-# pipenv
-#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
-#   However, in case of collaboration, if having platform-specific dependencies or dependencies
-#   having no cross-platform support, pipenv may install dependencies that don't work, or not
-#   install all needed dependencies.
-#Pipfile.lock
-
-# PEP 582; used by e.g. github.com/David-OConnor/pyflow
-__pypackages__/
-
-# Celery stuff
-celerybeat-schedule
-celerybeat.pid
-
-# SageMath parsed files
-*.sage.py
-
-# Environments
-.env
-.venv
-env/
-venv/
-ENV/
-env.bak/
-venv.bak/
-!/lib/spack/env
-
-# Spyder project settings
-.spyderproject
-.spyproject
-
-# Rope project settings
-.ropeproject
-
-# mkdocs documentation
-/site
-
-# mypy
-.mypy_cache/
-.dmypy.json
-dmypy.json
-
-# Pyre type checker
-.pyre/
-
-# pytype static type analyzer
-.pytype/
-
-# Cython debug symbols
-cython_debug/
-
-########################
-# Vim-specific ignores #
-########################
-
-# Swap
-[._]*.s[a-v][a-z]
-!*.svg  # comment out if you don't need vector files
-[._]*.sw[a-p]
-[._]s[a-rt-v][a-z]
-[._]ss[a-gi-z]
-[._]sw[a-p]
-
-# Session
-Session.vim
-Sessionx.vim
-
-# Temporary
-.netrwhist
-*~
-# Auto-generated tag files
-tags
-# Persistent undo
-[._]*.un~
-
-##########################
-# Emacs-specific ignores #
-##########################
-
-*~
-\#*\#
-/.emacs.desktop
-/.emacs.desktop.lock
-*.elc
-auto-save-list
-tramp
-.\#*
-
-# Org-mode
-.org-id-locations
-*_archive
-
-# flymake-mode
-*_flymake.*
-
-# eshell files
-/eshell/history
-/eshell/lastdir
-
-# zsh byte-compiled files
-*.zwc
-
-# elpa packages
-/elpa/
-
-# reftex files
-*.rel
-
-# AUCTeX auto folder
-/auto/
-
-# cask packages
-.cask/
-dist/
-
-# Flycheck
-flycheck_*.el
-
-# server auth directory
-/server/
-
-# projectiles files
-.projectile
-
-# directory configuration
-.dir-locals.el
-
-# network security
-/network-security.data
-
-############################
-# Eclipse-specific ignores #
-############################
-
-.metadata
-#bin/
-tmp/
-*.tmp
-*.bak
-*.swp
-*~.nib
-local.properties
-.settings/
-.loadpath
-.recommenders
-
-# External tool builders
-.externalToolBuilders/
-
-# Locally stored "Eclipse launch configurations"
-*.launch
-
-# PyDev specific (Python IDE for Eclipse)
-*.pydevproject
-
-# CDT-specific (C/C++ Development Tooling)
-.cproject
-
-# CDT- autotools
-.autotools
-
-# Java annotation processor (APT)
-.factorypath
-
-# PDT-specific (PHP Development Tools)
-.buildpath
-
-# sbteclipse plugin
-.target
-
-# Tern plugin
-.tern-project
-
-# TeXlipse plugin
-.texlipse
-
-# STS (Spring Tool Suite)
-.springBeans
-
-# Code Recommenders
-.recommenders/
-
-# Annotation Processing
-.apt_generated/
-.apt_generated_test/
-
-# Scala IDE specific (Scala & Java development for Eclipse)
-.cache-main
-.scala_dependencies
-.worksheet
-
-# Uncomment this line if you wish to ignore the project description file.
-# Typically, this file would be tracked if it contains build/dependency configurations:
-#.project
-
-##################################
-# Visual Studio-specific ignores #
-##################################
-
-.vscode/*
-!.vscode/settings.json
-!.vscode/tasks.json
-!.vscode/launch.json
-!.vscode/extensions.json
-*.code-workspace
-
-# Local History for Visual Studio Code
-.history/
-
-#################################
-# Sublime Text-specific ignores #
-#################################
-
-# Cache files for Sublime Text
-*.tmlanguage.cache
-*.tmPreferences.cache
-*.stTheme.cache
-
-# Workspace files are user-specific
-*.sublime-workspace
-
-# Project files should be checked into the repository, unless a significant
-# proportion of contributors will probably not be using Sublime Text
-# *.sublime-project
-
-# SFTP configuration file
-sftp-config.json
-sftp-config-alt*.json
-
-# Package control specific files
-Package Control.last-run
-Package Control.ca-list
-Package Control.ca-bundle
-Package Control.system-ca-bundle
-Package Control.cache/
-Package Control.ca-certs/
-Package Control.merged-ca-bundle
-Package Control.user-ca-bundle
-oscrypto-ca-bundle.crt
-bh_unicode_properties.cache
-
-# Sublime-github package stores a github token in this file
-# https://packagecontrol.io/packages/sublime-github
-GitHub.sublime-settings
-
-##############################
-# JetBrains-specific ignores #
-##############################
-
-# Ignore the entire folder since it may conatin more files than
-# just the ones listed below
-.idea/
-
-# Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio, WebStorm and Rider
-# Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839
-
-# User-specific stuff
-.idea/**/workspace.xml
-.idea/**/tasks.xml
-.idea/**/usage.statistics.xml
-.idea/**/dictionaries
-.idea/**/shelf
-
-# Generated files
-.idea/**/contentModel.xml
-
-# Sensitive or high-churn files
-.idea/**/dataSources/
-.idea/**/dataSources.ids
-.idea/**/dataSources.local.xml
-.idea/**/sqlDataSources.xml
-.idea/**/dynamic.xml
-.idea/**/uiDesigner.xml
-.idea/**/dbnavigator.xml
-
-# Gradle
-.idea/**/gradle.xml
-.idea/**/libraries
-
-# Gradle and Maven with auto-import
-# When using Gradle or Maven with auto-import, you should exclude module files,
-# since they will be recreated, and may cause churn.  Uncomment if using
-# auto-import.
-# .idea/artifacts
-# .idea/compiler.xml
-# .idea/jarRepositories.xml
-# .idea/modules.xml
-# .idea/*.iml
-# .idea/modules
-# *.iml
-# *.ipr
-
-# CMake
-cmake-build-*/
-
-# Mongo Explorer plugin
-.idea/**/mongoSettings.xml
-
-# File-based project format
-*.iws
-
-# IntelliJ
-out/
-
-# mpeltonen/sbt-idea plugin
-.idea_modules/
-
-# JIRA plugin
-atlassian-ide-plugin.xml
-
-# Cursive Clojure plugin
-.idea/replstate.xml
-
-# Crashlytics plugin (for Android Studio and IntelliJ)
-com_crashlytics_export_strings.xml
-crashlytics.properties
-crashlytics-build.properties
-fabric.properties
-
-# Editor-based Rest Client
-.idea/httpRequests
-
-# Android studio 3.1+ serialized cache file
-.idea/caches/build_file_checksums.ser
-
-##########################
-# macOS-specific ignores #
-##########################
-
-# General
-.DS_Store
-.AppleDouble
-.LSOverride
-
-# Icon must end with two \r
-Icon
-
-# Thumbnails
-._*
-
-# Files that might appear in the root of a volume
-.DocumentRevisions-V100
-.fseventsd
-.Spotlight-V100
-.TemporaryItems
-.Trashes
-.VolumeIcon.icns
-.com.apple.timemachine.donotpresent
-
-# Directories potentially created on remote AFP share
-.AppleDB
-.AppleDesktop
-Network Trash Folder
-Temporary Items
-.apdisk
-
-##########################
-# Linux-specific ignores #
-##########################
-
-*~
-
-# temporary files which can be created if a process still has a handle open of a deleted file
-.fuse_hidden*
-
-# KDE directory preferences
-.directory
-
-# Linux trash folder which might appear on any partition or disk
-.Trash-*
-
-# .nfs files are created when an open file is removed but is still being accessed
-.nfs*
-
-############################
-# Windows-specific ignores #
-############################
-
-# Windows thumbnail cache files
-Thumbs.db
-Thumbs.db:encryptable
-ehthumbs.db
-ehthumbs_vista.db
-
-# Dump file
-*.stackdump
-
-# Folder config file
-[Dd]esktop.ini
-
-# Recycle Bin used on file shares
-$RECYCLE.BIN/
-
-# Windows Installer files
-*.cab
-*.msi
-*.msix
-*.msm
-*.msp
-
-# Windows shortcuts
-*.lnk
+*.orig

.mailmap

@@ -3,8 +3,7 @@ Adam Moody            <moody20@llnl.gov>                Adam T. Moody
 Alfredo Gimenez       <gimenez1@llnl.gov>               Alfredo Gimenez         <alfredo.gimenez@gmail.com>
 Alfredo Gimenez       <gimenez1@llnl.gov>               Alfredo Adolfo Gimenez  <alfredo.gimenez@gmail.com>
 Andrew Williams       <williamsa89@cardiff.ac.uk>       Andrew Williams         <andrew@alshain.org.uk>
-Axel Huebl            <axelhuebl@lbl.gov>               Axel Huebl              <a.huebl@hzdr.de>
-Axel Huebl            <axelhuebl@lbl.gov>               Axel Huebl              <axel.huebl@plasma.ninja>
+Axel Huebl            <a.huebl@hzdr.de>                 Axel Huebl              <axel.huebl@plasma.ninja>
 Ben Boeckel           <ben.boeckel@kitware.com>         Ben Boeckel             <mathstuf@gmail.com>
 Ben Boeckel           <ben.boeckel@kitware.com>         Ben Boeckel             <mathstuf@users.noreply.github.com>
 Benedikt Hegner       <hegner@cern.ch>                  Benedikt Hegner         <benedikt.hegner@cern.ch>
@@ -21,8 +20,8 @@ Geoffrey Oxberry      <oxberry1@llnl.gov>               Geoffrey Oxberry
 Glenn Johnson         <glenn-johnson@uiowa.edu>         Glenn Johnson           <gjohnson@argon-ohpc.hpc.uiowa.edu>
 Glenn Johnson         <glenn-johnson@uiowa.edu>         Glenn Johnson           <glennpj@gmail.com>
 Gregory Becker        <becker33@llnl.gov>               Gregory Becker          <becker33.llnl.gov>
-Gregory Becker        <becker33@llnl.gov>               Gregory Becker          <becker33.llnl.gov>
-Gregory Becker        <becker33@llnl.gov>               Gregory Becker          <becker33@llnl.gov>
+Gregory Becker        <becker33@llnl.gov>               becker33                <becker33.llnl.gov>
+Gregory Becker        <becker33@llnl.gov>               becker33                <becker33@llnl.gov>
 Gregory L. Lee        <lee218@llnl.gov>                 Greg Lee                <lee218@llnl.gov>
 Gregory L. Lee        <lee218@llnl.gov>                 Gregory L. Lee          <lee218@cab687.llnl.gov>
 Gregory L. Lee        <lee218@llnl.gov>                 Gregory L. Lee          <lee218@cab690.llnl.gov>

.readthedocs.yml

@@ -1,16 +1,9 @@
 version: 2
 
-build:
-  os: "ubuntu-22.04"
-  apt_packages:
-    - graphviz
-  tools:
-    python: "3.11"
-
 sphinx:
   configuration: lib/spack/docs/conf.py
-  fail_on_warning: true
 
 python:
+  version: 3.7
   install:
     - requirements: lib/spack/docs/requirements.txt

.travis.yml

@@ -0,0 +1,168 @@
+#=============================================================================
+# Project settings
+#=============================================================================
+# Only build master and develop on push; do not build every branch.
+branches:
+  only:
+    - master
+    - develop
+    - /^releases\/.*$/
+
+#=============================================================================
+# Build matrix
+#=============================================================================
+
+dist: xenial
+
+jobs:
+  fast_finish: true
+  include:
+    - stage: 'style checks'
+      python: '3.8'
+      os: linux
+      language: python
+      env: TEST_SUITE=flake8
+# Shell integration with module files
+    - python: '3.8'
+      os: linux
+      language: python
+      env: [ TEST_SUITE=bootstrap ]
+    - stage: 'unit tests + documentation'
+      python: '2.6'
+      dist: trusty
+      os: linux
+      language: python
+      env: [ TEST_SUITE=unit, COVERAGE=true ]
+    - python: '2.7'
+      os: linux
+      language: python
+      env: [ TEST_SUITE=unit, COVERAGE=true ]
+    - python: '3.5'
+      os: linux
+      language: python
+      env: TEST_SUITE=unit
+    - python: '3.6'
+      os: linux
+      language: python
+      env: TEST_SUITE=unit
+    - python: '3.7'
+      os: linux
+      language: python
+      env: TEST_SUITE=unit
+    - python: '3.8'
+      os: linux
+      language: python
+      env: [ TEST_SUITE=unit, COVERAGE=true ]
+    - python: '3.8'
+      os: linux
+      language: python
+      env: TEST_SUITE=doc
+    - os: osx
+      language: generic
+      env: [ TEST_SUITE=unit, PYTHON_VERSION=2.7, COVERAGE=true ]
+      if: type != pull_request
+
+stages:
+  - 'style checks'
+  - 'unit tests + documentation'
+
+
+#=============================================================================
+# Environment
+#=============================================================================
+
+# Docs need graphviz to build
+addons:
+  # for Linux builds, we use APT
+  apt:
+    packages:
+      - ccache
+      - cmake
+      - gfortran
+      - graphviz
+      - gnupg2
+      - kcov
+      - mercurial
+      - ninja-build
+      - perl
+      - perl-base
+      - realpath
+      - r-base
+      - r-base-core
+      - r-base-dev
+      - zsh
+  # for Mac builds, we use Homebrew
+  homebrew:
+    packages:
+      - python@2
+      - gcc
+      - gnupg2
+      - ccache
+      - dash
+      - kcov
+    update: true
+
+# ~/.ccache needs to be cached directly as Travis is not taking care of it
+# (possibly because we use 'language: python' and not 'language: c')
+cache:
+  pip: true
+  ccache: true
+  directories:
+    - ~/.ccache
+
+# Work around Travis's lack of support for Python on OSX
+before_install:
+  - if [[ "$TRAVIS_OS_NAME" == "osx" ]]; then
+        pip2 install --upgrade pip;
+        pip2 install virtualenv;
+        virtualenv venv;
+        source venv/bin/activate;
+    fi
+  - ccache -M 2G && ccache -z
+
+# Install various dependencies
+install:
+  - pip install --upgrade pip
+  - pip install --upgrade six
+  - pip install --upgrade setuptools
+  - pip install --upgrade codecov coverage==4.5.4
+  - pip install --upgrade flake8
+  - pip install --upgrade pep8-naming
+  - if [[ "$TEST_SUITE" == "doc" ]]; then
+        pip install --upgrade -r lib/spack/docs/requirements.txt;
+    fi
+
+before_script:
+  # Need this for the git tests to succeed.
+  - git config --global user.email "spack@example.com"
+  - git config --global user.name "Test User"
+
+  # Need this to be able to compute the list of changed files
+  - git fetch origin ${TRAVIS_BRANCH}:${TRAVIS_BRANCH}
+
+#=============================================================================
+# Building
+#=============================================================================
+script:
+  - share/spack/qa/run-$TEST_SUITE-tests
+
+after_success:
+  - ccache -s
+  - case "$TEST_SUITE" in
+        unit)
+            if [[ "$COVERAGE" == "true" ]]; then
+                codecov --env PYTHON_VERSION
+                        --required
+                        --flags "${TEST_SUITE}${TRAVIS_OS_NAME}";
+            fi
+            ;;
+    esac
+
+#=============================================================================
+# Notifications
+#=============================================================================
+notifications:
+  email:
+    recipients: tgamblin@llnl.gov
+    on_success: change
+    on_failure: always

CITATION.cff

@@ -1,58 +0,0 @@
-# If you are referencing Spack in a publication, please cite the SC'15 paper
-# described here.
-#
-# Here's the raw citation:
-#
-#   Todd Gamblin, Matthew P. LeGendre, Michael R. Collette, Gregory L. Lee,
-#   Adam Moody, Bronis R. de Supinski, and W. Scott Futral.
-#   The Spack Package Manager: Bringing Order to HPC Software Chaos.
-#   In Supercomputing 2015 (SC’15), Austin, Texas, November 15-20 2015. LLNL-CONF-669890.
-#
-# Or, in BibTeX:
-#
-# @inproceedings{Gamblin_The_Spack_Package_2015,
-#     address = {Austin, Texas, USA},
-#     author = {Gamblin, Todd and LeGendre, Matthew and
-#               Collette, Michael R. and Lee, Gregory L. and
-#               Moody, Adam and de Supinski, Bronis R. and Futral, Scott},
-#     doi = {10.1145/2807591.2807623},
-#     month = {November 15-20},
-#     note = {LLNL-CONF-669890},
-#     series = {Supercomputing 2015 (SC’15)},
-#     title = {{The Spack Package Manager: Bringing Order to HPC Software Chaos}},
-#     url = {https://github.com/spack/spack},
-#     year = {2015}
-# }
-#
-# And here's the CITATION.cff format:
-#
-cff-version: 1.2.0
-message: "If you are referencing Spack in a publication, please cite the paper below."
-preferred-citation:
-  type: conference-paper
-  doi: "10.1145/2807591.2807623"
-  url: "https://github.com/spack/spack"
-  authors:
-  - family-names: "Gamblin"
-    given-names: "Todd"
-  - family-names: "LeGendre"
-    given-names: "Matthew"
-  - family-names: "Collette"
-    given-names: "Michael R."
-  - family-names: "Lee"
-    given-names: "Gregory L."
-  - family-names: "Moody"
-    given-names: "Adam"
-  - family-names: "de Supinski"
-    given-names: "Bronis R."
-  - family-names: "Futral"
-    given-names: "Scott"
-  title: "The Spack Package Manager: Bringing Order to HPC Software Chaos"
-  conference:
-    name: "Supercomputing 2015 (SC’15)"
-    city: "Austin"
-    region: "Texas"
-    country: "USA"
-  month: November 15-20
-  year: 2015
-  notes: LLNL-CONF-669890

COPYRIGHT

@@ -28,28 +28,14 @@ text in the license header:
 
 External Packages
 -------------------
-
-Spack bundles most external dependencies in lib/spack/external. It also
-includes the sbang tool directly in bin/sbang. These packages are covered
-by various permissive licenses. A summary listing follows. See the
-license included with each package for full details.
-
-PackageName: altgraph
-PackageHomePage: https://altgraph.readthedocs.io/en/latest/index.html
-PackageLicenseDeclared: MIT
+Spack bundles its external dependencies in lib/spack/external.  These
+packages are covered by various permissive licenses.  A summary listing
+follows.  See the license included with each package for full details.
 
 PackageName: argparse
 PackageHomePage: https://pypi.python.org/pypi/argparse
 PackageLicenseDeclared: Python-2.0
 
-PackageName: astunparse
-PackageHomePage: https://github.com/simonpercivall/astunparse
-PackageLicenseDeclared: Python-2.0
-
-PackageName: attrs
-PackageHomePage: https://github.com/python-attrs/attrs
-PackageLicenseDeclared: MIT
-
 PackageName: ctest_log_parser
 PackageHomePage: https://github.com/Kitware/CMake
 PackageLicenseDeclared: BSD-3-Clause
@@ -58,8 +44,8 @@ PackageName: distro
 PackageHomePage: https://pypi.python.org/pypi/distro
 PackageLicenseDeclared: Apache-2.0
 
-PackageName: functools32
-PackageHomePage: https://github.com/MiCHiLU/python-functools32
+PackageName: functools
+PackageHomePage: https://github.com/python/cpython/blob/2.7/Lib/functools.py
 PackageLicenseDeclared: Python-2.0
 
 PackageName: jinja2
@@ -70,10 +56,6 @@ PackageName: jsonschema
 PackageHomePage: https://pypi.python.org/pypi/jsonschema
 PackageLicenseDeclared: MIT
 
-PackageName: macholib
-PackageHomePage: https://macholib.readthedocs.io/en/latest/index.html
-PackageLicenseDeclared: MIT
-
 PackageName: markupsafe
 PackageHomePage: https://pypi.python.org/pypi/MarkupSafe
 PackageLicenseDeclared: BSD-3-Clause
@@ -86,10 +68,6 @@ PackageName: py
 PackageHomePage: https://pypi.python.org/pypi/py
 PackageLicenseDeclared: MIT
 
-PackageName: pyrsistent
-PackageHomePage: http://github.com/tobgu/pyrsistent
-PackageLicenseDeclared: MIT
-
 PackageName: pytest
 PackageHomePage: https://pypi.python.org/pypi/pytest
 PackageLicenseDeclared: MIT
@@ -98,10 +76,14 @@ PackageName: ruamel.yaml
 PackageHomePage: https://yaml.readthedocs.io/
 PackageLicenseDeclared: MIT
 
-PackageName: sbang
-PackageHomePage: https://github.com/spack/sbang
-PackageLicenseDeclared: Apache-2.0 OR MIT
-
 PackageName: six
 PackageHomePage: https://pypi.python.org/pypi/six
 PackageLicenseDeclared: MIT
+
+PackageName: macholib
+PackageHomePage: https://macholib.readthedocs.io/en/latest/index.html
+PackageLicenseDeclared: MIT
+
+PackageName: altgraph
+PackageHomePage: https://altgraph.readthedocs.io/en/latest/index.html
+PackageLicenseDeclared: MIT

LICENSE-MIT

@@ -1,21 +1,20 @@
-MIT License
+Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
+Spack Project Developers. See the top-level COPYRIGHT file for details.
 
-Copyright (c) 2013-2023 LLNS, LLC and other Spack Project Developers.
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
 
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
 
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.

README.md

@@ -1,12 +1,10 @@
 # <img src="https://cdn.rawgit.com/spack/spack/develop/share/spack/logo/spack-logo.svg" width="64" valign="middle" alt="Spack"/> Spack
 
-[![Unit Tests](https://github.com/spack/spack/workflows/linux%20tests/badge.svg)](https://github.com/spack/spack/actions)
-[![Bootstrapping](https://github.com/spack/spack/actions/workflows/bootstrap.yml/badge.svg)](https://github.com/spack/spack/actions/workflows/bootstrap.yml)
+[![Build Status](https://travis-ci.org/spack/spack.svg?branch=develop)](https://travis-ci.org/spack/spack)
+[![Linux Builds](https://github.com/spack/spack/workflows/linux%20builds/badge.svg)](https://github.com/spack/spack/actions)
 [![codecov](https://codecov.io/gh/spack/spack/branch/develop/graph/badge.svg)](https://codecov.io/gh/spack/spack)
-[![Containers](https://github.com/spack/spack/actions/workflows/build-containers.yml/badge.svg)](https://github.com/spack/spack/actions/workflows/build-containers.yml)
 [![Read the Docs](https://readthedocs.org/projects/spack/badge/?version=latest)](https://spack.readthedocs.io)
-[![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)
-[![Slack](https://slack.spack.io/badge.svg)](https://slack.spack.io)
+[![Slack](https://spackpm.herokuapp.com/badge.svg)](https://spackpm.herokuapp.com)
 
 Spack is a multi-platform package manager that builds and installs
 multiple versions and configurations of software. It works on Linux,
@@ -21,29 +19,27 @@ builds of the same package.  With Spack, you can build your software
 *all* the ways you want to.
 
 See the
-[Feature Overview](https://spack.readthedocs.io/en/latest/features.html)
+[Feature Overview](http://spack.readthedocs.io/en/latest/features.html)
 for examples and highlights.
 
 To install spack and your first package, make sure you have Python.
 Then:
 
-    $ git clone -c feature.manyFiles=true https://github.com/spack/spack.git
+    $ git clone https://github.com/spack/spack.git
     $ cd spack/bin
     $ ./spack install zlib
 
 Documentation
 ----------------
 
-[**Full documentation**](https://spack.readthedocs.io/) is available, or
+[**Full documentation**](http://spack.readthedocs.io/) is available, or
 run `spack help` or `spack help --all`.
 
-For a cheat sheet on Spack syntax, run `spack help --spec`.
-
 Tutorial
 ----------------
 
 We maintain a
-[**hands-on tutorial**](https://spack.readthedocs.io/en/latest/tutorial.html).
+[**hands-on tutorial**](http://spack.readthedocs.io/en/latest/tutorial.html).
 It covers basic to advanced usage, packaging, developer features, and large HPC
 deployments.  You can do all of the exercises on your own laptop using a
 Docker container.
@@ -61,8 +57,7 @@ packages to bugfixes, documentation, or even new core features.
 Resources:
 
 * **Slack workspace**: [spackpm.slack.com](https://spackpm.slack.com).
-  To get an invitation, visit [slack.spack.io](https://slack.spack.io).
-* [**Github Discussions**](https://github.com/spack/spack/discussions): not just for discussions, also Q&A.
+  To get an invitation, [**click here**](https://spackpm.herokuapp.com).
 * **Mailing list**: [groups.google.com/d/forum/spack](https://groups.google.com/d/forum/spack)
 * **Twitter**: [@spackpm](https://twitter.com/spackpm). Be sure to
   `@mention` us!
@@ -76,33 +71,15 @@ When you send your request, make ``develop`` the destination branch on the
 
 Your PR must pass Spack's unit tests and documentation tests, and must be
 [PEP 8](https://www.python.org/dev/peps/pep-0008/) compliant.  We enforce
-these guidelines with our CI process. To run these tests locally, and for
-helpful tips on git, see our
-[Contribution Guide](https://spack.readthedocs.io/en/latest/contribution_guide.html).
+these guidelines with [Travis CI](https://travis-ci.org/spack/spack).  To
+run these tests locally, and for helpful tips on git, see our
+[Contribution Guide](http://spack.readthedocs.io/en/latest/contribution_guide.html).
 
-Spack's `develop` branch has the latest contributions. Pull requests
-should target `develop`, and users who want the latest package versions,
-features, etc. can use `develop`.
-
-Releases
---------
-
-For multi-user site deployments or other use cases that need very stable
-software installations, we recommend using Spack's
-[stable releases](https://github.com/spack/spack/releases).
-
-Each Spack release series also has a corresponding branch, e.g.
-`releases/v0.14` has `0.14.x` versions of Spack, and `releases/v0.13` has
-`0.13.x` versions. We backport important bug fixes to these branches but
-we do not advance the package versions or make other changes that would
-change the way Spack concretizes dependencies within a release branch.
-So, you can base your Spack deployment on a release branch and `git pull`
-to get fixes, without the package churn that comes with `develop`.
-
-The latest release is always available with the `releases/latest` tag.
-
-See the [docs on releases](https://spack.readthedocs.io/en/latest/developer_guide.html#releases)
-for more details.
+Spack uses a rough approximation of the
+[Git Flow](http://nvie.com/posts/a-successful-git-branching-model/)
+branching model.  The ``develop`` branch contains the latest
+contributions, and ``master`` is always tagged and points to the latest
+stable release.
 
 Code of Conduct
 ------------------------
@@ -123,12 +100,9 @@ If you are referencing Spack in a publication, please cite the following paper:
 
  * Todd Gamblin, Matthew P. LeGendre, Michael R. Collette, Gregory L. Lee,
    Adam Moody, Bronis R. de Supinski, and W. Scott Futral.
-   [**The Spack Package Manager: Bringing Order to HPC Software Chaos**](https://www.computer.org/csdl/proceedings/sc/2015/3723/00/2807623.pdf).
+   [**The Spack Package Manager: Bringing Order to HPC Software Chaos**](http://www.computer.org/csdl/proceedings/sc/2015/3723/00/2807623.pdf).
    In *Supercomputing 2015 (SC’15)*, Austin, Texas, November 15-20 2015. LLNL-CONF-669890.
 
-On GitHub, you can copy this citation in APA or BibTeX format via the "Cite this repository"
-button. Or, see the comments in `CITATION.cff` for the raw BibTeX.
-
 License
 ----------------
 
@@ -146,4 +120,4 @@ See [LICENSE-MIT](https://github.com/spack/spack/blob/develop/LICENSE-MIT),
 
 SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
-LLNL-CODE-811652
+LLNL-CODE-647188

SECURITY.md

@@ -1,27 +0,0 @@
-# Security Policy
-
-## Supported Versions
-
-We provide security updates for `develop` and for the last two
-stable (`0.x`) release series of Spack. Security updates will be
-made available as patch (`0.x.1`, `0.x.2`, etc.) releases.
-
-For more on Spack's release structure, see
-[`README.md`](https://github.com/spack/spack#releases).
-
-## Reporting a Vulnerability
-
-You can report a vulnerability using GitHub's private reporting
-feature:
-
-1. Go to [github.com/spack/spack/security](https://github.com/spack/spack/security).
-2. Click "Report a vulnerability" in the upper right corner of that page.
-3. Fill out the form and submit your draft security advisory.
-
-More details are available in
-[GitHub's docs](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability).
-
-You can expect to hear back about security issues within two days.
-If your security issue is accepted, we will do our best to release
-a fix within a week. If fixing the issue will take longer than
-this, we will discuss timeline options with you.

bin/haspywin.py

@@ -1,19 +0,0 @@
-# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-# Spack Project Developers. See the top-level COPYRIGHT file for details.
-#
-# SPDX-License-Identifier: (Apache-2.0 OR MIT)
-import subprocess
-import sys
-
-
-def getpywin():
-    try:
-        import win32con  # noqa: F401
-    except ImportError:
-        print("pyWin32 not installed but is required...\nInstalling via pip:")
-        subprocess.check_call([sys.executable, "-m", "pip", "-q", "install", "--upgrade", "pip"])
-        subprocess.check_call([sys.executable, "-m", "pip", "-q", "install", "pywin32"])
-
-
-if __name__ == "__main__":
-    getpywin()

bin/sbang

@@ -1,103 +1,114 @@
-#!/bin/sh
+#!/bin/bash
 #
-# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-# sbang project developers. See the top-level COPYRIGHT file for details.
+# Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
+# Spack Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 #
 # `sbang`: Run scripts with long shebang lines.
 #
-# Many operating systems limit the length and number of possible
-# arguments in shebang lines, making it hard to use interpreters that are
-# deep in the directory hierarchy or require special arguments.
+# Many operating systems limit the length of shebang lines, making it
+# hard to use interpreters that are deep in the directory hierarchy.
+# `sbang` can run such scripts, either as a shebang interpreter, or
+# directly on the command line.
 #
-# To use, put the long shebang on the second line of your script, and
-# make sbang the interpreter, like this:
+# Usage
+# -----------------------------
+# Suppose you have a script, long-shebang.sh, like this:
 #
-#     #!/bin/sh /path/to/sbang
-#     #!/long/path/to/real/interpreter with arguments
+#     1    #!/very/long/path/to/some/interpreter
+#     2
+#     3    echo "success!"
 #
-# `sbang` will run the real interpreter with the script as its argument.
+# Invoking this script will result in an error on some OS's.  On
+# Linux, you get this:
 #
-# See https://github.com/spack/sbang for more details.
+#     $ ./long-shebang.sh
+#     -bash: ./long: /very/long/path/to/some/interp: bad interpreter:
+#            No such file or directory
+#
+# On Mac OS X, the system simply assumes the interpreter is the shell
+# and tries to run with it, which is likely not what you want.
+#
+#
+# `sbang` on the command line
+# -----------------------------
+# You can use `sbang` in two ways.  The first is to use it directly,
+# from the command line, like this:
+#
+#     $ sbang ./long-shebang.sh
+#     success!
+#
+#
+# `sbang` as the interpreter
+# -----------------------------
+# You can also use `sbang` *as* the interpreter for your script. Put
+# `#!/bin/bash /path/to/sbang` on line 1, and move the original
+# shebang to line 2 of the script:
+#
+#     1    #!/bin/bash /path/to/sbang
+#     2    #!/long/path/to/real/interpreter with arguments
+#     3
+#     4    echo "success!"
+#
+#     $ ./long-shebang.sh
+#     success!
+#
+# On Linux, you could shorten line 1 to `#!/path/to/sbang`, but other
+# operating systems like Mac OS X require the interpreter to be a
+# binary, so it's best to use `sbang` as a `bash` argument.
+# Obviously, for this to work, `sbang` needs to have a short enough
+# path that *it* will run without hitting OS limits.
+#
+# For Lua, scripts the second line can't start with #!, as # is not
+# the comment character in lua (even though lua ignores #! on the
+# *first* line of a script).  So, instrument a lua script like this,
+# using -- instead of # on the second line:
+#
+#     1    #!/bin/bash /path/to/sbang
+#     2    --!/long/path/to/lua with arguments
+#     3
+#     4    print "success!"
+#
+# How it works
+# -----------------------------
+# `sbang` is a very simple bash script. It looks at the first two
+# lines of a script argument and runs the last line starting with
+# `#!`, with the script as an argument. It also forwards arguments.
 #
-
-# Generic error handling
-die() {
-    echo "$@" 1>&2;
-    exit 1
-}
-
-# set SBANG_DEBUG to make the script print what would normally be executed.
-exec="exec"
-if [ -n "${SBANG_DEBUG}" ]; then
-    exec="echo "
-fi
 
 # First argument is the script we want to actually run.
 script="$1"
 
-# ensure that the script actually exists
-if [ -z "$script" ]; then
-    die "error: sbang requires exactly one argument"
-elif [ ! -f "$script" ]; then
-    die "$script: no such file or directory"
-fi
-
 # Search the first two lines of script for interpreters.
 lines=0
-while read -r line && [ $lines -ne 2 ]; do
-    if [ "${line#\#!}" != "$line" ]; then
-        shebang_line="${line#\#!}"
-    elif [ "${line#//!}" != "$line" ]; then      # // comments
-        shebang_line="${line#//!}"
-    elif [ "${line#--!}" != "$line" ]; then      # -- lua comments
-        shebang_line="${line#--!}"
-    elif [ "${line#<?php\ }" != "$line" ]; then  # php comments
-        shebang_line="${line#<?php\ \#!}"
-        shebang_line="${shebang_line%\ ?>}"
+while read line && ((lines < 2)) ; do
+    if [[ "$line" = '#!'* ]]; then
+        interpreter="${line#\#!}"
+    elif [[ "$line" = '//!'*node* ]]; then
+        interpreter="${line#//!}"
+    elif [[ "$line" = '--!'*lua* ]]; then
+        interpreter="${line#--!}"
     fi
     lines=$((lines+1))
 done < "$script"
+# this is ineeded for scripts with sbang parameter
+# like ones in intltool
+# #!/<spack-long-path>/perl -w
+# this is the interpreter line with all the parameters as a vector
+interpreter_v=(${interpreter})
+# this is the single interpreter path 
+interpreter_f="${interpreter_v[0]}"
 
-# error if we did not find any interpreter
-if [ -z "$shebang_line"  ]; then
-    die "error: sbang found no interpreter in $script"
-fi
-
-# parse out the interpreter and first argument
-IFS=' ' read -r interpreter arg1 rest <<EOF
-$shebang_line
-EOF
-
-# Determine if the interpreter is a particular program, accounting for the
-# '#!/usr/bin/env PROGRAM' convention. So:
-#
-#     interpreter_is perl
-#
-# will be true for '#!/usr/bin/perl' and '#!/usr/bin/env perl'
-interpreter_is() {
-    if [ "${interpreter##*/}" = "$1" ]; then
-        return 0
-    elif [ "$interpreter" = "/usr/bin/env" ] && [ "$arg1" = "$1" ]; then
-        return 0
+# Invoke any interpreter found, or raise an error if none was found.
+if [[ -n "$interpreter_f" ]]; then
+    if [[ "${interpreter_f##*/}" = "perl"* ]]; then
+        exec $interpreter -x "$@"
     else
-        return 1
+        exec $interpreter "$@"
     fi
-}
-
-if interpreter_is "sbang"; then
-    die "error: refusing to re-execute sbang to avoid infinite loop."
-fi
-
-# Finally invoke the real shebang line
-# ruby and perl need -x to ignore the first line of input (the sbang line)
-#
-if interpreter_is perl || interpreter_is ruby; then
-    # shellcheck disable=SC2086
-    $exec $shebang_line -x "$@"
 else
-    # shellcheck disable=SC2086
-    $exec $shebang_line "$@"
+    echo "error: sbang found no interpreter in $script"
+    exit 1
 fi

bin/spack

@@ -1,7 +1,7 @@
 #!/bin/sh
 # -*- python -*-
 #
-# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+# Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
 # Spack Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
@@ -10,13 +10,9 @@
 # Following line is a shell no-op, and starts a multi-line Python comment.
 # See https://stackoverflow.com/a/47886254
 """:"
-# prefer SPACK_PYTHON environment variable, python3, python, then python2
-SPACK_PREFERRED_PYTHONS="python3 python python2 /usr/libexec/platform-python"
-for cmd in "${SPACK_PYTHON:-}" ${SPACK_PREFERRED_PYTHONS}; do
-    if command -v > /dev/null "$cmd"; then
-        export SPACK_PYTHON="$(command -v "$cmd")"
-        exec "${SPACK_PYTHON}" "$0" "$@"
-    fi
+# prefer python3, then python, then python2
+for cmd in python3 python python2; do
+   command -v > /dev/null $cmd && exec $cmd $0 "$@"
 done
 
 echo "==> Error: spack could not find a python interpreter!" >&2
@@ -25,17 +21,15 @@ exit 1
 # Line above is a shell no-op, and ends a python multi-line comment.
 # The code above runs this file with our preferred python interpreter.
 
+from __future__ import print_function
+
 import os
-import os.path
 import sys
 
-min_python3 = (3, 6)
-
-if sys.version_info[:2] < min_python3:
+if sys.version_info[:2] < (2, 6):
     v_info = sys.version_info[:3]
-    msg = "Spack requires Python %d.%d or higher " % min_python3
-    msg += "You are running spack with Python %d.%d.%d." % v_info
-    sys.exit(msg)
+    sys.exit("Spack requires Python 2.6 or higher."
+             "This is Python %d.%d.%d." % v_info)
 
 # Find spack's location and its prefix.
 spack_file = os.path.realpath(os.path.expanduser(__file__))
@@ -45,8 +39,26 @@ spack_prefix = os.path.dirname(os.path.dirname(spack_file))
 spack_lib_path = os.path.join(spack_prefix, "lib", "spack")
 sys.path.insert(0, spack_lib_path)
 
-from spack_installable.main import main  # noqa: E402
+# Add external libs
+spack_external_libs = os.path.join(spack_lib_path, "external")
+
+if sys.version_info[:2] == (2, 6):
+    sys.path.insert(0, os.path.join(spack_external_libs, 'py26'))
+
+sys.path.insert(0, spack_external_libs)
+
+# Here we delete ruamel.yaml in case it has been already imported from site
+# (see #9206 for a broader description of the issue).
+#
+# Briefly: ruamel.yaml produces a .pth file when installed with pip that
+# makes the site installed package the preferred one, even though sys.path
+# is modified to point to another version of ruamel.yaml.
+if 'ruamel.yaml' in sys.modules:
+    del sys.modules['ruamel.yaml']
+
+if 'ruamel' in sys.modules:
+    del sys.modules['ruamel']
 
 # Once we've set up the system path, run the spack main method
-if __name__ == "__main__":
-    sys.exit(main())
+import spack.main  # noqa
+sys.exit(spack.main.main())

bin/spack-python

@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+# Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
 # Spack Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
@@ -22,4 +22,4 @@
 #
 # This is compatible across platforms.
 #
-exec /usr/bin/env spack python "$@"
+/usr/bin/env spack python "$@"

bin/spack-tmpconfig

@@ -1,96 +0,0 @@
-#!/bin/bash
-set -euo pipefail
-[[ -n "${TMPCONFIG_DEBUG:=}" ]] && set -x
-DIR="$(cd -P "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-mkdir -p "${XDG_RUNTIME_DIR:=/tmp}/spack-tests"
-export TMPDIR="${XDG_RUNTIME_DIR}"
-export TMP_DIR="$(mktemp -d -t spack-test-XXXXX)"
-clean_up() {
-    [[ -n "$TMPCONFIG_DEBUG" ]] && printf "cleaning up: $TMP_DIR\n"
-    rm -rf "$TMP_DIR"
-}
-trap clean_up EXIT
-trap clean_up ERR
-
-[[ -n "$TMPCONFIG_DEBUG" ]] && printf "Redirecting TMP_DIR and spack directories to $TMP_DIR\n"
-
-export BOOTSTRAP="${SPACK_USER_CACHE_PATH:=$HOME/.spack}/bootstrap"
-export SPACK_USER_CACHE_PATH="$TMP_DIR/user_cache"
-mkdir -p "$SPACK_USER_CACHE_PATH"
-
-private_bootstrap="$SPACK_USER_CACHE_PATH/bootstrap"
-use_spack=''
-use_bwrap=''
-# argument handling
-while (($# >= 1)) ; do
-    case "$1" in
-        -b) # privatize bootstrap too, useful for CI but not always cheap
-            shift
-            export BOOTSTRAP="$private_bootstrap"
-            ;;
-        -B) # use specified bootstrap dir
-            export BOOTSTRAP="$2"
-            shift 2
-            ;;
-        -s) # run spack directly with remaining args
-            shift
-            use_spack=1
-            ;;
-        --contain=bwrap)
-            if bwrap --help 2>&1 > /dev/null ; then
-                use_bwrap=1
-            else
-                echo Bubblewrap containment requested, but no bwrap command found
-                exit 1
-            fi
-            shift
-            ;;
-        --)
-            shift
-            break
-            ;;
-        *)
-            break
-            ;;
-    esac
-done
-typeset -a CMD
-if [[ -n "$use_spack" ]] ; then
-    CMD=("$DIR/spack" "$@")
-else
-    CMD=("$@")
-fi
-
-mkdir -p "$BOOTSTRAP"
-
-export SPACK_SYSTEM_CONFIG_PATH="$TMP_DIR/sys_conf"
-export SPACK_USER_CONFIG_PATH="$TMP_DIR/user_conf"
-mkdir -p "$SPACK_USER_CONFIG_PATH"
-cat >"$SPACK_USER_CONFIG_PATH/config.yaml" <<EOF
-config:
-  install_tree:
-    root: $TMP_DIR/install
-  misc_cache: $$user_cache_path/cache
-  source_cache: $$user_cache_path/source
-  environments_root: $TMP_DIR/envs
-EOF
-cat >"$SPACK_USER_CONFIG_PATH/bootstrap.yaml" <<EOF
-bootstrap:
-  root: $BOOTSTRAP
-EOF
-
-if [[ -n "$use_bwrap" ]] ; then
-    CMD=(
-        bwrap
-        --dev-bind / /
-        --ro-bind "$DIR/.." "$DIR/.." # do not touch spack root
-        --ro-bind $HOME/.spack $HOME/.spack # do not touch user config/cache dir
-        --bind "$TMP_DIR" "$TMP_DIR"
-        --bind "$BOOTSTRAP" "$BOOTSTRAP"
-        --die-with-parent
-        "${CMD[@]}"
-    )
-fi
-
-(( ${TMPCONFIG_DEBUG:=0} > 1)) && echo "Running: ${CMD[@]}"
-"${CMD[@]}"

bin/spack.bat

@@ -1,248 +0,0 @@
-:: Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-:: Spack Project Developers. See the top-level COPYRIGHT file for details.
-::
-:: SPDX-License-Identifier: (Apache-2.0 OR MIT)
-::#######################################################################
-::
-:: This file is part of Spack and sets up the spack environment for batch,
-:: This includes environment modules and lmod support,
-:: and it also puts spack in your path. The script also checks that at least
-:: module support exists, and provides suggestions if it doesn't. Source
-:: it like this:
-::
-::    . /path/to/spack/install/spack_cmd.bat
-::
-@echo off
-
-set spack="%SPACK_ROOT%"\bin\spack
-
-::#######################################################################
-:: This is a wrapper around the spack command that forwards calls to
-:: 'spack load' and 'spack unload' to shell functions.  This in turn
-:: allows them to be used to invoke environment modules functions.
-::
-:: 'spack load' is smarter than just 'load' because it converts its
-:: arguments into a unique Spack spec that is then passed to module
-:: commands.  This allows the user to use packages without knowing all
-:: their installation details.
-::
-:: e.g., rather than requiring a full spec for libelf, the user can type:
-::
-::     spack load libelf
-::
-:: This will first find the available libelf module file and use a
-:: matching one.  If there are two versions of libelf, the user would
-:: need to be more specific, e.g.:
-::
-::     spack load libelf@0.8.13
-::
-:: This is very similar to how regular spack commands work and it
-:: avoids the need to come up with a user-friendly naming scheme for
-:: spack module files.
-::#######################################################################
-
-:_sp_shell_wrapper
-set "_sp_flags="
-set "_sp_args="
-set "_sp_subcommand="
-setlocal enabledelayedexpansion
-:: commands have the form '[flags] [subcommand] [args]'
-:: flags will always start with '-', e.g. --help or -V
-:: subcommands will never start with '-'
-:: everything after the subcommand is an arg
-
-
-:process_cl_args
-rem Set first cl argument (denoted by %1) to be processed
-set t=%1
-rem shift moves all cl positional arguments left by one
-rem meaning %2 is now %1, this allows us to iterate over each
-rem argument
-shift
-rem assign next "first" cl argument to cl_args, will be null when
-rem there are now further arguments to process
-set cl_args=%1
-if "!t:~0,1!" == "-" (
-    if defined _sp_subcommand (
-        rem  We already have a subcommand, processing args now
-        if not defined _sp_args (
-            set "_sp_args=!t!"
-        ) else (
-            set "_sp_args=!_sp_args! !t!"
-        )
-    ) else (
-        if not defined _sp_flags (
-            set "_sp_flags=!t!"
-        ) else (
-            set "_sp_flags=!_sp_flags! !t!"
-        )
-    )
-) else if not defined _sp_subcommand (
-    set "_sp_subcommand=!t!"
-) else (
-    if not defined _sp_args (
-        set "_sp_args=!t!"
-    ) else (
-        set "_sp_args=!_sp_args! !t!"
-    )
-)
-
-rem  if this is not nu;ll, we have more tokens to process
-rem  start above process again with remaining unprocessed cl args
-if defined cl_args goto :process_cl_args
-
-
-:: --help, -h and -V flags don't require further output parsing.
-:: If we encounter, execute and exit
-if defined _sp_flags (
-    if NOT "%_sp_flags%"=="%_sp_flags:-h=%" (
-        python "%spack%" %_sp_flags%
-        exit /B 0
-    ) else if NOT "%_sp_flags%"=="%_sp_flags:--help=%" (
-        python "%spack%" %_sp_flags%
-        exit /B 0
-    ) else if NOT "%_sp_flags%"=="%_sp_flags:-V=%" (
-        python "%spack%" %_sp_flags%
-        exit /B 0
-    )
-)
-if not defined _sp_subcommand (
-   if not defined _sp_args (
-      if not defined _sp_flags (
-         python "%spack%" --help
-         exit /B 0
-      )
-   )
-)
-
-
-:: pass parsed variables outside of local scope. Need to do
-:: this because delayedexpansion can only be set by setlocal
-endlocal & (
-    set "_sp_flags=%_sp_flags%"
-    set "_sp_args=%_sp_args%"
-    set "_sp_subcommand=%_sp_subcommand%"
-)
-
-
-:: Filter out some commands. For any others, just run the command.
-if "%_sp_subcommand%" == "cd" (
-    goto :case_cd
-) else if "%_sp_subcommand%" == "env" (
-    goto :case_env
-) else if "%_sp_subcommand%" == "load" (
-    goto :case_load
-) else if "%_sp_subcommand%" == "unload" (
-    goto :case_load
-) else (
-    goto :default_case
-)
-
-::#######################################################################
-
-:case_cd
-:: Check for --help or -h
-:: TODO: This is not exactly the same as setup-env.
-:: In setup-env, '--help' or '-h' must follow the cd
-:: Here, they may be anywhere in the args
-if defined _sp_args (
-    if NOT "%_sp_args%"=="%_sp_args:--help=%" (
-        python "%spack%" cd -h
-        goto :end_switch
-    ) else if NOT "%_sp_args%"=="%_sp_args:-h=%" (
-        python "%spack%" cd -h
-        goto :end_switch
-    )
-)
-
-for /F "tokens=* USEBACKQ" %%F in (
-  `python "%spack%" location %_sp_args%`) do (
-    set "LOC=%%F"
-)
-for %%Z in ("%LOC%") do if EXIST %%~sZ\NUL (cd /d "%LOC%")
-goto :end_switch
-
-:case_env
-:: If no args or args contain --bat or -h/--help: just execute.
-if NOT defined _sp_args (
-    goto :default_case
-)
-
-if NOT "%_sp_args%"=="%_sp_args:--help=%" (
-    goto :default_case
-) else if NOT "%_sp_args%"=="%_sp_args: -h=%" (
-    goto :default_case
-) else if NOT "%_sp_args%"=="%_sp_args:--bat=%" (
-    goto :default_case
-) else if NOT "%_sp_args%"=="%_sp_args:deactivate=%" (
-    for /f "tokens=* USEBACKQ" %%I in (
-        `call python %spack% %_sp_flags% env deactivate --bat %_sp_args:deactivate=%`
-    ) do %%I
-) else if NOT "%_sp_args%"=="%_sp_args:activate=%" (
-    for /f "tokens=* USEBACKQ" %%I in (
-        `python %spack% %_sp_flags% env activate --bat %_sp_args:activate=%`
-    ) do %%I
-) else (
-    goto :default_case
-)
-goto :end_switch
-
-:case_load
-:: If args contain --sh, --csh, or -h/--help: just execute.
-if defined _sp_args (
-    if NOT "%_sp_args%"=="%_sp_args:--help=%" (
-        goto :default_case
-    ) else if NOT "%_sp_args%"=="%_sp_args:-h=%" (
-        goto :default_case
-    ) else if NOT "%_sp_args%"=="%_sp_args:--bat=%" (
-        goto :default_case
-    )
-)
-
-for /f "tokens=* USEBACKQ" %%I in (
-    `python "%spack%" %_sp_flags% %_sp_subcommand% --bat %_sp_args%`) do %%I
-
-goto :end_switch
-
-:case_unload
-goto :case_load
-
-:default_case
-python "%spack%" %_sp_flags% %_sp_subcommand% %_sp_args%
-goto :end_switch
-
-:end_switch
-exit /B %ERRORLEVEL%
-
-
-::########################################################################
-:: Prepends directories to path, if they exist.
-::      pathadd /path/to/dir            # add to PATH
-:: or   pathadd OTHERPATH /path/to/dir  # add to OTHERPATH
-::########################################################################
-
-:_spack_pathadd
-set "_pa_varname=PATH"
-set "_pa_new_path=%~1"
-if NOT "%~2" == "" (
-    set "_pa_varname=%~1"
-    set "_pa_new_path=%~2"
-    )
-set "_pa_oldvalue=%_pa_varname%"
-for %%Z in ("%_pa_new_path%") do if EXIST %%~sZ\NUL (
-    if defined %_pa_oldvalue% (
-        set "_pa_varname=%_pa_new_path%:%_pa_oldvalue%"
-    ) else (
-        set "_pa_varname=%_pa_new_path%"
-    )
-)
-exit /b 0
-
-:: set module system roots
-:_sp_multi_pathadd
-for %%I in (%~2) do (
-    for %%Z in (%_sp_compatible_sys_types%) do (
-        :pathadd "%~1" "%%I\%%Z"
-    )
-)
-exit /B %ERRORLEVEL%

bin/spack.ps1

@@ -1,146 +0,0 @@
-#  Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-#  Spack Project Developers. See the top-level COPYRIGHT file for details.
-
-#  SPDX-License-Identifier: (Apache-2.0 OR MIT)
-# #######################################################################
-
-function Compare-CommonArgs {
-    $CMDArgs = $args[0]
-    # These aruments take precedence and call for no futher parsing of arguments
-    # invoke actual Spack entrypoint with that context and exit after
-    "--help", "-h", "--version", "-V" | ForEach-Object {
-        $arg_opt = $_
-        if(($CMDArgs) -and ([bool]($CMDArgs.Where({$_ -eq $arg_opt})))) {
-            return $true
-        }
-    }
-    return $false
-}
-
-function Read-SpackArgs {
-    $SpackCMD_params = @()
-    $SpackSubCommand = $NULL
-    $SpackSubCommandArgs = @()
-    $args_ = $args[0]
-    $args_ | ForEach-Object {
-        if (!$SpackSubCommand) {
-            if($_.SubString(0,1) -eq "-")
-            {
-                $SpackCMD_params += $_
-            }
-            else{
-                $SpackSubCommand = $_
-            }
-        }
-        else{
-            $SpackSubCommandArgs += $_
-        }
-    }
-    return $SpackCMD_params, $SpackSubCommand, $SpackSubCommandArgs
-}
-
-function Set-SpackEnv {
-    # This method is responsible
-    # for processing the return from $(spack <command>)
-    # which are returned as System.Object[]'s containing
-    # a list of env commands
-    # Invoke-Expression can only handle one command at a time
-    # so we iterate over the list to invoke the env modification
-    # expressions one at a time
-    foreach($envop in $args[0]){
-        Invoke-Expression $envop
-    }
-}
-
-
-function Invoke-SpackCD {
-    if (Compare-CommonArgs $SpackSubCommandArgs) {
-        python "$Env:SPACK_ROOT/bin/spack" cd -h
-    }
-    else {
-        $LOC = $(python "$Env:SPACK_ROOT/bin/spack" location $SpackSubCommandArgs)
-        if (($NULL -ne $LOC)){
-            if ( Test-Path -Path $LOC){
-                Set-Location $LOC
-            }
-            else{
-                exit 1
-            }
-        }
-        else {
-            exit 1
-        }
-    }
-}
-
-function Invoke-SpackEnv {
-    if (Compare-CommonArgs $SpackSubCommandArgs[0]) {
-        python "$Env:SPACK_ROOT/bin/spack" env -h
-    }
-    else {
-        $SubCommandSubCommand = $SpackSubCommandArgs[0]
-        $SubCommandSubCommandArgs = $SpackSubCommandArgs[1..$SpackSubCommandArgs.Count]
-        switch ($SubCommandSubCommand) {
-            "activate" {
-                if (Compare-CommonArgs $SubCommandSubCommandArgs) {
-                    python "$Env:SPACK_ROOT/bin/spack" env activate $SubCommandSubCommandArgs
-                }
-                elseif ([bool]($SubCommandSubCommandArgs.Where({$_ -eq "--pwsh"}))) {
-                    python "$Env:SPACK_ROOT/bin/spack" env activate $SubCommandSubCommandArgs
-                }
-                elseif (!$SubCommandSubCommandArgs) {
-                    python "$Env:SPACK_ROOT/bin/spack" env activate $SubCommandSubCommandArgs
-                }
-                else {
-                    $SpackEnv = $(python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params env activate "--pwsh" $SubCommandSubCommandArgs)
-                    Set-SpackEnv $SpackEnv
-                }
-            }
-            "deactivate" {
-                if ([bool]($SubCommandSubCommandArgs.Where({$_ -eq "--pwsh"}))) {
-                    python"$Env:SPACK_ROOT/bin/spack" env deactivate $SubCommandSubCommandArgs
-                }
-                elseif($SubCommandSubCommandArgs) {
-                    python "$Env:SPACK_ROOT/bin/spack" env deactivate -h
-                }
-                else {
-                    $SpackEnv = $(python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params env deactivate "--pwsh")
-                    Set-SpackEnv $SpackEnv
-                }
-            }
-            default {python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand $SpackSubCommandArgs}
-        }
-    }
-}
-
-function Invoke-SpackLoad {
-    if (Compare-CommonArgs $SpackSubCommandArgs) {
-        python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand $SpackSubCommandArgs
-    }
-    elseif ([bool]($SpackSubCommandArgs.Where({($_ -eq "--pwsh") -or ($_ -eq "--list")}))) {
-        python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand $SpackSubCommandArgs
-    }
-    else {
-        $SpackEnv = $(python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand "--pwsh" $SpackSubCommandArgs)
-        Set-SpackEnv $SpackEnv
-    }
-}
-
-
-$SpackCMD_params, $SpackSubCommand, $SpackSubCommandArgs = Read-SpackArgs $args
-
-if (Compare-CommonArgs $SpackCMD_params) {
-    python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand $SpackSubCommandArgs
-    exit $LASTEXITCODE
-}
-
-# Process Spack commands with special conditions
-# all other commands are piped directly to Spack
-switch($SpackSubCommand)
-{
-    "cd"     {Invoke-SpackCD}
-    "env"    {Invoke-SpackEnv}
-    "load"   {Invoke-SpackLoad}
-    "unload" {Invoke-SpackLoad}
-    default  {python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand $SpackSubCommandArgs}
-}

bin/spack_cmd.bat

@@ -1,71 +0,0 @@
-@ECHO OFF
-setlocal EnableDelayedExpansion
-:: (c) 2021 Lawrence Livermore National Laboratory
-:: To use this file independently of Spack's installer, execute this script in its directory, or add the
-:: associated bin directory to your PATH. Invoke to launch Spack Shell.
-::
-:: source_dir/spack/bin/spack_cmd.bat
-::
-pushd %~dp0..
-set SPACK_ROOT=%CD%
-pushd %CD%\..
-set spackinstdir=%CD%
-popd
-
-
-:: Check if Python is on the PATH
-if not defined python_pf_ver (
-(for /f "delims=" %%F in ('where python.exe') do (
-                                                    set "python_pf_ver=%%F"
-                                                    goto :found_python
-                                                  ) ) 2> NUL
-)
-:found_python
-if not defined python_pf_ver (
-    :: If not, look for Python from the Spack installer
-    :get_builtin
-    (for /f "tokens=*" %%g in ('dir /b /a:d "!spackinstdir!\Python*"') do (
-        set "python_ver=%%g")) 2> NUL
-
-    if not defined python_ver (
-        echo Python was not found on your system.
-        echo Please install Python or add Python to your PATH.
-    ) else (
-        set "py_path=!spackinstdir!\!python_ver!"
-        set "py_exe=!py_path!\python.exe"
-    )
-    goto :exitpoint
-) else (
-    :: Python is already on the path
-    set "py_exe=!python_pf_ver!"
-    (for /F "tokens=* USEBACKQ" %%F in (
-        `"!py_exe!" --version`) do (set "output=%%F")) 2>NUL
-    if not "!output:Microsoft Store=!"=="!output!" goto :get_builtin
-    goto :exitpoint
-)
-:exitpoint
-
-set "PATH=%SPACK_ROOT%\bin\;%PATH%"
-if defined py_path (
-    set "PATH=%py_path%;%PATH%"
-)
-
-if defined py_exe (
-    "%py_exe%" "%SPACK_ROOT%\bin\haspywin.py"
-)
-
-set "EDITOR=notepad"
-
-DOSKEY spacktivate=spack env activate $*
-
-@echo **********************************************************************
-@echo ** Spack Package Manager
-@echo **********************************************************************
-
-IF "%1"=="" GOTO CONTINUE
-set
-GOTO:EOF
-
-:continue
-set PROMPT=[spack] %PROMPT%
-%comspec% /k

bin/spack_pwsh.ps1

@@ -1,10 +0,0 @@
-# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-# Spack Project Developers. See the top-level COPYRIGHT file for details.
-#
-# SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-$Env:SPACK_PS1_PATH="$PSScriptRoot\..\share\spack\setup-env.ps1"
-& (Get-Process -Id $pid).Path -NoExit {
-     . $Env:SPACK_PS1_PATH ; 
-    Push-Location $ENV:SPACK_ROOT
- }

etc/spack/defaults/bootstrap.yaml

@@ -1,23 +0,0 @@
-bootstrap:
-  # If set to false Spack will not bootstrap missing software,
-  # but will instead raise an error.
-  enable: true
-  # Root directory for bootstrapping work. The software bootstrapped
-  # by Spack is installed in a "store" subfolder of this root directory
-  root: $user_cache_path/bootstrap
-  # Methods that can be used to bootstrap software. Each method may or
-  # may not be able to bootstrap all the software that Spack needs,
-  # depending on its type.
-  sources:
-  - name: 'github-actions-v0.4'
-    metadata: $spack/share/spack/bootstrap/github-actions-v0.4
-  - name: 'github-actions-v0.3'
-    metadata: $spack/share/spack/bootstrap/github-actions-v0.3
-  - name: 'spack-install'
-    metadata: $spack/share/spack/bootstrap/spack-install
-  trusted:
-    # By default we trust bootstrapping from sources and from binaries
-    # produced on Github via the workflow
-    github-actions-v0.4: true
-    github-actions-v0.3: true
-    spack-install: true

etc/spack/defaults/concretizer.yaml

@@ -1,44 +0,0 @@
-# -------------------------------------------------------------------------
-# 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
-# `$SPACK_ROOT/etc/spack/concretizer.yaml`, `~/.spack/concretizer.yaml`,
-# or by adding a `concretizer:` section to an environment.
-# -------------------------------------------------------------------------
-concretizer:
-  # Whether to consider installed packages or packages from buildcaches when
-  # concretizing specs. If `true`, we'll try to use as many installs/binaries
-  # as possible, rather than building. If `false`, we'll always give you a fresh
-  # concretization. If `dependencies`, we'll only reuse dependencies but
-  # give you a fresh concretization for your root specs.
-  reuse: dependencies
-  # Options that tune which targets are considered for concretization. The
-  # concretization process is very sensitive to the number targets, and the time
-  # needed to reach a solution increases noticeably with the number of targets
-  # considered.
-  targets:
-    # Determine whether we want to target specific or generic
-    # microarchitectures. Valid values are: "microarchitectures" or "generic".
-    # An example of "microarchitectures" would be "skylake" or "bulldozer",
-    # while an example of "generic" would be "aarch64" or "x86_64_v4".
-    granularity: microarchitectures
-    # If "false" allow targets that are incompatible with the current host (for
-    # instance concretize with target "icelake" while running on "haswell").
-    # If "true" only allow targets that are compatible with the host.
-    host_compatible: true
-  # When "true" concretize root specs of environments together, so that each unique
-  # package in an environment corresponds to one concrete spec. This ensures
-  # environments can always be activated. When "false" perform concretization separately
-  # on each root spec, allowing different versions and variants of the same package in
-  # an environment.
-  unify: true
-  # Option to deal with possible duplicate nodes (i.e. different nodes from the same package) in the DAG.
-  duplicates:
-    # "none": allows a single node for any package in the DAG.
-    # "minimal": allows the duplication of 'build-tools' nodes only (e.g. py-setuptools, cmake etc.)
-    # "full" (experimental): allows separation of the entire build-tool stack (e.g. the entire "cmake" subDAG)
-    strategy: none

etc/spack/defaults/config.yaml

@@ -16,25 +16,23 @@
 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
+  install_tree: ~/.spack/opt/spack
 
 
   # Locations where templates should be found
   template_dirs:
     - $spack/share/spack/templates
 
-  # Directory where licenses should be located
-  license_dir: $spack/etc/spack/licenses
+
+  # Default directory layout
+  install_path_scheme: "${ARCHITECTURE}/${COMPILERNAME}-${COMPILERVER}/${PACKAGE}-${VERSION}-${HASH}"
+
+
+  # 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.
   #
@@ -45,8 +43,8 @@ config:
   # (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.
+  # 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
@@ -54,11 +52,6 @@ config:
   # 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.
@@ -68,32 +61,18 @@ config:
   # identifies Spack staging to avoid accidentally wiping out non-Spack work.
   build_stage:
     - $tempdir/$user/spack-stage
-    - $user_cache_path/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: $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
+  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
+  misc_cache: ~/.spack/cache
 
 
   # If this is false, tools like curl that use SSL will not verify
@@ -112,7 +91,7 @@ config:
   # 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
+  install_missing_compilers: False
 
 
   # If set to true, Spack will always check checksums after downloading
@@ -120,11 +99,6 @@ config:
   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
@@ -146,18 +120,12 @@ config:
   # 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`
+  # 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
 
 
@@ -165,27 +133,11 @@ config:
   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
+  db_lock_timeout: 3
 
 
   # How long to wait when attempting to modify a package (e.g. to install it).
@@ -195,37 +147,7 @@ config:
   # 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'
+  # 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'

etc/spack/defaults/cray/modules.yaml

@@ -1,16 +0,0 @@
-# -------------------------------------------------------------------------
-# This is the default configuration for Spack's module file generation.
-#
-# 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/modules.yaml
-#
-# Per-user settings (overrides default and site settings):
-#   ~/.spack/modules.yaml
-# -------------------------------------------------------------------------
-modules: {}

etc/spack/defaults/darwin/modules.yaml

@@ -15,7 +15,9 @@
 # -------------------------------------------------------------------------
 modules:
   prefix_inspections:
-    ./lib:
+    lib:
+      - DYLD_LIBRARY_PATH
       - DYLD_FALLBACK_LIBRARY_PATH
-    ./lib64:
+    lib64:
+      - DYLD_LIBRARY_PATH
       - DYLD_FALLBACK_LIBRARY_PATH

etc/spack/defaults/darwin/packages.yaml

@@ -15,39 +15,13 @@
 # -------------------------------------------------------------------------
 packages:
   all:
-    compiler:
-    - apple-clang
-    - clang
-    - gcc
-    - intel
+    compiler: [clang, gcc, intel]
     providers:
       elf: [libelf]
-      fuse: [macfuse]
-      gl: [apple-gl]
-      glu: [apple-glu]
       unwind: [apple-libunwind]
-      uuid: [apple-libuuid]
-  apple-gl:
-    buildable: false
-    externals:
-    - spec: apple-gl@4.1.0
-      prefix: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
-  apple-glu:
-    buildable: false
-    externals:
-    - spec: apple-glu@1.3.0
-      prefix: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
   apple-libunwind:
-    buildable: false
-    externals:
+    paths:
     # Apple bundles libunwind version 35.3 with macOS 10.9 and later,
     # although the version number used here isn't critical
-    - spec: apple-libunwind@35.3
-      prefix: /usr
-  apple-libuuid:
-    buildable: false
-    externals:
-    # Apple bundles libuuid in libsystem_c version 1353.100.2,
-    # although the version number used here isn't critical
-    - spec: apple-libuuid@1353.100.2
-      prefix: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
+      apple-libunwind@35.3: /usr
+    buildable: False

etc/spack/defaults/linux/modules.yaml

@@ -13,4 +13,9 @@
 # Per-user settings (overrides default and site settings):
 #   ~/.spack/modules.yaml
 # -------------------------------------------------------------------------
-modules: {}
+modules:
+  prefix_inspections:
+    lib:
+      - LD_LIBRARY_PATH
+    lib64:
+      - LD_LIBRARY_PATH

etc/spack/defaults/mirrors.yaml

@@ -1,4 +0,0 @@
-mirrors:
-  spack-public:
-    binary: false
-    url: https://mirror.spack.io

etc/spack/defaults/modules.yaml

@@ -14,42 +14,32 @@
 #   ~/.spack/modules.yaml
 # -------------------------------------------------------------------------
 modules:
-  # This maps paths in the package install prefix to environment variables
-  # they should be added to. For example, <prefix>/bin should be in PATH.
+  enable:
+    - tcl
   prefix_inspections:
-    ./bin:
+    bin:
       - PATH
-    ./man:
+    man:
       - MANPATH
-    ./share/man:
+    share/man:
       - MANPATH
-    ./share/aclocal:
+    share/aclocal:
       - ACLOCAL_PATH
-    ./lib/pkgconfig:
+    lib:
+      - LIBRARY_PATH
+    lib64:
+      - LIBRARY_PATH
+    include:
+      - CPATH
+    lib/pkgconfig:
       - PKG_CONFIG_PATH
-    ./lib64/pkgconfig:
+    lib64/pkgconfig:
       - PKG_CONFIG_PATH
-    ./share/pkgconfig:
+    share/pkgconfig:
       - PKG_CONFIG_PATH
-    ./:
+    '':
       - CMAKE_PREFIX_PATH
 
-  # These are configurations for the module set named "default"
-  default:
-    # Where to install modules
-    roots:
-     tcl:    $spack/share/spack/modules
-     lmod:   $spack/share/spack/lmod
-    # What type of modules to use ("tcl" and/or "lmod")
-    enable: []
-
-    tcl:
-      all:
-        autoload: direct
-
-    # Default configurations if lmod is enabled
-    lmod:
-      all:
-        autoload: direct
-      hierarchy:
-        - mpi
+  lmod:
+    hierarchy:
+      - mpi

etc/spack/defaults/packages.yaml

@@ -15,52 +15,36 @@
 # -------------------------------------------------------------------------
 packages:
   all:
-    compiler: [gcc, intel, pgi, clang, xl, nag, fj, aocc]
+    compiler: [gcc, intel, pgi, clang, xl, nag, fj]
     providers:
-      awk: [gawk]
-      blas: [openblas, amdblis]
       D: [ldc]
-      daal: [intel-oneapi-daal]
+      awk: [gawk]
+      blas: [openblas]
+      daal: [intel-daal]
       elf: [elfutils]
-      fftw-api: [fftw, amdfftw]
-      flame: [libflame, amdlibflame]
-      fuse: [libfuse]
-      gl: [glx, osmesa]
+      fftw-api: [fftw]
+      gl: [mesa+opengl, opengl]
+      glx: [mesa+glx, opengl]
       glu: [mesa-glu, openglu]
-      golang: [go, gcc]
-      go-or-gccgo-bootstrap: [go-bootstrap, gcc]
-      iconv: [libiconv]
-      ipp: [intel-oneapi-ipp]
+      golang: [gcc]
+      ipp: [intel-ipp]
       java: [openjdk, jdk, ibm-java]
       jpeg: [libjpeg-turbo, libjpeg]
-      lapack: [openblas, amdlibflame]
-      libglx: [mesa+glx, mesa18+glx]
-      libllvm: [llvm]
-      libosmesa: [mesa+osmesa, mesa18+osmesa]
-      lua-lang: [lua, lua-luajit-openresty, lua-luajit]
-      luajit: [lua-luajit-openresty, lua-luajit]
+      lapack: [openblas]
       mariadb-client: [mariadb-c-client, mariadb]
-      mkl: [intel-oneapi-mkl]
+      mkl: [intel-mkl]
       mpe: [mpe2]
       mpi: [openmpi, mpich]
       mysql-client: [mysql, mariadb-c-client]
       opencl: [pocl]
-      onedal: [intel-oneapi-dal]
-      pbs: [openpbs, torque]
       pil: [py-pillow]
       pkgconfig: [pkgconf, pkg-config]
-      qmake: [qt-base, qt]
-      rpc: [libtirpc]
-      scalapack: [netlib-scalapack, amdscalapack]
+      scalapack: [netlib-scalapack]
       sycl: [hipsycl]
-      szip: [libaec, libszip]
+      szip: [libszip, libaec]
       tbb: [intel-tbb]
       unwind: [libunwind]
-      uuid: [util-linux-uuid, libuuid]
-      xxd: [xxd-standalone, vim]
-      yacc: [bison, byacc]
-      ziglang: [zig]
-      zlib-api: [zlib-ng+compat, zlib]
+      sycl: [hipsycl]
     permissions:
       read: world
       write: user

etc/spack/defaults/upstreams.yaml

@@ -0,0 +1,7 @@
+upstreams:
+   global:
+     install_tree: $spack/opt/spack
+     modules:
+       tcl:    $spack/share/spack/modules
+       lmod:   $spack/share/spack/lmod
+       dotkit: $spack/share/spack/dotkit

etc/spack/defaults/windows/config.yaml

@@ -1,6 +0,0 @@
-config:
-  locks: false
-  concretizer: clingo
-  build_stage::
-    - '$spack/.staging'
-  stage_name: '{name}-{version}-{hash:7}'

etc/spack/defaults/windows/packages.yaml

@@ -1,22 +0,0 @@
-# -------------------------------------------------------------------------
-# This file controls default concretization preferences for Spack.
-#
-# 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/packages.yaml
-#
-# Per-user settings (overrides default and site settings):
-#   ~/.spack/packages.yaml
-# -------------------------------------------------------------------------
-packages:
-  all:
-    compiler:
-    - msvc
-    providers:
-      mpi: [msmpi]
-      gl: [wgl]

lib/spack/docs/.gitignore

@@ -5,4 +5,3 @@ llnl*.rst
 _build
 .spack-env
 spack.lock
-_spack_root

lib/spack/docs/Makefile

@@ -2,7 +2,7 @@
 #
 
 # You can set these variables from the command line.
-SPHINXOPTS    = -W --keep-going
+SPHINXOPTS    = -W
 SPHINXBUILD   = sphinx-build
 PAPER         =
 BUILDDIR      = _build

lib/spack/docs/_gh_pages_redirect/index.html

@@ -1,10 +1,10 @@
 <html>
   <head>
-    <meta http-equiv="refresh" content="0; url=https://spack.readthedocs.io/" />
+    <meta http-equiv="refresh" content="0; url=http://spack.readthedocs.io/" />
   </head>
   <body>
     <p>
-      This page has moved to <a href="https://spack.readthedocs.io/">https://spack.readthedocs.io/</a>
+      This page has moved to <a href="http://spack.readthedocs.io/">http://spack.readthedocs.io/</a>
     </p>
   </body>
 </html>

lib/spack/docs/_pygments/style.py

@@ -1,16 +0,0 @@
-# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-# Spack Project Developers. See the top-level COPYRIGHT file for details.
-#
-# SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-# The name of the Pygments (syntax highlighting) style to use.
-# We use our own extension of the default style with a few modifications
-from pygments.styles.default import DefaultStyle
-from pygments.token import Generic
-
-
-class SpackStyle(DefaultStyle):
-    styles = DefaultStyle.styles.copy()
-    background_color = "#f4f4f8"
-    styles[Generic.Output] = "#355"
-    styles[Generic.Prompt] = "bold #346ec9"

lib/spack/docs/_spack_root

@@ -0,0 +1 @@
+../../..

lib/spack/docs/binary_caches.rst

@@ -1,4 +1,4 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
@@ -13,47 +13,26 @@ Some sites may encourage users to set up their own test environments
 before carrying out central installations, or some users may prefer to set
 up these environments on their own motivation. To reduce the load of
 recompiling otherwise identical package specs in different installations,
-installed packages can be put into build cache tarballs, pushed to
+installed packages can be put into build cache tarballs, uploaded to
 your Spack mirror and then downloaded and installed by others.
 
-Whenever a mirror provides prebuilt packages, Spack will take these packages
-into account during concretization and installation, making ``spack install``
-significantly faster.
 
+--------------------------
+Creating build cache files
+--------------------------
 
-.. note::
-
-    We use the terms "build cache" and "mirror" often interchangeably. Mirrors
-    are used during installation both for sources and prebuilt packages. Build
-    caches refer to mirrors that provide prebuilt packages.
-
-
-----------------------
-Creating a build cache
-----------------------
+A compressed tarball of an installed package is created. Tarballs are created
+for all of its link and run dependency packages as well. Compressed tarballs are
+signed with gpg and signature and tarball and put in a ``.spack`` file. Optionally,
+the rpaths (and ids and deps on macOS) can be changed to paths relative to
+the Spack install tree before the tarball is created.
 
 Build caches are created via:
 
 .. code-block:: console
 
-    $ spack buildcache push <path/url/mirror name> <spec>
+   $ spack buildcache create spec
 
-This command takes the locally installed spec and its dependencies, and
-creates tarballs of their install prefixes. It also generates metadata files,
-signed with GPG. These tarballs and metadata files are then pushed to the
-provided binary cache, which can be a local directory or a remote URL.
-
-Here is an example where a build cache is created in a local directory named
-"spack-cache", to which we push the "ninja" spec:
-
-.. code-block:: console
-
-    $ spack buildcache push ./spack-cache ninja
-    ==> Pushing binary packages to file:///home/spackuser/spack/spack-cache/build_cache
-
-Note that ``ninja`` must be installed locally for this to work.
-
-Once you have a build cache, you can add it as a mirror, discussed next.
 
 ---------------------------------------
 Finding or installing build cache files
@@ -64,96 +43,19 @@ with:
 
 .. code-block:: console
 
-    $ spack mirror add <name> <url or path>
-
-
-Both web URLs and local paths on the filesystem can be specified. In the previous
-example, you might add the directory "spack-cache" and call it ``mymirror``:
+   $ spack mirror add <name> <url>
 
+Build caches are found via:
 
 .. code-block:: console
 
-    $ spack mirror add mymirror ./spack-cache
+   $ spack buildcache list
 
-
-You can see that the mirror is added with ``spack mirror list`` as follows:
+Build caches are installed via:
 
 .. code-block:: console
 
-
-    $ spack mirror list
-    mymirror           file:///home/spackuser/spack/spack-cache
-    spack-public       https://spack-llnl-mirror.s3-us-west-2.amazonaws.com/
-
-
-At this point, you've create a buildcache, but spack hasn't indexed it, so if
-you run ``spack buildcache list`` you won't see any results. You need to index
-this new build cache as follows:
-
-.. code-block:: console
-
-    $ spack buildcache update-index ./spack-cache
-
-Now you can use list:
-
-.. code-block:: console
-
-    $  spack buildcache list
-    ==> 1 cached build.
-    -- linux-ubuntu20.04-skylake / gcc@9.3.0 ------------------------
-    ninja@1.10.2
-
-With ``mymirror`` configured and an index available, Spack will automatically
-use it during concretization and installation. That means that you can expect
-``spack install ninja`` to fetch prebuilt packages from the mirror. Let's
-verify by re-installing ninja:
-
-.. code-block:: console
-
-    $ spack uninstall ninja
-    $ spack install ninja
-    ==> Installing ninja-1.11.1-yxferyhmrjkosgta5ei6b4lqf6bxbscz
-    ==> Fetching file:///home/spackuser/spack/spack-cache/build_cache/linux-ubuntu20.04-skylake-gcc-9.3.0-ninja-1.10.2-yxferyhmrjkosgta5ei6b4lqf6bxbscz.spec.json.sig
-    gpg: Signature made Do 12 Jan 2023 16:01:04 CET
-    gpg:                using RSA key 61B82B2B2350E171BD17A1744E3A689061D57BF6
-    gpg: Good signature from "example (GPG created for Spack) <example@example.com>" [ultimate]
-    ==> Fetching file:///home/spackuser/spack/spack-cache/build_cache/linux-ubuntu20.04-skylake/gcc-9.3.0/ninja-1.10.2/linux-ubuntu20.04-skylake-gcc-9.3.0-ninja-1.10.2-yxferyhmrjkosgta5ei6b4lqf6bxbscz.spack
-    ==> Extracting ninja-1.10.2-yxferyhmrjkosgta5ei6b4lqf6bxbscz from binary cache
-    ==> ninja: Successfully installed ninja-1.11.1-yxferyhmrjkosgta5ei6b4lqf6bxbscz
-    Search: 0.00s.  Fetch: 0.17s.  Install: 0.12s.  Total: 0.29s
-    [+] /home/harmen/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.3.0/ninja-1.11.1-yxferyhmrjkosgta5ei6b4lqf6bxbscz
-
-
-It worked! You've just completed a full example of creating a build cache with
-a spec of interest, adding it as a mirror, updating its index, listing the contents,
-and finally, installing from it.
-
-By default Spack falls back to building from sources when the mirror is not available
-or when the package is simply not already available. To force Spack to only install
-prebuilt packages, you can use
-
-.. code-block:: console
-
-   $ spack install --use-buildcache only <package>
-
-For example, to combine all of the commands above to add the E4S build cache
-and then install from it exclusively, you would do:
-
-.. code-block:: console
-
-    $ spack mirror add E4S https://cache.e4s.io
-    $ spack buildcache keys --install --trust
-    $ spack install --use-buildcache only <package>
-
-We use ``--install`` and ``--trust`` to say that we are installing keys to our
-keyring, and trusting all downloaded keys.
-
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-List of popular build caches
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* `Extreme-scale Scientific Software Stack (E4S) <https://e4s-project.github.io/>`_: `build cache <https://oaciss.uoregon.edu/e4s/inventory.html>`_
+   $ spack buildcache install
 
 
 ----------
@@ -173,7 +75,7 @@ need to be adjusted for better re-locatability.
 --------------------
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
-``spack buildcache push``
+``spack buildcache create``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Create tarball of installed Spack package and all dependencies.

lib/spack/docs/bootstrapping.rst

@@ -1,178 +0,0 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-   Spack Project Developers. See the top-level COPYRIGHT file for details.
-
-   SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-.. _bootstrapping:
-
-=============
-Bootstrapping
-=============
-
-In the :ref:`Getting started <getting_started>` Section we already mentioned that
-Spack can bootstrap some of its dependencies, including ``clingo``. In fact, there
-is an entire command dedicated to the management of every aspect of bootstrapping:
-
-.. command-output:: spack bootstrap --help
-
-Spack is configured to bootstrap its dependencies lazily by default; i.e. the first time they are needed and
-can't be found. You can readily check if any prerequisite for using Spack is missing by running:
-
-.. code-block:: console
-
-   % spack bootstrap status
-   Spack v0.19.0 - python@3.8
-
-   [FAIL] Core Functionalities
-     [B] MISSING "clingo": required to concretize specs
-
-   [FAIL] Binary packages
-     [B] MISSING "gpg2": required to sign/verify buildcaches
-
-
-   Spack will take care of bootstrapping any missing dependency marked as [B]. Dependencies marked as [-] are instead required to be found on the system.
-
-   % echo $?
-   1
-
-In the case of the output shown above Spack detected that both ``clingo`` and ``gnupg``
-are missing and it's giving detailed information on why they are needed and whether
-they can be bootstrapped. The return code of this command summarizes the results, if any
-dependencies are missing the return code is ``1``, otherwise ``0``. Running a command that
-concretizes a spec, like:
-
-.. code-block:: console
-
-   % spack solve zlib
-   ==> Bootstrapping clingo from pre-built binaries
-   ==> Fetching https://mirror.spack.io/bootstrap/github-actions/v0.1/build_cache/darwin-catalina-x86_64/apple-clang-12.0.0/clingo-bootstrap-spack/darwin-catalina-x86_64-apple-clang-12.0.0-clingo-bootstrap-spack-p5on7i4hejl775ezndzfdkhvwra3hatn.spack
-   ==> Installing "clingo-bootstrap@spack%apple-clang@12.0.0~docs~ipo+python build_type=Release arch=darwin-catalina-x86_64" from a buildcache
-   [ ... ]
-
-automatically triggers the bootstrapping of clingo from pre-built binaries as expected.
-
-Users can also bootstrap all the dependencies needed by Spack in a single command, which
-might be useful to setup containers or other similar environments:
-
-.. code-block:: console
-
-   $ spack bootstrap now
-   ==> Bootstrapping clingo from pre-built binaries
-   ==> Fetching https://mirror.spack.io/bootstrap/github-actions/v0.3/build_cache/linux-centos7-x86_64-gcc-10.2.1-clingo-bootstrap-spack-shqedxgvjnhiwdcdrvjhbd73jaevv7wt.spec.json
-   ==> Fetching https://mirror.spack.io/bootstrap/github-actions/v0.3/build_cache/linux-centos7-x86_64/gcc-10.2.1/clingo-bootstrap-spack/linux-centos7-x86_64-gcc-10.2.1-clingo-bootstrap-spack-shqedxgvjnhiwdcdrvjhbd73jaevv7wt.spack
-   ==> Installing "clingo-bootstrap@spack%gcc@10.2.1~docs~ipo+python+static_libstdcpp build_type=Release arch=linux-centos7-x86_64" from a buildcache
-   ==> Bootstrapping patchelf from pre-built binaries
-   ==> Fetching https://mirror.spack.io/bootstrap/github-actions/v0.3/build_cache/linux-centos7-x86_64-gcc-10.2.1-patchelf-0.15.0-htk62k7efo2z22kh6kmhaselru7bfkuc.spec.json
-   ==> Fetching https://mirror.spack.io/bootstrap/github-actions/v0.3/build_cache/linux-centos7-x86_64/gcc-10.2.1/patchelf-0.15.0/linux-centos7-x86_64-gcc-10.2.1-patchelf-0.15.0-htk62k7efo2z22kh6kmhaselru7bfkuc.spack
-   ==> Installing "patchelf@0.15.0%gcc@10.2.1 ldflags="-static-libstdc++ -static-libgcc"  arch=linux-centos7-x86_64" from a buildcache
-
------------------------
-The Bootstrapping store
------------------------
-
-The software installed for bootstrapping purposes is deployed in a separate store.
-Its location can be checked with the following command:
-
-.. code-block:: console
-
-   % spack bootstrap root
-
-It can also be changed with the same command by just specifying the newly desired path:
-
-.. code-block:: console
-
-   % spack bootstrap root /opt/spack/bootstrap
-
-You can check what is installed in the bootstrapping store at any time using:
-
-.. code-block:: console
-
-   % spack find -b
-   ==> Showing internal bootstrap store at "/Users/spack/.spack/bootstrap/store"
-   ==> 11 installed packages
-   -- darwin-catalina-x86_64 / apple-clang@12.0.0 ------------------
-   clingo-bootstrap@spack  libassuan@2.5.5  libgpg-error@1.42  libksba@1.5.1  pinentry@1.1.1  zlib@1.2.11
-   gnupg@2.3.1             libgcrypt@1.9.3  libiconv@1.16      npth@1.6       python@3.8
-
-In case it is needed you can remove all the software in the current bootstrapping store with:
-
-.. code-block:: console
-
-   % spack clean -b
-   ==> Removing bootstrapped software and configuration in "/Users/spack/.spack/bootstrap"
-
-   % spack find -b
-   ==> Showing internal bootstrap store at "/Users/spack/.spack/bootstrap/store"
-   ==> 0 installed packages
-
---------------------------------------------
-Enabling and disabling bootstrapping methods
---------------------------------------------
-
-Bootstrapping is always performed by trying the methods listed by:
-
-.. command-output:: spack bootstrap list
-
-in the order they appear, from top to bottom. By default Spack is
-configured to try first bootstrapping from pre-built binaries and to
-fall-back to bootstrapping from sources if that failed.
-
-If need be, you can disable bootstrapping altogether by running:
-
-.. code-block:: console
-
-   % spack bootstrap disable
-
-in which case it's your responsibility to ensure Spack runs in an
-environment where all its prerequisites are installed. You can
-also configure Spack to skip certain bootstrapping methods by disabling
-them specifically:
-
-.. code-block:: console
-
-   % spack bootstrap disable github-actions
-   ==> "github-actions" is now disabled and will not be used for bootstrapping
-
-tells Spack to skip trying to bootstrap from binaries. To add the "github-actions" method back you can:
-
-.. code-block:: console
-
-   % spack bootstrap enable github-actions
-
-There is also an option to reset the bootstrapping configuration to Spack's defaults:
-
-.. code-block:: console
-
-   % spack bootstrap reset
-   ==> Bootstrapping configuration is being reset to Spack's defaults. Current configuration will be lost.
-   Do you want to continue? [Y/n]
-   %
-
-----------------------------------------
-Creating a mirror for air-gapped systems
-----------------------------------------
-
-Spack's default configuration for bootstrapping relies on the user having
-access to the internet, either to fetch pre-compiled binaries or source tarballs.
-Sometimes though Spack is deployed on air-gapped systems where such access is denied.
-
-To help with similar situations Spack has a command that recreates, in a local folder
-of choice, a mirror containing the source tarballs and/or binary packages needed for
-bootstrapping.
-
-.. code-block:: console
-
-   % spack bootstrap mirror --binary-packages /opt/bootstrap
-   ==> Adding "clingo-bootstrap@spack+python %apple-clang target=x86_64" and dependencies to the mirror at /opt/bootstrap/local-mirror
-   ==> Adding "gnupg@2.3: %apple-clang target=x86_64" and dependencies to the mirror at /opt/bootstrap/local-mirror
-   ==> Adding "patchelf@0.13.1:0.13.99 %apple-clang target=x86_64" and dependencies to the mirror at /opt/bootstrap/local-mirror
-   ==> Adding binary packages from "https://github.com/alalazo/spack-bootstrap-mirrors/releases/download/v0.1-rc.2/bootstrap-buildcache.tar.gz" to the mirror at /opt/bootstrap/local-mirror
-
-   To register the mirror on the platform where it's supposed to be used run the following command(s):
-     % spack bootstrap add --trust local-sources /opt/bootstrap/metadata/sources
-     % spack bootstrap add --trust local-binaries /opt/bootstrap/metadata/binaries
-
-
-This command needs to be run on a machine with internet access and the resulting folder
-has to be moved over to the air-gapped system. Once the local sources are added using the
-commands suggested at the prompt, they can be used to bootstrap Spack.

lib/spack/docs/build_settings.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _build-settings:
 
-================================
-Package Settings (packages.yaml)
-================================
+===================
+Build Customization
+===================
 
 Spack allows you to customize how your software is built through the
 ``packages.yaml`` file.  Using it, you can make Spack prefer particular
@@ -49,20 +49,18 @@ packages rather than building its own packages. This may be desirable
 if machines ship with system packages, such as a customized MPI
 that should be used instead of Spack building its own MPI.
 
-External packages are configured through the ``packages.yaml`` file.
-Here's an example of an external configuration:
+External packages are configured through the ``packages.yaml`` file found
+in a Spack installation's ``etc/spack/`` or a user's ``~/.spack/``
+directory. Here's an example of an external configuration:
 
 .. code-block:: yaml
 
    packages:
      openmpi:
-       externals:
-       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64"
-         prefix: /opt/openmpi-1.4.3
-       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug"
-         prefix: /opt/openmpi-1.4.3-debug
-       - spec: "openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64"
-         prefix: /opt/openmpi-1.6.5-intel
+       paths:
+         openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64: /opt/openmpi-1.4.3
+         openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug: /opt/openmpi-1.4.3-debug
+         openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64: /opt/openmpi-1.6.5-intel
 
 This example lists three installations of OpenMPI, one built with GCC,
 one built with GCC and debug information, and another built with Intel.
@@ -78,15 +76,13 @@ of the installation prefixes.  The following example says that module
 .. code-block:: yaml
 
    cmake:
-     externals:
-     - spec: cmake@3.7.2
-       modules:
-       - CMake/3.7.2
+     modules:
+       cmake@3.7.2: CMake/3.7.2
 
-Each ``packages.yaml`` begins with a ``packages:`` attribute, followed
-by a list of package names.  To specify externals, add an ``externals:``
-attribute under the package name, which lists externals.
-Each external should specify a ``spec:`` string that should be as
+Each ``packages.yaml`` begins with a ``packages:`` token, followed
+by a list of package names.  To specify externals, add a ``paths`` or ``modules``
+token under the package name, which lists externals in a
+``spec: /path`` or ``spec: module-name`` format.  Each spec should be as
 well-defined as reasonably possible.  If a
 package lacks a spec component, such as missing a compiler or
 package version, then Spack will guess the missing component based
@@ -96,14 +92,11 @@ Each package version and compiler listed in an external should
 have entries in Spack's packages and compiler configuration, even
 though the package and compiler may not ever be built.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Prevent packages from being built from sources
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Adding an external spec in ``packages.yaml`` allows Spack to use an external location,
-but it does not prevent Spack from building packages from sources. In the above example,
-Spack might choose for many valid reasons to start building and linking with the
-latest version of OpenMPI rather than continue using the pre-installed OpenMPI versions.
+The packages configuration can tell Spack to use an external location
+for certain package versions, but it does not restrict Spack to using
+external packages.  In the above example, since newer versions of OpenMPI
+are available, Spack will choose to start building and linking with the
+latest version rather than continue using the pre-installed OpenMPI versions.
 
 To prevent this, the ``packages.yaml`` configuration also allows packages
 to be flagged as non-buildable.  The previous example could be modified to
@@ -113,25 +106,16 @@ be:
 
    packages:
      openmpi:
-       externals:
-       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64"
-         prefix: /opt/openmpi-1.4.3
-       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug"
-         prefix: /opt/openmpi-1.4.3-debug
-       - spec: "openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64"
-         prefix: /opt/openmpi-1.6.5-intel
+       paths:
+         openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64: /opt/openmpi-1.4.3
+         openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug: /opt/openmpi-1.4.3-debug
+         openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64: /opt/openmpi-1.6.5-intel
        buildable: False
 
 The addition of the ``buildable`` flag tells Spack that it should never build
-its own version of OpenMPI from sources, and it will instead always rely on a pre-built
-OpenMPI.
-
-.. note::
-
-   If ``concretizer:reuse`` is on (see :ref:`concretizer-options` for more information on that flag)
-   pre-built specs include specs already available from a local store, an upstream store, a registered
-   buildcache or specs marked as externals in ``packages.yaml``. If ``concretizer:reuse`` is off, only
-   external specs in ``packages.yaml`` are included in the list of pre-built specs.
+its own version of OpenMPI, and it will instead always rely on a pre-built
+OpenMPI.  Similar to ``paths``, ``buildable`` is specified as a property under
+a package name.
 
 If an external module is specified as not buildable, then Spack will load the
 external module into the build environment which can be used for linking.
@@ -140,369 +124,18 @@ The ``buildable`` does not need to be paired with external packages.
 It could also be used alone to forbid packages that may be
 buggy or otherwise undesirable.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Non-buildable virtual packages
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Virtual packages in Spack can also be specified as not buildable, and
-external implementations can be provided. In the example above,
-OpenMPI is configured as not buildable, but Spack will often prefer
-other MPI implementations over the externally available OpenMPI. Spack
-can be configured with every MPI provider not buildable individually,
-but more conveniently:
+.. _concretization-preferences:
 
-.. code-block:: yaml
+--------------------------
+Concretization Preferences
+--------------------------
 
-   packages:
-     mpi:
-       buildable: False
-     openmpi:
-       externals:
-       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64"
-         prefix: /opt/openmpi-1.4.3
-       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug"
-         prefix: /opt/openmpi-1.4.3-debug
-       - spec: "openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64"
-         prefix: /opt/openmpi-1.6.5-intel
-
-Spack can then use any of the listed external implementations of MPI
-to satisfy a dependency, and will choose depending on the compiler and
-architecture.
-
-In cases where the concretizer is configured to reuse specs, and other ``mpi`` providers
-(available via stores or buildcaches) are not wanted, Spack can be configured to require
-specs matching only the available externals:
-
-.. code-block:: yaml
-
-   packages:
-     mpi:
-       buildable: False
-       require:
-       - one_of: [
-           "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64",
-           "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug",
-           "openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64"
-         ]
-     openmpi:
-       externals:
-       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64"
-         prefix: /opt/openmpi-1.4.3
-       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug"
-         prefix: /opt/openmpi-1.4.3-debug
-       - spec: "openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64"
-         prefix: /opt/openmpi-1.6.5-intel
-
-This configuration prevents any spec using MPI and originating from stores or buildcaches to be reused,
-unless it matches the requirements under ``packages:mpi:require``. For more information on requirements see
-:ref:`package-requirements`.
-
-.. _cmd-spack-external-find:
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Automatically Find External Packages
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You can run the :ref:`spack external find <spack-external-find>` command
-to search for system-provided packages and add them to ``packages.yaml``.
-After running this command your ``packages.yaml`` may include new entries:
-
-.. code-block:: yaml
-
-   packages:
-     cmake:
-       externals:
-       - spec: cmake@3.17.2
-         prefix: /usr
-
-Generally this is useful for detecting a small set of commonly-used packages;
-for now this is generally limited to finding build-only dependencies.
-Specific limitations include:
-
-* Packages are not discoverable by default: For a package to be
-  discoverable with ``spack external find``, it needs to add special
-  logic. See :ref:`here <make-package-findable>` for more details.
-* The logic does not search through module files, it can only detect
-  packages with executables defined in ``PATH``; you can help Spack locate
-  externals which use module files by loading any associated modules for
-  packages that you want Spack to know about before running
-  ``spack external find``.
-* Spack does not overwrite existing entries in the package configuration:
-  If there is an external defined for a spec at any configuration scope,
-  then Spack will not add a new external entry (``spack config blame packages``
-  can help locate all external entries).
-
-.. _concretizer-options:
-
-----------------------
-Concretizer options
-----------------------
-
-``packages.yaml`` gives the concretizer preferences for specific packages,
-but you can also use ``concretizer.yaml`` to customize aspects of the
-algorithm it uses to select the dependencies you install:
-
-.. literalinclude:: _spack_root/etc/spack/defaults/concretizer.yaml
-   :language: yaml
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Reuse already installed packages
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The ``reuse`` attribute controls whether Spack will prefer to use installed packages (``true``), or
-whether it will do a "fresh" installation and prefer the latest settings from
-``package.py`` files and ``packages.yaml`` (``false``).
-You can use:
-
-.. code-block:: console
-
-   % spack install --reuse <spec>
-
-to enable reuse for a single installation, and you can use:
-
-.. code-block:: console
-
-   spack install --fresh <spec>
-
-to do a fresh install if ``reuse`` is enabled by default.
-``reuse: true`` is the default.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Selection of the target microarchitectures
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The options under the ``targets`` attribute control which targets are considered during a solve.
-Currently the options in this section are only configurable from the ``concretizer.yaml`` file
-and there are no corresponding command line arguments to enable them for a single solve.
-
-The ``granularity`` option can take two possible values: ``microarchitectures`` and ``generic``.
-If set to:
-
-.. code-block:: yaml
-
-   concretizer:
-     targets:
-       granularity: microarchitectures
-
-Spack will consider all the microarchitectures known to ``archspec`` to label nodes for
-compatibility. If instead the option is set to:
-
-.. code-block:: yaml
-
-   concretizer:
-     targets:
-       granularity: generic
-
-Spack will consider only generic microarchitectures. For instance, when running on an
-Haswell node, Spack will consider ``haswell`` as the best target in the former case and
-``x86_64_v3`` as the best target in the latter case.
-
-The ``host_compatible`` option is a Boolean option that determines whether or not the
-microarchitectures considered during the solve are constrained to be compatible with the
-host Spack is currently running on. For instance, if this option is set to ``true``, a
-user cannot concretize for ``target=icelake`` while running on an Haswell node.
-
-.. _package-requirements:
-
---------------------
-Package Requirements
---------------------
-
-Spack can be configured to always use certain compilers, package
-versions, and variants during concretization through package
-requirements.
-
-Package requirements are useful when you find yourself repeatedly
-specifying the same constraints on the command line, and wish that
-Spack respects these constraints whether you mention them explicitly
-or not. Another use case is specifying constraints that should apply
-to all root specs in an environment, without having to repeat the
-constraint everywhere.
-
-Apart from that, requirements config is more flexible than constraints
-on the command line, because it can specify constraints on packages
-*when they occur* as a dependency. In contrast, on the command line it
-is not possible to specify constraints on dependencies while also keeping
-those dependencies optional.
-
-^^^^^^^^^^^^^^^^^^^
-Requirements syntax
-^^^^^^^^^^^^^^^^^^^
-
-The package requirements configuration is specified in ``packages.yaml``,
-keyed by package name and expressed using the Spec syntax. In the simplest
-case you can specify attributes that you always want the package to have
-by providing a single spec string to ``require``:
-
-.. code-block:: yaml
-
-   packages:
-     libfabric:
-       require: "@1.13.2"
-
-In the above example, ``libfabric`` will always build with version 1.13.2. If you
-need to compose multiple configuration scopes ``require`` accepts a list of
-strings:
-
-.. code-block:: yaml
-
-   packages:
-     libfabric:
-       require:
-       - "@1.13.2"
-       - "%gcc"
-
-In this case ``libfabric`` will always build with version 1.13.2 **and** using GCC
-as a compiler.
-
-For more complex use cases, require accepts also a list of objects. These objects
-must have either a ``any_of`` or a ``one_of`` field, containing a list of spec strings,
-and they can optionally have a ``when`` and a ``message`` attribute:
-
-.. code-block:: yaml
-
-   packages:
-     openmpi:
-       require:
-       - any_of: ["@4.1.5", "%gcc"]
-         message: "in this example only 4.1.5 can build with other compilers"
-
-``any_of`` is a list of specs. One of those specs must be satisfied
-and it is also allowed for the concretized spec to match more than one.
-In the above example, that means you could build ``openmpi@4.1.5%gcc``,
-``openmpi@4.1.5%clang`` or ``openmpi@3.9%gcc``, but
-not ``openmpi@3.9%clang``.
-
-If a custom message is provided, and the requirement is not satisfiable,
-Spack will print the custom error message:
-
-.. code-block:: console
-
-   $ spack spec openmpi@3.9%clang
-   ==> Error: in this example only 4.1.5 can build with other compilers
-
-We could express a similar requirement using the ``when`` attribute:
-
-.. code-block:: yaml
-
-   packages:
-     openmpi:
-       require:
-       - any_of: ["%gcc"]
-         when: "@:4.1.4"
-         message: "in this example only 4.1.5 can build with other compilers"
-
-In the example above, if the version turns out to be 4.1.4 or less, we require the compiler to be GCC.
-For readability, Spack also allows a ``spec`` key accepting a string when there is only a single
-constraint:
-
-.. code-block:: yaml
-
-   packages:
-     openmpi:
-       require:
-       - spec: "%gcc"
-         when: "@:4.1.4"
-         message: "in this example only 4.1.5 can build with other compilers"
-
-This code snippet and the one before it are semantically equivalent.
-
-Finally, instead of ``any_of`` you can use ``one_of`` which also takes a list of specs. The final
-concretized spec must match one and only one of them:
-
-.. code-block:: yaml
-
-   packages:
-     mpich:
-       require:
-       - one_of: ["+cuda", "+rocm"]
-
-In the example above, that means you could build ``mpich+cuda`` or ``mpich+rocm`` but not ``mpich+cuda+rocm``.
-
-.. note::
-
-   For ``any_of`` and ``one_of``, the order of specs indicates a
-   preference: items that appear earlier in the list are preferred
-   (note that these preferences can be ignored in favor of others).
-
-.. note::
-
-   When using a conditional requirement, Spack is allowed to actively avoid the triggering
-   condition (the ``when=...`` spec) if that leads to a concrete spec with better scores in
-   the optimization criteria. To check the current optimization criteria and their
-   priorities you can run ``spack solve zlib``.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Setting default requirements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You can also set default requirements for all packages under ``all``
-like this:
-
-.. code-block:: yaml
-
-   packages:
-     all:
-       require: '%clang'
-
-which means every spec will be required to use ``clang`` as a compiler.
-
-Note that in this case ``all`` represents a *default set of requirements* -
-if there are specific package requirements, then the default requirements
-under ``all`` are disregarded. For example, with a configuration like this:
-
-.. code-block:: yaml
-
-   packages:
-     all:
-       require: '%clang'
-     cmake:
-       require: '%gcc'
-
-Spack requires ``cmake`` to use ``gcc`` and all other nodes (including ``cmake``
-dependencies) to use ``clang``.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Setting requirements on virtual specs
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-A requirement on a virtual spec applies whenever that virtual is present in the DAG.
-This can be useful for fixing which virtual provider you want to use:
-
-.. code-block:: yaml
-
-   packages:
-     mpi:
-       require: 'mvapich2 %gcc'
-
-With the configuration above the only allowed ``mpi`` provider is ``mvapich2 %gcc``.
-
-Requirements on the virtual spec and on the specific provider are both applied, if
-present. For instance with a configuration like:
-
-.. code-block:: yaml
-
-   packages:
-     mpi:
-       require: 'mvapich2 %gcc'
-     mvapich2:
-       require: '~cuda'
-
-you will use ``mvapich2~cuda %gcc`` as an ``mpi`` provider.
-
-.. _package-preferences:
-
--------------------
-Package Preferences
--------------------
-
-In some cases package requirements can be too strong, and package
-preferences are the better option. Package preferences do not impose
-constraints on packages for particular versions or variants values,
-they rather only set defaults -- the concretizer is free to change
-them if it must due to other constraints. Also note that package
-preferences are of lower priority than reuse of already installed
-packages.
+Spack can be configured to prefer certain compilers, package
+versions, dependencies, and variants during concretization.
+The preferred configuration can be controlled via the
+``~/.spack/packages.yaml`` file for user configurations, or the
+``etc/spack/packages.yaml`` site configuration.
 
 Here's an example ``packages.yaml`` file that sets preferred packages:
 
@@ -520,7 +153,7 @@ Here's an example ``packages.yaml`` file that sets preferred packages:
        providers:
          mpi: [mvapich2, mpich, openmpi]
 
-At a high level, this example is specifying how packages are preferably
+At a high level, this example is specifying how packages should be
 concretized.  The opencv package should prefer using GCC 4.9 and
 be built with debug options.  The gperftools package should prefer version
 2.2 over 2.4.  Every package on the system should prefer mvapich2 for
@@ -528,11 +161,13 @@ its MPI and GCC 4.4.7 (except for opencv, which overrides this by preferring GCC
 These options are used to fill in implicit defaults.  Any of them can be overwritten
 on the command line if explicitly requested.
 
-Package preferences accept the follow keys or components under
-the specific package (or ``all``) section: ``compiler``, ``variants``,
-``version``, ``providers``, and ``target``.  Each component has an
-ordered list of spec ``constraints``, with earlier entries in the
-list being preferred over later entries.
+Each ``packages.yaml`` file begins with the string ``packages:`` and
+package names are specified on the next level. The special string ``all``
+applies settings to *all* packages. Underneath each package name is one
+or more components: ``compiler``, ``variants``, ``version``,
+``providers``, and ``target``.  Each component has an ordered list of
+spec ``constraints``, with earlier entries in the list being preferred
+over later entries.
 
 Sometimes a package installation may have constraints that forbid
 the first concretization rule, in which case Spack will use the first
@@ -547,7 +182,7 @@ gcc to pgi will thus be preferred over the xlc compiler.
 
 The syntax for the ``provider`` section differs slightly from other
 concretization rules.  A provider lists a value that packages may
-``depends_on`` (e.g, MPI) and a list of rules for fulfilling that
+``depend_on`` (e.g, MPI) and a list of rules for fulfilling that
 dependency.
 
 .. _package_permissions:
@@ -598,25 +233,3 @@ directories inside the install prefix. This will ensure that even
 manually placed files within the install prefix are owned by the
 assigned group. If no group is assigned, Spack will allow the OS
 default behavior to go as expected.
-
-----------------------------
-Assigning Package Attributes
-----------------------------
-
-You can assign class-level attributes in the configuration:
-
-.. code-block:: yaml
-
-  packages:
-    mpileaks:
-      # Override existing attributes
-      url: http://www.somewhereelse.com/mpileaks-1.0.tar.gz
-      # ... or add new ones
-      x: 1
-
-Attributes set this way will be accessible to any method executed
-in the package.py file (e.g. the ``install()`` method). Values for these
-attributes may be any value parseable by yaml.
-
-These can only be applied to specific packages, not "all" or
-virtual packages.

lib/spack/docs/build_systems.rst

@@ -1,4 +1,4 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
@@ -29,7 +29,6 @@ on these ideas for each distinct build system that Spack supports:
    :maxdepth: 1
    :caption: Make-incompatible
 
-   build_systems/mavenpackage
    build_systems/sconspackage
    build_systems/wafpackage
 
@@ -39,7 +38,6 @@ on these ideas for each distinct build system that Spack supports:
 
    build_systems/autotoolspackage
    build_systems/cmakepackage
-   build_systems/cachedcmakepackage
    build_systems/mesonpackage
    build_systems/qmakepackage
    build_systems/sippackage
@@ -48,12 +46,10 @@ on these ideas for each distinct build system that Spack supports:
    :maxdepth: 1
    :caption: Language-specific
 
-   build_systems/luapackage
    build_systems/octavepackage
    build_systems/perlpackage
    build_systems/pythonpackage
    build_systems/rpackage
-   build_systems/racketpackage
    build_systems/rubypackage
 
 .. toctree::
@@ -62,11 +58,8 @@ on these ideas for each distinct build system that Spack supports:
 
    build_systems/bundlepackage
    build_systems/cudapackage
-   build_systems/custompackage
-   build_systems/inteloneapipackage
    build_systems/intelpackage
-   build_systems/rocmpackage
-   build_systems/sourceforgepackage
+   build_systems/custompackage
 
 For reference, the :py:mod:`Build System API docs <spack.build_systems>`
 provide a list of build systems and methods/attributes that can be

lib/spack/docs/build_systems/autotoolspackage.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _autotoolspackage:
 
----------
-Autotools
----------
+----------------
+AutotoolsPackage
+----------------
 
 Autotools is a GNU build system that provides a build-script generator.
 By running the platform-independent ``./configure`` script that comes
@@ -17,7 +17,7 @@ with the package, you can generate a platform-dependent Makefile.
 Phases
 ^^^^^^
 
-The ``AutotoolsBuilder`` and ``AutotoolsPackage`` base classes come with the following phases:
+The ``AutotoolsPackage`` base class comes with the following phases:
 
 #. ``autoreconf`` - generate the configure script
 #. ``configure`` - generate the Makefiles
@@ -112,44 +112,20 @@ phase runs:
 
 .. code-block:: console
 
-   $ autoreconf --install --verbose --force -I <aclocal-prefix>/share/aclocal
-
-In case you need to add more arguments, override ``autoreconf_extra_args``
-in your ``package.py`` on class scope like this:
-
-.. code-block:: python
-
-   autoreconf_extra_args = ["-Im4"]
+   $ libtoolize
+   $ aclocal
+   $ autoreconf --install --verbose --force
 
 All you need to do is add a few Autotools dependencies to the package.
 Most stable releases will come with a ``configure`` script, but if you
-check out a commit from the ``master`` branch, you would want to add:
+check out a commit from the ``develop`` branch, you would want to add:
 
 .. code-block:: python
 
-   depends_on('autoconf', type='build', when='@master')
-   depends_on('automake', type='build', when='@master')
-   depends_on('libtool',  type='build', when='@master')
-
-It is typically redundant to list the ``m4`` macro processor package as a
-dependency, since ``autoconf`` already depends on it.
-
-"""""""""""""""""""""""""""""""
-Using a custom autoreconf phase
-"""""""""""""""""""""""""""""""
-
-In some cases, it might be needed to replace the default implementation
-of the autoreconf phase with one running a script interpreter. In this
-example, the ``bash`` shell is used to run the ``autogen.sh`` script.
-
-.. code-block:: python
-
-   def autoreconf(self, spec, prefix):
-       which('bash')('autogen.sh')
-
-"""""""""""""""""""""""""""""""""""""""
-patching configure or Makefile.in files
-"""""""""""""""""""""""""""""""""""""""
+   depends_on('autoconf', type='build', when='@develop')
+   depends_on('automake', type='build', when='@develop')
+   depends_on('libtool',  type='build', when='@develop')
+   depends_on('m4',       type='build', when='@develop')
 
 In some cases, developers might need to distribute a patch that modifies
 one of the files used to generate ``configure`` or ``Makefile.in``.
@@ -159,57 +135,6 @@ create a new patch that directly modifies ``configure``. That way,
 Spack can use the secondary patch and additional build system
 dependencies aren't necessary.
 
-""""""""""""""""""""""""""""
-Old Autotools helper scripts
-""""""""""""""""""""""""""""
-
-Autotools based tarballs come with helper scripts such as ``config.sub`` and
-``config.guess``. It is the responsibility of the developers to keep these files
-up to date so that they run on every platform, but for very old software
-releases this is impossible. In these cases Spack can help to replace these
-files with newer ones, without having to add the heavy dependency on
-``automake``.
-
-Automatic helper script replacement is currently enabled by default on
-``ppc64le`` and ``aarch64``, as these are the known cases where old scripts fail.
-On these targets, ``AutotoolsPackage`` adds a build dependency on ``gnuconfig``,
-which is a very light-weight package with newer versions of the helper files.
-Spack then tries to run all the helper scripts it can find in the release, and
-replaces them on failure with the helper scripts from ``gnuconfig``.
-
-To opt out of this feature, use the following setting:
-
-.. code-block:: python
-
-   patch_config_files = False
-
-To enable it conditionally on different architectures, define a property and
-make the package depend on ``gnuconfig`` as a build dependency:
-
-.. code-block
-
-   depends_on('gnuconfig', when='@1.0:')
-
-   @property
-   def patch_config_files(self):
-      return self.spec.satisfies("@1.0:")
-
-.. note::
-
-    On some exotic architectures it is necessary to use system provided
-    ``config.sub`` and ``config.guess`` files. In this case, the most
-    transparent solution is to mark the ``gnuconfig`` package as external and
-    non-buildable, with a prefix set to the directory containing the files:
-
-   .. code-block:: yaml
-
-       gnuconfig:
-         buildable: false
-         externals:
-         - spec: gnuconfig@master
-           prefix: /usr/share/configure_files/
-
-
 """"""""""""""""
 force_autoreconf
 """"""""""""""""
@@ -230,7 +155,7 @@ version, this can be done like so:
 
    @property
    def force_autoreconf(self):
-       return self.version == Version('1.2.3')
+       return self.version == Version('1.2.3'):
 
 ^^^^^^^^^^^^^^^^^^^^^^^
 Finding configure flags
@@ -308,163 +233,7 @@ You may have noticed that most of the Autotools flags are of the form
 ``--without-baz``. Since these flags are so common, Spack provides a
 couple of helper functions to make your life easier.
 
-"""""""""""""""""
-enable_or_disable
-"""""""""""""""""
-
-Autotools flags for simple boolean variants can be automatically
-generated by calling the ``enable_or_disable`` method. This is
-typically used to enable or disable some feature within the package.
-
-.. code-block:: python
-
-   variant(
-       'memchecker',
-       default=False,
-       description='Memchecker support for debugging [degrades performance]'
-   )
-   config_args.extend(self.enable_or_disable('memchecker'))
-
-In this example, specifying the variant ``+memchecker`` will generate
-the following configuration options:
-
-.. code-block:: console
-
-   --enable-memchecker
-
-"""""""""""""""
-with_or_without
-"""""""""""""""
-
-Autotools flags for more complex variants, including boolean variants
-and multi-valued variants, can be automatically generated by calling
-the ``with_or_without`` method.
-
-.. code-block:: python
-
-   variant(
-       'schedulers',
-       values=disjoint_sets(
-           ('auto',), ('alps', 'lsf', 'tm', 'slurm', 'sge', 'loadleveler')
-       ).with_non_feature_values('auto', 'none'),
-       description="List of schedulers for which support is enabled; "
-       "'auto' lets openmpi determine",
-   )
-   if 'schedulers=auto' not in spec:
-       config_args.extend(self.with_or_without('schedulers'))
-
-In this example, specifying the variant ``schedulers=slurm,sge`` will
-generate the following configuration options:
-
-.. code-block:: console
-
-   --with-slurm --with-sge
-
-``enable_or_disable`` is actually functionally equivalent with
-``with_or_without``, and accepts the same arguments and variant types;
-but idiomatic autotools packages often follow these naming
-conventions.
-
-""""""""""""""""
-activation_value
-""""""""""""""""
-
-Autotools parameters that require an option can still be automatically
-generated, using the ``activation_value`` argument to
-``with_or_without`` (or, rarely, ``enable_or_disable``).
-
-.. code-block:: python
-
-   variant(
-      'fabrics',
-       values=disjoint_sets(
-           ('auto',), ('psm', 'psm2', 'verbs', 'mxm', 'ucx', 'libfabric')
-       ).with_non_feature_values('auto', 'none'),
-       description="List of fabrics that are enabled; "
-       "'auto' lets openmpi determine",
-   )
-   if 'fabrics=auto' not in spec:
-       config_args.extend(self.with_or_without('fabrics',
-           activation_value='prefix'))
-
-``activation_value`` accepts a callable that generates the configure
-parameter value given the variant value; but the special value
-``prefix`` tells Spack to automatically use the dependenency's
-installation prefix, which is the most common use for such
-parameters. In this example, specifying the variant
-``fabrics=libfabric`` will generate the following configuration
-options:
-
-.. code-block:: console
-
-   --with-libfabric=</path/to/libfabric>
-
-"""""""""""""""""""""""
-The ``variant`` keyword
-"""""""""""""""""""""""
-
-When Spack variants and configure flags do not correspond one-to-one, the
-``variant`` keyword can be passed to ``with_or_without`` and
-``enable_or_disable``. For example:
-
-.. code-block:: python
-
-   variant('debug_tools', default=False)
-   config_args += self.enable_or_disable('debug-tools', variant='debug_tools')
-
-Or when one variant controls multiple flags:
-
-.. code-block:: python
-
-   variant('debug_tools', default=False)
-   config_args += self.with_or_without('memchecker', variant='debug_tools')
-   config_args += self.with_or_without('profiler', variant='debug_tools')
-
-
-""""""""""""""""""""
-Conditional variants
-""""""""""""""""""""
-
-When a variant is conditional and its condition is not met on the concrete spec, the
-``with_or_without`` and ``enable_or_disable`` methods will simply return an empty list.
-
-For example:
-
-.. code-block:: python
-
-   variant('profiler', when='@2.0:')
-   config_args += self.with_or_without('profiler')
-
-will neither add ``--with-profiler`` nor ``--without-profiler`` when the version is
-below ``2.0``.
-
-""""""""""""""""""""
-Activation overrides
-""""""""""""""""""""
-
-Finally, the behavior of either ``with_or_without`` or
-``enable_or_disable`` can be overridden for specific variant
-values. This is most useful for multi-values variants where some of
-the variant values require atypical behavior.
-
-.. code-block:: python
-
-   def with_or_without_verbs(self, activated):
-       # Up through version 1.6, this option was named --with-openib.
-       # In version 1.7, it was renamed to be --with-verbs.
-       opt = 'verbs' if self.spec.satisfies('@1.7:') else 'openib'
-       if not activated:
-           return '--without-{0}'.format(opt)
-       return '--with-{0}={1}'.format(opt, self.spec['rdma-core'].prefix)
-
-Defining ``with_or_without_verbs`` overrides the behavior of a
-``fabrics=verbs`` variant, changing the configure-time option to
-``--with-openib`` for older versions of the package and specifying an
-alternative dependency name:
-
-.. code-block::
-
-   --with-openib=</path/to/rdma-core>
+TODO: document ``with_or_without`` and ``enable_or_disable``.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Configure script in a sub-directory

lib/spack/docs/build_systems/bundlepackage.rst

@@ -1,40 +1,17 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _bundlepackage:
 
-------
-Bundle
-------
+-------------
+BundlePackage
+-------------
 
-``BundlePackage`` represents a set of packages that are expected to work
-well together, such as a collection of commonly used software libraries.
-The associated software is specified as dependencies.
-
-If it makes sense, variants, conflicts, and requirements can be added to
-the package. :ref:`Variants <variants>` ensure that common build options
-are consistent across the packages supporting them.  :ref:`Conflicts
-and requirements <packaging_conflicts>` prevent attempts to build with known
-bugs or limitations.
-
-For example, if ``MyBundlePackage`` is known to only build on ``linux``,
-it could use the ``require`` directive as follows:
-
-.. code-block:: python
-
-    require("platform=linux", msg="MyBundlePackage only builds on linux")
-
-Spack has a number of built-in bundle packages, such as:
-
-* `AmdAocl <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/amd-aocl/package.py>`_
-* `EcpProxyApps <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/ecp-proxy-apps/package.py>`_
-* `Libc <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/libc/package.py>`_
-* `Xsdk <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/xsdk/package.py>`_
-
-where ``Xsdk`` also inherits from ``CudaPackage`` and ``RocmPackage`` and
-``Libc`` is a virtual bundle package for the C standard library.
+``BundlePackage`` represents a set of packages that are expected to work well
+together, such as a collection of commonly used software libraries.  The
+associated software is specified as bundle dependencies.
 
 
 ^^^^^^^^

lib/spack/docs/build_systems/cachedcmakepackage.rst

@@ -1,123 +0,0 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-   Spack Project Developers. See the top-level COPYRIGHT file for details.
-
-   SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-.. _cachedcmakepackage:
-
------------
-CachedCMake
------------
-
-The CachedCMakePackage base class is used for CMake-based workflows
-that create a CMake cache file prior to running ``cmake``. This is
-useful for packages with arguments longer than the system limit, and
-for reproducibility.
-
-The documentation for this class assumes that the user is familiar with
-the ``CMakePackage`` class from which it inherits. See the documentation
-for :ref:`CMakePackage <cmakepackage>`.
-
-^^^^^^
-Phases
-^^^^^^
-
-The ``CachedCMakePackage`` base class comes with the following phases:
-
-#. ``initconfig`` - generate the CMake cache file
-#. ``cmake`` - generate the Makefile
-#. ``build`` - build the package
-#. ``install`` - install the package
-
-By default, these phases run:
-
-.. code-block:: console
-
-   $ mkdir spack-build
-   $ cd spack-build
-   $ cat << EOF > name-arch-compiler@version.cmake
-   # Write information on compilers and dependencies
-   # includes information on mpi and cuda if applicable
-   $ cmake .. -DCMAKE_INSTALL_PREFIX=/path/to/installation/prefix -C name-arch-compiler@version.cmake
-   $ make
-   $ make test  # optional
-   $ make install
-
-The ``CachedCMakePackage`` class inherits from the ``CMakePackage``
-class, and accepts all of the same options and adds all of the same
-flags to the ``cmake`` command. Similar to the ``CMakePAckage`` class,
-you may need to add a few arguments yourself, and the
-``CachedCMakePackage`` provides the same interface to add those
-flags.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Adding entries to the CMake cache
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In addition to adding flags to the ``cmake`` command, you may need to
-add entries to the CMake cache in the ``initconfig`` phase. This can
-be done by overriding one of four methods:
-
-#. ``CachedCMakePackage.initconfig_compiler_entries``
-#. ``CachedCMakePackage.initconfig_mpi_entries``
-#. ``CachedCMakePackage.initconfig_hardware_entries``
-#. ``CachedCMakePackage.initconfig_package_entries``
-
-Each of these methods returns a list of CMake cache strings. The
-distinction between these methods is merely to provide a
-well-structured and legible cmake cache file -- otherwise, entries
-from each of these methods are handled identically.
-
-Spack also provides convenience methods for generating CMake cache
-entries. These methods are available at module scope in every Spack
-package. Because CMake parses boolean options, strings, and paths
-differently, there are three such methods:
-
-#. ``cmake_cache_option``
-#. ``cmake_cache_string``
-#. ``cmake_cache_path``
-
-These methods each accept three parameters -- the name of the CMake
-variable associated with the entry, the value of the entry, and an
-optional comment -- and return strings in the appropriate format to be
-returned from any of the ``initconfig*`` methods. Additionally, these
-methods may return comments beginning with the ``#`` character.
-
-A typical usage of these methods may look something like this:
-
-.. code-block:: python
-
-   def initconfig_mpi_entries(self)
-       # Get existing MPI configurations
-       entries = super(self, Foo).initconfig_mpi_entries()
-
-       # The existing MPI configurations key on whether ``mpi`` is in the spec
-       # This spec has an MPI variant, and we need to enable MPI when it is on.
-       # This hypothetical package controls MPI with the ``FOO_MPI`` option to
-       # cmake.
-       if '+mpi' in self.spec:
-           entries.append(cmake_cache_option('FOO_MPI', True, "enable mpi"))
-       else:
-           entries.append(cmake_cache_option('FOO_MPI', False, "disable mpi"))
-
-   def initconfig_package_entries(self):
-       # Package specific options
-       entries = []
-
-       entries.append('#Entries for build options')
-
-       bar_on = '+bar' in self.spec
-       entries.append(cmake_cache_option('FOO_BAR', bar_on, 'toggle bar'))
-
-       entries.append('#Entries for dependencies')
-
-       if self.spec['blas'].name == 'baz':  # baz is our blas provider
-       entries.append(cmake_cache_string('FOO_BLAS', 'baz', 'Use baz'))
-       entries.append(cmake_cache_path('BAZ_PREFIX', self.spec['baz'].prefix))
-
-^^^^^^^^^^^^^^^^^^^^^^
-External documentation
-^^^^^^^^^^^^^^^^^^^^^^
-
-For more information on CMake cache files, see:
-https://cmake.org/cmake/help/latest/manual/cmake.1.html

lib/spack/docs/build_systems/cmakepackage.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _cmakepackage:
 
------
-CMake
------
+------------
+CMakePackage
+------------
 
 Like Autotools, CMake is a widely-used build-script generator. Designed
 by Kitware, CMake is the most popular build system for new C, C++, and
@@ -21,7 +21,7 @@ whereas Autotools is Unix-only.
 Phases
 ^^^^^^
 
-The ``CMakeBuilder`` and ``CMakePackage`` base classes come with the following phases:
+The ``CMakePackage`` base class comes with the following phases:
 
 #. ``cmake`` - generate the Makefile
 #. ``build`` - build the package
@@ -128,116 +128,20 @@ Adding flags to cmake
 ^^^^^^^^^^^^^^^^^^^^^
 
 To add additional flags to the ``cmake`` call, simply override the
-``cmake_args`` function. The following example defines values for the flags
-``WHATEVER``, ``ENABLE_BROKEN_FEATURE``, ``DETECT_HDF5``, and ``THREADS`` with
-and without the :meth:`~spack.build_systems.cmake.CMakeBuilder.define` and
-:meth:`~spack.build_systems.cmake.CMakeBuilder.define_from_variant` helper functions:
+``cmake_args`` function:
 
 .. code-block:: python
 
    def cmake_args(self):
-       args = [
-           '-DWHATEVER:STRING=somevalue',
-           self.define('ENABLE_BROKEN_FEATURE', False),
-           self.define_from_variant('DETECT_HDF5', 'hdf5'),
-           self.define_from_variant('THREADS'), # True if +threads
-       ]
+       args = []
+
+       if '+hdf5' in self.spec:
+           args.append('-DDETECT_HDF5=ON')
+       else:
+           args.append('-DDETECT_HDF5=OFF')
 
        return args
 
-Spack supports CMake defines from conditional variants too. Whenever the condition on
-the variant is not met, ``define_from_variant()`` will simply return an empty string,
-and CMake simply ignores the empty command line argument. For example the following
-
-.. code-block:: python
-
-   variant('example', default=True, when='@2.0:')
-
-   def cmake_args(self):
-      return [self.define_from_variant('EXAMPLE', 'example')]
-
-will generate ``'cmake' '-DEXAMPLE=ON' ...`` when `@2.0: +example` is met, but will
-result in ``'cmake' '' ...`` when the spec version is below ``2.0``.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-CMake arguments provided by Spack
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The following default arguments are controlled by Spack:
-
-
-``CMAKE_INSTALL_PREFIX``
-------------------------
-
-Is set to the the package's install directory.
-
-
-``CMAKE_PREFIX_PATH``
----------------------
-
-CMake finds dependencies through calls to ``find_package()``, ``find_program()``,
-``find_library()``, ``find_file()``, and ``find_path()``, which use a list of search
-paths from ``CMAKE_PREFIX_PATH``. Spack sets this variable to a list of prefixes of the
-spec's transitive dependencies.
-
-For troubleshooting cases where CMake fails to find a dependency, add the
-``--debug-find`` flag to ``cmake_args``.
-
-``CMAKE_BUILD_TYPE``
---------------------
-
-Every CMake-based package accepts a ``-DCMAKE_BUILD_TYPE`` flag to
-dictate which level of optimization to use. In order to ensure
-uniformity across packages, the ``CMakePackage`` base class adds
-a variant to control this:
-
-.. code-block:: python
-
-   variant('build_type', default='RelWithDebInfo',
-           description='CMake build type',
-           values=('Debug', 'Release', 'RelWithDebInfo', 'MinSizeRel'))
-
-However, not every CMake package accepts all four of these options.
-Grep the ``CMakeLists.txt`` file to see if the default values are
-missing or replaced. For example, the
-`dealii <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/dealii/package.py>`_
-package overrides the default variant with:
-
-.. code-block:: python
-
-   variant('build_type', default='DebugRelease',
-           description='The build type to build',
-           values=('Debug', 'Release', 'DebugRelease'))
-
-For more information on ``CMAKE_BUILD_TYPE``, see:
-https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html
-
-
-``CMAKE_INSTALL_RPATH`` and ``CMAKE_INSTALL_RPATH_USE_LINK_PATH=ON``
---------------------------------------------------------------------
-
-CMake uses different RPATHs during the build and after installation, so that executables
-can locate the libraries they're linked to during the build, and installed executables
-do not have RPATHs to build directories. In Spack, we have to make sure that RPATHs are
-set properly after installation.
-
-Spack sets ``CMAKE_INSTALL_RPATH`` to a list of ``<prefix>/lib`` or ``<prefix>/lib64``
-directories of the spec's link-type dependencies. Apart from that, it sets
-``-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=ON``, which should add RPATHs for directories of
-linked libraries not in the directories covered by ``CMAKE_INSTALL_RPATH``.
-
-Usually it's enough to set only ``-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=ON``, but the
-reason to provide both options is that packages may dynamically open shared libraries,
-which CMake cannot detect. In those cases, the RPATHs from ``CMAKE_INSTALL_RPATH`` are
-used as search paths.
-
-.. note::
-
-   Some packages provide stub libraries, which contain an interface for linking without
-   an implementation. When using such libraries, it's best to override the option
-   ``-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=OFF`` in ``cmake_args``, so that stub libraries
-   are not used at runtime.
-
 
 ^^^^^^^^^^
 Generators
@@ -275,6 +179,36 @@ generators, but it should be simple to add support for alternative
 generators. For more information on CMake generators, see:
 https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html
 
+^^^^^^^^^^^^^^^^
+CMAKE_BUILD_TYPE
+^^^^^^^^^^^^^^^^
+
+Every CMake-based package accepts a ``-DCMAKE_BUILD_TYPE`` flag to
+dictate which level of optimization to use. In order to ensure
+uniformity across packages, the ``CMakePackage`` base class adds
+a variant to control this:
+
+.. code-block:: python
+
+   variant('build_type', default='RelWithDebInfo',
+           description='CMake build type',
+           values=('Debug', 'Release', 'RelWithDebInfo', 'MinSizeRel'))
+
+However, not every CMake package accepts all four of these options.
+Grep the ``CMakeLists.txt`` file to see if the default values are
+missing or replaced. For example, the
+`dealii <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/dealii/package.py>`_
+package overrides the default variant with:
+
+.. code-block:: python
+
+   variant('build_type', default='DebugRelease',
+           description='The build type to build',
+           values=('Debug', 'Release', 'DebugRelease'))
+
+For more information on ``CMAKE_BUILD_TYPE``, see:
+https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html
+
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 CMakeLists.txt in a sub-directory
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

lib/spack/docs/build_systems/cudapackage.rst

@@ -1,131 +1,43 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _cudapackage:
 
-----
-Cuda
-----
+-----------
+CudaPackage
+-----------
 
-Different from other packages, ``CudaPackage`` does not represent a build system.
-Instead its goal is to simplify and unify usage of ``CUDA`` in other packages by providing a `mixin-class <https://en.wikipedia.org/wiki/Mixin>`_.
+Different from other packages, ``CudaPackage`` does not represent a build
+system. Instead its goal is to simplify and unify usage of ``CUDA`` in other
+packages.
 
-You can find source for the package at
-`<https://github.com/spack/spack/blob/develop/lib/spack/spack/build_systems/cuda.py>`__.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Provided variants and dependencies
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-^^^^^^^^
-Variants
-^^^^^^^^
-
-This package provides the following variants:
-
-* **cuda**
-
-  This variant is used to enable/disable building with ``CUDA``. The default
-  is disabled (or ``False``).
-
-* **cuda_arch**
-
-  This variant supports the optional specification of one or multiple architectures.
-  Valid values are maintained in the ``cuda_arch_values`` property and
-  are the numeric character equivalent of the compute capability version
-  (e.g., '10' for version 1.0). Each provided value affects associated
-  ``CUDA`` dependencies and compiler conflicts.
-  
-  The variant builds both PTX code for the _virtual_ architecture
-  (e.g. ``compute_10``) and binary code for the _real_ architecture (e.g. ``sm_10``).
-
-  GPUs and their compute capability versions are listed at
-  https://developer.nvidia.com/cuda-gpus .
-
-^^^^^^^^^
-Conflicts
-^^^^^^^^^
-
-Conflicts are used to prevent builds with known bugs or issues. While
-base ``CUDA`` conflicts have been included with this package, you may
-want to add more for your software.
-
-For example, if your package requires ``cuda_arch`` to be specified when
-``cuda`` is enabled, you can add the following conflict to your package
-to terminate such build attempts with a suitable message:
-
-.. code-block:: python
-
-    conflicts('cuda_arch=none', when='+cuda',
-              msg='CUDA architecture is required')
-
-Similarly, if your software does not support all versions of the property,
-you could add ``conflicts`` to your package for those versions.  For example,
-suppose your software does not work with CUDA compute capability versions
-prior to SM 5.0 (``50``).  You can add the following code to display a
-custom message should a user attempt such a build:
-
-.. code-block:: python
-
-    unsupported_cuda_archs = [
-        '10', '11', '12', '13',
-        '20', '21',
-        '30', '32', '35', '37'
-    ]
-    for value in unsupported_cuda_archs:
-        conflicts('cuda_arch={0}'.format(value), when='+cuda',
-                  msg='CUDA architecture {0} is not supported'.format(value))
-
-^^^^^^^
-Methods
-^^^^^^^
-
-This package provides one custom helper method, which is used to build
-standard CUDA compiler flags.
-
-**cuda_flags**
-
-    This built-in static method returns a list of command line flags
-    for the chosen ``cuda_arch`` value(s).  The flags are intended to
-    be passed to the CUDA compiler driver (i.e., ``nvcc``).
-
-    This method must be explicitly called when you are creating the
-    arguments for your build in order to use the values.
+``CudaPackage`` provides ``cuda`` variant (default to ``off``) to enable/disable
+``CUDA``, and ``cuda_arch`` variant to optionally specify the architecture.
+It also declares dependencies on the ``CUDA`` package ``depends_on('cuda@...')``
+based on the architecture as well as specifies conflicts for certain compiler versions.
 
 ^^^^^
 Usage
 ^^^^^
 
-This helper package can be added to your package by adding it as a base
-class of your package.  For example, you can add it to your
-:ref:`CMakePackage <cmakepackage>`-based package as follows:
+In order to use it, just add another base class to your package, for example:
 
 .. code-block:: python
-   :emphasize-lines: 1,7-16
 
-    class MyCudaPackage(CMakePackage, CudaPackage):
+    class MyPackage(CMakePackage, CudaPackage):
         ...
         def cmake_args(self):
             spec = self.spec
-            args = []
-            ...
             if '+cuda' in spec:
-                # Set up the cuda macros needed by the build
-                args.append('-DWITH_CUDA=ON')
-                cuda_arch_list = spec.variants['cuda_arch'].value
-                cuda_arch = cuda_arch_list[0]
-                if cuda_arch != 'none':
-                    args.append('-DCUDA_FLAGS=-arch=sm_{0}'.format(cuda_arch))
+                options.append('-DWITH_CUDA=ON')
+                cuda_arch = spec.variants['cuda_arch'].value
+                if cuda_arch is not None:
+                    options.append('-DCUDA_FLAGS=-arch=sm_{0}'.format(cuda_arch[0]))
             else:
-                # Ensure build with cuda is disabled
-                args.append('-DWITH_CUDA=OFF')
-            ...
-            return args
-
-assuming only the ``WITH_CUDA`` and ``CUDA_FLAGS`` flags are required.
-You will need to customize options as needed for your build.
-
-This example also illustrates how to check for the ``cuda`` variant using
-``self.spec`` and how to retrieve the ``cuda_arch`` variant's value, which
-is a list, using ``self.spec.variants['cuda_arch'].value``.
-
-With over 70 packages using ``CudaPackage`` as of January 2021 there are
-lots of examples to choose from to get more ideas for using this package.
+                options.append('-DWITH_CUDA=OFF')

lib/spack/docs/build_systems/custompackage.rst

@@ -1,4 +1,4 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
@@ -9,7 +9,7 @@
 Custom Build Systems
 --------------------
 
-While the built-in build systems should meet your needs for the
+While the build systems listed above should meet your needs for the
 vast majority of packages, some packages provide custom build scripts.
 This guide is intended for the following use cases:
 
@@ -31,7 +31,7 @@ installation. Both of these packages require custom build systems.
 Base class
 ^^^^^^^^^^
 
-If your package does not belong to any of the built-in build
+If your package does not belong to any of the aforementioned build
 systems that Spack already supports, you should inherit from the
 ``Package`` base class. ``Package`` is a simple base class with a
 single phase: ``install``. If your package is simple, you may be able
@@ -168,8 +168,7 @@ if and only if this flag is set, we would use the following line:
 Testing
 ^^^^^^^
 
-Let's put everything together and add unit tests to be optionally run
-during the installation of our package.
+Let's put everything together and add unit tests to our package.
 In the ``perl`` package, we can see:
 
 .. code-block:: python
@@ -183,6 +182,12 @@ As you can guess, this runs ``make test`` *after* building the package,
 if and only if testing is requested. Again, this is not specific to
 custom build systems, it can be added to existing build systems as well.
 
+Ideally, every package in Spack will have some sort of test to ensure
+that it was built correctly. It is up to the package authors to make
+sure this happens. If you are adding a package for some software and
+the developers list commands to test the installation, please add these
+tests to your ``package.py``.
+
 .. warning::
 
    The order of decorators matters. The following ordering:
@@ -202,12 +207,3 @@ custom build systems, it can be added to existing build systems as well.
    the tests will always be run regardless of whether or not
    ``--test=root`` is requested. See https://github.com/spack/spack/issues/3833
    for more information
-
-Ideally, every package in Spack will have some sort of test to ensure
-that it was built correctly. It is up to the package authors to make
-sure this happens. If you are adding a package for some software and
-the developers list commands to test the installation, please add these
-tests to your ``package.py``.
-
-For more information on other forms of package testing, refer to
-:ref:`Checking an installation <checking_an_installation>`.

lib/spack/docs/build_systems/inteloneapipackage.rst

@@ -1,204 +0,0 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-   Spack Project Developers. See the top-level COPYRIGHT file for details.
-
-   SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-.. _inteloneapipackage:
-
-
-===========
-IntelOneapi
-===========
-
-
-.. contents::
-
-
-oneAPI packages in Spack
-========================
-
-Spack can install and use the Intel oneAPI products. You may either
-use spack to install the oneAPI tools or use the `Intel
-installers`_. After installation, you may use the tools directly, or
-use Spack to build packages with the tools.
-
-The Spack Python class ``IntelOneapiPackage`` is a base class that is
-used by ``IntelOneapiCompilers``, ``IntelOneapiMkl``,
-``IntelOneapiTbb`` and other classes to implement the oneAPI
-packages. See the :ref:`package-list` for the full list of available
-oneAPI packages or use::
-
-  spack list -d oneAPI
-
-For more information on a specific package, do::
-
-  spack info --all <package-name>
-
-Intel no longer releases new versions of Parallel Studio, which can be
-used in Spack via the :ref:`intelpackage`. All of its components can
-now be found in oneAPI.
-
-Examples
-========
-
-Building a Package With icx
----------------------------
-
-In this example, we build patchelf with ``icc`` and ``icx``. The
-compilers are installed with spack.
-
-Install the oneAPI compilers::
-
-  spack install intel-oneapi-compilers
-
-Add the compilers to your ``compilers.yaml`` so spack can use them::
-
-  spack compiler add `spack location -i intel-oneapi-compilers`/compiler/latest/linux/bin/intel64
-  spack compiler add `spack location -i intel-oneapi-compilers`/compiler/latest/linux/bin
-
-Verify that the compilers are available::
-
-  spack compiler list
-
-The ``intel-oneapi-compilers`` package includes 2 families of
-compilers:
-
-* ``intel``: ``icc``, ``icpc``, ``ifort``. Intel's *classic*
-  compilers.
-* ``oneapi``: ``icx``, ``icpx``, ``ifx``. Intel's new generation of
-  compilers based on LLVM.
-
-To build the ``patchelf`` Spack package with ``icc``, do::
-
-  spack install patchelf%intel
-
-To build with with ``icx``, do ::
-
-  spack install patchelf%oneapi
-
-
-Using oneAPI Spack environment
--------------------------------
-
-In this example, we build lammps with ``icx`` using Spack environment for oneAPI packages created by Intel. The
-compilers are installed with Spack like in example above.
-
-Install the oneAPI compilers::
-
-  spack install intel-oneapi-compilers
-
-Add the compilers to your ``compilers.yaml`` so Spack can use them::
-
-  spack compiler add `spack location -i intel-oneapi-compilers`/compiler/latest/linux/bin/intel64
-  spack compiler add `spack location -i intel-oneapi-compilers`/compiler/latest/linux/bin
-
-Verify that the compilers are available::
-
-  spack compiler list
-
-Clone `spack-configs <https://github.com/spack/spack-configs>`_ repo and activate Intel oneAPI CPU environment::
-
-  git clone https://github.com/spack/spack-configs
-  spack env activate spack-configs/INTEL/CPU
-  spack concretize -f
-
-`Intel oneAPI CPU environment <https://github.com/spack/spack-configs/blob/main/INTEL/CPU/spack.yaml>`_  contains applications tested and validated by Intel, this list is constantly extended. And currently it supports:
-
-- `Devito <https://www.devitoproject.org/>`_
-- `GROMACS <https://www.gromacs.org/>`_
-- `HPCG <https://www.hpcg-benchmark.org/>`_
-- `HPL <https://netlib.org/benchmark/hpl/>`_
-- `LAMMPS <https://www.lammps.org/#gsc.tab=0>`_
-- `OpenFOAM <https://www.openfoam.com/>`_
-- `Quantum Espresso <https://www.quantum-espresso.org/>`_
-- `STREAM <https://www.cs.virginia.edu/stream/>`_
-- `WRF <https://github.com/wrf-model/WRF>`_
-
-To build lammps with oneAPI compiler from this environment just run::
-
-  spack install lammps
-
-Compiled binaries can be find using::
-
-  spack cd -i lammps
-
-You can do the same for all other applications from this environment.
-
-
-Using oneAPI MPI to Satisfy a Virtual Dependence
-------------------------------------------------------
-
-The ``hdf5`` package works with any compatible MPI implementation. To
-build ``hdf5`` with Intel oneAPI MPI do::
-
-  spack install hdf5 +mpi ^intel-oneapi-mpi
-
-Using Externally Installed oneAPI Tools
-=======================================
-
-Spack can also use oneAPI tools that are manually installed with
-`Intel Installers`_.  The procedures for configuring Spack to use
-external compilers and libraries are different.
-
-Compilers
----------
-
-To use the compilers, add some information about the installation to
-``compilers.yaml``. For most users, it is sufficient to do::
-
-  spack compiler add /opt/intel/oneapi/compiler/latest/linux/bin/intel64
-  spack compiler add /opt/intel/oneapi/compiler/latest/linux/bin
-
-Adapt the paths above if you did not install the tools in the default
-location. After adding the compilers, using them is the same
-as if you had installed the ``intel-oneapi-compilers`` package.
-Another option is to manually add the configuration to
-``compilers.yaml`` as described in :ref:`Compiler configuration
-<compiler-config>`.
-
-Libraries
----------
-
-If you want Spack to use oneMKL that you have installed without Spack in
-the default location, then add the following to
-``~/.spack/packages.yaml``, adjusting the version as appropriate::
-
-  intel-oneapi-mkl:
-    externals:
-    - spec: intel-oneapi-mkl@2021.1.1
-      prefix: /opt/intel/oneapi/
-
-
-Using oneAPI Tools Installed by Spack
-=====================================
-
-Spack can be a convenient way to install and configure compilers and
-libraries, even if you do not intend to build a Spack package. If you
-want to build a Makefile project using Spack-installed oneAPI compilers,
-then use spack to configure your environment::
-
-  spack load intel-oneapi-compilers
-
-And then you can build with::
-
-  CXX=icpx make
-
-You can also use Spack-installed libraries. For example::
-
-  spack load intel-oneapi-mkl
-
-Will update your environment CPATH, LIBRARY_PATH, and other
-environment variables for building an application with oneMKL.
-
-More information
-================
-
-This section describes basic use of oneAPI, especially if it has
-changed compared to Parallel Studio. See :ref:`intelpackage` for more
-information on :ref:`intel-virtual-packages`,
-:ref:`intel-unrelated-packages`,
-:ref:`intel-integrating-external-libraries`, and
-:ref:`using-mkl-tips`.
-
-
-.. _`Intel installers`: https://software.intel.com/content/www/us/en/develop/documentation/installation-guide-for-intel-oneapi-toolkits-linux/top.html

lib/spack/docs/build_systems/intelpackage.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _intelpackage:
 
------
-Intel
------
+------------
+IntelPackage
+------------
 
 .. contents::
 
@@ -15,9 +15,6 @@ Intel
 Intel packages in Spack
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-This is an earlier version of Intel software development tools and has
-now been replaced by Intel oneAPI Toolkits.
-
 Spack can install and use several software development products offered by Intel.
 Some of these are available under no-cost terms, others require a paid license.
 All share the same basic steps for configuration, installation, and, where
@@ -140,7 +137,6 @@ If you need to save disk space or installation time, you could install the
 ``intel`` compilers-only subset (0.6 GB) and just the library packages you
 need, for example ``intel-mpi`` (0.5 GB) and ``intel-mkl`` (2.5 GB).
 
-.. _intel-unrelated-packages:
 
 """"""""""""""""""""
 Unrelated packages
@@ -362,8 +358,6 @@ affected by an advanced third method:
 Next, visit section `Selecting Intel Compilers`_ to learn how to tell
 Spack to use the newly configured compilers.
 
-.. _intel-integrating-external-libraries:
-
 """"""""""""""""""""""""""""""""""
 Integrating external libraries
 """"""""""""""""""""""""""""""""""
@@ -397,7 +391,7 @@ for specifics and examples for ``packages.yaml`` files.
 
 .. If your system administrator did not provide modules for pre-installed Intel
    tools, you could do well to ask for them, because installing multiple copies
-   of the Intel tools, as is won't to happen once Spack is in the picture, is
+   of the Intel tools, as is wont to happen once Spack is in the picture, is
    bound to stretch disk space and patience thin. If you *are* the system
    administrator and are still new to modules, then perhaps it's best to follow
    the `next section <Installing Intel tools within Spack_>`_ and install the tools
@@ -424,13 +418,9 @@ Adapt the following example. Be sure to maintain the indentation:
    # other content ...
 
      intel-mkl:
-       externals:
-       - spec: "intel-mkl@2018.2.199  arch=linux-centos6-x86_64"
-         modules:
-         -  intel-mkl/18/18.0.2
-       - spec: "intel-mkl@2018.3.222  arch=linux-centos6-x86_64"
-         modules:
-         -  intel-mkl/18/18.0.3
+       modules:
+         intel-mkl@2018.2.199  arch=linux-centos6-x86_64:  intel-mkl/18/18.0.2
+         intel-mkl@2018.3.222  arch=linux-centos6-x86_64:  intel-mkl/18/18.0.3
 
 The version numbers for the ``intel-mkl`` specs defined here correspond to file
 and directory names that Intel uses for its products because they were adopted
@@ -461,16 +451,12 @@ mechanism.
 
    packages:
      intel-parallel-studio:
-       externals:
-       - spec: "intel-parallel-studio@cluster.2018.2.199 +mkl+mpi+ipp+tbb+daal  arch=linux-centos6-x86_64"
-         modules:
-         -  intel/18/18.0.2
-       - spec: "intel-parallel-studio@cluster.2018.3.222 +mkl+mpi+ipp+tbb+daal  arch=linux-centos6-x86_64"
-         modules:
-         -  intel/18/18.0.3
+       modules:
+         intel-parallel-studio@cluster.2018.2.199 +mkl+mpi+ipp+tbb+daal  arch=linux-centos6-x86_64:  intel/18/18.0.2
+         intel-parallel-studio@cluster.2018.3.222 +mkl+mpi+ipp+tbb+daal  arch=linux-centos6-x86_64:  intel/18/18.0.3
        buildable: False
 
-One additional example illustrates the use of ``prefix:`` instead of
+One additional example illustrates the use of ``paths:`` instead of
 ``modules:``, useful when external modulefiles are not available or not
 suitable:
 
@@ -478,15 +464,13 @@ suitable:
 
    packages:
      intel-parallel-studio:
-       externals:
-       - spec: "intel-parallel-studio@cluster.2018.2.199 +mkl+mpi+ipp+tbb+daal"
-         prefix: /opt/intel
-       - spec: "intel-parallel-studio@cluster.2018.3.222 +mkl+mpi+ipp+tbb+daal"
-         prefix: /opt/intel
+       paths:
+         intel-parallel-studio@cluster.2018.2.199 +mkl+mpi+ipp+tbb+daal: /opt/intel
+         intel-parallel-studio@cluster.2018.3.222 +mkl+mpi+ipp+tbb+daal: /opt/intel
        buildable: False
 
 Note that for the Intel packages discussed here, the directory values in the
-``prefix:`` entries must be the high-level and typically version-less
+``paths:`` entries must be the high-level and typically version-less
 "installation directory" that has been used by Intel's product installer.
 Such a directory will typically accumulate various product versions.  Amongst
 them, Spack will select the correct version-specific product directory based on
@@ -564,29 +548,43 @@ follow `the next section <intel-install-libs_>`_ instead.
              modules:    []
              spec:       intel@18.0.3
              paths:
-               cc:       /usr/bin/true
-               cxx:      /usr/bin/true
-               f77:      /usr/bin/true
-               fc:       /usr/bin/true
+               cc:       stub
+               cxx:      stub
+               f77:      stub
+               fc:       stub
 
-      Replace ``18.0.3`` with the version that you determined in the preceding
-      step. The exact contents under ``paths:`` do not matter yet, but the paths must exist.
+      Replace ``18.0.3`` with the version that you determined in the preceeding
+      step. The contents under ``paths:`` do not matter yet.
 
-   This temporary stub is required such that the ``intel-parallel-studio`` package
-   can be installed for the ``intel`` compiler (which the package itself is going
-   to provide after the installation) rather than an arbitrary system compiler.
-   The paths given in ``cc``, ``cxx``, ``f77``, ``fc`` must exist, but will
-   never be used to build anything during the installation of ``intel-parallel-studio``.
+   You are right to ask: "Why on earth is that necessary?" [fn8]_.
+   The answer lies in Spack striving for strict compiler consistency.
+   Consider what happens without such a pre-declared compiler stub:
+   Say, you ask Spack to install a particular version
+   ``intel-parallel-studio@edition.V``.  Spack will apply an unrelated compiler
+   spec to concretize and install your request, resulting in
+   ``intel-parallel-studio@edition.V %X``. That compiler ``%X`` is not going to
+   be the version that this new package itself provides. Rather, it would
+   typically be ``%gcc@...`` in a default Spack installation or possibly indeed
+   ``%intel@...``, but at a version that precedes ``V``.
 
-   The reason for this stub is that ``intel-parallel-studio`` also provides the
-   ``mpi`` and ``mkl`` packages and when concretizing a spec, Spack ensures
-   strong consistency of the used compiler across all dependencies:  [fn8]_.
-   Installing a package ``foo +mkl %intel`` will make Spack look for a package
-   ``mkl %intel``, which can be provided by ``intel-parallel-studio+mkl %intel``,
-   but not by ``intel-parallel-studio+mkl %gcc``.
+   The problem comes to the fore as soon as you try to use any virtual ``mkl``
+   or ``mpi`` packages that you would expect to now be provided by
+   ``intel-parallel-studio@edition.V``.  Spack will indeed see those virtual
+   packages, but only as being tied to the compiler that the package
+   ``intel-parallel-studio@edition.V`` was concretized with *at installation*.
+   If you were to install a client package with the new compilers now available
+   to you, you would naturally run ``spack install foo +mkl %intel@V``, yet
+   Spack will either complain about ``mkl%intel@V`` being missing (because it
+   only knows about ``mkl%X``) or it will go and attempt to install *another
+   instance* of ``intel-parallel-studio@edition.V %intel@V`` so as to match the
+   compiler spec ``%intel@V`` that you gave for your client package ``foo``.
+   This will be unexpected and will quickly get annoying because each
+   reinstallation takes up time and extra disk space.
 
-   Failure to do so may result in additional installations of ``mkl``, ``intel-mpi`` or
-   even ``intel-parallel-studio`` as dependencies for other packages.
+   To escape this trap, put the compiler stub declaration shown here in place,
+   then use that pre-declared compiler spec to install the actual package, as
+   shown next.  This approach works because during installation only the
+   package's own self-sufficient installer will be used, not any compiler.
 
    .. _`verify-compiler-anticipated`:
 
@@ -637,25 +635,11 @@ follow `the next section <intel-install-libs_>`_ instead.
      want to use the ``intel64`` variant.  The ``icpc`` and ``ifort`` compilers
      will be located in the same directory as ``icc``.
 
-   * Make sure to specify ``modules: ['intel-parallel-studio-cluster2018.3-intel-18.0.3-HASH']``
-     (with ``HASH`` being the short hash as displayed when running
-     ``spack find -l intel-parallel-studio@cluster.2018.3`` and the versions adapted accordingly)
-     to ensure that the correct and complete environment for the Intel compilers gets
-     loaded when running them. With modern versions of the Intel compiler you may otherwise see
-     issues about missing libraries. Please also note that module name must exactly match
-     the name as returned by ``module avail`` (and shown in the example above).
-
-   * Use the ``modules:`` and/or ``cflags:`` tokens to further specify a suitable accompanying
+   * Use the ``modules:`` and/or ``cflags:`` tokens to specify a suitable accompanying
      ``gcc`` version to help pacify picky client packages that ask for C++
      standards more recent than supported by your system-provided ``gcc`` and its
      ``libstdc++.so``.
 
-   * If you specified a custom variant (for example ``+vtune``) you may want to add this as your
-     preferred variant in the packages configuration for the ``intel-parallel-studio`` package
-     as described in :ref:`package-preferences`. Otherwise you will have to specify
-     the variant every time ``intel-parallel-studio`` is being used as ``mkl``, ``fftw`` or ``mpi``
-     implementation to avoid pulling in a different variant.
-
    * To set the Intel compilers for default use in Spack, instead of the usual ``%gcc``,
      follow section `Selecting Intel compilers`_.
 
@@ -712,7 +696,7 @@ follow `the next section <intel-install-libs_>`_ instead.
              - /home/$user/spack-stage
 
         Do not duplicate the ``config:`` line if it already is present.
-        Adapt the location, which here is the same as in the preceding example.
+        Adapt the location, which here is the same as in the preceeding example.
 
    3. Retry installing the large package.
 
@@ -814,13 +798,13 @@ by one of the following means:
      $ spack install libxc@3.0.0%intel
 
 
-* Alternatively, request Intel compilers implicitly by package preferences.
+* Alternatively, request Intel compilers implicitly by concretization preferences.
   Configure the order of compilers in the appropriate ``packages.yaml`` file,
   under either an ``all:`` or client-package-specific entry, in a
   ``compiler:`` list. Consult the Spack documentation for
   `Configuring Package Preferences <https://spack-tutorial.readthedocs.io/en/latest/tutorial_configuration.html#configuring-package-preferences>`_
   and
-  :ref:`Package Preferences <package-preferences>`.
+  :ref:`Concretization Preferences <concretization-preferences>`.
 
 Example: ``etc/spack/packages.yaml`` might simply contain:
 
@@ -840,7 +824,6 @@ for example:
       compiler: [ intel@18, intel@17, gcc@4.4.7, gcc@4.9.3, gcc@7.3.0, ]
 
 
-.. _intel-virtual-packages:
 
 """"""""""""""""""""""""""""""""""""""""""""""""
 Selecting libraries to satisfy virtual packages
@@ -870,7 +853,7 @@ virtual package, in order of decreasing preference.  To learn more about the
 ``providers:`` settings, see the Spack tutorial for
 `Configuring Package Preferences <https://spack-tutorial.readthedocs.io/en/latest/tutorial_configuration.html#configuring-package-preferences>`_
 and the section
-:ref:`Package Preferences <package-preferences>`.
+:ref:`Concretization Preferences <concretization-preferences>`.
 
 Example: The following fairly minimal example for ``packages.yaml`` shows how
 to exclusively use the standalone ``intel-mkl`` package for all the linear
@@ -914,7 +897,6 @@ With the proper installation as detailed above, no special steps should be
 required when a client package specifically (and thus deliberately) requests an
 Intel package as dependency, this being one of the target use cases for Spack.
 
-.. _using-mkl-tips:
 
 """""""""""""""""""""""""""""""""""""""""""""""
 Tips for configuring client packages to use MKL
@@ -983,7 +965,7 @@ a *virtual* ``mkl`` package is declared in Spack.
 
   Likewise, in a
   :ref:`MakefilePackage <makefilepackage>`
-  or similar package that does not use AutoTools you may need to provide include
+  or similiar package that does not use AutoTools you may need to provide include
   and link options for use on command lines or in environment variables.
   For example, to generate an option string of the form ``-I<dir>``, use:
 
@@ -1073,6 +1055,6 @@ Footnotes
    2. Set the hash length in ``install-path-scheme``, also in ``config.yaml``
       (:ref:`q.v. <config-yaml>`).
    3. You will want to set the *same* hash length for
-      :ref:`module files <modules-projections>`
-      if you have Spack produce them for you, under ``projections`` in
-      ``modules.yaml``.
+      :ref:`tcl module files <modules-naming-scheme>`
+      if you have Spack produce them for you, under ``naming_scheme`` in
+      ``modules.yaml``.  Other module dialects cannot be altered in this manner.

lib/spack/docs/build_systems/luapackage.rst

@@ -1,105 +0,0 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-   Spack Project Developers. See the top-level COPYRIGHT file for details.
-
-   SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-.. _luapackage:
-
----
-Lua
----
-
-The ``Lua`` build-system is a helper for the common case of Lua packages that provide
-a rockspec file.  This is not meant to take a rock archive, but to build
-a source archive or repository that provides a rockspec, which should cover
-most lua packages. In the case a Lua package builds by Make rather than
-luarocks, prefer MakefilePackage.
-
-^^^^^^
-Phases
-^^^^^^
-
-The ``LuaBuilder`` and `LuaPackage`` base classes come with the following phases:
-
-#. ``unpack`` - if using a rock, unpacks the rock and moves into the source directory
-#. ``preprocess`` - adjust sources or rockspec to fix build
-#. ``install`` - install the project
-
-By default, these phases run:
-
-.. code-block:: console
-
-   # If the archive is a source rock
-   $ luarocks unpack <archive>.src.rock
-   $ # preprocess is a noop by default
-   $ luarocks make <name>.rockspec
-
-
-Any of these phases can be overridden in your package as necessary.
-
-^^^^^^^^^^^^^^^
-Important files
-^^^^^^^^^^^^^^^
-
-Packages that use the Lua/LuaRocks build system can be identified by the
-presence of a ``*.rockspec`` file in their sourcetree, or can be fetched as
-a source rock archive (``.src.rock``). This file declares things like build
-instructions and dependencies, the ``.src.rock`` also contains all code.
-
-It is common for the rockspec file to list the lua version required in
-a dependency. The LuaPackage class adds appropriate dependencies on a Lua
-implementation, but it is a good idea to specify the version required with
-a ``depends_on`` statement.  The block normally will be a table definition like
-this:
-
-.. code-block:: lua
-
-   dependencies = {
-      "lua >= 5.1",
-   }
-
-The LuaPackage class supports source repositories and archives containing
-a rockspec and directly downloading source rock files.  It *does not* support
-downloading dependencies listed inside a rockspec, and thus does not support
-directly downloading a rockspec as an archive.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^
-Build system dependencies
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-All base dependencies are added by the build system, but LuaRocks is run to
-avoid downloading extra Lua dependencies during build.  If the package needs
-Lua libraries outside the standard set, they should be added as dependencies.
-
-To specify a Lua version constraint but allow all lua implementations, prefer
-to use ``depends_on("lua-lang@5.1:5.1.99")`` to express any 5.1 compatible
-version. If the package requires LuaJit rather than Lua,
-a ``depends_on("luajit")`` should be used to ensure a LuaJit distribution is
-used instead of the Lua interpreter. Alternately, if only interpreted Lua will
-work ``depends_on("lua")`` will express that.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Passing arguments to luarocks make
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-If you need to pass any arguments to the ``luarocks make`` call, you can
-override the ``luarocks_args`` method like so:
-
-.. code-block:: python
-
-    def luarocks_args(self):
-        return ['flag1', 'flag2']
-
-One common use of this is to override warnings or flags for newer compilers, as in:
-
-.. code-block:: python
-
-    def luarocks_args(self):
-        return ["CFLAGS='-Wno-error=implicit-function-declaration'"]
-
-^^^^^^^^^^^^^^^^^^^^^^
-External documentation
-^^^^^^^^^^^^^^^^^^^^^^
-
-For more information on the LuaRocks build system, see:
-https://luarocks.org/

lib/spack/docs/build_systems/makefilepackage.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _makefilepackage:
 
---------
-Makefile
---------
+---------------
+MakefilePackage
+---------------
 
 The most primitive build system a package can use is a plain Makefile.
 Makefiles are simple to write for small projects, but they usually
@@ -18,7 +18,7 @@ variables.
 Phases
 ^^^^^^
 
-The ``MakefileBuilder`` and ``MakefilePackage`` base classes come with 3 phases:
+The ``MakefilePackage`` base class comes with 3 phases:
 
 #. ``edit`` - edit the Makefile
 #. ``build`` - build the project
@@ -147,10 +147,8 @@ and a ``filter_file`` method to help with this. For example:
    def edit(self, spec, prefix):
        makefile = FileFilter('Makefile')
 
-       makefile.filter(r'^\s*CC\s*=.*',  'CC = '  + spack_cc)
-       makefile.filter(r'^\s*CXX\s*=.*', 'CXX = ' + spack_cxx)
-       makefile.filter(r'^\s*F77\s*=.*', 'F77 = ' + spack_f77)
-       makefile.filter(r'^\s*FC\s*=.*',  'FC = '  + spack_fc)
+       makefile.filter('CC = gcc',  'CC = cc')
+       makefile.filter('CXX = g++', 'CC = c++')
 
 
 `stream <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/stream/package.py>`_

lib/spack/docs/build_systems/mavenpackage.rst

@@ -1,102 +0,0 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-   Spack Project Developers. See the top-level COPYRIGHT file for details.
-
-   SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-.. _mavenpackage:
-
------
-Maven
------
-
-Apache Maven is a general-purpose build system that does not rely
-on Makefiles to build software. It is designed for building and
-managing and Java-based project.
-
-^^^^^^
-Phases
-^^^^^^
-
-The ``MavenBuilder`` and ``MavenPackage`` base classes come with the following phases:
-
-#. ``build`` - compile code and package into a JAR file
-#. ``install`` - copy to installation prefix
-
-By default, these phases run:
-
-.. code-block:: console
-
-   $ mvn package
-   $ install . <prefix>
-
-
-^^^^^^^^^^^^^^^
-Important files
-^^^^^^^^^^^^^^^
-
-Maven packages can be identified by the presence of a ``pom.xml`` file.
-This file lists dependencies and other metadata about the project.
-There may also be configuration files in the ``.mvn`` directory.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^
-Build system dependencies
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Maven requires the ``mvn`` executable to build the project. It also
-requires Java at both build- and run-time. Because of this, the base
-class automatically adds the following dependencies:
-
-.. code-block:: python
-
-   depends_on('java', type=('build', 'run'))
-   depends_on('maven', type='build')
-
-
-In the ``pom.xml`` file, you may see sections like:
-
-.. code-block:: xml
-
-   <requireJavaVersion>
-      <version>[1.7,)</version>
-   </requireJavaVersion>
-   <requireMavenVersion>
-      <version>[3.5.4,)</version>
-   </requireMavenVersion>
-
-
-This specifies the versions of Java and Maven that are required to
-build the package. See
-https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN402
-for a description of this version range syntax. In this case, you
-should add:
-
-.. code-block:: python
-
-   depends_on('java@7:', type='build')
-   depends_on('maven@3.5.4:', type='build')
-
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Passing arguments to the build phase
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The default build and install phases should be sufficient to install
-most packages. However, you may want to pass additional flags to
-the build phase. For example:
-
-.. code-block:: python
-
-   def build_args(self):
-       return [
-           '-Pdist,native',
-           '-Dtar',
-           '-Dmaven.javadoc.skip=true'
-       ]
-
-
-^^^^^^^^^^^^^^^^^^^^^^
-External documentation
-^^^^^^^^^^^^^^^^^^^^^^
-
-For more information on the Maven build system, see:
-https://maven.apache.org/index.html

lib/spack/docs/build_systems/mesonpackage.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _mesonpackage:
 
------
-Meson
------
+------------
+MesonPackage
+------------
 
 Much like Autotools and CMake, Meson is a build system.  But it is
 meant to be both fast and as user friendly as possible.  GNOME's goal
@@ -17,7 +17,7 @@ is to port modules to use the Meson build system.
 Phases
 ^^^^^^
 
-The ``MesonBuilder`` and ``MesonPackage`` base classes come with the following phases:
+The ``MesonPackage`` base class comes with the following phases:
 
 #. ``meson`` - generate ninja files
 #. ``build`` - build the project
@@ -121,15 +121,11 @@ override the ``meson_args`` method like so:
 .. code-block:: python
 
    def meson_args(self):
-       return ['--warnlevel=3']
+       return ['--default-library=both']
 
 
 This method can be used to pass flags as well as variables.
 
-Note that the ``MesonPackage`` base class already defines variants for
-``buildtype``, ``default_library`` and ``strip``, which are mapped to default
-Meson arguments, meaning that you don't have to specify these.
-
 ^^^^^^^^^^^^^^^^^^^^^^
 External documentation
 ^^^^^^^^^^^^^^^^^^^^^^

lib/spack/docs/build_systems/octavepackage.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _octavepackage:
 
-------
-Octave
-------
+-------------
+OctavePackage
+-------------
 
 Octave has its own build system for installing packages.
 
@@ -15,7 +15,7 @@ Octave has its own build system for installing packages.
 Phases
 ^^^^^^
 
-The ``OctaveBuilder`` and ``OctavePackage`` base classes have a single phase:
+The ``OctavePackage`` base class has a single phase:
 
 #. ``install`` - install the package
 

lib/spack/docs/build_systems/perlpackage.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _perlpackage:
 
-----
-Perl
-----
+-----------
+PerlPackage
+-----------
 
 Much like Octave, Perl has its own language-specific
 build system.
@@ -16,7 +16,7 @@ build system.
 Phases
 ^^^^^^
 
-The ``PerlBuilder`` and ``PerlPackage`` base classes come with 3 phases that can be overridden:
+The ``PerlPackage`` base class comes with 3 phases that can be overridden:
 
 #. ``configure`` - configure the package
 #. ``build`` - build the package
@@ -120,6 +120,8 @@ so ``PerlPackage`` contains:
 
    extends('perl')
 
+   depends_on('perl', type=('build', 'run'))
+
 
 If your package requires a specific version of Perl, you should
 specify this.

lib/spack/docs/build_systems/qmakepackage.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _qmakepackage:
 
------
-QMake
------
+------------
+QMakePackage
+------------
 
 Much like Autotools and CMake, QMake is a build-script generator
 designed by the developers of Qt. In its simplest form, Spack's
@@ -29,7 +29,7 @@ variables or edit ``*.pro`` files to get things working properly.
 Phases
 ^^^^^^
 
-The ``QMakeBuilder`` and ``QMakePackage`` base classes come with the following phases:
+The ``QMakePackage`` base class comes with the following phases:
 
 #. ``qmake`` - generate Makefiles
 #. ``build`` - build the project
@@ -108,19 +108,6 @@ override the ``qmake_args`` method like so:
 
 This method can be used to pass flags as well as variables.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-``*.pro`` file in a sub-directory
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-If the ``*.pro`` file used to tell QMake how to build the package is
-found in a sub-directory, you can tell Spack to run all phases in this
-sub-directory by adding the following to the package:
-
-.. code-block:: python
-
-   build_directory = 'src'
-
-
 ^^^^^^^^^^^^^^^^^^^^^^
 External documentation
 ^^^^^^^^^^^^^^^^^^^^^^

lib/spack/docs/build_systems/racketpackage.rst

@@ -1,46 +0,0 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-   Spack Project Developers. See the top-level COPYRIGHT file for details.
-
-   SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-.. _racketpackage:
-
-------
-Racket
-------
-
-Much like Python, Racket packages and modules have their own special build system.
-To learn more about the specifics of Racket package system, please refer to the
-`Racket Docs <https://docs.racket-lang.org/pkg/cmdline.html>`_.
-
-^^^^^^
-Phases
-^^^^^^
-
-The ``RacketBuilder`` and ``RacketPackage`` base classes provides an ``install`` phase that
-can be overridden, corresponding to the use of:
-
-.. code-block:: console
-
-   $ raco pkg install
-
-^^^^^^^
-Caveats
-^^^^^^^
-
-In principle, ``raco`` supports a second, ``setup`` phase; however, we have not
-implemented this separately, as in normal circumstances, ``install`` also handles
-running ``setup`` automatically.
-
-Unlike Python, Racket currently on supports two installation scopes for packages, user
-or system, and keeps a registry of installed packages at each scope in its configuration files.
-This means we can't simply compose a "``RACKET_PATH``" environment variable listing all of the
-places packages are installed, and update this at will.
-
-Unfortunately this means that all currently installed packages which extend Racket via ``raco pkg install``
-are accessible whenever Racket is accessible.
-
-Additionally, because Spack does not implement uninstall hooks, uninstalling a Spack  ``rkt-`` package
-will have no effect on the ``raco`` installed packages visible to your Racket installation.
-Instead, you must manually run ``raco pkg remove`` to keep the two package managers in a mutually
-consistent state.

lib/spack/docs/build_systems/rocmpackage.rst

@@ -1,122 +0,0 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-   Spack Project Developers. See the top-level COPYRIGHT file for details.
-
-   SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-.. _rocmpackage:
-
-----
-ROCm
-----
-
-The ``ROCmPackage`` is not a build system but a helper package. Like ``CudaPackage``,
-it provides standard variants, dependencies, and conflicts to facilitate building
-packages using GPUs though for AMD in this case.
-
-You can find the source for this package (and suggestions for setting up your
-``compilers.yaml`` and ``packages.yaml`` files) at
-`<https://github.com/spack/spack/blob/develop/lib/spack/spack/build_systems/rocm.py>`__.
-
-^^^^^^^^
-Variants
-^^^^^^^^
-
-This package provides the following variants:
-
-* **rocm**
-
-  This variant is used to enable/disable building with ``rocm``.
-  The default is disabled (or ``False``).
-
-* **amdgpu_target**
-
-  This variant supports the optional specification of the AMD GPU architecture.
-  Valid values are the names of the GPUs (e.g., ``gfx701``), which are maintained
-  in the ``amdgpu_targets`` property.
-
-^^^^^^^^^^^^
-Dependencies
-^^^^^^^^^^^^
-
-This package defines basic ``rocm`` dependencies, including ``llvm`` and ``hip``.
-
-^^^^^^^^^
-Conflicts
-^^^^^^^^^
-
-Conflicts are used to prevent builds with known bugs or issues. This package
-already requires that the ``amdgpu_target`` always be specified for ``rocm``
-builds. It also defines a conflict that prevents builds with an ``amdgpu_target``
-when ``rocm`` is disabled.
-
-Refer to `Conflicts <https://spack.readthedocs.io/en/latest/packaging_guide.html?highlight=conflicts#conflicts>`__
-for more information on package conflicts.
-
-^^^^^^^
-Methods
-^^^^^^^
-
-This package provides one custom helper method, which is used to build
-standard AMD hip compiler flags.
-
-**hip_flags**
-
-    This built-in static method returns the appropriately formatted
-    ``--amdgpu-target`` build option for ``hipcc``.
-
-    This method must be explicitly called when you are creating the
-    arguments for your build in order to use the values.
-
-^^^^^
-Usage
-^^^^^
-
-This helper package can be added to your package by adding it as a base
-class of your package.  For example, you can add it to your
-:ref:`CMakePackage <cmakepackage>`-based package as follows:
-
-.. code-block:: python
-   :emphasize-lines: 1,3-7,14-25
-
-    class MyRocmPackage(CMakePackage, ROCmPackage):
-        ...
-        # Ensure +rocm and amdgpu_targets are passed to dependencies
-        depends_on('mydeppackage', when='+rocm')
-        for val in ROCmPackage.amdgpu_targets:
-            depends_on('mydeppackage amdgpu_target={0}'.format(val),
-                       when='amdgpu_target={0}'.format(val))
-        ...
-
-        def cmake_args(self):
-            spec = self.spec
-            args = []
-            ...
-            if '+rocm' in spec:
-                # Set up the hip macros needed by the build
-                args.extend([
-                    '-DENABLE_HIP=ON',
-                    '-DHIP_ROOT_DIR={0}'.format(spec['hip'].prefix)])
-                rocm_archs = spec.variants['amdgpu_target'].value
-                if 'none' not in rocm_archs:
-                    args.append('-DHIP_HIPCC_FLAGS=--amdgpu-target={0}'
-                                .format(",".join(rocm_archs)))
-            else:
-                # Ensure build with hip is disabled
-                args.append('-DENABLE_HIP=OFF')
-            ...
-            return args
-        ...
-
-assuming only on the ``ENABLE_HIP``, ``HIP_ROOT_DIR``, and ``HIP_HIPCC_FLAGS``
-macros are required to be set and the only dependency needing rocm options
-is ``mydeppackage``. You will need to customize the flags as needed for your
-build.
-
-This example also illustrates how to check for the ``rocm`` variant using
-``self.spec`` and how to retrieve the ``amdgpu_target`` variant's value
-using ``self.spec.variants['amdgpu_target'].value``.
-
-All five packages using ``ROCmPackage`` as of January 2021 also use the
-:ref:`CudaPackage <cudapackage>`. So it is worth looking at those packages
-to get ideas for creating a package that can support both ``cuda`` and
-``rocm``.

lib/spack/docs/build_systems/rpackage.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _rpackage:
 
---
-R
---
+--------
+RPackage
+--------
 
 Like Python, R has its own built-in build system.
 
@@ -19,7 +19,7 @@ new Spack packages for.
 Phases
 ^^^^^^
 
-The ``RBuilder`` and ``RPackage`` base classes have a single phase:
+The ``RPackage`` base class has a single phase:
 
 #. ``install`` - install the package
 
@@ -79,14 +79,12 @@ Description
 The first thing you'll need to add to your new package is a description.
 The top of the homepage for ``caret`` lists the following description:
 
-   Classification and Regression Training
+   caret: Classification and Regression Training
 
    Misc functions for training and plotting classification and regression models.
 
-The first line is a short description (title) and the second line is a long
-description. In this case the description is only one line but often the
-description is several lines. Spack makes use of both short and long
-descriptions and convention is to use both when creating an R  package.
+You can either use the short description (first line), long description
+(second line), or both depending on what you feel is most appropriate.
 
 ^^^^^^^^
 Homepage
@@ -126,81 +124,21 @@ If you only specify the URL for the latest release, your package will
 no longer be able to fetch that version as soon as a new release comes
 out. To get around this, add the archive directory as a ``list_url``.
 
-^^^^^^^^^^^^^^^^^^^^^
-Bioconductor packages
-^^^^^^^^^^^^^^^^^^^^^
-
-Bioconductor packages are set up in a similar way to CRAN packages, but there
-are some very important distinctions. Bioconductor packages can be found at:
-https://bioconductor.org/. Bioconductor packages are R packages and so follow
-the same packaging scheme as CRAN packages. What is different is that
-Bioconductor itself is versioned and released. This scheme, using the
-Bioconductor package installer, allows further specification of the minimum
-version of R as well as further restrictions on the dependencies between
-packages than what is possible with the native R packaging system. Spack can
-not replicate these extra features and thus Bioconductor packages in Spack need
-to be managed as a group during updates in order to maintain package
-consistency with Bioconductor itself.
-
-Another key difference is that, while previous versions of packages are
-available, they are not available from a site that can be programmatically set,
-thus a ``list_url`` attribute can not be used. However, each package is also
-available in a git repository, with branches corresponding to each Bioconductor
-release. Thus, it is always possible to retrieve the version of any package
-corresponding to a Bioconductor release simply by fetching the branch that
-corresponds to the Bioconductor release of the package repository. For this
-reason, spack Bioconductor R packages use the git repository, with the commit
-of the respective branch used in the ``version()`` attribute of the package.
-
-^^^^^^^^^^^^^^^^^^^^^^^^
-cran and bioc attributes
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-Much like the ``pypi`` attribute for python packages, due to the fact that R
-packages are obtained from specific repositories, it is possible to set up shortcut
-attributes that can be used to set ``homepage``, ``url``, ``list_url``, and
-``git``. For example, the following ``cran`` attribute:
-
-.. code-block:: python
-
-   cran = 'caret'
-
-is equivalent to:
-
-.. code-block:: python
-
-   homepage = 'https://cloud.r-project.org/package=caret'
-   url      = 'https://cloud.r-project.org/src/contrib/caret_6.0-86.tar.gz'
-   list_url = 'https://cloud.r-project.org/src/contrib/Archive/caret'
-
-Likewise, the following ``bioc`` attribute:
-
-.. code-block:: python
-
-   bioc = 'BiocVersion'
-
-is equivalent to:
-
-.. code-block:: python
-
-   homepage = 'https://bioconductor.org/packages/BiocVersion/'
-   git      = 'https://git.bioconductor.org/packages/BiocVersion'
-
-
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 Build system dependencies
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 As an extension of the R ecosystem, your package will obviously depend
 on R to build and run. Normally, we would use ``depends_on`` to express
-this, but for R packages, we use ``extends``. This implies a special
-dependency on R, which is used to set environment variables such as
-``R_LIBS`` uniformly. Since every R package needs this, the ``RPackage``
-base class contains:
+this, but for R packages, we use ``extends``. ``extends`` is similar to
+``depends_on``, but adds an additional feature: the ability to "activate"
+the package by symlinking it to the R installation directory. Since
+every R package needs this, the ``RPackage`` base class contains:
 
 .. code-block:: python
 
    extends('r')
+   depends_on('r', type=('build', 'run'))
 
 
 Take a close look at the homepage for ``caret``. If you look at the
@@ -219,7 +157,7 @@ R dependencies
 R packages are often small and follow the classic Unix philosophy
 of doing one thing well. They are modular and usually depend on
 several other packages. You may find a single package with over a
-hundred dependencies. Luckily, R packages are well-documented
+hundred dependencies. Luckily, CRAN packages are well-documented
 and list all of their dependencies in the following sections:
 
 * Depends
@@ -360,8 +298,8 @@ like so:
 
 .. code-block:: python
 
-   def configure_args(self):
-       mpi_name = self.spec['mpi'].name
+   def configure_args(self, spec, prefix):
+       mpi_name = spec['mpi'].name
 
        # The type of MPI. Supported values are:
        # OPENMPI, LAM, MPICH, MPICH2, or CRAY

lib/spack/docs/build_systems/rubypackage.rst

@@ -1,183 +1,16 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _rubypackage:
 
-----
-Ruby
-----
+-----------
+RubyPackage
+-----------
 
 Like Perl, Python, and R, Ruby has its own build system for
 installing Ruby gems.
 
-^^^^^^
-Phases
-^^^^^^
-
-The ``RubyBuilder`` and ``RubyPackage`` base classes provide the following phases that
-can be overridden:
-
-#. ``build`` - build everything needed to install
-#. ``install`` - install everything from build directory
-
-For packages that come with a ``*.gemspec`` file, these phases run:
-
-.. code-block:: console
-
-   $ gem build *.gemspec
-   $ gem install *.gem
-
-
-For packages that come with a ``Rakefile`` file, these phases run:
-
-.. code-block:: console
-
-   $ rake package
-   $ gem install *.gem
-
-
-For packages that come pre-packaged as a ``*.gem`` file, the build
-phase is skipped and the install phase runs:
-
-.. code-block:: console
-
-   $ gem install *.gem
-
-
-These are all standard ``gem`` commands and can be found by running:
-
-.. code-block:: console
-
-   $ gem help commands
-
-
-For packages that only distribute ``*.gem`` files, these files can be
-downloaded with the ``expand=False`` option in the ``version`` directive.
-The build phase will be automatically skipped.
-
-^^^^^^^^^^^^^^^
-Important files
-^^^^^^^^^^^^^^^
-
-When building from source, Ruby packages can be identified by the
-presence of any of the following files:
-
-* ``*.gemspec``
-* ``Rakefile``
-* ``setup.rb`` (not yet supported)
-
-However, not all Ruby packages are released as source code. Some are only
-released as ``*.gem`` files. These files can be extracted using:
-
-.. code-block:: console
-
-   $ gem unpack *.gem
-
-
-^^^^^^^^^^^
-Description
-^^^^^^^^^^^
-
-The ``*.gemspec`` file may contain something like:
-
-.. code-block:: ruby
-
-   summary = 'An implementation of the AsciiDoc text processor and publishing toolchain'
-   description = 'A fast, open source text processor and publishing toolchain for converting AsciiDoc content to HTML 5, DocBook 5, and other formats.'
-
-
-Either of these can be used for the description of the Spack package.
-
-^^^^^^^^
-Homepage
-^^^^^^^^
-
-The ``*.gemspec`` file may contain something like:
-
-.. code-block:: ruby
-
-   homepage = 'https://asciidoctor.org'
-
-
-This should be used as the official homepage of the Spack package.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^
-Build system dependencies
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-All Ruby packages require Ruby at build and run-time. For this reason,
-the base class contains:
-
-.. code-block:: python
-
-   extends('ruby')
-
-
-The ``*.gemspec`` file may contain something like:
-
-.. code-block:: ruby
-
-   required_ruby_version = '>= 2.3.0'
-
-
-This can be added to the Spack package using:
-
-.. code-block:: python
-
-   depends_on('ruby@2.3.0:', type=('build', 'run'))
-
-
-^^^^^^^^^^^^^^^^^
-Ruby dependencies
-^^^^^^^^^^^^^^^^^
-
-When you install a package with ``gem``, it reads the ``*.gemspec``
-file in order to determine the dependencies of the package.
-If the dependencies are not yet installed, ``gem`` downloads them
-and installs them for you. This may sound convenient, but Spack
-cannot rely on this behavior for two reasons:
-
-#. Spack needs to be able to install packages on air-gapped networks.
-
-   If there is no internet connection, ``gem`` can't download the
-   package dependencies. By explicitly listing every dependency in
-   the ``package.py``, Spack knows what to download ahead of time.
-
-#. Duplicate installations of the same dependency may occur.
-
-   Spack supports *activation* of Ruby extensions, which involves
-   symlinking the package installation prefix to the Ruby installation
-   prefix. If your package is missing a dependency, that dependency
-   will be installed to the installation directory of the same package.
-   If you try to activate the package + dependency, it may cause a
-   problem if that package has already been activated.
-
-For these reasons, you must always explicitly list all dependencies.
-Although the documentation may list the package's dependencies,
-often the developers assume people will use ``gem`` and won't have to
-worry about it. Always check the ``*.gemspec`` file to find the true
-dependencies.
-
-Check for the following clues in the ``*.gemspec`` file:
-
-* ``add_runtime_dependency``
-
-  These packages are required for installation.
-
-* ``add_dependency``
-
-  This is an alias for ``add_runtime_dependency``
-
-* ``add_development_dependency``
-
-  These packages are optional dependencies used for development.
-  They should not be added as dependencies of the package.
-
-^^^^^^^^^^^^^^^^^^^^^^
-External documentation
-^^^^^^^^^^^^^^^^^^^^^^
-
-For more information on Ruby packaging, see:
-https://guides.rubygems.org/
+This build system is a work-in-progress. See
+https://github.com/spack/spack/pull/3127 for more information.

lib/spack/docs/build_systems/sconspackage.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _sconspackage:
 
------
-SCons
------
+------------
+SConsPackage
+------------
 
 SCons is a general-purpose build system that does not rely on
 Makefiles to build software. SCons is written in Python, and handles
@@ -42,7 +42,7 @@ As previously mentioned, SCons allows developers to add subcommands like
    $ scons install
 
 
-To facilitate this, the ``SConsBuilder`` and ``SconsPackage`` base classes provide the
+To facilitate this, the ``SConsPackage`` base class provides the
 following phases:
 
 #. ``build`` - build the package

lib/spack/docs/build_systems/sippackage.rst

@@ -1,13 +1,13 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+.. Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
    Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. _sippackage:
 
----
-SIP
----
+----------
+SIPPackage
+----------
 
 SIP is a tool that makes it very easy to create Python bindings for C and C++
 libraries. It was originally developed to create PyQt, the Python bindings for
@@ -22,7 +22,7 @@ provides support functions to the automatically generated code.
 Phases
 ^^^^^^
 
-The ``SIPBuilder`` and ``SIPPackage`` base classes come with the following phases:
+The ``SIPPackage`` base class comes with the following phases:
 
 #. ``configure`` - configure the package
 #. ``build`` - build the package
@@ -32,7 +32,7 @@ By default, these phases run:
 
 .. code-block:: console
 
-   $ sip-build --verbose --target-dir ...
+   $ python configure.py --bindir ... --destdir ...
    $ make
    $ make install
 
@@ -41,30 +41,36 @@ By default, these phases run:
 Important files
 ^^^^^^^^^^^^^^^
 
-Each SIP package comes with a custom configuration file written in Python.
-For newer packages, this is called ``project.py``, while in older packages,
-it may be called ``configure.py``. This script contains instructions to build
-the project.
+Each SIP package comes with a custom ``configure.py`` build script,
+written in Python. This script contains instructions to build the project.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 Build system dependencies
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-``SIPPackage`` requires several dependencies. Python and SIP are needed at build-time
-to run the aforementioned configure script. Python is also needed at run-time to
-actually use the installed Python library. And as we are building Python bindings
-for C/C++ libraries, Python is also needed as a link dependency. All of these
-dependencies are automatically added via the base class.
+``SIPPackage`` requires several dependencies. Python is needed to run
+the ``configure.py`` build script, and to run the resulting Python
+libraries. Qt is needed to provide the ``qmake`` command. SIP is also
+needed to build the package. SIP is an unusual dependency in that it
+must be installed in the same installation directory as the package,
+so instead of a ``depends_on``, we use a ``resource``. All of these
+dependencies are automatically added via the base class
 
 .. code-block:: python
 
-   extends("python", type=("build", "link", "run"))
-   depends_on("py-sip", type="build")
+   extends('python')
+
+   depends_on('qt', type='build')
+
+   resource(name='sip',
+            url='https://www.riverbankcomputing.com/static/Downloads/sip/4.19.18/sip-4.19.18.tar.gz',
+            sha256='c0bd863800ed9b15dcad477c4017cdb73fa805c25908b0240564add74d697e1e',
+            destination='.')
 
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Passing arguments to ``sip-build``
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Passing arguments to ``configure.py``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Each phase comes with a ``<phase_args>`` function that can be used to pass
 arguments to that particular phase. For example, if you need to pass
@@ -72,11 +78,11 @@ arguments to the configure phase, you can use:
 
 .. code-block:: python
 
-   def configure_args(self):
-       return ["--no-python-dbus"]
+   def configure_args(self, spec, prefix):
+       return ['--no-python-dbus']
 
 
-A list of valid options can be found by running ``sip-build --help``.
+A list of valid options can be found by running ``python configure.py --help``.
 
 ^^^^^^^
 Testing
@@ -93,17 +99,10 @@ in the site-packages directory:
    $ python
    >>> import setuptools
    >>> setuptools.find_packages()
-   [
-       'PyQt5', 'PyQt5.QtCore', 'PyQt5.QtGui', 'PyQt5.QtHelp',
-       'PyQt5.QtMultimedia', 'PyQt5.QtMultimediaWidgets', 'PyQt5.QtNetwork',
-       'PyQt5.QtOpenGL', 'PyQt5.QtPrintSupport', 'PyQt5.QtQml',
-       'PyQt5.QtQuick', 'PyQt5.QtSvg', 'PyQt5.QtTest', 'PyQt5.QtWebChannel',
-       'PyQt5.QtWebSockets', 'PyQt5.QtWidgets', 'PyQt5.QtXml',
-       'PyQt5.QtXmlPatterns'
-    ]
+   ['QtPy5']
 
 
-Large, complex packages like ``py-pyqt5`` will return a long list of
+Large, complex packages like ``QtPy5`` will return a long list of
 packages, while other packages may return an empty list. These packages
 only install a single ``foo.py`` file. In Python packaging lingo,
 a "package" is a directory containing files like:
@@ -115,25 +114,21 @@ a "package" is a directory containing files like:
    foo/baz.py
 
 
-whereas a "module" is a single Python file.
-
-The ``SIPPackage`` base class automatically detects these module
-names for you. If, for whatever reason, the module names detected
-are wrong, you can provide the names yourself by overriding
-``import_modules`` like so:
+whereas a "module" is a single Python file. Since ``find_packages``
+only returns packages, you'll have to determine the correct module
+names yourself. You can now add these packages and modules to the
+package like so:
 
 .. code-block:: python
 
    import_modules = ['PyQt5']
 
 
-These tests often catch missing dependencies and non-RPATHed
-libraries. Make sure not to add modules/packages containing the word
-"test", as these likely won't end up in the installation directory,
-or may require test dependencies like pytest to be installed.
+When you run ``spack install --test=root py-pyqt5``, Spack will attempt
+to import the ``PyQt5`` module after installation.
 
-These tests can be triggered by running ``spack install --test=root``
-or by running ``spack test run`` after the installation has finished.
+These tests most often catch missing dependencies and non-RPATHed
+libraries.
 
 ^^^^^^^^^^^^^^^^^^^^^^
 External documentation

lib/spack/docs/build_systems/sourceforgepackage.rst

@@ -1,55 +0,0 @@
-.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
-   Spack Project Developers. See the top-level COPYRIGHT file for details.
-
-   SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-.. _sourceforgepackage:
-
------------
-Sourceforge
------------
-
-``SourceforgePackage`` is a
-`mixin-class <https://en.wikipedia.org/wiki/Mixin>`_. It automatically
-sets the URL based on a list of Sourceforge mirrors listed in
-`sourceforge_mirror_path`, which defaults to a half dozen known mirrors.
-Refer to the package source
-(`<https://github.com/spack/spack/blob/develop/lib/spack/spack/build_systems/sourceforge.py>`__) for the current list of mirrors used by Spack.
-
-
-^^^^^^^
-Methods
-^^^^^^^
-
-This package provides a method for populating mirror URLs.
-
-**urls**
-
-    This method returns a list of possible URLs for package source.
-    It is decorated with `property` so its results are treated as
-    a package attribute.
-
-    Refer to
-    `<https://spack.readthedocs.io/en/latest/packaging_guide.html#mirrors-of-the-main-url>`__
-    for information on how Spack uses the `urls` attribute during
-    fetching.
-
-^^^^^
-Usage
-^^^^^
-
-This helper package can be added to your package by adding it as a base
-class of your package and defining the relative location of an archive
-file for one version of your software.
-
-.. code-block:: python
-   :emphasize-lines: 1,3
-
-    class MyPackage(AutotoolsPackage, SourceforgePackage):
-        ...
-        sourceforge_mirror_path = "my-package/mypackage.1.0.0.tar.gz"
-        ...
-
-Over 40 packages are using ``SourceforcePackage`` this mix-in as of
-July 2022 so there are multiple packages to choose from if you want
-to see a real example.