On Fri, 2020-06-05 at 21:49 +0200, Jakub Jelinek wrote: > On Fri, Jun 05, 2020 at 01:36:37PM -0600, Jeff Law wrote: > > > On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote: > > > ... > > > > > > Sadly some upstreams insist on clang just because they like it more, > > > without any technical reason. The question that comes to my mind: > > > Should we still try to convince upstreams to use GCC in such cases or > > > not? > > It happens (choosing Clang because they like it) and while we can (and have) > > engaged upstreams on this topic and I suspect we will continue to do so in some > > cases. > > > > But in the end I think we still have to respect the upstream project's choices, > > even if it's just because they like Clang/LLVM more than GCC. > > Why? Shouldn't the Fedora maintainers be able to decide this? If they have been > using GCC for years and it hasn't been an obstackle for them, why should > they switch? Maintainers aren't static and when the maintainer chooses to go a different direction than upstream, then there's a cost to be paid. While it may work for a particular maintainer to do something different for their package, what about the poor person who takes the package over when the original maintainer leaves or someone who has to pick it up to deal with a CVE while the maintainer is on PTO. Not everyone is as toolchain savvy as you, or is able to understand the intent of code as well, or is likely to have the longevity you've had, etc. You're at a level that most developers will never achieve in their career. Think about folks that are less experienced, or with fewer natural gifts, etc and sometimes you come up with different answers. Conceptually, IHMO, packages in Fedora should be as close to upstream as possible. Toolchain selection is a piece of that. The major exception in my mind is flag selection, particularly due to the need to enforce consistent security hardening, distro-wide optimizations, or ISA selection to ensure the bits run everywhere they're supposed to. > If I understand the LO case, it is just that LO sometimes uses the Skia > library which is written by Google and Google likes compiler monoculture and > is using heavily #ifdef __clang__ in it and using the clang variants of the > generic vectors guarded by that, and as fallback just doesn't use simd. > I believe Honza Hubicka had quite some changes for Skia, not sure if they went > upstream already or not. > But the maintainers should be able to choose, build just Skia with clang and > rest of LO with GCC, or everything with GCC and with help from us get Skia > into shape for better portability (that would be ideal, but of course can > mean more hopefully one time work), or build all of it with Clang/LLVM. Again, I'd fall back to the "what does upstream do". DOing something different should require strong technical justification and none of the stuff I've seen discussed around LO, Firefox or Chromium would meet that bar IMHO. 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
