Allowing cc/c++ To Be More Easily Changed Out Has Been Deferred To Fedora 34

[phoronix]

Phoronix: Allowing cc/c++ To Be More Easily Changed Out Has Been Deferred To Fedora 34

Proposed last year for Fedora 32 was aiming to make it easier to swap out GCC for other alternate compilers (like Clang) by using the update-alternatives functionality on Fedora for handling the /usr/bin/cc and /usr/bin/c++ symbolic links. That work was deferred to Fedora 33 as it wasn't completed in time while now it's been deferred yet again to Fedora 34 next year...

http://www.phoronix.com/scan.php?page=news_item&px=F34-Delayed-CC-Alternatives

[Britoid]

I was actually looking forward to this because of Silverblue.

[rene]

what a feature the wold was waiting for, ... not. Obviously that should have been plumbed a decade or two ago, … however, what stop you from build with make CC=clang CXX=clang+++? https://www.youtube.com/watch?v=NMQrnVDf-rY

[skeevy420]

what a feature the wold was waiting for, ... not. Obviously that should have been plumbed a decade or two ago, … however, what stop you from build with make CC=clang CXX=clang+++? https://www.youtube.com/watch?v=NMQrnVDf-rY

Sometimes a project or its build system is setup in a manner where it will ignore the user and use the system defaults.

[rene]

Sometimes a project or its build system is setup in a manner where it will ignore the user and use the system defaults.

a) can you name one? b) nothing sed or vi would not solve – easy plumbing ;-)

[skeevy420]

a) can you name one? b) nothing sed or vi would not solve – easy plumbing ;-)

Off the top of my head, no. It's been a while. IIRC, parts of Proton are like that but I believe those are bash scripts calling various make commands directly and setting anything globally wouldn't have mattered.

I think this is about keeping up with Ubuntu more than anything. Ubuntu already does this and I've come across guides using update-alternative in the past...but being an Arch user when I read them I didn't pay attention to them because they weren't relevant for me back then.

[RahulSundaram]

a) can you name one? b) nothing sed or vi would not solve – easy plumbing ;-)

a) there are plenty of examples you run into when you are a distribution. here is one https://github.com/pytorch/pytorch/issues/8107

b) The purpose of alternatives is that you never have to worry about exceptions or bugs and how to handle them. You don't have to override and you don't have to muck around with vi or sed and you can switch back and forth trivially

[rene]

a) there are plenty of examples you run into when you are a distribution. here is one https://github.com/pytorch/pytorch/issues/8107

I am a distribution (https://t2sde.org) and no example comes to mind.

b) The purpose of alternatives is that you never have to worry about exceptions or bugs and how to handle them. You don't have to override and you don't have to muck around with vi or sed and you can switch back and forth trivially

Wishfull thinking, if something is hardcoded it more likely hardcoded gcc anyways, so your fancy alternatives likely does not help you either ;-)

[You-]

Wishfull thinking, if something is hardcoded it more likely hardcoded gcc anyways, so your fancy alternatives likely does not help you either ;-)

The main package for which this will be considered, Firefox, has a good chance it will go LLVM only.

[zerothruster]

I am a distribution (https://t2sde.org) and no example comes to mind.



Wishfull thinking, if something is hardcoded it more likely hardcoded gcc anyways, so your fancy alternatives likely does not help you either ;-)

I prefer to use gcc. And I don't use 'alternatives'. My default compiler is gcc but the following packages need CC, CXX or similar specified in the environment to avoid to avoid using clang: cups, mozilla-derivatives (firefox, js68 from firefox-68, seamonkey - ditto thunderbird except that builds much more slowly and larger with gcc), node-js, potrace, vlc.