On Fri, 2020-06-05 at 09:59 +0100, Jonathan Wakely wrote: > On 05/06/20 10:23 +0200, Tomáš Popela wrote: > > On Fri, Jun 5, 2020 at 9:56 AM Kevin Kofler <kevin.kofler(a)chello.at> wrote: > > > > > I am opposed to this change. Chromium and Firefox build fine with GCC. I > > > think that a distribution should be built with a consistent toolchain > > > wherever possible. > > > > > > > Kevin, that's not true at all. Maybe it looks like it builds fine for you, > > because all the fixes get to you, but I as a co-maintainer of Chromium in > > Fedora and ex-maintainer of Chromium in RHEL can say that most of the time > > I spent fixing GCC problems. Just look at the current SPEC file and search > > for gcc there.. There are several gcc related bugs - > > https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec. Or > > even better look at > > https://bugs.chromium.org/p/chromium/issues/detail?id=819294 where the GCC > > The very first one there is just a bug in Chromium: using a type > without including the header that defines it. There are several others > like that (relying on unique_ptr bing declared implicitly, relying on > nullptr_t being declared implicitly ...) > > Those are upstream bugs and should be fixed. Period. Yup. And what you're hitting on is a real issue. Monocultures are generally bad. All the world is a vax, all the world is a sparc (running solaris), all the world is x86-linux, everything builds with gcc and so-on. There's a secondary problem you're touching on and that's engagement to get stuff fixed correctly. Finding the balance there can be hard too, particularly if the developer doesn't know *how* to engage a particular community. I run into this myself and it can be frustrating. So while I'd rather see better engagement on bugs, I do understand why a Chromium developer might not have reported issues to the GCC community. In an ideal world, everything would build with both compilers, folks would review and fix all the diagnostics they generate. Selection of which binaries would essentially happen at the end of the build cycle with the decision made on a per- package basis. However, I strongly suspect the pitchforks would be out if we tried to go that far :-) [ ... ] > tl;dr This is a chromium problem, not just a GCC problem. Fixing those > portability problems is an investment and reduces technical debt. It's a balance and judgment call. For Chromium and Firefox the cost of maintaining GCC as a build toolchain has apparently outgrown the cost of non- portable code. Of course the cost of the latter usually does show up until much later in a product's lifecycle, so only time will tell if those projects have made a good decision. 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
