Most Mozilla developers have their own particular set-ups and work-flows, and over time develop various scripts, shortcuts, and habits to make their lives easier. But we rarely talk about them.
In this post I will describe various interesting aspects of how I work on Mozilla code, in the hope that (a) it will give other people useful ideas, and (b) other people will in turn give me useful ideas.
Machines
I have two machines: a quite new and very fast Linux desktop machine, on which I do 99% of my coding work, and a two-year old Macbook Pro, on which I do little coding but a lot of browsing and other non-development stuff. In theory my Linux desktop also has a Windows VM on it, though in practice that hasn’t happened yet!
I use Ubuntu on my Linux machine. I don’t really enjoy sysadmin-type stuff, so I use the most widely-used, vanilla distribution available. That way, if something goes wrong there’s a decent chance somebody else will have had the same problem.
Mercurial Repositories
I do most of my work on mozilla-inbound. I clone that into a “master” repository, that I leave untouched, called ws0. Then I have nine local clones of ws0, called ws1..ws9. I don’t have trouble filling the nine local clones because I usually have multiple different coding tasks in flight at any one time. Indeed, this is a necessity when dealing with the various latencies involved with development, such as compilation and local test runs (minutes), try server runs (hours), and reviews (days).
Mercurial
I use Mercurial queues and am quite content with them, though I am looking forward to changeset evolution becoming stable. I tried git once but didn’t like it much; the CLI is awful, the speed wasn’t noticeably better than Mercurial (and this was before I upgraded from Mercurial 1.8 to 2.7, which is much faster), and it was inconvenient to have to move patches over to a Mercurial repo before landing.
One problem I had with Mercurial queues was that I would often type hg qref patchname when I meant hg qnew patchname. This can lead to surprising and annoying mix-ups with patches, so I wrote a pre-hook for hg qref — if I give it an argument that isn’t -e or -u, I almost certainly meant hg qnew, so it aborts with a reminder. This has saved me some hassle on numerous occasions.
Some Mercurial extensions that I particularly like are color (colour output), progress (progress bars for slow operations), record (commit part of a change) and bzexport (upload patches to Bugzilla from the command line).
Try Server
Even though I do most of my work with mozilla-inbound, pushing to try from mozilla-inbound isn’t a great idea, because every so often you’ll catch some test breakage caused by someone else’s patch and then you have to work out if it’s your fault or was pre-existing. So recently I took RyanVM’s advice and wrote a script that transplants the patch queue from a mozilla-inbound repo to a mozilla-central repo, and then pushes to try. This avoids the test bustage problem, but occasionally the patches don’t apply cleanly. In that case I just push from the mozilla-inbound repo and deal with the risk of test bustage.
Compiling
I mostly use Clang, though I also sometimes use GCC. Clang is substantially faster than GCC, and its error messages are much better (though GCC’s have improved recently). Clang’s generated code is slightly worse (~5–10% slower), but that’s not much of an issue for me while developing. In fact, faster compilation time is important enough that my most common build configuration has the following line:
Last time I measured (which was before unified builds were introduced) this shaved a couple of minutes off build times, as compared to a vanilla --enable-optimize build.
Mozconfigs
I have a lot of mozconfig files. I switch frequently between different kinds of builds, so much so that all my custom short-cut commands (e.g. for building and running the browser) have a mandatory argument that specifies the relevant mozconfig. As a result, the mozconfig names I use are much shorter than the default names. For example, the following is a selection of some of my more commonly-used mozconfigs for desktop Firefox.
d64: debug 64-bit build with clang
o64: optimized 64-bit build with clang
gd64: debug 64-bit build with GCC
go64: optimized 64-bit build with GCC
cd64: debug 64-bit build with clang and ccache
co64: optimized 64-bit build with clang and ccache
o64v: optimized 64-bit build with clang and –enable-valgrind
o64dmd: optimized 64-bit build with clang and –enable-dmd
Although I never do 32-bit browser builds, I do sometimes do 32-bit JS shell builds, so the ’64′ isn’t entirely redundant!
Building
I have a script called mmq that I use to build the browser. I invoke it like this:
The argument is the mozconfig/objdir name. This script invokes the build and redirects the output to an errors.err file (for use with quickfix, see below). Once compilation finishes, the script also does some hacky grepping to reprint the first five compilation errors, if they exist, once compilation finishes. I do this to make it easier to find the errors — sometimes they get swamped by the subsequent output. (My use of Quickfix has made this feature less important than it once was, though it’s still a good thing to have.)
Profiles
I have multiple profiles.
default: used for my normal browsing.
dev: my standard development profile.
dev2: a second development profile, mostly used if I already am using the dev profile in another browser invocation.
e10s: a profile with Electrolysis enabled.
Starting Firefox
I have a script called ff with which I start Firefox like the following.
The first argument is the mozconfig, and the second is the profile. Much of the time, this invokes Firefox in the usual way, e.g.:
However, this script knows about my mozconfigs and it automatically does more elaborate invocations when necessary, e.g. for DMD (which requires the setting of some environment variables). I also wrote it so that I can tack on gdb as a third argument and it’ll run under GDB.
Virtual desktop and window layout
I use a 2×2 virtual desktop layout.
In each of the top-left and bottom-left screens I have three xterms — a full-height one on the left side in which I do editing, and two half-height ones on the right side in which I invoke builds, hg commands, and sundry other stuff.
In the top-right screen I have Firefox open for general use.
In the bottom-right screen I have a Chatzilla window open.
Text Editing
I use Vim. This is largely due to path dependence; it’s what they taught in my introductory programming classes at university, and I’ve happily used it ever since. My setup isn’t particularly advanced, and most of it isn’t worth writing about. However, I have done a few things that I think are worth mentioning.
Tags
Tags are fantastic — they let you jump immediately to the definition of a function/type/macro. I use ctags and I have an alias for the following command.
I have to re-run this command periodically to keep up with changes to the codebase. Fortunately, it only takes about 5 seconds on my fast SSD. (My old machine with a mechanical HD took much longer). The coverage isn’t perfect but it’s good enough, and the specification of .idl files in the –langmap option was a recent tweak I made that improved coverage quite a bit.
Quickfix
I now use quickfix, which is a special mode to speed up the edit-compile-edit cycle. The commands I use to build Firefox redirect the output to a special file, and if there are any compile errors, I use Vim’s quickfix command to quickly jump to their locations. This saves enormous amounts of manual file and line traversal — I can’t recommend it highly enough.
In order to use quickfix you need to tell Vim what the syntax of the compile errors is. I have the following command in my .vimrc for this.
This isn’t pretty, but it works well for Mozilla code. Then it’s just a matter of doing :cf to load the new errors file (which also takes me to the first error) and then :cn/:cp to move forward and backward through the list. Occasionally I get an error in a header file that is present in the objdir and the matching fails, and so I have to navigate to that file manually, but this is rare enough that I haven’t bothered trying to fix it properly.
One nice thing about quickfix is that it lets me start fixing errors before compilation has finished! As soon as I see the first error message I can do :cf. This means I have to re-do :cf and skip over the already-fixed errors if more errors occur later, but this is still often a win.
If you use Vim, work on Mozilla C++ code, and don’t use it, you should set it up right now. There are many additional commands and options, but what I’ve written above is enough to get you started, and covers 95% of my usage. (In case you’re curious, the :cnf, :cpf, :copen and :cclose commands cover the other 5%.)
:grep
I also set up Vim’s :grep command for use with Firefox. I put the following script in ~/bin/.
It does a recursive grep for a pattern through various kinds of source files, ignoring my objdirs and repository directories. To use it, I just type “:grep
” and Vim runs the script and sends the results to quickfix, so I can again use :cn and :cp to navigate through the matches. (Vim already knows about grep’s output format, so you don’t need to configure anything for that.)
I can also use that script from the command line, which is useful when I want to see all the matches at once, rather than stepping through them one at a time in Vim.
Trailing whitespace detection
This line in my .vimrc tells Vim to highlight any trailing whitespace in red.
The good thing about this is that I now never submit patches with trailing whitespace. The bad thing is that I can see where other people have left behind trailing whitespace 
Ctrl-P
Finally, I installed the Ctrl-P plugin, which aims to speed up the opening of files by letting you type in portions of the file’s path. This is potentially quite useful for Mozilla code, where the directory nesting can get quite deep. However, Ctrl-P has been less of a win than I hoped, for two reasons.
First, it’s quite slow, even on my very fast desktop with its very fast SSD. While typing, there are often pauses of hundreds of milliseconds after each keystroke, which is annoying.
Second, I find it too eager to find matches. If you type a sequence of characters, it will match against any file that has those characters present in that order, no matter how many other characters separate them, and it will do so case-insensitively. This might work well for some people, but if I’m opening a file such as content/base/src/nsContentUtils.cpp, I always end up typing just the filename in full. By the time I’ve typed “nsContentU” ideally it would be down to the two files in the repository that match that exact string. But instead I get the following.
I wish I could say “case-insensitive exact matches, please”, but I don’t think that’s possible. As a result, I don’t use Ctrl-P that much, though it’s still occasionally useful if I want to open a file for which I know the name but not the path — it’s faster for that than dropping back to a shell and using find.
Conclusion
That’s everything of note that I can think of right now. Please feel free to steal as many ideas as you wish from this post.
I haven’t given full details for a lot of the things I mentioned above. I’m happy to give more details (e.g. what various scripts look like) if people are interested.
Finally, I encourage other developers to write posts like this one explaining how they work on Mozilla code. Thanks!