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@xxxxxxxxxx
== 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@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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
