https://bugzilla.redhat.com/show_bug.cgi?id=2277782
--- Comment #2 from Alyssa Rosenzweig <alyssa(a)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...
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2277782
Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=rep...