On 12/20/2019 03:20 PM, Neal Gompa wrote:
> 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.
I believe it's also used by the %cmake and %meson macros.
--
真実はいつも一つ!/ Always, there's only one truth!