Fedora decided to use gcc as *the* compiler [1], and frankly, we have enough trouble getting packages to compile without trying to support more than one compiler (vide the lass mass rebuild). What you propose: building with a different compiler, makes sense mostly at the level of a single package. For example, I often build systemd with clang, because although gcc generally provides better diagnostics, clang does catch some different errors. But to make use of this (and to diagnose failures), requires pretty intimate knowledge about the package and the code being compiled. Thus, its something that a maintainer might do for their package, or even more likely, something that upstream will use in development. Doing this at the level of the whole distro is pointless, we already get quite a few build warnings from gcc, and almost nobody looks at them. In effect, my feeling is that although what you propose might be useful sometimes, that "sometimes" would not be very often, and the required complexity is not worth it. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler Zbyszek On Sun, Feb 18, 2018 at 10:10:46AM +0000, Tomasz Kłoczko wrote: > On 16 February 2018 at 11:56, Jan Kurik <jkurik@xxxxxxxxxx> wrote: > [..] > > ** List of deliverables: > > N/A (not a System Wide Change) > > > > * Policies and guidelines: > > Nothing needed, guidelines already have paragraph about listing all > > required BuildRequires. > > As definitely proposed change will create the whole wave of small > changes adding at least one new BuildRequires I just started thinking > about going slightly deeper (but only a bit deeper ;) ). > > When gcc or other compilers are no longer part of the core build env > suit/env as you mention it is necessary to add it straight in > BuildRequires for example gcc. > That is OK. > > Q: does it really needs to be gcc? What about clang? > A: theoretically it does not need to be gcc .. especially as macros > like %cmake, %configure are injecting over CC, CXX and other variables > exact commands. > > As long as none of the macros like %cmake or %cobfigure has straight > dependency and are not forcing to use gcc (those macros are using > other macros like %{__cc}) already it possible to test build package > written in C using C++ compiler to for example expose some set of > compile warnings generated by C++ compiler or .. use clang. > Build the whole package with use some C code security scanners? No > problem. It is possible to do this without touching spec file. > > OK, so .. at the moment macros like: > > %__cc gcc > %__cpp gcc -E > %__cxx g++ > > are defined in /usr/lib/macros which is part of the rpm. > If those macros will be removed from this file and moved to > /usr/lib/macros.d/macros.{gcc,clang} it should be possible to provide > the platform which will open the whole spectrum of completely new > possibilities with some minimal changes in whole build env and no > other changes in all specs. > Only weak point in above is how to force use gcc if both gcc and clang > will be installed (which will be quite typical in case all packagers > private build envs). > However, I think that even this is a very small obstacle which can be > easily handled. > > Now by default %/{__cc} is provided by gcc but if here it will be > introduced small flexible it should be possible to control which > compiler should be used even if in packagers build system will be > installed both gcc and clang by simple few changes in ~.rpmrc or on > Fedora build systems in ~mock/.rpmrc file. > > So maybe instead: > > BuildRequires: gcc > > better would be to use: > > BuildRequires: %{__cc} > > or: > > BuildRequires: c-compiler > > ?? > if both gcc and clang will have: > > Provides: c-compiler > > still it will be possible installed gcc and clang without conflicts. > I'm sure that above it is not complete idea and few small bits still > are missing. > > I think that we should hold for few seconds and consider change a bit > this proposal to pen those possibilities. > > > Comments? > > kloczek > -- > Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
