Change variant name to platform triple / quadruple?

[tiran]

In Fromager <= 0.28, the variant name is an arbitrary string. By convention, we are using names like cpu or cuda-ubi9. The first part of the string is the GPU-specific library and the second part is missing or the nick name of the build environment. The approach is good enough for now, because we only test on Linux x86_64 for UBI9 / CentOS 9. In the future, we are going to support more platforms and hardware architectures. Some combinations may require specific patches or settings.

Compilers like gcc, llvm/clang, and Rust use platform triple(e) to express platform support and target:

• Rust
• llvm
• libtool

We could use a similar approach in Fromager and define an inheritance order for settings, e.g. GPU arch > CPU arch > OS > default.

dimensions

• hardware accelerator / GPU library (CPU, CUDA, ROCm, Gaudi, oneAPI, ...)
• accelerator library version (CUDA 12.4, 12.5; ROCm 6.1, 6.2)
• CPU architecture (x86_64, aarch64, ppc64le, s390x)
• OS (Linux, macOS, Windows)
• libc (glibc, musl libc) and libc ABI
• platform / distro ABI (RHEL (el9, el10), Fedora (fc39, fc40), others?)

Some dimensions are implied by others, e.g. ubi9 implies Linux with glibc and el9 ABI. The OS and CPU arch can be retrieved at runtime (platform module).

Triple syntax

<arch>-<vendor>-<sys>-<abi>

Example (Fedora 39):

$ clang -dumpmachine
x86_64-redhat-linux-gnu
$ gcc -dumpmachine
x86_64-redhat-linux

Suggestion

• x86_64-ubi9-linux-gnu-cuda
• x86_64-ubi9-linux-cuda
• cuda:ubi9:x86_64

[dhellmann]

I think we could standardize on a format downstream, but I hesitate to impose a standard like that upstream. It gets us into the same situation we are with wheel build tags, where the creators of the standard didn't anticipate future needs and now we don't have a way to express GPU-specific builds.