Update spack submodule branch spack-stack-dev from spack develop#1877
Closed
climbfuji wants to merge 23 commits intoJCSDA:developfrom
Closed
Update spack submodule branch spack-stack-dev from spack develop#1877climbfuji wants to merge 23 commits intoJCSDA:developfrom
climbfuji wants to merge 23 commits intoJCSDA:developfrom
Conversation
.gitmodules and submodule pointer for spack for code review and testing
…g,gcc,oneapi}.yaml; remove outdated packages yaamls for aocc, apple-clang, intel classic
…eature/update_spack-stack-dev_from_develop
…/ubuntu-ci-x86_64-oneapi.cfg and .github/workflows/ubuntu-ci-x86_64-oneapi-ifx.cfg
…es.yaml to avoid duplicate packages
…o prevent build errors with gcc when generator=ninja
…hod to determine preferred compiler
…eview and testing
climbfuji
changed the title
2 tasks
…eature/update_spack-stack-dev_from_develop
Collaborator
rickgrubin-noaa
left a comment
rickgrubin-noaa
left a comment
There was a problem hiding this comment.
The changed noted in the PR description will come into play for v2.1, correct?
Collaborator
Author
Correct, but we can start building and testing with develop. |
rickgrubin-noaa
approved these changes
Jan 14, 2026
… for external openmpi
mathomp4
approved these changes
Jan 20, 2026
7 tasks
… spack-stack repo; add as variant to jedi-neptune-env and enable variant in neptune-dev environment template
…/github.com/climbfuji/spack-stack into feature/update_spack-stack-dev_from_develop
auto-merge was automatically disabled
January 21, 2026 23:50
Pull request was closed
github-project-automation
bot
moved this from In Progress
to Done
in spack-stack-2.1.x (2026 Q1)
13 tasks
Collaborator
Author
|
This PR was accidentally closed in a way that I cannot reopen it. See #1886 for its replacement. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR updates the spack submodule branch
spack-stack-devfrom the upstream spackdevelop. Until now, it was based on Spack v1.0.1. See JCSDA/spack#574This update requires us to switch to the new (spack v1) syntax for declaring preferred compilers, since the blanket
packages:all:require:['gcc'](for example) no longer works for packages that don't depend on a compiler (no c, cxx, fortran dependency). While updating the commonpackages_<compiler>.yamlfiles, I removed the remainingconfigs/common/packages_<compiler>.yaml.NOTYETUPDATEDfiles.The concretizer now behaves slightly differently, and we can no longer declare external compiler runtime libraries. I opposed this for a long time, but, alas, I'll choose a different hill to die on. This had to be done for every site config. A few more tweaks to the common
packages.yamlare needed to avoid duplicate packages. Note also that external packages now have to match any variants that arerequire:d in the environment config.The above changes require updates to the
setup-meta-modulesextension, the GitHub actions workflows, and the unit tests for the spack-stack extension.Lastly, this PR brings in a new version of bufr-query 0.0.5. Note that the concretizer in spack v1.0.1 had a bug that caused it to simply ignore bufr-query, even though it was supposed to be built (variant in jedi-base-env had default value
True). The new concretizer fixed this bug, and now we do getbufr-queryas part of the unified environment and the Skylab environment.Dependencies
Issues addressed
Closes #1874
Closes #1875
Closes #1766
Closes #1767
Applications affected
Potentially all. Or none.
Systems affected
Potential all. Or none. Heck, who knows. We'll find out.
This works on the NRL Atlantis system with NEPTUNE
Testing
Checklist