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/ Fixed. > > > 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 :) Agreed 100%. Based on comments from others I've already updated the proposal to hopefully clarify this change is strictly the compiler and does not include the runtime. Trying to support libc++ would be a compatibility nightmare. I do believe one day we'll need to do something there, but now isn't the time to open that discussion. > > > > 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. If they're on equal footing upstream, then no I don't think changing would be the right thing to do. I don't think that's really the case for Firefox or Chromium. I'm less familiar with the LibreOffice situation, so I won't try to give an opinion there. Perhaps in this case we leave it up to the Fedora packager? > > > 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. So that text was literally copy and pasted from internal discussions. So, yea, it's my opinion and I think it's one of the option questions this body needs to hammer out to more precisely define any updated policy. My preference would be to stick with GCC when upstream has no recommendations/support policy around supported compilers to avoid unnecessary churn. I would also be willing to support the Fedora packager's discretion if they can make a case for it and upstream has no strong preference. For example a packager may simply be more familiar with Clang/LLVM and thus more adept at understanding what a particular diagnostic means and how to fix it properly. Changing, but then expecting you, Tom, Jason or someone else to fix or interpret diagnostics for them no longer working code isn't reasonable IMHO. > > 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. I could live with this so long as we define "good reason" to include upstream preferring one toolchain over the other. > > "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. I think we're actually largely in agreement. I don't want change for change's sake or because the cool developers use X Y or Z. I want the change to have a real technical reason behind it. > > 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?). You may remember me advocating for this in our meeting in Montreal :-) So, yea, I'd be totally on board with something like this. I think Tillman was also interested and even floated the idea of finding additional Fedora builder resources to facilitate this kind of scheme. The big problem then becomes getting packagers to address the diagnostics. I've been disappointed at how many packages are ignoring diagnostics (particularly those with security implications) and I'm actively looking at schemes to improve this situation :-) 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
