Background

We need to come to a decision on how the humble spack.yaml will fare in multiple targets HPCs. Specifically, we currently have a single spack.yaml for Gadi, but if we can't make it sufficiently generic (compilers, target, etc), we need a different solution.

Potential Implementations

• Simplest, cleanest, most naive: The single spack.yaml can be made sufficiently generic for all (future) deployment targets
• CI-enabled templating: Single spack.yaml, have sections that require modification per-target to be templated somehow - maybe as an environment variable, or some other marker in the spack.yaml that notes that the section is to be injected at install time. The injected spack.yaml is still part of a release artifact. But, as some incredibly wise person noted once: "Every line of code we write is a line of code we have to maintain".
• More complex (EDIT: Not that complex now due to work in Fix Up Multi-Target TODOs build-cd#199): Have a spack.yaml per target - eg. gadi.spack.yaml, setonix.spack.yaml. Has duplication of sections.