-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deploy: add and update hpctoolkit package for deployment #2000
base: develop
Are you sure you want to change the base?
Conversation
Thank you for your pull request! Should you want to clear the PR build directory after failures, please use this pipeline. Before running the cleanup pipeline, please ensure that any PR building pipelines have been cancelled or finished running. |
@@ -0,0 +1,126 @@ | |||
from spack.package import * |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(This is referring to the whole file, not that particular line 😅)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sergiorg-hpc : so, this new file is copied from upstream's develop branch without any of our custom changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, that is correct, I was just explaining that to @heerener. This contains only the differences between our current upstream version and the actual upstream version of hpctoolkit
in the Spack repo.
I remember @matz-e telling me back in the day not to meddle with the original Spack recipes, so that he could update everything at once when he fetches from upstream (this is really back in the day, 1.5 years ago maybe, so perhaps this is no longer valid).
Since then, I have always added patches with new versions. For instance, I did that with arm-forge
and other recipes.
If you are fine with the idea of updating the full package specification, @kotsaloscv and I have no objection. We were playing safe here based on what I remembered from @matz-e.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, understood. I don't know our strategy or recommendation in 2023. Let's wait for a blessing from @matz-e then!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After clarifying discussion, the idea is: "don't modify anything in builtin
that you are not prepared to lose."
Backporting upstream/develop
recipes is absolutely fine and even preferred (keeps number of patches lower, and won't interfere / get lost with the next upgrade).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what @heerener said.
To test your PR, use the following on BlueBrain5: unset MODULEPATH
. /gpfs/bbp.cscs.ch/ssd/apps/bsd/pulls/2000/config/modules.sh
module load unstable Please test the following updated modules:
|
Just to update: even the module is built, it’s needed some more work. |
No description provided.