On Fri, Dec 20, 2019 at 5:25 PM Tom Stellard <tstellar@xxxxxxxxxx> wrote: > > On 12/20/2019 03:20 PM, Neal Gompa wrote: > > On Fri, Dec 20, 2019 at 5:19 PM Tom Stellard <tstellar@xxxxxxxxxx> wrote: > >> > >> On 12/20/2019 02:01 PM, Neal Gompa wrote: > >>> On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard <tstellar@xxxxxxxxxx> wrote: > >>>> > >>>> On 12/20/2019 03:33 AM, Nicolas Chauvet wrote: > >>>>> Le jeu. 19 déc. 2019 à 22:44, Ben Cotton <bcotton@xxxxxxxxxx> a écrit : > >>>>>> > >>>>>> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc > >>>>>> > >>>>>> == 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@xxxxxxxxxx> > >>>>>> > >>>>>> == 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! _______________________________________________ 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
