If you're writing any code for Mozilla, you sure have tasted how disturbing it might be to write some piece of code, then do a full build of the entire code base, and then testing your work, only to find that you need to make a small correction, and recycle the whole build and test process again. This may waste a lot of time which can be used elsewhere, so here are two tricks that may come in handy.
Code changes only in JAR modules
cd /path/to/mozilla/sources make -C toolkit/themes
Or this command if you're using an objdir:
cd /path/to/mozilla/sources make -C objdir/toolkit/themes
And, voilà! You can run and test your changes, and it took less than 10 seconds to build the new version (if you have a reasonably modern machine, that is).
Code changes to C++ modules
If you happen to be working on a C++ module, then you can use the two-stage build like this example. Firstly, you should add the following to your .mozconfig (if it doesn't already contain those), and use an objdir:
ac_add_options --disable-static ac_add_options --disable-libxul
These options make the compile process produce separate shared library modules that are dynamically-linked at runtime. So, if you're making a change to, let's say, nsEventStateManager.cpp, then all you have to do is to build the shared component in which this file is being linked. That is:
cd /path/to/mozilla/sources make -C objdir/content/events
This compiles nsEventStateManager.cpp (with any other files which need to be re-compiled because of compile-time dependencies). To actually link this file into the executable module loaded at runtime, you have to make the build directory as well. This directory is usually named “build” and is located in the module's main directory (for example, netwerk/build), but there are some exceptions. The build dir for uriloader is docshell/build, and the build dir for content, dom, editor and view is layout/build. So, the next command to run is:
make -C objdir/layout/build
Which takes the resulf of compilation of nsEventStateManager.cpp and links it into a shared library to be loaded at runtime. This is usually much more faster than a new build, unless you're making tree-wide changes. Try it, and you'll never hack without it!