RFC: Centralized ROCm target list + utility

[Christian Kastner <ckk@debian.org>]

Hi team,

following up on [1], I propose the following:

 1. pkg-rocm-tools ships master lists of build targets for distributions
 2. pkg-rocm-tools ships a utility to query this list


1. Master lists
===============

For each distribution, we ship a newline-separated list of build targets in

    /usr/share/pkg-rocm-tools/data/build-targets/<codename>

which look like this:

   # Comments are supported, blank lines are skipped
   gfx900
   gfx906
   ...

<codename> can be a symlink to some other <codename>.

Currently, the trixie list consists of the typical targets, and unstable
and experimental are symlinks to trixie.


2. Utility
==========

We ship a utility to easily parse/transform the data of the master
lists. Here is the proposed interface:

$ rocm-arch-support
  -> Prints space-separated list of targets for the current
    distribution: "gfx803 gfx900 gfx906 gfx908 ..."

$ rocm-arch-support --dist <codename>
  -> like above, but for the distribution with the given codename

$ rocm-arch-support --sep '<str>'
  -> like above, but use arbitrary <sep> as a target separator

$ rocm-arch-support --for-build
  -> Prints semicolon-separated list of targets for the current source
     package: "gfx803;gfx900;gfx906;gfx908;..."
  -> use as eg: AMDGPU_TARGETS="$(rocm-arch-support --for-build)"

  "For the current source package" means that this can only be invoked
  in the root of a debian source package, where the utility may infer
  various things, such as the distribution being built for from
  d/changelog.


Other considerations
====================

Instead of bin:pkg-rocm-tools, this could also be a good fit for
bin:hipcc. However, the latter pulls in 951MiB of dependencies, which
would be complete overkill for anything that only needs to query this
list for reasons other than building.

I assume bin:pkg-rocm-tools will continue to grow with more packaging
utilities so it will become a quasi-must-dependency of a build anyway.
So the utility seemed to fit better there.


The above is already already implemented and tested. I will be uploading
to experimental shortly as I need this for the rocrand update.

If anyone can come up with better names for the utility or its
arguments, please suggest them.

Best,
Christian

[1]: https://lists.debian.org/debian-ai/2025/05/msg00024.html