1. 20
  1.  

  2. 8

    I know where the author is heading, but some browsers building with one compiler doesn’t strike me as a monoculutre. Not too long ago “everyone” (with few exceptions) using or programming for Linux was using GCC and glibc. Now people use clang, gcc and probably others (icc, etc.). So it’s more like things became a lot less of a monoculture and probably mostly for the effort of BSD and MacOS users and developers making sure that software doesn’t only work with GCC.

    Yes, it’s at least Mozilla and Chrome now using clang, but these are neither the only browsers nor is big projects focusing mostly on a defined set of tools something very uncommon.

    It’s just a guess, but I also think that it will not suddenly become a huge undertaking to try to compile Firefox with another compiler. For the Rust parts maybe, but it’s already like that.

    Not to say it’s a good thing, but there of course are up- and downsides. Especially for such a big project and especially for a project already using said implementation, helping to develop it it makes a lot more sense than in various other cases where you often only have one supported version of GCC. People using source based approaches to install packages probably know this. Compiling some version of some compilers, maybe taking hours just to compile a little piece of software that absolutely requires it.

    Other than that, even if Mozilla now uses one compiler over different platforms I hope they won’t start “ruling out” compilation with other compilers or rejecting a few lines of code to keep or establish compatibility. At least from the article it sounds like that would be the case.

    1. 10

      It makes me really appreciate the projects that require only a c89/c99 compliant compiler, like sqlite and lua. Admittedly their dependencies are also minimal, only require the c standard library iirc, but it sure is nice.

      1. 5

        I know where the author is heading, but some browsers building with one compiler doesn’t strike me as a monoculutre.

        So, even for a “toy” project, we used to build again:

        • MSVC on Windows 7, x32, x64
        • GCC on Linux, x32, x64, Itanium
        • Clang on Linux (iirc), x32, x64
        • GCC on Irix, MIPS

        And we would’ve built on an Alpha if we had one lying around–helps reveal the really thorny issues.

        The thing is, not using multiple compilers (and architectures!) helps hide bugs.

        1. 1

          Completely agree, but it’s still not unusual for projects to use one compiler for their official releases.

        2. 2

          It’s just a guess, but I also think that it will not suddenly become a huge undertaking to try to compile Firefox with another compiler.

          Suddenly? No, but I’m afraid that sooner or later having both clang and rust will become required for any platform that wants to ship firefox. Which is a shame, since Mozilla mission is:

          Our mission is to ensure the Internet is a global public resource, open and accessible to all.

          1. 1

            Suddenly? No, but I’m afraid that sooner or later having both clang and rust will become required for any platform that wants to ship firefox. Which is a shame, since Mozilla mission is:

            That’s already the case. Stylo needs clang to build. You can build some parts with GCC though.

            1. 1

              Clang and rust are both open projects, so I don’t see how it conflicts with their mission.

              1. 1

                I agree. Sadly the browser already without this has very big difference in platform support, even without that. For example WebRTC (the multimedia part), sandboxing capabilities, etc. But then of course supporting that on many platforms isn’t easy. Would be great of course, if that mission lead to a focus on not only supporting Windows, Linux and MacOS.

                Maybe someone has more insights, but something that makes me wonder a lot about how things work internally at Mozilla is that there is quite a few bug reports with ready to integrate patches remaining unanswered for often years, yet there is often changes that completely surprise users, some of them being very far away from Mozilla’s stated mission.

                While I get that not all the people working for Mozilla work in all areas it seems a bit like on the “accepting and integrating contributions” side of things there is a problem. As a foundation asking for monetary contribution it’s often a bad sign when contribution in form of work gets not taken care of. I hope Mozilla can fix this, so contributors don’t get too frustrated.

              2. 0

                So it’s more like things became a lot less of a monoculture and probably mostly for the effort of BSD and MacOS users and developers making sure that software doesn’t only work with GCC.

                Not to belittle works of BSD people, a lot of Clang portability work was done by Debian before BSD decided on Clang. https://clang.debian.net/ goes back to Clang 2.9.

                1. 3

                  FreeBSD initially imported Clang at revision r72732 into the tree June 2nd 2009:

                  https://svnweb.freebsd.org/base?view=revision&revision=193323 https://llvm.org/viewvc/llvm-project/?pathrev=72732

                  This was long before FreeBSD 9.0-RELEASE (January 2012).

                  The public documentation of the effort starts back in Feburary of 2009:

                  https://wiki.freebsd.org/action/recall/BuildingFreeBSDWithClang?action=recall&rev=2

                  As of June 2009, Clang was at version 2.5. Version 2.6 didn’t happen until October 2009.

                  http://lists.llvm.org/pipermail/llvm-announce/2009-March/000031.html http://lists.llvm.org/pipermail/llvm-announce/2009-October/000033.html

                  So this means the devs were working with the devel/llvm-devel FreeBSD port, which would have been based on HEAD or slightly newer than Clang 2.4.

                  https://docs.freebsd.org/cgi/getmsg.cgi?fetch=512205+0+/usr/local/www/mailindex/archive/2009/cvs-ports/20090222.cvs-ports

                  So I’m not sure that I believe the story that Debian was that invested in LLVM/Clang before FreeBSD was. There was no reason to; the Linux kernel had so many GCC-isms to overcome, what would be the gain? (other than some faster compiling of packages but poorer performing binaries)

                  edit: FreeBSD was trying to build all of the ports collection with Clang around May 2010. This still predates Debian by over a year

                  https://wiki.freebsd.org/action/recall/PortsAndClang?action=recall&rev=1

                  1. 1

                    Okay, wrong perspective then. From my angle I saw how tons of projects got pull requests, patches, etc. so they’d work with clang.

                    Do you have any background on why the Debian clang community even popped up early? I’d have considered them to be be philosophically closer to sticking to GCC (other than for where it’s necessary).

                    Also saw that Wikipedia actually does have a nice timeline. However it doesn’t mention where Debian starts only where it “finishes”: https://en.wikipedia.org/wiki/Clang#Status_history

                    1. 3

                      Do you have any background on why the Debian clang community even popped up early?

                      Debian is so large that it has a lot of (pardon me) crazy people. As an evidence, I submit the existence of Debian GNU/kFreeBSD.

                2. 1

                  If I read this correctly, it seems like the reason for it is mostly Rust usage. Is that correct?

                  1. 3

                    Yes, clang and rustc both use llvm - this should allow for LTO across both types of object files.