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. -- 真実はいつも一つ！/ 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
