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.\u00a0 But we rarely talk about them.<\/p>\n
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.<\/p>\n
I have two machines:\u00a0 a\u00a0quite new and very fast Linux desktop<\/a> 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.\u00a0 In theory my Linux desktop also has a Windows VM on it, though in practice that hasn’t happened yet!<\/p>\n I use Ubuntu on my Linux machine.\u00a0 I don’t really enjoy sysadmin-type stuff, so I use the most widely-used, vanilla distribution available.\u00a0 That way, if something goes wrong there’s a decent chance somebody else will have had the same problem.<\/p>\n I do most of my work on mozilla-inbound.\u00a0 I clone that into a “master” repository,\u00a0 that I leave untouched, called I use Mercurial queues and am quite content with them, though I am looking forward to changeset evolution<\/a> becoming stable.\u00a0 I tried git once but didn’t like it much;\u00a0 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.<\/p>\n One problem I had with Mercurial queues was that I would often type Some Mercurial extensions that I particularly like are color<\/a> (colour output), progress<\/a> (progress bars for slow operations), record<\/a> (commit part of a change) and bzexport<\/a> (upload patches to Bugzilla from the command line).<\/p>\n 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.\u00a0 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.\u00a0 This avoids the test bustage problem, but occasionally the patches don’t apply cleanly.\u00a0 In that case I just push from the mozilla-inbound repo and deal with the risk of test bustage.<\/p>\n I mostly use Clang, though I also sometimes use GCC.\u00a0 Clang is substantially faster than GCC, and its error messages are much better (though GCC’s have improved recently).\u00a0 Clang’s generated code is slightly worse (~5–10% slower), but that’s not much of an issue for me while developing.\u00a0 In fact, faster compilation time is important enough that my most common build configuration has the following line:<\/p>\n 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 I have a lot of mozconfig files.\u00a0 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 Although I never do 32-bit browser builds, I do sometimes do 32-bit JS shell builds, so the ’64’ isn’t entirely redundant!<\/p>\n I have a script called The argument is the mozconfig\/objdir name.\u00a0 This script invokes the build and redirects the output to an I have multiple profiles.<\/p>\n I have a script called The first argument is the mozconfig, and the second is the profile.\u00a0 Much of the time, this invokes Firefox in the usual way, e.g.:<\/p>\n 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).\u00a0 I also wrote it so that I can tack on I use a 2×2 virtual desktop layout.<\/p>\n 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.<\/p>\n In the top-right screen I have Firefox open for general use.<\/p>\n In the bottom-right screen I have a Chatzilla window open.<\/p>\n I use Vim.\u00a0 This is largely due to path dependence;\u00a0 it’s what they taught in my introductory programming classes at university, and I’ve happily used it ever since.\u00a0 My setup isn’t particularly advanced, and most of it isn’t worth writing about.\u00a0 However, I have done a few things that I think are worth mentioning.<\/p>\n Tags are fantastic — they let you jump immediately to the definition of a function\/type\/macro.\u00a0 I use ctags and I have an alias for the following command.<\/p>\n I have to re-run this command periodically to keep up with changes to the codebase.\u00a0 Fortunately, it only takes about 5 seconds on my fast SSD.\u00a0 (My old machine with a mechanical HD took much<\/em> longer).\u00a0 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.<\/p>\n I now use quickfix<\/em>, which is a special mode to speed up the edit-compile-edit cycle.\u00a0 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.\u00a0 This saves enormous amounts of manual file and line traversal — I can’t recommend it highly enough.<\/p>\n In order to use quickfix you need to tell Vim what the syntax of the compile errors is.\u00a0 I have the following command in my .vimrc for this.<\/p>\n This isn’t pretty, but it works well for Mozilla code.\u00a0 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.\u00a0 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.<\/p>\n One nice thing about quickfix is that it lets me start fixing errors before compilation has finished!\u00a0 As soon as I see the first error message I can do :cf.\u00a0 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.<\/p>\n If you use Vim, work on Mozilla C++ code, and don’t use it, you should set it up\u00a0right now<\/em>.\u00a0 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.\u00a0 (In case you’re curious, the :cnf, :cpf, :copen and :cclose commands cover the other 5%.)<\/p>\n I also set up Vim’s :grep command for use with Firefox.\u00a0 I put the following script in ~\/bin\/.<\/p>\n It does a recursive grep for a pattern through various kinds of source files, ignoring my objdirs and repository directories.\u00a0 To use it, I just type “:grep <pattern>” and Vim runs the script and sends the results to quickfix, so I can again use :cn and :cp to navigate through the matches.\u00a0 (Vim already knows about grep’s output format, so you don’t need to configure anything for that.)<\/p>\n 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.<\/p>\n This line in my .vimrc tells Vim to highlight any trailing whitespace in red.<\/p>\n [Update: I accidentally omitted the final four lines of this when I first published this post.]<\/p>\n The good thing about this is that I now never submit patches with trailing whitespace.\u00a0 The bad thing is that I can see where other people have left behind trailing whitespace \ud83d\ude42<\/p>\nMercurial Repositories<\/h3>\n
ws0<\/code>. Then I have nine local clones of ws0<\/code>, called ws1<\/code>..ws9<\/code>. 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).<\/p>\nMercurial<\/h3>\n
hg qref patchname<\/code> when I meant hg qnew patchname<\/code>. This can lead to surprising and annoying mix-ups with patches, so I wrote a pre-hook for hg qref<\/code> — if I give it an argument that isn’t -e<\/code> or -u<\/code>, I almost certainly meant hg qnew<\/code>, so it aborts with a reminder. This has saved me some hassle on numerous occasions.<\/p>\nTry Server<\/h3>\n
Compiling<\/h3>\n
ac_add_options --enable-optimize='-O0' # worse code, but faster builds<\/pre>\n
--enable-optimize<\/code> build.<\/p>\nMozconfigs<\/h3>\n
<\/code>) have a mandatory argument that specifies the relevant mozconfig.\u00a0 As a result, the mozconfig names I use are much shorter than the default names.\u00a0 For example, the following is a selection of some of my more commonly-used mozconfigs for desktop Firefox.<\/p>\n\n
Building<\/h3>\n
mmq<\/code> that I use to build the browser.\u00a0 I invoke it like this:<\/p>\nmmq o64<\/pre>\n
errors.err<\/code> file (for use with quickfix<\/em>, see below).\u00a0 Once compilation finishes, the script also does some hacky grepping to reprint the first five compilation errors, if they exist, once compilation finishes.\u00a0 I do this to make it easier to find the errors — sometimes they get swamped by the subsequent output.\u00a0 (My use of Quickfix has made this feature less important than it once was, though it’s still a good thing to have.)<\/p>\nProfiles<\/h3>\n
\n
default<\/code>: used for my normal browsing.<\/li>\ndev<\/code>: my standard development profile.<\/li>\ndev2<\/code>: a second development profile, mostly used if I already am using the dev<\/code> profile in another browser invocation.<\/li>\ne10s<\/code>: a profile with Electrolysis enabled.<\/li>\n<\/ul>\nStarting Firefox<\/h3>\n
ff<\/code> with which I start Firefox like the following.<\/p>\nff o64 dev<\/pre>\n
o64\/dist\/bin\/firefox -P dev -no-remote<\/pre>\n
gdb<\/code> as a third argument and it’ll run under GDB.<\/p>\nVirtual desktop and window layout<\/h3>\n
Text Editing<\/h3>\n
Tags<\/h4>\n
ctags -R --langmap=C++:.c.h.cpp.idl --languages=C++ --exclude='*dist\\\/include*' --exclude='*[od]32\/*' --exclude='*[od]64\/*'<\/pre>\n
Quickfix<\/h4>\n
\" Multiple entries (separated by commas):\r\n\" - compile (%f:%l:%c) errors for different levels of file nesting\r\n\" - linker (%f:%l) errors for different levels of file nesting\r\nset efm=..\/..\/..\/..\/..\/%f:%l:%c:\\ error:\\ %m,..\/..\/..\/..\/%f:%l:%c:\\ error:\\ %m,..\/..\/..\/%f:%l:%c:\\ error:\\ %m,..\/..\/%f:%l:%c:\\ error:\\ %m,..\/%f:%l:%c:\\ error:\\ %m,%f:%l:%c:\\ error:\\ %m,..\/..\/..\/..\/..\/%f:%l:\\ error:\\ %m,..\/..\/..\/..\/%f:%l:\\ error:\\ %m,..\/..\/..\/%f:%l:\\ error:\\ %m,..\/..\/%f:%l:\\ error:\\ %m,..\/%f:%l:\\ error:\\ %m,%f:%l:\\ error:\\ %m<\/pre>\n
:grep<\/h4>\n
#! \/bin\/sh\r\npattern=$1;\r\nif [ -z \"$pattern\" ]; then\r\n\u00a0\u00a0\u00a0 echo \"usage: $FUNCNAME <pattern>\";\r\n\u00a0\u00a0\u00a0 return 1;\r\nfi;\r\ngrep -n -r -s \\\r\n\u00a0\u00a0\u00a0 --exclude-dir=\"*[od]32*\" \\\r\n\u00a0\u00a0\u00a0 --exclude-dir=\"*[od]64*\" \\\r\n\u00a0\u00a0\u00a0 --exclude-dir=\".hg*\" \\\r\n\u00a0\u00a0\u00a0 --exclude-dir=\".svn*\" \\\r\n\u00a0\u00a0\u00a0 --include=\"*.cpp\" \\\r\n\u00a0\u00a0\u00a0 --include=\"*.h\" \\\r\n\u00a0\u00a0\u00a0 --include=\"*.c\" \\\r\n\u00a0\u00a0\u00a0 --include=\"*.idl\" \\\r\n\u00a0\u00a0\u00a0 --include=\"*.html\" \\\r\n\u00a0\u00a0\u00a0 --include=\"*.xul\" \\\r\n\u00a0\u00a0\u00a0 --include=\"*.js\" \\\r\n\u00a0\u00a0\u00a0 --include=\"*.jsm\" \\\r\n\u00a0\u00a0\u00a0 \"$pattern\"<\/pre>\n
Trailing whitespace detection<\/h4>\n
highlight ExtraWhitespace ctermbg=red guibg=red\r\nautocmd BufWinEnter *.{c,cc,cpp,h,py,js,idl} match ExtraWhitespace \/\\s\\+$\/\r\nautocmd InsertEnter *.{c,cc,cpp,h,py,js,idl} match ExtraWhitespace \/\\s\\+\\%#\\@<!$\/\r\nautocmd InsertLeave *.{c,cc,cpp,h,py,js,idl} match ExtraWhitespace \/\\s\\+$\/\r\nautocmd BufWinLeave *.{c,cc,cpp,h,py,js,idl} call clearmatches()<\/pre>\nCtrl-P<\/h4>\n