10:18 a.m.
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM. This
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.
The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.
Note this change is only for compiler selection. It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.
== Owner ==
* Name: Jeff Law
* Name: Tom Stellard
* Email: tstellar(a)redhat.com
== Detailed Description ==
The main goal here is to give a packager some freedom to select the
best compiler for their package. This policy change will allow
packagers to choose to use a non-default compiler for their package,
if they have a valid technical reason to do so. The default compiler
for Fedora is gcc or when upstream doesn't support gcc, then the
default compiler is clang. Examples of valid technical reasons to not
use the default compiler, include but are not limited to:
* The default compiler cannot build a package correctly.
* The packager needs to disable a compiler feature (e.g. LTO) in order
for the default compiler to correctly compile their package.
* The default compiler takes significantly longer to build a package.
* The default compiler is missing a feature that would benefit the package.
If this policy is implemented, it may be beneficial for packagers to
use conditional macros to switch between different compilers. This
could be useful when trying to make a comparison between the two
compilers or to make it easy to change back to the default compiler.
Therefore, in addition to updating the compiler policy, we are also
proposing to add the following macros to redhat-rpm-config to help
facilitate easily switching between different compilers:
The new macros are:
* %cc - equivalent to %__cc (C Compiler)
* %cxx - equivalent to %__cxx (C++ Compiler)
* %cpp - equivalent to %_cpp (C preprocessor)
The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:
%bcond_with toolchain_clang
%bcond_with toolchain_gcc
[https://pagure.io/packaging-committee/pull-request/1066 Pull request]
with proposed policy changes.
Note this change is only for compiler selection. It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.
It is worth noting that Clang/LLVM's implementation of
-fstack-clash-protection, which is one of Fedora's default compiler
flags, is under development and does not yet have an implementation
for AArch64.
== Feedback ==
* The original proposal stated that Fedora packagers should follow
upstream's compiler preferences, but based on feedback, the proposal
was updated to allow a packager to choose the compiler they feel is
best as long as there is a valid technical reason to do so.
== Benefit to Fedora ==
This change allows packagers more freedom to use the compiler that
produces the best version of their package, which helps to give our
users a better overall experience. Also, giving package maintainers
more freedom to select the best compiler, let's them spend more time
focusing on package improvements and less time on debugging compiler
issues.
An example of a package that could benefit from this policy is
Firefox. Upstream, the Firefox project builds primarily with
Clang/LLVM. Yet we force the Fedora package owner to find and fix
issues building with GCC then either carry those custom fixes forward
in Fedora or negotiate with upstream to get those changes upstreamed.
While this process can be helpful in finding non-portable code, this
is ultimately a poor use of the packager's time.
Additionally Fedora loses the benefit of the testing provided by other
distributions where Firefox is compiled in the same way as the
upstream project -- when issues arise the Fedora team must consider
the possibility that the problem is due to using GCC instead of
Clang/LLVM or the patches to make that possible. Again, this is a
poor use of Fedora developer's time.
Other packages that may benefit include:
* llvm/clang (currently has to disable LTO due to compilation failures).
* qemu (could take advantage of clang's CFI hardening feature).
== Scope ==
* Proposal owners:
** Update the Fedora Packaging Guidelines to reflect the policy change
and submit patch with new macros to redhat-rpm-config.
* Other developers:
** Developers that want to use a new compiler in accordance with the
policy may update their packages if they want, but there is no
required action for packagers with this change.
* Release engineering: [https://pagure.io/releng/issue/9503] (a check
of an impact with Release Engineering is needed)
** I do not believe this change requires any coordination with release
engineering. No mass rebuild is required.
* Policies and guidelines:
** Yes, the packaging guidelines certainly need to be updated for this
feature. That can happen as soon as the exact text is agreed upon.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This should not require any configuration changes or data migration,
nor should it change existing functionality.
== How To Test ==
For packages where the compiler should change, the package owner will
need to update the spec file and build the package with the new
compiler. Once done, the package's testsuite should be run (if it's
not part of the standard build process).
In general, I would think the standard Fedora QE work should be
sufficient here, perhaps with a bit of additional attention to the
affected packages. The graphical nature of some of the potentially
affected packages like Firefox and Chrome will make testing difficult
on some of Fedora's architectures.
== User Experience ==
Users should not notice any change.
== Dependencies ==
There are no dependencies, once the policy change is made, if
packagers choose to update their packages, they can do it at any time.
== Contingency Plan ==
The backup plan is trivial. We can keep the current policy in place.
* Contingency mechanism:
** It seems like we could institute the policy change anytime we
choose. But it also seems like once the policy change is in place,
packages that are going to convert should do so before beta freeze.
* Contingency deadline: Fedora can ship with this feature in an
incomplete state.
* Blocks release? No
* Blocks product? N/A
== 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 other should be
driven by the packager's preferences not by Fedora specific policy.
The only policy restriction should be that the compiler must exist in
Fedora.
== Release Notes ==
This change should not have any end user impacts nor does it strictly
require a release note. However, a short release note could be
written if FESCO or the development community thinks it would be
useful.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
10:27 a.m.
On Fri, Apr 23, 2021 at 11:18 AM Ben Cotton <bcotton(a)redhat.com> wrote:
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.
To be clear, does "given a good technical reason" imply that there is
some kind of approval process for this? Or that there's a way to
object to the compiler usage based on an insufficiently-good technical
reason?
Or is it just a way of saying "we trust you to exercise good judgment"?
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
10:42 a.m.
On Fri, Apr 23, 2021 at 3:30 PM Ben Cotton <bcotton(a)redhat.com> wrote:
Or is it just a way of saying "we trust you to exercise good
judgment"?
If one does not trust the packagers good
judgement you likely have a bigger
issue to address.
I doubt many packagers are going to
change from the default compiler
unless there is a compelling reason.
11:32 a.m.
On 4/23/21 8:27 AM, Ben Cotton wrote:
On Fri, Apr 23, 2021 at 11:18 AM Ben Cotton
<bcotton(a)redhat.com> wrote:
>
> change proposal replaces that policy with one where, given a good
> technical reason, a packager may:
> * Choose to build with their package with clang even if the upstream
> project supports gcc.
> * Choose to build with gcc even if upstream does not support it.
>
To be clear, does "given a good technical reason" imply that there is
some kind of approval process for this? Or that there's a way to
object to the compiler usage based on an insufficiently-good technical
reason?
Or is it just a way of saying "we trust you to exercise good judgment"?
I did not have in mind any kind of process for either approving the
technical justification or for auditing packages that had decided to
switch compilers to make sure their reasons are valid.
The proposed changes[1] to the packaging guidelines does require packagers
document their reasons in bugzilla, but that's it.
I think it would be better to not have an approval process, but I would
rather have this proposal + an approval process than no proposal at all.
-Tom
[1] https://pagure.io/packaging-committee/pull-request/1066
11:35 a.m.
On Fri, Apr 23, 2021 at 12:32 PM Tom Stellard <tstellar(a)redhat.com> wrote:
The proposed changes[1] to the packaging guidelines does require
packagers
document their reasons in bugzilla, but that's it.
At the risk of getting too bikesheddy, wouldn't it be better to
document it in the spec file? It seems like that would be easier to
find two years in the future when someone wants to know why a
particular package builds with compilerX instead of gcc.
Am I missing a benefit that having a tracking bug would provide?
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
8:44 a.m.
On Fri, Apr 23, 2021 at 12:35:34PM -0400, Ben Cotton wrote:
On Fri, Apr 23, 2021 at 12:32 PM Tom Stellard
<tstellar(a)redhat.com> wrote:
> The proposed changes[1] to the packaging guidelines does require packagers
> document their reasons in bugzilla, but that's it.
>
At the risk of getting too bikesheddy, wouldn't it be better to
document it in the spec file? It seems like that would be easier to
find two years in the future when someone wants to know why a
particular package builds with compilerX instead of gcc.
In the spec file, or simply in the git commit message. E.g. if there's
a bug that can be put in a comment, that's great. But if the maintainer
needs to write a longer explanation, maybe it's not worth putting it in
the spec file. I'd just leave it up to the maintainer.
Am I missing a benefit that having a tracking bug would provide?
A tracking bug would imply that there's something to be fixed. But
e.g. in case of firefox it sounds like the package might switch back
and forth over time, depending on the state of the upstream code,
without any bugzilla involvement. Mandating a tracking bug seems like
unnecessary overhead.
Zbyszek
11:38 a.m.
On 4/23/2021 10:32 AM, Tom Stellard wrote:
On 4/23/21 8:27 AM, Ben Cotton wrote:
> On Fri, Apr 23, 2021 at 11:18 AM Ben Cotton <bcotton(a)redhat.com> wrote:
>>
>> change proposal replaces that policy with one where, given a good
>> technical reason, a packager may:
>> * Choose to build with their package with clang even if the upstream
>> project supports gcc.
>> * Choose to build with gcc even if upstream does not support it.
>>
> To be clear, does "given a good technical reason" imply that there is
> some kind of approval process for this? Or that there's a way to
> object to the compiler usage based on an insufficiently-good technical
> reason?
>
> Or is it just a way of saying "we trust you to exercise good judgment"?
>
I did not have in mind any kind of process for either approving the
technical justification or for auditing packages that had decided to
switch compilers to make sure their reasons are valid.
Nor did I when I made the
original proposal. I'm of the opinion that we
should be
trusting the package maintainers and upstreams to make these kinds of
decisions.
I think it would be better to not have an approval process, but I would
rather have this proposal + an approval process than no proposal at all.
Agreed.
And just to be clear to the wider community. Tom asked to take over
pushing on
this proposal after I left Red Hat. I fully support that effort.
Thanks,
Jeff
10:37 a.m.
On Fri, Apr 23, 2021 at 11:19 AM Ben Cotton <bcotton(a)redhat.com> wrote:
An example of a package that could benefit from this policy is
Firefox. Upstream, the Firefox project builds primarily with
Clang/LLVM. Yet we force the Fedora package owner to find and fix
issues building with GCC then either carry those custom fixes forward
in Fedora or negotiate with upstream to get those changes upstreamed.
While this process can be helpful in finding non-portable code, this
is ultimately a poor use of the packager's time.
Additionally Fedora loses the benefit of the testing provided by other
distributions where Firefox is compiled in the same way as the
upstream project -- when issues arise the Fedora team must consider
the possibility that the problem is due to using GCC instead of
Clang/LLVM or the patches to make that possible. Again, this is a
poor use of Fedora developer's time.
This is not a good reason for changing the default compiler. This
makes it sound like Fedora alone is building Firefox with GCC, which
is not the case. If anything, *most* Linux distributions build it with
GCC. Even if I grant the idea that using Clang is "better", our builds
would not be very close to Mozilla's because we use different compiler
flags, system libraries, crypto policies, etc.
To me, this sounds like an excuse to avoid doing the right thing and
leveraging the toolchain that offers the highest quality code
generation (performance, security, etc.).
To be clear, I'm not necessarily outright saying this policy change is
bad, but the reasoning is weak and you're not providing a compelling
case for it. Fedora is known as the distribution where the folks
working on it help drive technical excellence in other projects, and
this sounds like you want to give up on that in this case.
I'm not particularly enthused by this Change if that's the kind of
rationale I would get for people switching compiler stacks.
--
真実はいつも一つ！/ Always, there's only one truth!
11:01 a.m.
On Fri, Apr 23, 2021 at 3:38 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
To me, this sounds like an excuse to avoid doing the right thing and
leveraging the toolchain that offers the highest quality code
generation (performance, security, etc.).
I am not in favor of switching the distro (or any
package) to the compiler flavor of the month (llvm
this week, gcc next month, llvm six months from
now, etc.) to constantly be chasing the current
best toolchain.
And neither am I in favor of requiring packagers
to use a toolchain that upstream is not interested
in supporting (anyone should be free to spend
their time on such, requiring others to do so
does not sound like a good choice to me).
11:35 a.m.
On 4/23/21 8:37 AM, Neal Gompa wrote:
On Fri, Apr 23, 2021 at 11:19 AM Ben Cotton
<bcotton(a)redhat.com> wrote:
>
> An example of a package that could benefit from this policy is
> Firefox. Upstream, the Firefox project builds primarily with
> Clang/LLVM. Yet we force the Fedora package owner to find and fix
> issues building with GCC then either carry those custom fixes forward
> in Fedora or negotiate with upstream to get those changes upstreamed.
> While this process can be helpful in finding non-portable code, this
> is ultimately a poor use of the packager's time.
>
> Additionally Fedora loses the benefit of the testing provided by other
> distributions where Firefox is compiled in the same way as the
> upstream project -- when issues arise the Fedora team must consider
> the possibility that the problem is due to using GCC instead of
> Clang/LLVM or the patches to make that possible. Again, this is a
> poor use of Fedora developer's time.
>
This is not a good reason for changing the default compiler. This
makes it sound like Fedora alone is building Firefox with GCC, which
is not the case. If anything, *most* Linux distributions build it with
GCC. Even if I grant the idea that using Clang is "better", our builds
would not be very close to Mozilla's because we use different compiler
flags, system libraries, crypto policies, etc.
To me, this sounds like an excuse to avoid doing the right thing and
leveraging the toolchain that offers the highest quality code
generation (performance, security, etc.).
To be clear, I'm not necessarily outright saying this policy change is
bad, but the reasoning is weak and you're not providing a compelling
case for it. Fedora is known as the distribution where the folks
working on it help drive technical excellence in other projects, and
this sounds like you want to give up on that in this case.
I'm not particularly enthused by this Change if that's the kind of
rationale I would get for people switching compiler stacks.
OK, I also listed some other packages (qemu, clang, llvm) that might benefit,
what do you think of those reasons? Or should I expand more on what the benefits
would be to those packages?
-Tom
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
10:37 a.m.
On Fri, Apr 23, 2021 at 3:19 PM Ben Cotton <bcotton(a)redhat.com> wrote:
Ultimately, I think what the packaging guidelines should be if
the proposal is accepted are essentially:
For C/C++ projects:
If the upstream has no stated preference for the compiler, the
packager SHOULD use the system default compiler (i.e. GCC).
If the upstream specifies a preference, in their documentation,
build, or support processes, the packager SHOULD follow
the direction of the upstream.
The packager MAY, at their discretion, choose to use
an alternative compiler that is otherwise available in
Fedora. The reasons for those override choices
MUST be documented in the .spec file.
11 a.m.
Hi,
On 4/23/21 5:37 PM, Gary Buhrmaster wrote:
On Fri, Apr 23, 2021 at 3:19 PM Ben Cotton <bcotton(a)redhat.com>
wrote:
>
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>
Ultimately, I think what the packaging guidelines should be if
the proposal is accepted are essentially:
For C/C++ projects:
If the upstream has no stated preference for the compiler, the
packager SHOULD use the system default compiler (i.e. GCC).
If the upstream specifies a preference, in their documentation,
build, or support processes, the packager SHOULD follow
the direction of the upstream.
The packager MAY, at their discretion, choose to use
an alternative compiler that is otherwise available in
Fedora. The reasons for those override choices
MUST be documented in the .spec file.
+1 I think that this is a good way to formulate the guidelines around
this.
It also matches nicely with the firefox example from the changes page,
I have heard others in this thread call the reasoning surrounding
building firefox with llvm somewhat weak (I'm paraphrasing here),
but firefox is a quite large project; and needlessly deviating from
upstream really is not doing anyone any favors here IMHO.
Regards,
Hans
11:37 a.m.
On 4/23/21 8:37 AM, Gary Buhrmaster wrote:
On Fri, Apr 23, 2021 at 3:19 PM Ben Cotton <bcotton(a)redhat.com>
wrote:
>
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>
Ultimately, I think what the packaging guidelines should be if
the proposal is accepted are essentially:
For C/C++ projects:
If the upstream has no stated preference for the compiler, the
packager SHOULD use the system default compiler (i.e. GCC).
If the upstream specifies a preference, in their documentation,
build, or support processes, the packager SHOULD follow
the direction of the upstream.
The packager MAY, at their discretion, choose to use
an alternative compiler that is otherwise available in
Fedora. The reasons for those override choices
MUST be documented in the .spec file.
The current proposed changes to the packaging guidelines require
documenting the reason in bugzilla and linking it to an umbrella
"Non-default compiler" bug. Is that sufficient?
-Tom
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
2:46 p.m.
* Gary Buhrmaster:
For C/C++ projects:
If the upstream has no stated preference for the compiler, the
packager SHOULD use the system default compiler (i.e. GCC).
If the upstream specifies a preference, in their documentation,
build, or support processes, the packager SHOULD follow
the direction of the upstream.
Are there any upstreams that specify a preference for Clang in general?
Usually it's a specific binary build of Clang, or maybe a source build
with certain patches applied (and that is downloaded and built the first
time the project is built, as some sort of bootstrapping step).
So it's not so much “use Clang”, but “use our compiler, not the system
compiler”.
Thanks,
Florian
12:07 p.m.
Swift (swift-lang) absolutely, positively requires clang. I tried
building Swift with gcc and that is a lost weekend I’d love to get
back.
Ron
On 23 Apr 2021, at 14:46, Florian Weimer wrote:
> * Gary Buhrmaster:
>
>> For C/C++ projects:
>>
>> If the upstream has no stated preference for the compiler, the
>> packager SHOULD use the system default compiler (i.e. GCC).
>>
>> If the upstream specifies a preference, in their documentation,
>> build, or support processes, the packager SHOULD follow
>> the direction of the upstream.
>
> Are there any upstreams that specify a preference for Clang in
> general?
>
> Usually it's a specific binary build of Clang, or maybe a source build
> with certain patches applied (and that is downloaded and built the
> first
> time the project is built, as some sort of bootstrapping step).
>
> So it's not so much “use Clang”, but “use our compiler, not the
> system
> compiler”.
>
> Thanks,
> Florian
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
10:57 a.m.
On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM. This
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.
The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.
Does the choice have to be consistent per package, or is it within
expectations to use different compilers on different Fedora arches ?
== Detailed Description ==
It is worth noting that Clang/LLVM's implementation of
-fstack-clash-protection, which is one of Fedora's default compiler
flags, is under development and does not yet have an implementation
for AArch64.
This would suggest need to use GCC on x86 and CLang on aarch64 within
a single package.
== Feedback ==
* The original proposal stated that Fedora packagers should follow
upstream's compiler preferences, but based on feedback, the proposal
was updated to allow a packager to choose the compiler they feel is
best as long as there is a valid technical reason to do so.
== Benefit to Fedora ==
Other packages that may benefit include:
* llvm/clang (currently has to disable LTO due to compilation failures).
* qemu (could take advantage of clang's CFI hardening feature).
Upstream QEMU has been considering whether there's any loss of
features implied by replacing GCC with use of CLang in QEMU builds.
One edge case was discovered for s390x target.
GCC has a min code generation target of z900 (hw release circa 2000),
CLang has a min code genreation target of z10 (hw release circa 2008)
This doesn't matter for compiling QEMU itself, as anyone actually
running QEMU on an s390x is likely to have z10 or newer.
It does cause a problem with firmware builds though. If QEMU wants
to emulate old hardware (qemu-system-s390x -cpu z900 ..args...),
then the firmware blob needs to have been built to target z900
which is not possible with CLang.
So if QEMU is switched to use CLang, then we will possibly need to
use GCC still for QEMU's firmware builds, or only use CLang on
certain Fedora arches.
This is quite a niche problem that's unlikely to cause issues
for most people, but its a illustration that swapping compilers
out can have unexpected consequences/complications.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
11:42 a.m.
On 4/23/21 8:57 AM, Daniel P. Berrangé wrote:
On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>
> == Summary ==
> Fedora has historically forced packages to build with GCC unless the
> upstream project for the package only supported Clang/LLVM. This
> change proposal replaces that policy with one where, given a good
> technical reason, a packager may:
> * Choose to build with their package with clang even if the upstream
> project supports gcc.
> * Choose to build with gcc even if upstream does not support it.
>
> The goal is to give the packager the ability to use their own
> technical judgement to choose the best compiler.
Does the choice have to be consistent per package, or is it within
expectations to use different compilers on different Fedora arches ?
This would be up to the packager to decide.
> == Detailed Description ==
> It is worth noting that Clang/LLVM's implementation of
> -fstack-clash-protection, which is one of Fedora's default compiler
> flags, is under development and does not yet have an implementation
> for AArch64.
This would suggest need to use GCC on x86 and CLang on aarch64 within
a single package.
Again, the packager would need to consider this when weighing the pros
and cons.
-Tom
> == Feedback ==
> * The original proposal stated that Fedora packagers should follow
> upstream's compiler preferences, but based on feedback, the proposal
> was updated to allow a packager to choose the compiler they feel is
> best as long as there is a valid technical reason to do so.
>
> == Benefit to Fedora ==
> Other packages that may benefit include:
> * llvm/clang (currently has to disable LTO due to compilation failures).
> * qemu (could take advantage of clang's CFI hardening feature).
Upstream QEMU has been considering whether there's any loss of
features implied by replacing GCC with use of CLang in QEMU builds.
One edge case was discovered for s390x target.
GCC has a min code generation target of z900 (hw release circa 2000),
CLang has a min code genreation target of z10 (hw release circa 2008)
This doesn't matter for compiling QEMU itself, as anyone actually
running QEMU on an s390x is likely to have z10 or newer.
It does cause a problem with firmware builds though. If QEMU wants
to emulate old hardware (qemu-system-s390x -cpu z900 ..args...),
then the firmware blob needs to have been built to target z900
which is not possible with CLang.
So if QEMU is switched to use CLang, then we will possibly need to
use GCC still for QEMU's firmware builds, or only use CLang on
certain Fedora arches.
This is quite a niche problem that's unlikely to cause issues
for most people, but its a illustration that swapping compilers
out can have unexpected consequences/complications.
Regards,
Daniel
11:45 a.m.
On 4/23/2021 9:57 AM, Daniel P. Berrangé wrote:
On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CompilerPolicy == Summary ==
> Fedora has historically forced packages to build with GCC unless the
> upstream project for the package only supported Clang/LLVM. This
> change proposal replaces that policy with one where, given a good
> technical reason, a packager may: * Choose to build with their
> package with clang even if the upstream project supports gcc. *
> Choose to build with gcc even if upstream does not support it. The
> goal is to give the packager the ability to use their own technical
> judgement to choose the best compiler.
Does the choice have to be consistent per package, or is it within
expectations to use different compilers on different Fedora arches ?
I'd think
most packages would be consistent, but I don't think it
necessarily needs to be policy. If a package maintainer has a good
reason to use gcc for part of the package and llvm/clang for another,
then they should be able to do that.
> == Detailed Description ==
> It is worth noting that Clang/LLVM's implementation of
> -fstack-clash-protection, which is one of Fedora's default compiler
> flags, is under development and does not yet have an implementation
> for AArch64.
This would suggest need to use GCC on x86 and CLang on aarch64 within
a single package.
Note the lack of stack-clash on aarch64 is a transient issue. It
is
being worked on, but just didn't make it into llvm12, I would expect it
to land for llvm13 (Tom's a better resource on that going forward, so if
he's got newer information than mine, believe his :-)
Upstream QEMU has been considering whether there's any loss of
features implied by replacing GCC with use of CLang in QEMU builds.
One edge case was discovered for s390x target. GCC has a min code
generation target of z900 (hw release circa 2000), CLang has a min
code genreation target of z10 (hw release circa 2008) This doesn't
matter for compiling QEMU itself, as anyone actually running QEMU on
an s390x is likely to have z10 or newer. It does cause a problem with
firmware builds though. If QEMU wants to emulate old hardware
(qemu-system-s390x -cpu z900 ..args...), then the firmware blob needs
to have been built to target z900 which is not possible with CLang. So
if QEMU is switched to use CLang, then we will possibly need to use
GCC still for QEMU's firmware builds, or only use CLang on certain
Fedora arches. This is quite a niche problem that's unlikely to cause
issues for most people, but its a illustration that swapping compilers
out can have unexpected consequences/complications.
This is a great example where
trying to force consistency doesn't make
sense and the maintainers can/should do what is best for the package and
Fedora.
jeff
11:46 a.m.
On Fri, Apr 23, 2021 at 3:57 PM Daniel P. Berrangé <berrange(a)redhat.com> wrote:
This is quite a niche problem that's unlikely to cause issues
for most people, but its a illustration that swapping compilers
out can have unexpected consequences/complications.
Presuming I am remembering my s390x history
correctly, that is a most interesting use case, as
to why someone needs to emulate a z900 which
was EOS over six years ago, and for which a
z12 should (famous last words) be able to run
all the same user level software(*) would likely
be separately interesting.
But I think most would agree that there will always
be edge cases (and s390x does seem to find
edge cases).
(*) I suppose if you have something like a z/OS
v1.7 image that was never upgraded to a z/OS
version more recent with the necessary hardware
enablements for a z12 that might be a reason.
11:27 a.m.
在 2021-04-23星期五的 11:18 -0400，Ben Cotton写道：
The policy update will also recommend that packagers use
standardized
macro names when using conditional options to control the compiler
choice:
%bcond_with toolchain_clang
%bcond_with toolchain_gcc
replacing current
%global toolchain clang
or
%global toolchain gcc
described at
https://src.fedoraproject.org/rpms/redhat-rpm-config//blob/rawhide/f/macr...
?
--
Qiyu Yan
GPG keyid: 0x4FC914F065F2DF12
11:50 a.m.
On 4/23/21 9:27 AM, Qiyu Yan wrote:
在 2021-04-23星期五的 11:18 -0400，Ben Cotton写道：
> The policy update will also recommend that packagers use standardized
> macro names when using conditional options to control the compiler
> choice:
>
> %bcond_with toolchain_clang
> %bcond_with toolchain_gcc
replacing current
%global toolchain clang
or
%global toolchain gcc
described at
https://src.fedoraproject.org/rpms/redhat-rpm-config//blob/rawhide/f/macr...
?
No, you would still need to use the toolchain macro. The bcond_with is for adding
an option that you can pass to rpmbuild or mock to control the compiler. I will
try to add a full example to the packager guidelines so this is clear, but if
you wanted to add the option to build with clang, while still using gcc by default,
then your spec file would look like this:
%bcond_with toolchain_clang
%if %{with toolchain_clang}
%global toolchain clang
%endif
-Tom
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
11:38 a.m.
On 4/23/21 11:18 AM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM. This
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.
The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.
Note this change is only for compiler selection. It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.
== Owner ==
* Name: Jeff Law
* Name: Tom Stellard
* Email: tstellar(a)redhat.com
== Detailed Description ==
The main goal here is to give a packager some freedom to select the
best compiler for their package. This policy change will allow
packagers to choose to use a non-default compiler for their package,
if they have a valid technical reason to do so. The default compiler
for Fedora is gcc or when upstream doesn't support gcc, then the
default compiler is clang. Examples of valid technical reasons to not
use the default compiler, include but are not limited to:
* The default compiler cannot build a package correctly.
* The packager needs to disable a compiler feature (e.g. LTO) in order
for the default compiler to correctly compile their package.
* The default compiler takes significantly longer to build a package.
* The default compiler is missing a feature that would benefit the package.
If this policy is implemented, it may be beneficial for packagers to
use conditional macros to switch between different compilers. This
could be useful when trying to make a comparison between the two
compilers or to make it easy to change back to the default compiler.
Therefore, in addition to updating the compiler policy, we are also
proposing to add the following macros to redhat-rpm-config to help
facilitate easily switching between different compilers:
The new macros are:
* %cc - equivalent to %__cc (C Compiler)
* %cxx - equivalent to %__cxx (C++ Compiler)
* %cpp - equivalent to %_cpp (C preprocessor)
The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:
%bcond_with toolchain_clang
%bcond_with toolchain_gcc
[https://pagure.io/packaging-committee/pull-request/1066 Pull request]
with proposed policy changes.
Note this change is only for compiler selection. It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.
It is worth noting that Clang/LLVM's implementation of
-fstack-clash-protection, which is one of Fedora's default compiler
flags, is under development and does not yet have an implementation
for AArch64.
== Feedback ==
* The original proposal stated that Fedora packagers should follow
upstream's compiler preferences, but based on feedback, the proposal
was updated to allow a packager to choose the compiler they feel is
best as long as there is a valid technical reason to do so.
== Benefit to Fedora ==
This change allows packagers more freedom to use the compiler that
produces the best version of their package, which helps to give our
users a better overall experience. Also, giving package maintainers
more freedom to select the best compiler, let's them spend more time
focusing on package improvements and less time on debugging compiler
issues.
An example of a package that could benefit from this policy is
Firefox. Upstream, the Firefox project builds primarily with
Clang/LLVM. Yet we force the Fedora package owner to find and fix
issues building with GCC then either carry those custom fixes forward
in Fedora or negotiate with upstream to get those changes upstreamed.
While this process can be helpful in finding non-portable code, this
is ultimately a poor use of the packager's time.
Additionally Fedora loses the benefit of the testing provided by other
distributions where Firefox is compiled in the same way as the
upstream project -- when issues arise the Fedora team must consider
the possibility that the problem is due to using GCC instead of
Clang/LLVM or the patches to make that possible. Again, this is a
poor use of Fedora developer's time.
Other packages that may benefit include:
* llvm/clang (currently has to disable LTO due to compilation failures).
* qemu (could take advantage of clang's CFI hardening feature).
== Scope ==
* Proposal owners:
** Update the Fedora Packaging Guidelines to reflect the policy change
and submit patch with new macros to redhat-rpm-config.
* Other developers:
** Developers that want to use a new compiler in accordance with the
policy may update their packages if they want, but there is no
required action for packagers with this change.
* Release engineering: [https://pagure.io/releng/issue/9503] (a check
of an impact with Release Engineering is needed)
** I do not believe this change requires any coordination with release
engineering. No mass rebuild is required.
* Policies and guidelines:
** Yes, the packaging guidelines certainly need to be updated for this
feature. That can happen as soon as the exact text is agreed upon.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This should not require any configuration changes or data migration,
nor should it change existing functionality.
== How To Test ==
For packages where the compiler should change, the package owner will
need to update the spec file and build the package with the new
compiler. Once done, the package's testsuite should be run (if it's
not part of the standard build process).
In general, I would think the standard Fedora QE work should be
sufficient here, perhaps with a bit of additional attention to the
affected packages. The graphical nature of some of the potentially
affected packages like Firefox and Chrome will make testing difficult
on some of Fedora's architectures.
== User Experience ==
Users should not notice any change.
== Dependencies ==
There are no dependencies, once the policy change is made, if
packagers choose to update their packages, they can do it at any time.
== Contingency Plan ==
The backup plan is trivial. We can keep the current policy in place.
* Contingency mechanism:
** It seems like we could institute the policy change anytime we
choose. But it also seems like once the policy change is in place,
packages that are going to convert should do so before beta freeze.
* Contingency deadline: Fedora can ship with this feature in an
incomplete state.
* Blocks release? No
* Blocks product? N/A
== 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 other should be
driven by the packager's preferences not by Fedora specific policy.
The only policy restriction should be that the compiler must exist in
Fedora.
Can this part be rephrased, because the policy doesn't speak about
personal preferences (like I like Clang error messages) but technical ones.
I personally think, if the package can be built with all the features of
the application and the compiler hardening features, that GCC should be
the default. To be clear things aren't built by personal preferences of
the packager.
== Release Notes ==
This change should not have any end user impacts nor does it strictly
require a release note. However, a short release note could be
written if FESCO or the development community thinks it would be
useful.
11:52 a.m.
On 4/23/21 9:38 AM, Robert Marcano via devel wrote:
On 4/23/21 11:18 AM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>
> == Summary ==
> Fedora has historically forced packages to build with GCC unless the
> upstream project for the package only supported Clang/LLVM. This
> change proposal replaces that policy with one where, given a good
> technical reason, a packager may:
> * Choose to build with their package with clang even if the upstream
> project supports gcc.
> * Choose to build with gcc even if upstream does not support it.
>
> The goal is to give the packager the ability to use their own
> technical judgement to choose the best compiler.
>
> Note this change is only for compiler selection. It does not change
> existing policies WRT runtime library selection, linker selection,
> debuggers, etc.
>
> == Owner ==
> * Name: Jeff Law
> * Name: Tom Stellard
> * Email: tstellar(a)redhat.com
>
>
> == Detailed Description ==
>
> The main goal here is to give a packager some freedom to select the
> best compiler for their package. This policy change will allow
> packagers to choose to use a non-default compiler for their package,
> if they have a valid technical reason to do so. The default compiler
> for Fedora is gcc or when upstream doesn't support gcc, then the
> default compiler is clang. Examples of valid technical reasons to not
> use the default compiler, include but are not limited to:
>
> * The default compiler cannot build a package correctly.
> * The packager needs to disable a compiler feature (e.g. LTO) in order
> for the default compiler to correctly compile their package.
> * The default compiler takes significantly longer to build a package.
> * The default compiler is missing a feature that would benefit the package.
>
> If this policy is implemented, it may be beneficial for packagers to
> use conditional macros to switch between different compilers. This
> could be useful when trying to make a comparison between the two
> compilers or to make it easy to change back to the default compiler.
> Therefore, in addition to updating the compiler policy, we are also
> proposing to add the following macros to redhat-rpm-config to help
> facilitate easily switching between different compilers:
> The new macros are:
>
> * %cc - equivalent to %__cc (C Compiler)
> * %cxx - equivalent to %__cxx (C++ Compiler)
> * %cpp - equivalent to %_cpp (C preprocessor)
>
> The policy update will also recommend that packagers use standardized
> macro names when using conditional options to control the compiler
> choice:
>
> %bcond_with toolchain_clang
> %bcond_with toolchain_gcc
>
> [https://pagure.io/packaging-committee/pull-request/1066 Pull request]
> with proposed policy changes.
>
> Note this change is only for compiler selection. It does not change
> existing policies WRT runtime library selection, linker selection,
> debuggers, etc.
>
> It is worth noting that Clang/LLVM's implementation of
> -fstack-clash-protection, which is one of Fedora's default compiler
> flags, is under development and does not yet have an implementation
> for AArch64.
>
> == Feedback ==
> * The original proposal stated that Fedora packagers should follow
> upstream's compiler preferences, but based on feedback, the proposal
> was updated to allow a packager to choose the compiler they feel is
> best as long as there is a valid technical reason to do so.
>
> == Benefit to Fedora ==
>
> This change allows packagers more freedom to use the compiler that
> produces the best version of their package, which helps to give our
> users a better overall experience. Also, giving package maintainers
> more freedom to select the best compiler, let's them spend more time
> focusing on package improvements and less time on debugging compiler
> issues.
>
> An example of a package that could benefit from this policy is
> Firefox. Upstream, the Firefox project builds primarily with
> Clang/LLVM. Yet we force the Fedora package owner to find and fix
> issues building with GCC then either carry those custom fixes forward
> in Fedora or negotiate with upstream to get those changes upstreamed.
> While this process can be helpful in finding non-portable code, this
> is ultimately a poor use of the packager's time.
>
> Additionally Fedora loses the benefit of the testing provided by other
> distributions where Firefox is compiled in the same way as the
> upstream project -- when issues arise the Fedora team must consider
> the possibility that the problem is due to using GCC instead of
> Clang/LLVM or the patches to make that possible. Again, this is a
> poor use of Fedora developer's time.
>
> Other packages that may benefit include:
> * llvm/clang (currently has to disable LTO due to compilation failures).
> * qemu (could take advantage of clang's CFI hardening feature).
>
> == Scope ==
> * Proposal owners:
> ** Update the Fedora Packaging Guidelines to reflect the policy change
> and submit patch with new macros to redhat-rpm-config.
> * Other developers:
> ** Developers that want to use a new compiler in accordance with the
> policy may update their packages if they want, but there is no
> required action for packagers with this change.
> * Release engineering: [https://pagure.io/releng/issue/9503] (a check
> of an impact with Release Engineering is needed)
> ** I do not believe this change requires any coordination with release
> engineering. No mass rebuild is required.
> * Policies and guidelines:
> ** Yes, the packaging guidelines certainly need to be updated for this
> feature. That can happen as soon as the exact text is agreed upon.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> This should not require any configuration changes or data migration,
> nor should it change existing functionality.
>
> == How To Test ==
> For packages where the compiler should change, the package owner will
> need to update the spec file and build the package with the new
> compiler. Once done, the package's testsuite should be run (if it's
> not part of the standard build process).
>
> In general, I would think the standard Fedora QE work should be
> sufficient here, perhaps with a bit of additional attention to the
> affected packages. The graphical nature of some of the potentially
> affected packages like Firefox and Chrome will make testing difficult
> on some of Fedora's architectures.
>
> == User Experience ==
> Users should not notice any change.
>
> == Dependencies ==
> There are no dependencies, once the policy change is made, if
> packagers choose to update their packages, they can do it at any time.
>
> == Contingency Plan ==
> The backup plan is trivial. We can keep the current policy in place.
>
> * Contingency mechanism:
> ** It seems like we could institute the policy change anytime we
> choose. But it also seems like once the policy change is in place,
> packages that are going to convert should do so before beta freeze.
> * Contingency deadline: Fedora can ship with this feature in an
> incomplete state.
> * Blocks release? No
> * Blocks product? N/A
>
> == 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 other should be
> driven by the packager's preferences not by Fedora specific policy.
> The only policy restriction should be that the compiler must exist in
> Fedora.
Can this part be rephrased, because the policy doesn't speak about personal
preferences (like I like Clang error messages) but technical ones.
So something like s/preferences/best technical judgement/ ?
-Tom
I personally think, if the package can be built with all the features
of the application and the compiler hardening features, that GCC should be the default. To
be clear things aren't built by personal preferences of the packager.
>
> == Release Notes ==
> This change should not have any end user impacts nor does it strictly
> require a release note. However, a short release note could be
> written if FESCO or the development community thinks it would be
> useful.
>
>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
12:01 p.m.
On 4/23/21 12:52 PM, Tom Stellard wrote:
On 4/23/21 9:38 AM, Robert Marcano via devel wrote:
> On 4/23/21 11:18 AM, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>>
>> == Summary ==
>> Fedora has historically forced packages to build with GCC unless the
>> upstream project for the package only supported Clang/LLVM. This
>> change proposal replaces that policy with one where, given a good
>> technical reason, a packager may:
>> * Choose to build with their package with clang even if the upstream
>> project supports gcc.
>> * Choose to build with gcc even if upstream does not support it.
>>
>> The goal is to give the packager the ability to use their own
>> technical judgement to choose the best compiler.
>>
>> Note this change is only for compiler selection. It does not change
>> existing policies WRT runtime library selection, linker selection,
>> debuggers, etc.
>>
>> == Owner ==
>> * Name: Jeff Law
>> * Name: Tom Stellard
>> * Email: tstellar(a)redhat.com
>>
>>
>> == Detailed Description ==
>>
>> The main goal here is to give a packager some freedom to select the
>> best compiler for their package. This policy change will allow
>> packagers to choose to use a non-default compiler for their package,
>> if they have a valid technical reason to do so. The default compiler
>> for Fedora is gcc or when upstream doesn't support gcc, then the
>> default compiler is clang. Examples of valid technical reasons to not
>> use the default compiler, include but are not limited to:
>>
>> * The default compiler cannot build a package correctly.
>> * The packager needs to disable a compiler feature (e.g. LTO) in order
>> for the default compiler to correctly compile their package.
>> * The default compiler takes significantly longer to build a package.
>> * The default compiler is missing a feature that would benefit the
>> package.
>>
>> If this policy is implemented, it may be beneficial for packagers to
>> use conditional macros to switch between different compilers. This
>> could be useful when trying to make a comparison between the two
>> compilers or to make it easy to change back to the default compiler.
>> Therefore, in addition to updating the compiler policy, we are also
>> proposing to add the following macros to redhat-rpm-config to help
>> facilitate easily switching between different compilers:
>> The new macros are:
>>
>> * %cc - equivalent to %__cc (C Compiler)
>> * %cxx - equivalent to %__cxx (C++ Compiler)
>> * %cpp - equivalent to %_cpp (C preprocessor)
>>
>> The policy update will also recommend that packagers use standardized
>> macro names when using conditional options to control the compiler
>> choice:
>>
>> %bcond_with toolchain_clang
>> %bcond_with toolchain_gcc
>>
>> [https://pagure.io/packaging-committee/pull-request/1066 Pull request]
>> with proposed policy changes.
>>
>> Note this change is only for compiler selection. It does not change
>> existing policies WRT runtime library selection, linker selection,
>> debuggers, etc.
>>
>> It is worth noting that Clang/LLVM's implementation of
>> -fstack-clash-protection, which is one of Fedora's default compiler
>> flags, is under development and does not yet have an implementation
>> for AArch64.
>>
>> == Feedback ==
>> * The original proposal stated that Fedora packagers should follow
>> upstream's compiler preferences, but based on feedback, the proposal
>> was updated to allow a packager to choose the compiler they feel is
>> best as long as there is a valid technical reason to do so.
>>
>> == Benefit to Fedora ==
>>
>> This change allows packagers more freedom to use the compiler that
>> produces the best version of their package, which helps to give our
>> users a better overall experience. Also, giving package maintainers
>> more freedom to select the best compiler, let's them spend more time
>> focusing on package improvements and less time on debugging compiler
>> issues.
>>
>> An example of a package that could benefit from this policy is
>> Firefox. Upstream, the Firefox project builds primarily with
>> Clang/LLVM. Yet we force the Fedora package owner to find and fix
>> issues building with GCC then either carry those custom fixes forward
>> in Fedora or negotiate with upstream to get those changes upstreamed.
>> While this process can be helpful in finding non-portable code, this
>> is ultimately a poor use of the packager's time.
>>
>> Additionally Fedora loses the benefit of the testing provided by other
>> distributions where Firefox is compiled in the same way as the
>> upstream project -- when issues arise the Fedora team must consider
>> the possibility that the problem is due to using GCC instead of
>> Clang/LLVM or the patches to make that possible. Again, this is a
>> poor use of Fedora developer's time.
>>
>> Other packages that may benefit include:
>> * llvm/clang (currently has to disable LTO due to compilation failures).
>> * qemu (could take advantage of clang's CFI hardening feature).
>>
>> == Scope ==
>> * Proposal owners:
>> ** Update the Fedora Packaging Guidelines to reflect the policy change
>> and submit patch with new macros to redhat-rpm-config.
>> * Other developers:
>> ** Developers that want to use a new compiler in accordance with the
>> policy may update their packages if they want, but there is no
>> required action for packagers with this change.
>> * Release engineering: [https://pagure.io/releng/issue/9503] (a check
>> of an impact with Release Engineering is needed)
>> ** I do not believe this change requires any coordination with release
>> engineering. No mass rebuild is required.
>> * Policies and guidelines:
>> ** Yes, the packaging guidelines certainly need to be updated for this
>> feature. That can happen as soon as the exact text is agreed upon.
>> * Trademark approval: N/A (not needed for this Change)
>>
>> == Upgrade/compatibility impact ==
>> This should not require any configuration changes or data migration,
>> nor should it change existing functionality.
>>
>> == How To Test ==
>> For packages where the compiler should change, the package owner will
>> need to update the spec file and build the package with the new
>> compiler. Once done, the package's testsuite should be run (if it's
>> not part of the standard build process).
>>
>> In general, I would think the standard Fedora QE work should be
>> sufficient here, perhaps with a bit of additional attention to the
>> affected packages. The graphical nature of some of the potentially
>> affected packages like Firefox and Chrome will make testing difficult
>> on some of Fedora's architectures.
>>
>> == User Experience ==
>> Users should not notice any change.
>>
>> == Dependencies ==
>> There are no dependencies, once the policy change is made, if
>> packagers choose to update their packages, they can do it at any time.
>>
>> == Contingency Plan ==
>> The backup plan is trivial. We can keep the current policy in place.
>>
>> * Contingency mechanism:
>> ** It seems like we could institute the policy change anytime we
>> choose. But it also seems like once the policy change is in place,
>> packages that are going to convert should do so before beta freeze.
>> * Contingency deadline: Fedora can ship with this feature in an
>> incomplete state.
>> * Blocks release? No
>> * Blocks product? N/A
>>
>> == 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
>> other should be
>> driven by the packager's preferences not by Fedora specific policy.
>> The only policy restriction should be that the compiler must exist in
>> Fedora.
>
> Can this part be rephrased, because the policy doesn't speak about
> personal preferences (like I like Clang error messages) but technical
> ones.
>
So something like s/preferences/best technical judgement/ ?
Sure, looks better
-Tom
> I personally think, if the package can be built with all the features
> of the application and the compiler hardening features, that GCC
> should be the default. To be clear things aren't built by personal
> preferences of the packager.
>
>>
>> == Release Notes ==
>> This change should not have any end user impacts nor does it strictly
>> require a release note. However, a short release note could be
>> written if FESCO or the development community thinks it would be
>> useful.
>>
>>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
>
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
11:44 a.m.
The policy update will also recommend that packagers use
standardized
macro names when using conditional options to control the compiler
choice:
%bcond_with toolchain_clang
%bcond_with toolchain_gcc
[...]
Note this change is only for compiler selection. It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.
Should the macro names really contain "toolchain" if they only select
the compiler? "Toolchain" suggests to me that they swap out the whole
toolchain including preprocessor, compiler, assembler, linker and
whatever else may be involved.
Björn Persson
12:03 p.m.
On 4/23/21 9:44 AM, Björn Persson wrote:
> The policy update will also recommend that packagers use
standardized
> macro names when using conditional options to control the compiler
> choice:
>
> %bcond_with toolchain_clang
> %bcond_with toolchain_gcc
[...]
> Note this change is only for compiler selection. It does not change
> existing policies WRT runtime library selection, linker selection,
> debuggers, etc.
Should the macro names really contain "toolchain" if they only select
the compiler? "Toolchain" suggests to me that they swap out the whole
toolchain including preprocessor, compiler, assembler, linker and
whatever else may be involved.
Having a consistent toolchain is important, and I wanted to name it so that
in the future there would be the flexibility to change other parts of
the toolchain if needed.
-Tom
Björn Persson
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
9 a.m.
On Fri, Apr 23, 2021 at 07:24:28PM +0200, Vitaly Zaitsev via devel wrote:
On 23.04.2021 17:18, Ben Cotton wrote:
>The goal is to give the packager the ability to use their own
>technical judgement to choose the best compiler.
+1 for this change.
Same here. I like the no-nonsense policy of "trust the maintainer" to
make the right technical decisions.
Zbyszek
10:45 a.m.
On 4/26/2021 8:00 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Apr 23, 2021 at 07:24:28PM +0200, Vitaly Zaitsev via devel
wrote:
> On 23.04.2021 17:18, Ben Cotton wrote:
>> The goal is to give the packager the ability to use their own
>> technical judgement to choose the best compiler.
> +1 for this change.
Same here. I like the no-nonsense policy of "trust the maintainer" to
make the right technical decisions.
Exactly.
Jeff
1:01 p.m.
On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
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 other should be
driven by the packager's preferences not by Fedora specific policy.
The only policy restriction should be that the compiler must exist in
Fedora.
I'll be probably repeating myself, but the two compilers are known to be
ABI incompatible in very important ways, none of the
https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207
bugs have been touched since last time this was discussed and I'm not aware
of any ABI compatibility testing between the two compilers.
So if some library packages switch compilers and programs using those
libraries don't or vice versa, this proposal has quite high risks of
introducing hard to debug debugs.
I agree that for open source software and generally for users it is useful
if there are multiple competing implementations, in this case for the
toolchain, and the competition has been IMHO quite fruitful for both GCC and
LLVM over the past years. It is also very useful if open source packages
are made portable or kept portable, so that one can use multiple compilers
to compile them, one can benefit from different diagnostics, instrumentation
etc. But I'm not sure this proposal is a step in the right direction
though, e.g. in the Firefox case that is being used as an example for this
proposal that leads in a completely different direction, a package that has
been formerly portable and supported multiple compilers will turn into a
single compiler only application and will lose its portability.
Google, Apple, BSDs don't really care about toolchain choice and they push
a single toolchain only.
Jakub
9:26 a.m.
On Fri, Apr 23 2021 at 08:01:03 PM +0200, Jakub Jelinek
<jakub(a)redhat.com> wrote:
I'll be probably repeating myself, but the two compilers are
known to
be
ABI incompatible in very important ways, none of the
https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207
bugs have been touched since last time this was discussed and I'm not
aware
of any ABI compatibility testing between the two compilers.
So if some library packages switch compilers and programs using those
libraries don't or vice versa, this proposal has quite high risks of
introducing hard to debug debugs.
Perhaps this proposal should be revisited in the future when there are
fewer scary ABI bugs.
10:51 a.m.
On 4/24/2021 8:26 AM, Michael Catanzaro wrote:
On Fri, Apr 23 2021 at 08:01:03 PM +0200, Jakub Jelinek
<jakub(a)redhat.com> wrote:
> I'll be probably repeating myself, but the two compilers are known to be
> ABI incompatible in very important ways, none of the
> https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207
>
> bugs have been touched since last time this was discussed and I'm not
> aware
> of any ABI compatibility testing between the two compilers.
> So if some library packages switch compilers and programs using those
> libraries don't or vice versa, this proposal has quite high risks of
> introducing hard to debug debugs.
Perhaps this proposal should be revisited in the future when there are
fewer scary ABI bugs.
That's not really a scary ABI bug. There's disagreement about a fairly
unusual case involving extension of 8 bit arguments and some issues with
128 bit types. I wouldn't consider either a show stopper for this proposal.
jeff
11:01 a.m.
On Mon, Apr 26, 2021 at 09:51:50AM -0600, Jeff Law wrote:
On 4/24/2021 8:26 AM, Michael Catanzaro wrote:
> On Fri, Apr 23 2021 at 08:01:03 PM +0200, Jakub Jelinek
> <jakub(a)redhat.com> wrote:
> > I'll be probably repeating myself, but the two compilers are known to be
> > ABI incompatible in very important ways, none of the
> > https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207
> >
> > bugs have been touched since last time this was discussed and I'm
> > not aware
> > of any ABI compatibility testing between the two compilers.
> > So if some library packages switch compilers and programs using those
> > libraries don't or vice versa, this proposal has quite high risks of
> > introducing hard to debug debugs.
>
> Perhaps this proposal should be revisited in the future when there are
> fewer scary ABI bugs.
That's not really a scary ABI bug. There's disagreement about a fairly
unusual case involving extension of 8 bit arguments and some issues with 128
There is disagreement on passing all 8-bit and 16-bit arguments by value on
x86_64, which in many cases works just by pure luck because GCC often
emits the extension even on the caller side where it is not mandated by the psABI,
while LLVM relies on an extension the psABI doesn't guarantee.
Several packages already ran into this in the past, I don't think we can
ignore that one.
The va_arg passing bug for __int128 is less important, sure, most packages
don't use 128-bit integers and if they do, they rarely pass it through
va_arg. But having 8-bit and 16-bit arguments on ABI boundaries is very
common.
That is one thing and the other one is that the interoperability testing
between the two compilers wasn't really performed, so besides those known
bugs there can be unknown ones.
Jakub
11:01 a.m.
Hi,
On Fri, 2021-04-23 at 20:01 +0200, Jakub Jelinek wrote:
On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
> 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 other should be
> driven by the packager's preferences not by Fedora specific policy.
> The only policy restriction should be that the compiler must exist in
> Fedora.
I'll be probably repeating myself, but the two compilers are known to
be
ABI incompatible in very important ways, none of the
https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207
bugs have been touched since last time this was discussed and I'm not
aware
of any ABI compatibility testing between the two compilers.
So if some library packages switch compilers and programs using those
libraries don't or vice versa, this proposal has quite high risks of
introducing hard to debug debugs.
So should the policy at least say that this is only allowed for
packages that don't provide libraries or other code that might be
linked against?
I agree that for open source software and generally for users it is
useful
if there are multiple competing implementations, in this case for the
toolchain, and the competition has been IMHO quite fruitful for both GCC and
LLVM over the past years. It is also very useful if open source packages
are made portable or kept portable, so that one can use multiple compilers
to compile them, one can benefit from different diagnostics, instrumentation
etc. But I'm not sure this proposal is a step in the right direction
though, e.g. in the Firefox case that is being used as an example for this
proposal that leads in a completely different direction, a package that has
been formerly portable and supported multiple compilers will turn into a
single compiler only application and will lose its portability.
Google, Apple, BSDs don't really care about toolchain choice and they push
a single toolchain only.
I cannot say I like this proposed policy very much. For the packages I
work on, elfutils, valgrind, debugedit, etc. we have enough trouble
keeping up with gcc versions, new flags, optimizations, etc. I don't
think we will have time to debug issues because packages are now also
build with another compiler. Leaving the system as a whole in a worse
state because of it.
I understand there are upstreams which are more aligned with other
toolchains, distros or a distribution model where a specific compiler
version is mandated. But even if a packages switches compilers it will
be the version as packaged in Fedora, and so some porting, testing,
etc. (because the version in Fedora will be different anyway) will be
necessary. It seem better and more consistent for packages to use the
default system compiler (gcc) unless it really cannot be build with it.
Cheers,
Mark
6:55 p.m.
Ben Cotton wrote:
Is the change owners' plan here to resubmit this same rejected change for
every single release until people get so fed up that they end up approving
it just to get it out of the way?
Sorry, but resubmitting a rejected change when nothing in the context
situation has really changed since is not a productive thing to do.
What will FESCo's workload look like if the owners of every rejected change
start doing this? Do you want me to resubmit "KDE Plasma Desktop by Default"
for every single release?
Kevin Kofler
7:37 p.m.
On 4/23/21 4:55 PM, Kevin Kofler via devel wrote:
Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
Is the change owners' plan here to resubmit this same rejected change for
every single release until people get so fed up that they end up approving
it just to get it out of the way?
This change was never rejected. It become stalled waiting for the change
owners to address some feedback from FESCo. The feedback has been addressed now,
which is why it was resubmitted.
You can review the discussion here: https://pagure.io/fesco/issue/2409
-Tom
Sorry, but resubmitting a rejected change when nothing in the
context
situation has really changed since is not a productive thing to do.
What will FESCo's workload look like if the owners of every rejected change
start doing this? Do you want me to resubmit "KDE Plasma Desktop by Default"
for every single release?
Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
9:47 p.m.
On 4/23/2021 6:37 PM, Tom Stellard wrote:
On 4/23/21 4:55 PM, Kevin Kofler via devel wrote:
> Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>
> Is the change owners' plan here to resubmit this same rejected change
> for
> every single release until people get so fed up that they end up
> approving
> it just to get it out of the way?
>
This change was never rejected. It become stalled waiting for the change
owners to address some feedback from FESCo. The feedback has been
addressed now,
which is why it was resubmitted.
Right. I just never had time to take the FESCo feedback and run the
change to completion. I'm not sure why Kevin is trying to characterize
this as a rejected change.
Jeff
4:10 a.m.
Tom Stellard wrote:
This change was never rejected. It become stalled waiting for the
change
owners to address some feedback from FESCo. The feedback has been
addressed now, which is why it was resubmitted.
Ah, then I hereby urge FESCo to finally reject this for real. The mailing
list feedback was overwhelmingly negative last time this was brought up.
It is a distribution choice which compiler produces the best results for the
distribution (best optimization, highest security, etc.). If that compiler
is GCC, then why would we want to build packages with Clang, unless there is
no other way? (Or if Clang is really better, then why do we not build the
whole distribution with Clang? But as far as I know, GCC is still the better
compiler overall, so there is no point in switching.)
Kevin Kofler
7:59 a.m.
Dne 24. 04. 21 v 11:10 Kevin Kofler via devel napsal(a):
Tom Stellard wrote:
> This change was never rejected. It become stalled waiting for the change
> owners to address some feedback from FESCo. The feedback has been
> addressed now, which is why it was resubmitted.
Ah, then I hereby urge FESCo to finally reject this for real. The mailing
list feedback was overwhelmingly negative last time this was brought up.
It is a distribution choice which compiler produces the best results for the
distribution (best optimization, highest security, etc.). If that compiler
is GCC, then why would we want to build packages with Clang, unless there is
no other way? (Or if Clang is really better, then why do we not build the
whole distribution with Clang? But as far as I know, GCC is still the better
compiler overall, so there is no point in switching.)
Kevin, I'd love to support your stance and use GCC. However, there are
reasons why we will need to consider Clang for e.g. Ruby:
https://bugzilla.redhat.com/show_bug.cgi?id=1721553
And the reason is not even that upstream favors Clang. The situation is
unfortunately not just black and white.
Vít
Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
9:20 a.m.
Vít Ondruch wrote:
Kevin, I'd love to support your stance and use GCC. However,
there are
reasons why we will need to consider Clang for e.g. Ruby:
https://bugzilla.redhat.com/show_bug.cgi?id=1721553
And the reason is not even that upstream favors Clang. The situation is
unfortunately not just black and white.
Looks like the best solution there is to disable PCH support in the Ruby
JIT.
Kevin Kofler
10:15 a.m.
Dne 26. 04. 21 v 16:20 Kevin Kofler via devel napsal(a):
Vít Ondruch wrote:
> Kevin, I'd love to support your stance and use GCC. However, there are
> reasons why we will need to consider Clang for e.g. Ruby:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1721553
>
> And the reason is not even that upstream favors Clang. The situation is
> unfortunately not just black and white.
Looks like the best solution there is to disable PCH support in the Ruby
JIT.
It is best solution if your objective is to use GCC. The other best
solution might be to disable GCC hardening (and that is the current
state in Fedora just FTR). But if your objective is hardening as well as
fast execution, disabling PCH support has potentially so high
performance cost that it turns Ruby JIT slower then the execution
without JIT.
Vít
10:43 a.m.
On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote:
Vít Ondruch wrote:
> Kevin, I'd love to support your stance and use GCC. However, there are
> reasons why we will need to consider Clang for e.g. Ruby:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1721553
>
> And the reason is not even that upstream favors Clang. The situation is
> unfortunately not just black and white.
Looks like the best solution there is to disable PCH support in the Ruby
JIT.
FWIW Vit, myself and others have already extensively discussed this
situation. Clang is really the best solution in the case of the Ruby
JIT given the various constraints in play.
Jeff
10:52 a.m.
On Mon, Apr 26, 2021 at 09:43:34AM -0600, Jeff Law wrote:
On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote:
> Vít Ondruch wrote:
> > Kevin, I'd love to support your stance and use GCC. However, there are
> > reasons why we will need to consider Clang for e.g. Ruby:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1721553
> >
> > And the reason is not even that upstream favors Clang. The situation is
> > unfortunately not just black and white.
> Looks like the best solution there is to disable PCH support in the Ruby
> JIT.
FWIW Vit, myself and others have already extensively discussed this
situation. Clang is really the best solution in the case of the Ruby JIT
given the various constraints in play.
Isn't that MIR instead?
Jakub
10:54 a.m.
On 4/26/2021 9:52 AM, Jakub Jelinek wrote:
On Mon, Apr 26, 2021 at 09:43:34AM -0600, Jeff Law wrote:
> On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote:
>> Vít Ondruch wrote:
>>> Kevin, I'd love to support your stance and use GCC. However, there are
>>> reasons why we will need to consider Clang for e.g. Ruby:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1721553
>>>
>>> And the reason is not even that upstream favors Clang. The situation is
>>> unfortunately not just black and white.
>> Looks like the best solution there is to disable PCH support in the Ruby
>> JIT.
> FWIW Vit, myself and others have already extensively discussed this
> situation. Clang is really the best solution in the case of the Ruby JIT
> given the various constraints in play.
Isn't that MIR instead?
Hopefully one day. But right now Clang is the best choice for Ruby.
jeff
10:53 a.m.
On 4/24/2021 3:10 AM, Kevin Kofler via devel wrote:
Tom Stellard wrote:
> This change was never rejected. It become stalled waiting for the change
> owners to address some feedback from FESCo. The feedback has been
> addressed now, which is why it was resubmitted.
Ah, then I hereby urge FESCo to finally reject this for real. The mailing
list feedback was overwhelmingly negative last time this was brought up.
That's not a fair characterization of the discussion. There were
concerns raised, but I wouldn't say it was "overwhelmingly negative"
It is a distribution choice which compiler produces the best results for the
distribution (best optimization, highest security, etc.). If that compiler
is GCC, then why would we want to build packages with Clang, unless there is
no other way? (Or if Clang is really better, then why do we not build the
whole distribution with Clang? But as far as I know, GCC is still the better
compiler overall, so there is no point in switching.)
There are cases where Clang is the better choice and other cases where
GCC is the better choice. The upstream projects are in the best
position to make such decisions for their projects and the Fedora
maintainers are in the best position to bring that decision into Fedora.
Jeff
2:18 p.m.
* Jeff Law:
There are cases where Clang is the better choice and other cases
where
GCC is the better choice. The upstream projects are in the best
position to make such decisions for their projects and the Fedora
maintainers are in the best position to bring that decision into
Fedora.
All Clang-preferring upstreams I know use their own build, downloaded
when the development environment is set up. The system Clang compiler
would still be not blessed by upstream. Given that people who build
with the system compiler on Linux are more likely to use GCC than Clang,
switching to a system Clang compiler may not actually result in a
more-tested build environment. Unless there is a plan to add
firefox-clang, chromium-clang &c packages, but I really can't see that
happening.
I'm not saying that the proposed Change is wrong, it's just that this
particular argument based on upstream preference is not very compelling
because upstreams do not actually prefer to use Clang system compilers.
Thanks,
Florian
3:35 p.m.
On 4/26/21 12:18 PM, Florian Weimer wrote:
* Jeff Law:
> There are cases where Clang is the better choice and other cases where
> GCC is the better choice. The upstream projects are in the best
> position to make such decisions for their projects and the Fedora
> maintainers are in the best position to bring that decision into
> Fedora.
All Clang-preferring upstreams I know use their own build, downloaded
when the development environment is set up. The system Clang compiler
would still be not blessed by upstream. Given that people who build
with the system compiler on Linux are more likely to use GCC than Clang,
switching to a system Clang compiler may not actually result in a
more-tested build environment. Unless there is a plan to add
firefox-clang, chromium-clang &c packages, but I really can't see that
happening.
I'm not saying that the proposed Change is wrong, it's just that this
particular argument based on upstream preference is not very compelling
because upstreams do not actually prefer to use Clang system compilers.
I don't really want to get in into a debate about specific packages, but
your general point that upstream preference may not be best for Fedora is a
good one, and it's why the proposal was changed from "packagers should use
upstream preference" to "packagers should use best judgement".
Given that the whole point of this proposal is that packagers should make
their own decisions, maybe the proposal owners shouldn't be making suggestions
for which packages might be better off with a different compiler. I
will consider changing this in the proposal.
-Tom
Thanks,
Florian
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
10:52 a.m.
Tom Stellard wrote:
I don't really want to get in into a debate about specific
packages, but
your general point that upstream preference may not be best for Fedora is
a good one, and it's why the proposal was changed from "packagers should
use upstream preference" to "packagers should use best judgement".
That amounts to saying that every packager can use whatever compiler they
want, which basically means we do not have a preferred compiler at all
anymore. I do not consider this acceptable.
Kevin Kofler
12:01 p.m.
On 4/27/21 8:52 AM, Kevin Kofler via devel wrote:
Tom Stellard wrote:
> I don't really want to get in into a debate about specific packages, but
> your general point that upstream preference may not be best for Fedora is
> a good one, and it's why the proposal was changed from "packagers should
> use upstream preference" to "packagers should use best judgement".
That amounts to saying that every packager can use whatever compiler they
want, which basically means we do not have a preferred compiler at all
anymore. I do not consider this acceptable.
The change proposal defines a default compiler for Fedora:
"The default compiler for Fedora is gcc or when upstream doesn't support gcc,
then the default compiler is clang. "
The actual text from the change proposal that describes when a packager may
switch from the default is:
"Given a good technical reason, a packager may:
Choose to build with their package with clang even if the upstream project supports
gcc.
Choose to build with gcc even if upstream does not support it.
"
-Tom
Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
1093
days inactive
1098
days old
48 comments
19 participants
participants (19)
-
Ben Cotton -
Björn Persson -
Daniel P. Berrangé -
Florian Weimer -
Gary Buhrmaster -
Hans de Goede -
Jakub Jelinek -
Jeff Law -
Kevin Kofler -
Mark Wielaard -
Michael Catanzaro -
Neal Gompa -
Qiyu Yan -
Robert Marcano -
Ron Olson -
Tom Stellard -
Vitaly Zaitsev -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek