Compilers become external packages in Spack

[pearce8]

• Need to move compilers.yaml to packages.yaml
• Need to understand when Ramble will shift to this as well, Spack expected to shift by November 2024.
• Compiler-runtimes will show up as dependencies in the dependence graph.
• Evaluate impact of conflict: and prefer: syntax changes
• Binary compatibility on linux is now based on the libc version - how is this checked?

Hi all,

Spack v0.22 is out with some long-awaited changes to compiler handling, and many other features!

We are in the process of making compilers proper dependencies in Spack, and a number of changes in v0.22 support that effort. You may notice nodes in your dependency graphs for compiler runtime libraries like gcc-runtime or libgfortran, and you may notice that Spack graphs now include libc. We've also begun moving compiler configuration from compilers.yaml to packages.yaml to make it consistent with other externals. We are trying to do this with the least disruption possible, so your existing compilers.yaml files should still work. We expect to be done with this transition by the v0.23 release in November.

Highlights from the release:
Compiler runtime dependencies
Packages compiled with %gcc on Linux, macOS and FreeBSD now depend on a new package, gcc-runtime.
Packages compiled with %oneapi now depend on a new package intel-oneapi-runtime.
Changes to the optimization criteria of the solver improve the hit-rate of buildcaches by a fair amount.
Spack will reuse specs built with compilers that are not explicitly configured in compilers.yaml.
Binary compatibility on linux is now based on the libc version, instead of on the os tag.
Each package that can provide a compiler is now detectable using spack external find. External packages defining compiler paths are effectively used as compilers, and spack external find -t compiler can be used as a substitute for spack compiler find.
Improved spack find UI for Environments
Improved command-line string quoting
Revert default spack install behavior to --reuse
More control over reused specs
New redistribute() directive
New conflict: and prefer: syntax for package preferences
include_concrete in environments: ou may want to build on the concrete contents of another environment without changing that environment. You can now include the concrete specs from another environment's spack.lock with include_concrete.
Improved Python isolation through the use of a new python-venv package that we shim in front of spack-built and external python.
More details in the release notes here:
https://github.com/spack/spack/releases/tag/v0.22.0
-Todd