|
|
Log in / Subscribe / Register

Rethinking Fedora's compiler policy

Rethinking Fedora's compiler policy

Posted Apr 29, 2021 21:27 UTC (Thu) by josh (subscriber, #17465)
In reply to: Rethinking Fedora's compiler policy by nim-nim
Parent article: Rethinking Fedora's compiler policy

I've seen plenty of projects that only support building with GCC, because they use GCC extensions. And ultimately, that doesn't tend to get fixed by patching the project, it tends to get fixed by adding the requisite feature to clang.

Until recently, the Linux kernel was one of those projects. People have put extensive work into making the Linux kernel work with clang. That work includes people adding features to clang, and people committing to ongoing maintenance of clang support in the Linux kernel. And it does add complexity to the Linux kernel; that complexity is just deemed worthwhile because clang adds useful features as well.

So, sure, if you have the time and bandwidth to work with upstream and commit to helping upstream maintain support for another compiler, and upstream is willing to maintain the complexity added by supporting another compiler, then it might be reasonable downstream to use that compiler. If you don't have that time or bandwidth, you aren't prepared to commit to maintaining it upstream, or it adds enough complexity that upstream isn't willing to maintain it, then it might not be reasonable to expect.

The same arguments apply to supporting less common architectures, or operating systems. Someone has to not only do the work, but maintain the work, and upstream has to be willing to deal with any added complexity.


to post comments


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds