[RFC] Package multiple versions of llvm tool-chain

[Calandracas606]

Major llvm releases introduce breaking changes, and it can take a while for software that depends on llvm to adapt.

Debian packages versioned llvm packages, as does llvm's own deb repository to allow multiple versions of the tool-chain to be installed simultaneously

Void already provides multiple versions of libllvm (12 and 15), I propose doing something similar but with more components of the tool-chain, such as clang and libclang.

For example, this would allow Void to build mesa with llvm17, but zig with llvm15 (zig does not support llvm17 yet)

This would also allow void to package new llvm versions, before setting one as the "default" versions. Similar to how void has "linux" and "linux-mainline" packages, void could add llvm17, but keep the llvm meta-package depending on llvm15. This would also require creating new meta-packages for other components of the tool-chain such as clang, and having the meta-package "clang" depend on a new package, "clang15".

llvm's cmake has support for building and installing in this way. /usr/bin/clang is already a symlink to /usr/bin/clang-15

If this seems reasonable, I propose adding these changes to my WIP llvm17 package, #46935

[classabbyamp]

seems reasonable

[jonpikum]

Would this open the door to LLVM forks - e.g. ROCm?
Not sure how muddy that might get.
Or would the goal be mainline only?

[Calandracas606]

Would this open the door to LLVM forks - e.g. ROCm? Not sure how muddy that might get. Or would the goal be mainline only?

ROCm is already possible, it has no dependancies on system llvm, and can be installed to a directory such as /usr/lib/rocm

I have a working template (x86_64 glibc only) but it is quite messy. I don't think it's a good fit for a void package though.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.