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. 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?). _______________________________________________ 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
