On Tue, 2020-06-09 at 08:57 +0200, Nicolas Mailhot wrote: > Le lundi 08 juin 2020 à 09:48 -0600, Jeff Law a écrit : > > I put faith in both the upstreams and packagers to do the right thing > > for their project. Right now Fedora policy does exactly the opposite > > by forcing everyone to use GCC rather than making an informed, per > > project, decision. > > Look, 9∕10th of the times the "informed" upstream decision is just one > poor dev who slapped some build automation using the first compiler he > though of in quick and dirty mode so he could get back to coding as > fast as possible (sometimes, for another system than Linux, that was > grandfathered for Linux builds later, because who cares about those > things in real life). That certainly happens. I get to see both the good and the bad in terms of code quality, build systems, etc for Fedora. I won't call out any packages by name, but some of the stuff I've seen is of such poor quality that the author should be embarrassed. Thankfully these packages are likely only being used by one person and when it crashes because they've written high school quality code the impact is minimal. In other cases the upstream code is exceedingly good and thorough in terms of trying to do the right thing. So much in fact that it obscures the intent of the code so much that GCC can't actually analyze it fully and GCC spits out a false positive diagnostic. I've seen code put in to shut up things like Coverity that is horribly wrong and introduces new buffer overflows and undefined behavior. But I'm also experienced enough to know there's a lot of selection bias that goes on here. I see the old crappy code because it breaks and breaks often as we update from one version of gcc to the next. I see the well written, security sensitive code as well because gcc tries hard to issue diagnostics for potentially problematic code -- and it's precisely those codes that end up being complex as the developer tries to do the right thing and avoid undefined behavior in the first place. > > Sifting through build systems, possible compilers and compiler options > takes an enormous amount of care and knowledge which is lacking in the > average upstream project. Only giants like Chrome or Mozilla can afford > to do this level of analysis. I’m not even putting LibreOffice in this > class – they switched compiler for a subset of their codebase, probably > just to workaround a perf regression quickly in the hope that someone > would analyse the regression causes later. Not even sure they bothered > to check if the regression happened with all possible build flags > combinations, one report of "it’s faster using compiler XXX" (one > version of one compiler on one system with one set of build flags), is > usually sufficient for this kind of switch. No doubt. It does take work, often significant amounts of work. I get to see it all because of the work I do to try and make sure GCC and Fedora work well together results in me looking at hundreds or thousands of build issues every cycle. I have to figure out the build system, intent of the sources or testcases, then debug what's going on in the package and what should be going on in whatever part is failing, then make a decision about whether or not the issue is a package problem or a compiler problem, then fix the problem or give someone else enough state to do so. Rinse and repeat. > > Arguably, in Fedora the average packager can not afford it either – he > relies 100% on the default compiler flags defined by the gcc team. And > the gcc team can afford to look at those closely only because of the > mass effect of a whole distribution codebase that is fully built using > the same compiler and flags everywhere. And that's not changing. The GCC team still selects default flags, we still analyze build issues to ensure things go as smoothly as possible, we still look for ways to make things work faster, compiler to smaller code, etc. We also work closely with our LLVM team to make sure we're doing the right thing for the Clang/LLVM toolchain as well. > > “Upstream knows better” – for upstream’s own code sure, but for > everything else (legalities, the tird party code they depend on, build > systems and automation) certainly not. I'd disagree, particularly around build systems and the compiler components within build systems. THere's always exceptions, but by in large I believe upstreams are in the best position to select the compiler toolchains. Jeff _______________________________________________ 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
