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. Thanks, Tom _______________________________________________ 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
