rocm: make amdgpu_target sticky#34591
Conversation
The sticky property will prevent clingo from changing the amdgpu_target to work around conflicts. This is the same behaviour as was adopted for cuda_arch in 055c9d1.
spackbot-app
bot
added
build-systems
core
spackbot-app
bot
requested review from
haampie,
renjithravindrankannath and
srekolam
|
This should prevent some of the weird choices of amdgpu_target variant values we see on the CI. |
adamjstewart
left a comment
adamjstewart
left a comment
There was a problem hiding this comment.
Why do so many packages define this variant? Can they subclass ROCmPackage or would that create circular dependencies?
I was thinking the same thing, but I'm not sure how to do that nicely. The defaults for ROCmPackage don't make sense for libraries that are part of ROCm. Defaulting to |
|
You could extend the base class but add |
|
That sounds like a good idea. That might be a good next step to explore after #34586. |
The sticky property will prevent clingo from changing the amdgpu_target to work around conflicts. This is the same behaviour as was adopted for cuda_arch in 055c9d1.
|
Confusingly CI passed here, even though it failed on develop. |
The sticky property will prevent clingo from changing the amdgpu_target to work around conflicts. This is the same behaviour as was adopted for cuda_arch in 055c9d1.
The sticky property will prevent clingo from changing the amdgpu_target to work around conflicts. This is the same behaviour as was adopted for cuda_arch in 055c9d1.
5 participants
The sticky property will prevent clingo from changing the amdgpu_target to work around conflicts. This is the same behaviour as was adopted for cuda_arch in 055c9d1.