This list is sorted such that the largest speed up is first.

• Build only specific targets
• Linking using gold
• Build WebKit without debug symbols
• Shared libraries
• Using tmpfs
• Scons Tricks
• Avoid Scons entirely
• Loading only part of the build configuration
• SCons interactive mode

Build only specific targets

If you specify just the target(s) you want built, the build will only walk that portion of the dependency graph:

$ cd $CHROMIUM_ROOT/src
$ make base_unittests

You can also specify explicit files that you want built. The above is basically equivalent to:

$ cd $CHROMIUM_ROOT/src
$ make out/Debug/base_unittests

Linking using gold

The experimental "gold" linker is much faster than the standard one.

On some systems (including Debian experimental, Ubuntu Karmic), just apt-get install binutils-gold.

Otherwise, try running src/build/install-build-deps.sh and answer Y when it asks you if you want to use gold as your system linker.

If you want to do it the hard way, here are the old instructions:

1. Check out the binutils CVS.
2. apt-get build-dep binutils to get build dependencies.
3. Run the binutils configure with --enable-gold and build it.
4. Create a new directory for your new binary.
5. cp gold/ld-new to /my/directory/ld (note the rename)
6. Add -B/my/directory to the flags you pass to CC and CXX. E.g., export CC="ccache gcc -B$BINPATH" and similarly for CXX.

Build WebKit without debug symbols

WebKit is about half our weight in terms of debug symbols. (Lots of templates!) If you're working on UI bits where you don't care to trace into WebKit you can cut down the size and slowness of debug builds significantly by building WebKit without debug symbols.

Set the gyp variable remove_webcore_debug_symbols=1, either via the GYP_DEFINES environment variable, the -D flag to gyp, or by adding the following to ~/.gyp/include.gypi:

{
  'variables': {
    'remove_webcore_debug_symbols': 1,
  },
}

Shared libraries

We normally static link, which produces enormous (test_shell has been seen at nearly 500mb) executables. If you dynamically link, you save a lot of time linking for a bit of time during startup, which is fine especially when you're in an edit/compile/test cycle.

Run gyp with the -Dlibrary=shared_library flag to put it in this configuration. Note that this build frequently breaks, so if it doesn't work it's up to you to diagnose.

Using tmpfs

If you have RAM to spare, you can use tmpfs for the build output to reduce the amount of disk writes required. I.e. mount tmpfs to the output directory where the build output goes:

As root:

• For scons: mount -t tmpfs -o size=4G,nr_inodes=10k,mode=1777 tmpfs /path/to/out
• For scons: mount -t tmpfs -o size=4G,nr_inodes=10k,mode=1777 tmpfs /path/to/sconsbuild

Caveat: Make sure you have enough ram to do this, otherwise your system will thrash. In particular, if you have a 4G of ram on your machine, don't set this to 4G, or probably even 3G. You need enough space to keep running your linkers, compilers, desktop, browsers, editors, etc.

Scons Tricks

Avoid Scons entirely

Follow the normal LinuxBuildInstructions. If you really want to keep using Scons, keep reading.

Loading only part of the build configuration

You can tell our scons scripts to only load the dependency info for certain targets. For example, if you're working on files in base/ and only building the tests there, you can pass LOAD=base,base_unittests on the command line to only load the base .scons files necessary for building the base library and its unittests. Note that if you edit a file outside of the SConscript set you're loading, SCons won't pick up that the file has changed.

$ cd $CHROMIUM_ROOT/src/build
$ hammer LOAD=webkit

If you're primarily focusing on the browser, then use the following command line:

$ cd $CHROMIUM_ROOT/src/build
$ hammer --implicit-cache chrome LOAD=chrome,browser

This dropped the time it takes scons to figure out nothing changed from 36 seconds to 6 seconds on my machine.

NOTE: the targets defined by gyp are now more fine-grained than the old "Hammer" targets, and don't necessarily pull in all of the dependent configurations. So if you now specify (e.g.) LOAD=base_unittests, that only loads the configuration necessary to build the actual base_unittests executable, and does not load the dependency information for building libbase.a--that is, it would treat libbase.a as a "source file" input to the link of base_unittests.

SCons interactive mode

SCons loads its SConscript files each time you run it. If you instead leave it running between builds, it doesn't need to reload the files. Pass the --interactive flag on your command line (ideally with LOAD= flags too) and then from the SCons prompt build with a command like b test_shell.

$ cd $CHROMIUM_ROOT/src/build
$ hammer --interactive
scons>>>b test_shell

Note that you'll need to restart hammer if you edit a .gyp file, or if you want to change the portion of the configuration you load with LOAD=.