Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Chromium Firefox Open Source Software Build

Building All the Major Open-Source Web Browsers 106

Posted by Soulskill from the who-needs-packages dept.
An anonymous reader writes: Cristophe de Dinechin, long-time software developer, has an interesting article on the processes involved in building the major browsers. From the article:

"Mozilla Firefox, Chromium (the open-source variant of Chrome) and WebKit (the basis for Safari) are all great examples of open-source software. The Qt project has a simple webkit-based web browser in their examples. So that's at least four different open-source web browsers to choose from. But what does it take to actually build them? The TL;DR answer is that these are complex pieces of software, each of them with rather idiosyncratic build systems, and that you should consider 100GB of disk space to build all the browsers, a few hours of download, and be prepared to learn lots of new, rather specific tools."
This discussion has been archived. No new comments can be posted.

Building All the Major Open-Source Web Browsers More

Building All the Major Open-Source Web Browsers

Comments Filter:

  • Build (Score:1)

    by Anonymous Coward

    cd /usr/ports/www/firefox && make install clean
    cd /usr/ports/www/chromium && make install clean
    cd /usr/ports/www/webkit-gtk3 && make install clean

    Wasn't that hard.

    • C:\Users\ABG>cd /usr/ports/www/firefox && make install clean
      The system cannot find the path specified.

      I guess those of us using Windows still aren't going to be contributing much any time soon. :-(

      • You have to install the compiler repos just like a Linux user would.

        You also might be interested in Cygwin:
        http://cygwin.com/ [cygwin.com]

        and Windows Services for UNIX:
        http://www.microsoft.com/en-us... [microsoft.com]

        • Re:Build (Score:5, Interesting)

          by Anonymous Brave Guy ( 457657 ) on Saturday October 25, 2014 @05:19PM (#48231275)

          Unfortunately, like too many OSS projects, Mozilla seems to think it will have the only cygwin instance on my system. It therefore assumes it's OK for me to just reconfigure the entire universe according to its preferences, redefine all my paths so the MozillaBuild version of everything takes precedence over anything else that's already installed, and so on.

          In reality, I have various other tools installed that bridge the Windows and Linux worlds, including things fundamental to using various version control systems and other everyday needs. As much as I'd like to support Mozilla and be willing to contribute a bit here and there, I'm not going to compromise the development machine I also use to earn my pay cheque just to get their esoteric build system to work.

          • Re: (Score:2)

            by dryeo ( 100693 )

            How hard is it to write a script to adjust your path, open a cmd window and type in mozenv.cmd?

            • If it were just one little thing like a path that needed to be customised, obviously it would be trivial to do so. Unfortunately, with the kind of project that has a whole custom build system and wants its exact required version of everything under the sun installed, it is rarely so simple. For example, the consequences of having two different versions of a VCS installed on your system could be horrible if there had been a change in the internal source repository representation from one to the other and you

              • Re: (Score:2)

                by dryeo ( 100693 )

                According to https://developer.mozilla.org/... [mozilla.org] you just need to make sure that c:\mozilla-build comes before cygwin on the PATH and run something like start-shell-msvc2013.bat (various bat files depending on msvc version). Pretty simple.
                Mozilla doesn't require exact versions of everything, it just needs working versions of everything and if you're worried about problems with Mercurial, just use your default Python 2.7 and corresponding hg.exe.
                Best to start by following their exact instructions then pruning

                • No doubt it is possible set it all up and get it working eventually. I've worked on projects with much more complicated set-ups than what you describe that build on a lot more different platforms than Firefox, and once you've figured out the details things generally run OK.

                  That said, there are quite a few statements even on the page you linked to (which is also the one I'd read last time I looked into this) that suggest requirements and dependencies beyond a single PATH update. An obvious example is that pr

                  • Using the windows program Sandboxie allows you to easily do everything you have mentioned. It lets you create different sandboxes for different things.
      • 1) install VirtualBox or similar
        2) create a FreeBSD VM
        3) ????
        4) Profit

        • Unfortunately, in this case that '????' is something like "develop several years' worth of cross-compilation infrastructure so you can build on your guest OS but run on the host".

    • Re: (Score:2)

      by dryeo ( 100693 )

      Building Firefox (the only one I have experience with) will never work that way unless there has been a lot of patching to the official source. Firefox isn't designed to be installed with make install and install isn't even a target and building means "make -f client.mk"
      From client.mk

      # Build a mozilla application.
      #
      # To build a tree,
      # 1. hg clone ssh://hg.mozilla.org/mozilla-central mozilla
      # 2. cd mozilla
      # 3. create your .mozconfig file with
      # ac_add_options --enable-application=browser
      # 4. gmake -f client.mk
      #
      # Other targets (gmake -f client.mk [targets...]),
      # build
      # clean (realclean is now the same as clean)
      # distclean

      • The grandparent's example was not made up. It was how it's actually done on FreeBSD. Invoking make there downloads the sources, patches them, and then invokes the standard build procedure you quoted. So yes, somebody had to do some work to wrap the build process in a uniform interface, but it's no more work than what's needed for maintaining binary packages like Debian's apt packages. And once that work is done, anybody else using that operating system distribution can do it as simply as the grandparent sho

    • Re: (Score:2)

      by descubes ( 35093 )

      You are not building the latest, only whatever patched version exists in your ports. And did you actually run the commands and verify that your machine is powerful enough to do it?

  • Easy with Gentoo (Score:5, Informative)

    by crow ( 16139 ) on Saturday October 25, 2014 @04:25PM (#48231055) Homepage Journal

    Of course, if you use a source-based distribution, it's easy, but that's not the point. If you download the source and build it yourself, you'll have to learn a bit about how they manage the build environment. You'll have to handle being sure all the dependencies are installed. You'll have to figure out any configuration options.

    That's exactly what people who make distributions do. If you want to see how complicated the build is for any piece of software, just look at how complicated the build scripts are for various distributions. I expect you can find these for the binary distributions. With Gentoo, just look at the ebuild file.

    • That's exactly what people who make distributions do. If you want to see how complicated the build is for any piece of software, just look at how complicated the build scripts are for various distributions.

      I think it's a bad idea to rely on distributors to do this work. With my projects, I always try to make the build process as simple as possible.

      If somebody is thinking about maybe contributing to the project, I want it to be completely painless.

      It doesn't always work out, especially with third party dependencies, but I try to keep the build process as simple as checkout source code, and build it. No configuration at all. Obviously you can configure stuff, but there should be a default that will work for alm

      • Re: (Score:3)

        by crow ( 16139 )

        I agree that it should be easy. My point wasn't to rely on distributors for building. It was that the work has already been done for major projects like the ones listed, so you can get a sense of their build complexity by looking at what they had to do.

        For example, here are some ebuild sizes:
        gcc-4.9.1 1556 bytes
        mythtv-0.27.4 9796 bytes
        firefox-33.0 11698 bytes
        libreoffice-4.3.1.2 18473 bytes
        chromium-40.0.2194.2 18610 bytes
        netbeans-ide-8.0 29367 bytes

        That's a rough approximation of complexity. Sure, you ca

  • I run Gentoo (Score:4, Interesting)

    by NoNonAlphaCharsHere ( 2201864 ) on Saturday October 25, 2014 @04:27PM (#48231069)
    So it's simply emerge --update world* but I always groan when I see Chromium has a new version, which it does almost weekly, because it takes approximately FOREVER to compile. Firefox and Seamonkey take a long time, sure, but Chromium, yikes, come back tomorrow.

    *Actually, it's: emerge -v --deep --newuse --with-bdeps=y --update world 2>&1 | tee update-world-deeper-`date +%F`.log, but that's just me.

    • Yeah, I'm in the same boat; it's approaching the point where I'm debating just unmerging the damn thing as I mostly use FF. It's gotten to the point that I've masked* Chromium and am now only updating it monthly when I manually unmask it. I'm on a fairly recent laptop CPU (i5-3230M) and building Chromium takes so long it reminds me of emerging gnome2 back when I had a Pentium3 800MHz.

      * for non-Gentoo users, masking a package basically hides it from future updates. You can mask specific versions or anythi

      • I thought there were options to install pre-compiled versions of the packages. Are they not all available, or am I just mistaken?

        (Obviously I'm not a Gentoo user. Mostly Debian).

        • Re: (Score:1)

          by Anonymous Coward

          The entire point of Gentoo is literally to compile the entire system on your system, custom-built for your hardware, for maximum efficiency for your specs. For instance, you might have the latest Intel i7 Whizbang with the added XYZ super-fast instruction set, but it'll be many years before that ends up being compiled by default into binaries. There are still binaries being built that are 386 compatible, for instance! Even when you get those instructions compiled in a lot of time there's conditional code

          • "The entire point of Gentoo is literally to compile the entire system on your system, custom-built for your hardware, for maximum efficiency for your specs."

            Not necessarily. It's also good just for general customization that doesn' t necessarily HAVE to be about hardware fitting.

            I used to use Gentoo because I liked to turn on every feature of every package that I possibly could without causing conflicts. There were all sorts of features that could be en/disabled at compile time in various desktop environme

            • Re: (Score:2)

              by penix1 ( 722987 )

              I too use Gentoo and have since 2003. I started using it because it was the only one that had all my hardware working "out of the box" so to speak. Besides, it is a really good way to learn Linux under the hood.

              Having said that, you can get some really messed up crap especially if you setup your use flags or compiler options wrong. What I do hate about Gentoo is the seemingly random masking of packages that knocks out other packages that are working just fine. Yes, you can unmask them but that is a PITA. So

        • "I thought there were options to install pre-compiled versions of the packages."

          Gentoo does support that although the repositories only have binaries for a few really big packages like web browsers and desktop managers that would otherwise take a long time to compile. Those are probably the things you benefit the most from compiling though.

          You can set up third party repositories. I think there might be some pre-compiled ones out there. I think there is even a way to set up one build server that builds pac

        • Pre-compiled binaries do exist as ebuilds in portage for some very large apps (i.e. libreoffice, firefox, seamonkey, etc.) however they are not very common (only ~100 ebuilds out of ~17K available on my laptop running unstable aka ~amd64) however there's another option called BINHOST that lets you take prebuild packages on one system and distribute just the binaries to other clients.

          There are both public and private binhosts, however Gentoo doesn't officially provide any so you're somehwhat using them at yo

    • I just run my updates in screen terminals and I have turned portage's nice level up a bit so I can keep doing other things. It finishes when it finishes, I don' t watch it. I don't have Chromium though and have pretty much gotten rid of everything that updates constantly and is big like that.

      I do groan when I see libreoffice on the list though. But.. again, it runs in the background so no real time loss to me.

  • There's software for auto-detection of necessary libraries (cmake is probably the best, since it's more portable than autoconf).

    If you've the source tree, then you should require one single platform-dependent package containing cmake, gnu make, curl or wget, grep, cut and associated libraries, along with a text file containing a list of dependencies, where to get them and where to put them.

    Your build system then scans for everything needed. If you've got it, it uses it. If you don't, it fetches the source,

    • Re: (Score:1)

      by Anonymous Coward

      If only someone would come along and write a new, unified make system. Perhaps "systemm" would be a nice name. As it would replace a lot of outdated and clunky UNIX tools, it could, with time, also replace all compilers (systemm.gcc, systemm.clang, etc), file system management (systemm.mv, systemm.cp, and systemm.rm) and date/time functions (systemm.time).

    • (cmake is probably the best, since it's more portable than autoconf).

      As a user of autoconfed packages, I find autoconf superior to cmake. Packages built with autoconf have standardized mechanisms for uninstallation (a cmake package may generate an install-manifest file, an uninstall target, or none of the two), to specify where to put documentation, for cross-compilation, and to fine-tune the build and the installation. With cmake, I can't even tell the package where to install libraries (most packages will allow you to do it, but each package has a different standard about

  • People who do this (Score:5, Informative)

    by SampleFish ( 2769857 ) on Saturday October 25, 2014 @04:51PM (#48231171)

    There are some really great distros that are based on said sources:

    Pale Moon is an open source alternative to FireFox:
    http://www.palemoon.org/ [palemoon.org]

    SRWare Iron is a Chromium project:
    http://www.srware.net/en/softw... [srware.net]

    • Re: (Score:2, Informative)

      by Anonymous Coward

      SRWare Iron is not a Chromium project - it's a closed-source fork of the open-source Chromium codebase. I find it interesting that there are people who are concerned enough about privacy to switch away from Chrome/Chromium, but are still happy to use a closed-source browser which has had unknown modifications done to it.

      http://www.insanitybit.com/201... [insanitybit.com]

  • idiosyncratic is understatement (Score:5, Insightful)

    by Martin Spamer ( 244245 ) on Saturday October 25, 2014 @05:20PM (#48231281) Homepage Journal

    Idiosyncratic builds is not limited to just browsers and is probably the biggest problem faced by Open Source projects today.

    I use open source tools daily and yet with 20 years development experience I have yet to fine one open source project that straightforward to build.

  • Funny thing is, I don't actually remember why - other than there was some feature that wasn't available in the default build back then (Keychain integration, perhaps?)

    Anyway, there were a number of libraries and other packages that had to be added to the system in order for the build process to succeed... but I don't remember it being all that difficult to do. Time consuming, yes - but not difficult.

  • Just type:
    emerge conkeror && emerge links && emerge lynx && emerge w3m && emerge emacs && emerge google-chrome && emerge chromium && emerge firefox && emerge wget && emerge opera
    Now walk away and go make some tea.

    See, not complicated at all!

    Of course, that last one really just downloads a binary. But.. might as well include it too just for the completeness;

  • The Surf webkit browser source is 96kb (788kb with the full commit revision history).

    Good luck with your bloat.
    surf.suckless.org

    • Thanks for the comment about the Surf browser. I am really disillusioned about the current state of Internet Browsers in general. They have become tools of the marketing asshats and spyware in their own right. It's appalling what the industry is getting away with and just how far they are willing to go for a buck. It turns out nerds are not paragons of integrity...

    • Re: (Score:2)

      by descubes ( 35093 )

      Interesting. Actually, the Qt web browser is small too (but Qt itself is big). Same thing here, it uses WebKit behind the scene.

      Unfortunately, does not build on OSX:

      surf.c:9:10: fatal error: 'gtk/gtk.h' file not found
        #include
                          ^
        1 error generated.

  • ...last time I tried

            apt-get source --build iceweasel
            apt-get source --build chromium
            apt-get source --build webkitgtk

    it worked perfectly fine - what's the issue?

Slashdot Top Deals

If all else fails, lower your standards.

Close