You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
After testing, these variables are only interpreted on spack.specs rather than spack.packages.all.requires - we put our compiler and target definitions (the things we were looking to change) in the packages section. And I'm not even sure that we can put the target in the specs section, anyway. Seems like option 1 is a no...
Background
We need to come to a decision on how the humble
spack.yaml
will fare in multipletargetsHPCs. Specifically, we currently have a singlespack.yaml
for Gadi, but if we can't make it sufficiently generic (compilers, target, etc), we need a different solution.Potential Implementations
spack.yaml
can be made sufficiently generic for all (future) deployment targetsspack.yaml
, have sections that require modification per-target to be templated somehow - maybe as an environment variable, or some other marker in thespack.yaml
that notes that the section is to be injected at install time. The injectedspack.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".spack.yaml
per target - eg.gadi.spack.yaml
,setonix.spack.yaml
. Has duplication of sections.The text was updated successfully, but these errors were encountered: