Building Mozilla Firefox on Windows 7

I’d always thought it would be scary building a large application like Mozilla Firefox completely from source, but a few weeks ago I did some initial looking into it. With a recent nudge from a professor, I went ahead and successfully retrieved the source and compiled Firefox. Here’s how I did it.

Step 0: I read the documentation.

Not just a little either, but everything you can to build Firefox on Windows. Mozilla Developer Central has an extensive series of wiki entries dedicated solely to multi-platform building. The build system is complex and issues may come up. If you’re like me you want to get your hands dirty and you’ll ignore the “Impatient” route they suggest.

Step 1: Review Build Preqrequisites.

An extensive system has extensive prerequisites for various versions. Feeling ambitious, I decided to try building the most-recent code for the upcoming Firefox 4. Going off a checklist, I worked my way down:

Hardware Requirements

Mozilla requires a “development-class system” to compile. With the following hardware, I was above their recommended specs:

  • AMD Phenom X3 8450
  • 3 GB RAM
  • 100+ GB HDD space
  • Windows 7 Professional 32-bit

Software Requirements

These are the tools required by the Mozilla build system. I already had a Visual C++ Compiler and Windows SDK, but still to be downloaded was the MozillaBuild System (found here). Given my target product of Firefox 4, my compiler version needed to supported. Firefox 4 is compatible with Visual Studio 2005, 2008 and 2010. My configuration for compiling is below:

  • Visual Studio Ultimate 2010
  • Windows SDK 6.0A, 7.0A, and 7.1
  • MozillaBuild 1.5.1

MozillaBuild was installed by default to “C:\mozilla-build” (you can change this, just don’t include spaces in the path name!) and with it came a bevy of tools. Windows versions of VIM and python are there, along with the software source control program used by Mozilla (Mercurial, found in “C:\mozilla-build\hg”). With hardware and software dependencies taken care of, it was time to get the source code!

Step 2: Grabbing the Source Code

Mozilla uses Mercurial to manage source control and versioning. Mercurial is an application which, if you’re following along to the T should have been installed along with MozillaBuild in Step 1. If not, you can find installation instructions here. Once downloading it though, it came time to configure Mercurial. Mercurial uses an ini file to store settings, which must be created from scratch after installation. Here’s how to do it:

  1. Open Notepad (or another text editor)
  2. Save the empty file to Mercurial’s install directory (“C:\mozilla-build\hg”)

This file will drive the source retrieval process. Mozilla has a few recommended settings listed on their wiki, copied into my own Mercurial.ini and shown below:

[ui]
username = Your Real Name <user@example.com>
merge = your-merge-program (or internal:merge)


git = 1
showfunc = 1
unified = 8

[defaults]
commit = -v

Name is easy enough to fill in, but the merge tool entry may be one of many things. A few of the wiki editors on MDC prefer tools such as kdiff, but having already had TortoiseSVN and TortoiseMerge installed, I decided to use TortoiseMerge by setting the value to the absolute path of the program (“C:\Program Files\TortoiseSVN\bin\TortoiseMerge.exe”). Merge tools come in many flavours though, with a comprehensive listing here.

Actually Grabbing the Code

With the configuration all set, I just had to choose a location to store the source code and then to retrieve it. The location should have no spaces (I chose D:\FFsrc\src20). Then simply call “hg clone http://hg.mozilla.org/mozilla-central/ D:\FFsrc\src20″ from the command line with the parameter after clone being the location to clone from and the last argument being the location to close to. Mozilla Central is the trunk, which at this point will become Firefox 4.

Mercurial at Work
Mercurial at Work

By default, the MozillaBuild installation does not modify the PATH variable on your computer and Windows won’t know what program hg is unless you are in the Mercurial root directory (C:\mozilla-build\hg). You can fix this like so:

  1. Right click on My Computer
  2. Choose Properties
  3. Choose “Advanced” (may show as “Advanced Settings”)
  4. Click “Environment Variables”
  5. Scroll down the list of System variables until you find PATH
  6. Double-click the entry
  7. Move to the end of the string and enter “;C:\mozilla-build\hg” without quotes
  8. Click OK
  9. Click OK
  10. Click OK

At this point the command to pull code from Mozilla’s source repository should work when run from anywhere. Restarting the system may be required for any changes made to the PATH variable to take effect. Pulling the files will take a while: the complete source as of today’s date weighs in at a hefty 670 MB.

Step 3: Configuring the Build

Firefox uses a file (.mozconfig) to specify build options, which are then passed to the make file. This is an ordinary text file with options specified one-per-line, located at the root of the source tree (in my case, D:\FFsrc\src20). There are an extensive number of options which may enable the creation of one of any of the Mozilla products all outlined in their documentation. At the bottom of that page is a listing of several recommended configurations for builds such as Release Firefox, Firefox Debug, Thunderbird Debug and SeaMonkey Optimized (not statically linked). I went with the Firefox release configuration, shown below:

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-opt
ac_add_options --disable-tests

After creating a .mozconfig file (much the same way you create the Mercurial.ini file) enter the above in your .mozconfig and save it to the root for your source (D:\FFsrc\src20). While this doesn’t seem like many commands, a great many which are not specified have default values, and often defaults result in the best overall performance. A dissection of the options shows a variable, topsrcdir,with relative paths specified for object generation (MOZ_OBJDIR). This will be the location all compilation output (including our final Firefox executables) will reside within.

With everything in place, it’s time to cross our fingers and build Firefox.

Step 4: Building Firefox

Here is where all the diligent work above pays off. The build takes a long time (50 minutes using the hardware, software and build configurations listed above) and may easily take more depending on your build options.

Compilation is performed through a unix-style shell included in the MozillaBuild install from Step 1. This is run in the form of one of many batch scripts (located at the root install directory for MozillaBuild), each with customizations for whether the compiler used will be Visual Studio 2003, 2005, 2008 or 2010. Using Visual Studio 2010, the appropriate file for me is start-msvc10.bat. While I am on a 32-bit OS and their are 64-bit versions of the scripts, developers on the wiki caution against using the experimental 64-bit versions.

Whichever shell is right for you, the final steps to building are:

  1. Run the appropriate build file
  2. Make the source root your current directory (cd “D:\FFSrc\src20”)
  3. Type “make -f client.mk build” without quotes and hit enter

Building Firefox
Building Firefox

Every stage of the build is written to standard output (the console) by default, so you can watch the build progress every step of the way. By the end of the build process you should have your very own build of Firefox. You can find it in the default Windows location of MOZ_OBJDIR\dist\bin\firefox.exe, as specified in your .mozconfig file in Step 3.

Enjoy your custom-built Firefox!

Comments

One response to “Building Mozilla Firefox on Windows 7”

  1. […] to model and ship my changes. I had been working off an older code base (current from when I had last built Firefox) so line numbers are slightly skewed with respect to the current code. It seemed to work on my […]

Leave a Reply

More posts

Discover more from Software by Steven

Subscribe now to keep reading and get access to the full archive.

Continue reading