Re: ci.rocm: invalid device function
On 2025-07-22 20:40, Samuel Thibault wrote:
> It would be convenient that rocm-target-arch provides a way to produce
> the --offload-arch series, to save all maintainers from coining some
> debian/rules snippet for that :)
>
> (similarly to dpkg .mk files which provide CC, CFLAGS, etc. we could
> have HIPCCFLAGS)
I of course agree with the idea in principle, but I'm not sure it's
practical.
rocm-target-arch was primarily created because existing packages needed
a distribution-wide *centrally defined* list of arches instead of a
package-local hard-coded one. Having it format output was just for minor
convenience.
Your 1 LOC solution [2] is already so simple and concise that I
whether adding logic for other approaches is worth the added interface
complexity.
The HIPCCFLAGS approach you suggest could work, but I don't know if
setting that would clash with some other potential use, and maintainers
still have to add 1 LOC.
Alternatively, rocm-target-arch could get gain another option for this
particular output format.
Alternatively, the existing --sep option could infer/do this when use
with some special value, eg: --sep=offload-arch. Though that might
already be too clever?
I have no strong opinions either way. I suspect that we might need more
data/feedback on how various other packages build, or what their
maintainers expect.
Best,
Christian
PS: If you are using rocm-target-arch in a package build, please also
use the --for-build option, which will pick the arch list for the
distribution in d/changelog. experimental currently has more arches
then unstable.
[2]: https://salsa.debian.org/debian/starpu/-/blob/experimental/debian/rules?ref_type=heads#L23
Reply to: