On Fri, 2020-06-05 at 12:27 +0000, devel-request@xxxxxxxxxxxxxxxxxxxxxxx wrote: > > On Fri, 2020-06-05 at 10:14 +0100, Jonathan Wakely wrote: > > On 04/06/20 16:30 -0400, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/CompilerPolicy > > [snip] > > > == Documentation == > > > Several years ago Red Hat's tools team championed for Fedora policy > > > to strongly > > > discourage the use of LLVM/Clang for package building. Exceptions > > > were made for > > > packages that could only be built with Clang/LLVM: > > > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler > > > > > > > > > At that point in history Red Hat had no Clang/LLVM engineers or > > > expertise. In > > > fact, the LLVM packages were actually maintained by an engineer on > > > the desktop > > > team (they had a hard requirement for llvm-pipe, so they got to own > > > the > > > Clang/LLVM bits). The policy essentially was a risk management > > > strategy for > > > Fedora. > > > > > > Times have changed and as a result we should revisit that Fedora > > > policy. > > > > > > The Red Hat tools team believes that LLVM/Clang and GCC should be > > > considered equals from > > > a Fedora policy standpoint. Selection of one toolchain over the > > > should should be > > > > s/should should be/other should be/ > > > > > driven by the upstream project's preferences not by Fedora specific > > > policy. > > > > I think this needs to be clear that we're talking about the compiler > > here, not the C++ standard library. Fedora has no libc++ expertise > > I'm > > aware of. > > > > I think we want to be a lot more cautious about using libc++, because > > it would potentially require large parts of the C++ stack to be built > > twice and installed in parallel (think Python 2 and Python 3). For > > example if your package depends on Boost and you want to use libc++ > > then you need Boost rebuilt. Similarly for any C++ library, Qt, > > gtkmm, > > etc. etc. > > > > And I do not intend to offer C++ support for people who decide to use > > Clang + libc++ but don't try to resolve their own build failures :) > > > > > > > What that means in practice is that if the project upstream prefers > > > Clang/LLVM, > > > then Fedora should in turn be using Clang/LLVM to build those > > > packages. As a > > > concrete example, let's consider Chromium. > > > > > > Chromium upstream has been building with Clang/LLVM for several > > > years. > > > Yet policy > > > has forced Fedora package owners to shoulder a significant burden > > > to make it > > > build with GCC. Furthermore, Fedora does not get as much benefit > > > at it could by > > > forcing Chromium to be built with GCC since most other instances > > > are built with > > > Clang/LLVM. > > > > > > By changing policy Fedora package maintainers no longer have to > > > waste > > > time trying > > > to make Chromium build/work with GCC and Fedora gains additional > > > "many eyes" and > > > "many users" benefits by relying on the same tools to build Chrome > > > as the > > > upstream developers and other distributions. > > > > > > Additionally, if an upstream project currently uses GCC, but > > > switches to > > > Clang/LLVM (or vice-versa), then the package in Fedora should > > > switch > > > in a similar > > > manner. The only policy restriction should be that the compiler > > > must > > > exist in Fedora. > > > > If upstream supports both compilers, that's probably not a good > > reason > > to change anything in Fedora. > > > > > In some ways this means there is no "default" compiler for Fedora. > > > The default > > > is whatever the upstream project supports/recommends. However, > > > there are > > > probably many packages with upstreams that are ambivalent about > > > their compiler > > > choice. For those packages I would recommend we keep the status > > > quo at the > > > current time. For a package with a dead upstream, the Fedora > > > packager should be > > > able to select the compiler they want to use for the package. > > > > I would prefer the policy to have a stronger preference for GCC when > > there is no good reason to change. Currently it's worded like keeping > > the status quo is Jeff's personal opinion. I would like it to be > > policy. > > > > i.e. where the current policy is that you *must* use GCC, unless > > granted a specific exception, I would like it to be that you *should* > > use GCC unless there's a good reason not to. > > > > "Upstream only builds+tests with Clang and using GCC requires lots of > > work from the Fedora maintainer to fix problems that upstream don't > > care about" is a good reason to use Clang. > > > > "I've heard the cool kids use Clang, so I changed my package to use > > it, but I don't know what these compiler errors mean" is not a good > > reason to switch if it just makes work for other people. > > > > When there is a real advantage to using a particular compiler, I do > > think it's good that packagers should be able to make an informed > > choice. > > Fully agree here, we should be still preferring GCC and not allow > changing compilers just because it seems cool. Precisely. I don't believe we should just blindly change compilers for any project. The change really should be driven by the upstream community. They're generally in the best position to determine what toolchain best suits their needs. If the upstream community for a give package doesn't have a strong preference, then things should stay as-is. I'd love to see that in any updated policy as well. > > > Ideally we'd have CI building (nearly) everything with *both* GCC and > > Clang, and finding and fixing problems in packages and in both > > compilers. But that's probably not realistic (yet?). > > Well, building itself is not that interesting but running some > benchmarks periodically with clang / gcc compiled binaries would be > interesting. Though this definitely is huge amount of work and we > should not block this change on this. Building is certainly interesting as the set of diagnostics you get from the toolchains is different and I would consider doing so best practice. However, we don't have a strong policy of addressing diagnostics in Fedora and thus building with both has little value at this time. I'd like to change that, but it's out of scope right now. Benchmarking for performance seems to me like something an upstream project should be doing as they evaluate their toolchain choices. Ultimately the only benchmark that matters is your own code ;-) jeff > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
