Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?
The experts in a particular codebase are going to be the upstream maintainers,
not Fedora packagers.   Sometimes those are the same developers, but often they
are not.  In the former case, obviously the right thing will "just happen".  In
the latter the upstream is the right place to be making this decision.


> 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.
If I read that patch correctly, they were prefering Clang/LLVM just in the skia
library and not across the whole project -- which also seems like a valid case to
me.  If part of a project wants to use Clang/LLVM and another part is using GCC,
then that's the project's decision.  That decision has consequences (like the
inability to LTO across those components), but again, the upstream project is
going to be in the  best position to make that decision.



> 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.
I would agree if you inserted "upstream" before "maintainers" here :-)

I do think that we could/should have an exception policy where the Fedora
packager could make a case to do something different from upstream WRT toolchain
selection.  But that should be an exceptional case, not the norm.

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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux