Assignment 1 (bhearsum)
The first step in building Firefox on Windows is getting a compiler. For someone who works on Linux most of the time this seemed like an easy step. A compiler's a compiler, right? Apparantly not! After reading the build documentation I found out that depending on which branch is being built a different compiler is needed. The latest version of Microsoft's cl compiler will only build the HEAD branch (Firefox 3.0). Visual Studio 2003 compilers will build all branches of the Mozilla tree. Microsoft does not make the free editions of these available anymore, luckily Seneca students have access to the full versions through ACS. I chose to build HEAD.
The Mozilla build system requires a unix-like environment to function correctly; this is a big reason why compiling Firefox on Windows can be such a headache. In order to get this functionality I had to install Cygwin. It provides a unix-style shell and all the standard unix tools. GNU make and CVS were also installed via Cygwin. I had to modify the default cygwin.bat file to point it to the Visual Studio libraries, include files, and executables as well as the moztools. Now I only have a few more things to install before building!
There are certain libraries and binaries that are required for building on the Mozilla tree that Cygwin does not provide. These are distributed in a package called moztools, which I got from the Mozilla Developer Center. To compile and link Windows applications I had to install the Microsoft Platform SDK. The installer for Mozilla applications uses the Nullsoft Install System. This isn't required to build but I wanted to create an installer so I could easily distribute my build.
Now that all of this is installed I can start building! Well....almost. The Mozilla build system does not use the traditional './configure; make; make install' method of compilation and installation. I imagine this is because of the complexity of the project. In any case, configure and compile-time options are set in a special file called .mozconfig. Configure options are preceeded by 'ac_add_options' and compile-time ones by 'mk_add_options'. Here is the .mozconfig file I used:
mk_add_options MOZ_OBJ_DIR="/cygdrive/c/mozilla/obj-ff3" mk_add_options MOZ_CO_PROJECT="browser" ac_add_options --enable-application=browser ac_add_options --enable-optimize ac_add_options --enable-static --disable-shared
MOZ_OBJ_DIR tells the compiler where to put the object files. This is useful when building multiple projects from the same tree. MOZ_CO_PROJECT tells the build system what files you will need when checking out from CVS. In this case I am only building the browser. --enable-application is similar to MOZ_CO_PROJECT, but it tells autotools what you will be building so that it can generate the proper Makefiles. --enable-optimize will enable the default optimizations. This can benefit performance and start-up time but makes debugging extremely difficult. The last two options tell the linker to use static linking instead of shared libraries. Because I want to generate an installer it is required that I use static linking.
Getting the Source
It's almost time to build but first I need the source tree. Depending on what branch I want to build the first step is different. Each branch has different “client.mk” Makefile. This file is the master Makefile for the build system. I am building HEAD so I checked out the client.mk for it with:
cvs -d :pserver:anonymous:firstname.lastname@example.org:/cvsroot co mozilla/client.mk
Since the .mozconfig is already setup grabbing the source tree is a simple matter. The command 'make -f client.mk pull_all' will retrieve the source code for all projects specified in the .mozconfig. After this finished I issued 'make -f client.mk build' and the compilation started.
After spending all of this time installing and setting up various things it would've been nice if it “just worked” but that was not the case. During the first build attempt I had an error about 20 minutes in. I did some googling on it and found nothing useful. I double checked my mozconfig and it looked fine. Finally, I went to irc://irc.mozilla.org/#developers and the first thing they asked me was “what version of make are you using?”. Whoops! I re-read the Windows Build Prerequisites and learned that make 3.81 is NOT supported. Installing the right version (3.80) was an easy task with Cygwin and I was quickly restarting the build from scratch. Again, shortly after the build began I encountered an error. Looking back at my conversation in #developers I saw that a few people suggested looking at the Tinderbox before pulling HEAD. I'm still unsure what to look for on the Tinderbox page but I now know that the HEAD tree is often broken. There was nothing I could do about this error except wait a bit and try again.
The fruits of my labour:
After a few tries I did get the tree to build. The most invaluable resource in this process was the Mozilla Developer Center. The build documentation was very complete. All of the problems I had were a result of me not fully reading the build documentation thoroughly. It talks about make 3.80 as well as checking the Tinderbox before pulling the source tree. The only thing confusing to me was the naming of things on the Tinderbox. The tree for HEAD builds of Firefox is “Firefox”. To me that sounds like the current stable release. Even inside of the trees the naming is confusing. Each Tinderbox tree page is filled with different build names. As it turns out, “WINNT 5.2 gaius Dep release” is the tree that shows updated test builds for Windows 2003. I don't think I would've figured this without asking. I expected to see “Firefox HEAD Win2k3” or something along those lines. The more I work with the Tinderbox the easier this has become. The non-HEAD trees are named after their CVS counterparts. As long as you know the various CVS tags this is simple, but it can be intimidating for a newbie!