-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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. > 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. > _______________________________________________ > 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----- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aNw8ACgkQEV1auJxc Hh5q1xAAs2zy7F/XnKRoAU6461WLo//0MF1sbzwsTesn6+ZHDgG/S12QHQw6U2du qvdKjBc3MKLTSnOZk1okhVrP2jQUJTSvxjBMnWBc/nsvmZCCrE5juZaMtPAJgxXx JZPVywdtccMv9PcHtmaG6fCoCSi+HiEOlLRfbwobZPpmG+9WiIDvOV+sErLFRYbW 7CJeRqOu9c1Nf8TuZgiRemw1xAK1FcKWM+PCvxZi/ZjL1lmuasY0dJL89YOeaWfL NIFo8zOFigCiQatjMIS0yFwcFJGRNIml3/u+/WuNJE8y8FCMohsmUHVcoHVe1PZv 1JHJS34xWOhLoi/PhDfzlFD+awWQiap+Sy35uwsVFBydGLVArYD7BFSz6X5mrbNq dP2RW1xF5LjPNA42rcddF199SxfEZCkK+ADlCG9/fjxbBk15T11h+q/F+9itWuIU 1T/PGl4h/wOQdgr/eU/SlmvBf++lMRQV2el0l92tbsJ5SogyXZEC/x5S6qAyqrkv Y6wFW84V0qK1wBvFlG9xkRHhWil31CPaOe08pUUzkxp5RYFDah+gxE9p4DcbY6jE zkETeJw23nHEJeR+9GIVsy7OxZHRNFNMW6bZgenDCKdYhHSr9ZjKrwgKjZvsmW+A VE9jh5oMMISgBBOJj0OxpMikZK+TXRabifr2KqSXlAC7kQ59hT0= =SpbG -----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
