-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, 2020-06-05 at 23:11 -0600, Jeff Law 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/ > 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 :-) Just make them error by default and people will have to deal with it :) > 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 - -- Igor Raits <ignatenkobrain@xxxxxxxxxxxxxxxxx> -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7bMH8ACgkQEV1auJxc Hh5bGw//RlZibAdAUs6xXOk0A/6Xudz/GdVdf23qeO+BWyPHjQWpFfRsFEuUu6y2 P+RQ/tqdBwccACX1+H39f1mBfvx3GQfRiWbtf2aZTZ305Pc/1psh9nSvMOisa6dP LV8PnS5/tptVmjqOdALupkwA2A6XHp8VDy/EbLJ8dcV7Aag5ygEMttOdzfqg9bPJ +nha9VanxPWOsirfxpv6gb824LFFqjqZnWoOJuDqNIYnAmb/b6IbJdkqGcDcIrni 1Rz5w5Pmc4/B7SIYvmXu9BAW4rLmFPEPRmc6S+kWERLNMm03dtsYfo8D3JQo6a7W cTqa2fwoG9fy4pH6MG4/CSAbaAjxYK41lMloUCOtBVIsRjkUFt6m/snyPZd1m2mC en2292Am0dkk3H9ZcCra7/sDyerb2WrwUwgLOpUqpklmXB+r+ILTyaxRH5p/oolS T5xd1aLMJ9utBLMIINDaHnNiI/jqoO/7OEesjb3Qxu65PiLWCzYTfpEX6zlxCG+m 9yQi18QrwA5Cd9uGug+cTZlH6CeVGPIqMR6F+pNvqdkxz+yXlTkCQsQFGkuCWcpC 0wewgBpf7OXf5XcEgXM5ZbewgNrdWq8PQ5RlAuovOkAGe214gQtSt8gwESfJ2D5c aefXybm8ef+NWpHufw2DAIzqc8zXAc7AqaDPSy11tOoDtfsRSJw= =DYhd -----END PGP SIGNATURE----- _______________________________________________ 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
