QMO quality.mozilla.org (alpha)

There are a lot of reasons why you want to build the Mozilla tree. Once you build it you can run the automated regression test suites like mochitest, reftest, and xpcshell. You can also check out patches from bugzilla that are in development. And perhaps one day you may want to get involved with fixing bugs in bugzilla as well. It's actually gotten much easier to build the tree as a first time user.

There is great documentation for this on the wiki, but that is very general documentation that will be more useful to you after you've done this once. This page will walk you through each step of building Firefox for the default platforms. Once you can build on one of these platforms, you will be comfortable enough to use the main build docs to build the other products.

Prerequisites

First thing to do is ensure you have enough space. A built Firefox tree on trunk usually takes about 1 Gb. Next, check out your prerequisites for your Operating System:

• MacOS Intel (Universal build)
• MacOS PPC only
• Linux
• Windows
  1. Go to the bug in bugzilla
  2. From the Attachments table, click on the "Details" link of the bug you are interested in.
  3. Select all the information in the patch, don't leave anything out. Copy and Paste it into a Text Editor.
  4. Save the patch into the "mozilla" directory of your build area. You can name it anything you like.
  5. In a terminal window, apply the patch to the source tree by typing:
  • Ensure the "MOZ_OBJDIR" line reads: mk_add_options MOZ_OBJDIR=release
  • If you want to enable the automatic RefTests and MochiTests, add these lines:
  • ac_add_options --enable-tests
    ac_add_options --enable-mochitest
  • mkdir ~/code/fx-trunk
  • cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/client.mk
  • cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/build/macosx/universal/mozconfig
  • cd mozilla
  • make -f client.mk checkout
  • make -f client.mk build
  • MacOS: mozilla/release/dist/Firefox.app
  • Linux: mozilla/release/dist/bin/firefox
  • Windows: mozilla\release\dist\bin\firefox.exe
  • cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/testing
  • cvs up -A client.mk
  • make -f client.mk checkout
  • make -f client.mk build
  • C toolkit/mozapps/downloads/foo.c

 

The MozConfig File

The Mozilla build tree is special in that one tree can build several different projects i.e. Thunderbird, Firefox, Sunbird, Seamonkey, Camino, etc. The way that this is controlled is via the MozConfig file. The easiest way to get a MozConfig file that you know will be properly formatted is to pull a MozConfig off the Tinderbox for your Operating System. Here are the Tinderboxes for Firefox Trunk. The Mac one is called "MacOSX Darwin 8.8.4 bm-xserve08 Dep Universal Nightly", Linux is "Linux fx-linux-tbox Dep Nightly", and Windows is "WINNT 5.2 fx-win32-tbox Dep Nightly".

Pick the latest build (note that the Tinderbox should be green. If the Tinderbox is not green, something is wrong with the build, and you should wait to try this until the Tinderbox returns to a green state). Click on the "L" link and choose "View Full Log".

Look for this line in the log file: "-->mozconfig<-------------"

Copy the elements of the MozConfig from below that line to the "-->end mozconfig<--" line. Paste that into a text editor. You want to save this in your home directory as ".mozconfig". Note the dot before the filename and that it is all lowercase.

 

Special Editing For the MozConfig File

You can edit the MozConfig file to reflect what you would like to build. We change the MOZ_OBJDIR to a directory that the build can create itself. By setting it to "release" we tell the build to create a folder called "release" in the build tree to put all the temporary and generated files into during the build process.

 

Once you have made the MOZ_OBJDIR modification (the other modifications are optional), save the file as ".mozconfig" (note the dot and all lowercase) in your home directory. Your home directory is accessed by ~/. On Windows the home directory for Mozilla Build is C:\Documents And Settings\<user>\

Get the Code

Now, we are ready to get the code. The simplest way to get the code is to check it out from CVS, our version control system. First, create a directory where you want to put Firefox:

Browse to the fx-trunk directory. Use the following command to check out the client.mk file. The client.mk file is the heart of the build system. It contains all the information on how to configure the mozilla build tree to build any product.

 

You will notice that the command creates the "mozilla" directory for you. Look again at your .mozconfig file. If there are lines like ". $topsrcdir/build/macosx/universal/mozconfig" at the top of the file, then our work is not quite done. Those are included mozconfig files, and we must check them out specifically as well. This is done by replacing "$topsrcdir" with "mozilla" like so:

 

Once those all the included mozconfig files are checked out, we step into the mozilla directory.

 

Now, we ask client.mk to pull the proper files to build the project described by our mozconfig file. The project is specified by the MOZ_CO_PROJECT line.

 

You will see the files coming down from the CVS server. This is a good time to grab some coffee.

 

Build It

 

Once the files have landed, you're ready to build the software. It is a very simple command:

 

And it will start building. The build system does a series of checks first to ensure that everything is set up properly. If it detects any issues with your system, it will fail and display some error messages about the issue. I recommend to watch the scroll for the first minute or so to ensure that the start up checks all pass successfully, particularly if this is the first time you've built the Mozilla tree on this system. After a minute or two, the build system settles into the real work of creating the chosen product. This is a good time to get dinner. If you have a slow machine, stay for desert. It usually takes 1-2 hours depending on the computer and the OS. As long as you see information spewing by the console window, things are going OK.

Once the build finishes, you will find the Firefox executable here:

 

Note that if you pulled from trunk, the application name may be called Minefield on mac. Also, if you want to run Firefox from the command line on a mac you would do this:

 

mozilla/release/dist/Firefox.app/Contents/MacOS/firefox-bin

 

Patching The Build

 

As I mentioned earlier, one of the reasons for doing all this is to try out patches for bugs that are in development. This is quite easy to do.

 

• patch -p0 <mypatch.diff

Note that there is no space between the < sign and the name of the patch. Do not leave out the < sign, or the patch won't work.

 

This will work for 98% of patches. If the patch was created at a different level in the tree, then the patch utility might ask you for the location of the file to patch. Simply type it in. This looks like this:

h-144:~/code/fx-trunk2/mozilla clint$ patch -p0 <bug394516.diff
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties b/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties
|--- a/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties
|+++ b/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties
--------------------------
File to patch:

I supplied the path to the file: toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties

And the patcher responds:

patching file toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties

This means that it succeeded. If the patch fails, then you will see something like this:

patching file toolkit/mozapps/downloads/content/downloads.js
Hunk #1 FAILED at 80.
Hunk #2 FAILED at 207.
Hunk #3 FAILED at 271.
3 out of 3 hunks FAILED -- saving rejects to file toolkit/mozapps/downloads/content/downloads.js.rej

If a patch fails to apply, this usually means that the patch is out of date with the current state of the tree. You can try updating your tree, or if your tree is up to date, then you should post a polite comment in the bug alerting the creator of the patch that it is bitrotten, and needs to be updated.

 

Finding the Test Automation Code

 

The core of the test automation code is not checked out by simply adding ac_add_options --enable-tests to the mozconfig file. You will need to specifically check it out by hand. You can use this command to do that. (Remember to do all checkouts from the directory above the mozilla build directory).

 

Updating a Tree

 

There will come a time when you will want to update a tree to the latest version of the code. You do this by starting with this command from the mozilla directory (be sure to make certain that your mozconfig is in place in your home directory!)

 

Next, you perform the normal checkout.

 

Then you do the build

 

If the checkout fails because it finds a conflict in your source tree, it will denote the conflciting files like this:

 

 

You can delete that file and the "make -f client.mk checkout" process will update it, and repopulate it with the current state of the codebase.

 

Enjoy your building!