On Fri, Dec 20, 2019 at 5:19 PM Tom Stellard
<tstellar(a)redhat.com> wrote:
>
> On 12/20/2019 02:01 PM, Neal Gompa wrote:
>> On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard <tstellar(a)redhat.com> wrote:
>>>
>>> On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
>>>> Le jeu. 19 déc. 2019 à 22:44, Ben Cotton <bcotton(a)redhat.com> a
écrit :
>>>>>
>>>>>
https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bi...
>>>>>
>>>>> == Summary ==
>>>>> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
>>>>> symlinks are managed by update-alternatives.
>>>>>
>>>>> == Owner ==
>>>>> * Name: [[User:tstellar| Tom Stellard]]
>>>>> * Email: <tstellar(a)redhat.com>
>>>>>
>>>>> == Detailed Description ==
>>>>> The gcc package currently installs symlinks to /usr/bin/cc and
>>>>> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
>>>>> respectively. For this change, the gcc package will be modified so
>>>>> that update-alternatives creates and manages these symlinks.
>>>>>
>>>>> In addition to modifying the gcc package, the clang package will be
>>>>> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
>>>>> alternatives for /usr/bin/cc and /usr/bin/c++. The clang
alternatives
>>>>> will have a lower priority than the gcc alternatives, so that by
>>>>> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
>>>>> implementations.
>>>>>
>>>>> The clang package currently has a run-time dependency on gcc, so
this
>>>>> ensures that gcc will always provide the default implementation,
>>>>> because it's impossible to install clang without gcc.
>>>>>
>>>>> The only way users will be able to change the /usr/bin/cc or
>>>>> /usr/bin/c++ implementations will be by explicitly using the
>>>>> update-alternatives tool.
>>>>>
>>>>> == Benefit to Fedora ==
>>>>> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
>>>>> the default C/C++ compilers. Being able to easily swap out these
>>>>> implementation will provide a lot of flexibility within Fedora for
>>>>> doing things like:
>>>>>
>>>>> * Setting up alternative buildroots for testing.
>>>>> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
>>>>> packages to new compiler flags or to capture statistics about
compiler
>>>>> usage.
>>>>> * Letting users experiment easily with alternate compilers.
>>>>> * Easily switch between system gcc and a development version of gcc.
>>>>>
>>>>> == Scope ==
>>>>> * Proposal owners: The proposal owner will implement the necessary
>>>>> changes in the gcc and clang packages.
>>>>>
>>>>> * Other developers: The gcc maintainers will be responsible for
>>>>> reviewing and approving changes to the gcc package.
>>>>>
>>>>> * Release engineering: (a check of an impact with Release Engineering
is needed)
>>>>> * Policies and guidelines: No policies or guidelines will need to be
>>>>> updated as a result of this change.
>>>>> * Trademark approval: N/A (not needed for this Change)
>>>>>
>>>>>
>>>>> == Upgrade/compatibility impact ==
>>>>> This change should not impact upgradeability.
>>>>>
>>>>> == How To Test ==
>>>>> CI tests will be added to the gcc package to ensure that /usr/bin/cc
>>>>> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
>>>>> installed. There will also be a CI test added to the clang package
to
>>>>> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
>>>>> clang is installed.
>>>>>
>>>>> == User Experience ==
>>>>> This change will give users a much better way to experiment using
>>>>> other compilers for their own development. They will be able to
>>>>> easily switch between different compilers without having to modify
>>>>> their projects build system or make non-standard changes to their
>>>>> Fedora system.
>>>>>
>>>>> == Dependencies ==
>>>>> This change has no other dependencies besides the changes to the gcc
>>>>> and clang packages.
>>>>>
>>>>> == Contingency Plan ==
>>>>> * Contingency mechanism: (What to do? Who will do it?) Proposal
Owner
>>>>> will revert changes made to gcc and clang packages and rebuild.
>>>>> * Contingency deadline: If the changes are not complete by 2 weeks
>>>>> before the mass rebuild, then we will consider postponing to the
next
>>>>> Fedora release and back out any changes that were made.
>>>>> * Blocks release? No
>>>>> * Blocks product? None
>>>>>
>>>>> == Documentation ==
>>>>> Release notes will be added for this change.
>>>>>
>>>>> == Release Notes ==
>>>>> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
>>>>> update-alternatives. If you would like to change these symlinks to
>>>>> point to another compiler, like clang, for example, you can use
these
>>>>> commands:
>>>>>
>>>>> `update-alternatives --set cc /usr/bin/clang`
>>>>>
>>>>> `update-alternatives --set c++ /usr/bin/clang++`
>>>>
>>>> Does this process even works in RPM context ? given rpm -E %{__cc}
>>>> outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
>>>> for __cxx, __cpp)
>>>
>>> /usr/bin/cc is the default compiler for cmake projects.
>>>
>>>> If that's only supposed to work in a local compilation context (not
>>>> with RPM), what is the benefit from using alternatives rather than
>>>> export CC=clang ?
>>>
>>> I'm actually not sure how much better alternatives is that using only
CC=clang.
>>> I haven't done a full rebuild with only CC=clang and without
>>> the proposed /usr/bin/cc alternative pointing to clang to see what the
>>> numbers look like.
>>>
>>> What I have done is build all the packages that depend on gcc with
/usr/bin/cc
>>> pointing to clang and also CC=/usr/bin/cc (and the same for the c++
compilers).
>>> With these changes at least 1281 of 4271 packages still build with gcc.
>>> So the best case scenario for CC=/usr/bin/clang is that it will work for
about 70%
>>> of packages.
>>>
>>>> What about ccache ? (does it need to also be registered with
alternatives) ?
>>>>
>>>
>>> No, because if you want to use ccache with the cc compiler you run:
>>> /usr/lib64/ccache/cc
>>>
>>>
>>>> As I imagine, setting clang for a given package with such alternatives
>>>> would requires to add a BR of some clang-default that will call
>>>> alternatives in %post.
>>>> At first sight, I would dramatically prefer to have a RPM macro that
>>>> would set __cc, __cpp,__cxx and the relevant cflags ldflgas in %prep.
>>>> (and eventually another macro that would set then back to default).
>>>>
>>>
>>> This is something I have been looking at as well, but less as a solution
>>> to the "mass-rebuilds with clang" problem, and more focused on
getting
>>> a consistent experience for packages that currently do build with clang.
>>> e.g.
>>>
>>> %enable_cc_clang \
>>> %__cc clang \
>>> %__cxx clang++ \
>>> %__cpp clang-cpp \
>>> %global optflags %(echo %{optflags} | sed -e-e
's/-fstack-clash-protection//g')
>>>
>>> I think this is something packages could use in %prep, but it would be nice
to
>>> take this a step further and have something we could conditionally enable for
all packages
>>> to allow the kinds of mass rebuilds I would like to try. I just haven't
been able to
>>> figure out the best way to do this yet. If you have any suggestions for how
to
>>> make this work, I would like to hear them.
>>>
>>
>> Since Koji 1.18, you can set macros on a Koji tag, which would
>> influence the settings of the package build underneath it. If your
>> mass building is done in a Koji instance, that's a way to do it.
>> Alternatively, if you have an Open Build Service instance, you can set
>> the macro at the OBS project level, import all the Fedora sources, and
>> watch it rebuild with a different compiler automatically.
>>
>
> This is good to know. For now I'm experimenting with mock + jenkins, but
> I would like to move to koji at some point int the future.
>
> One question I have about a macro solution is how do I inject
> export CC=%__cc into the builds? Do I need to add this
> to the %prep macro?
>
You'd probably need to change %set_build_flags to add definitions for those.
Will that take affect for all builds? I only see it being used by the
%configure macro.
-Tom