https://bugzilla.redhat.com/show_bug.cgi?id=2277782
--- Comment #2 from Alyssa Rosenzweig alyssa@rosenzweig.io ---
Notice this is already available on Fedora 40, where clang17-tools-extra provides /usr/bin/clang-format-17 and clang-tools-extra provides /usr/bin/clang-format from LLVM 18.1.
Great to know, thanks!
Could you provide more information on how this version is pinned, please? e.g. are you trying to install an RPM that requires on clang-format-16?
Due to the unstable nature of clang-format output, an upstream project has to pin a particular version that all its developers use. The RPM doesn't involve clang-format in any way, this is just for upstream devs.
I think projects pick the latest version they can get away with (say, packaged in a suitably old version of Debian), and then stay there as long as they can get away with. It looks like Mesa uses LLVM 15 and FEX uses LLVM 16. Bumping the version requires a flag day "reformat everything" commit which isn't too pleasant, so even if the whole team uses the latest Fedora, it would be inconvenient to have to track upstream LLVM.
Tangential observation, but clang-format output seems to be much more stable for C code (like Mesa) than C++ code (like FEX). I guess that shouldn't be too surprising.
---
In context of clang-format adoption for a third project, I saw someone suggest pulling binaries from https://github.com/llvm/llvm-project/releases/tag/llvmorg-16.0.4 and skipping the package management. This works as a stopgap but having packaged 'properly' would certainly be nicer! Especially since those bins are 800 MB compressed shipping the entire LLVM toolchain (-:
---
Maybe enforcing clang-format use in CI wasn't such a great idea after all...