If you've never built Chromium on Windows, first read Getting Started.
is run. See
Getting the code
Create a directory (with no spaces anywhere in the path name) to hold your source code. In this example we'll assume it's
c:/trunk, but other names are fine.
Before syncing the client, visit the Chromium Buildbot waterfall and make sure it says
tree OPEN at the top. If you sync while the tree is closed, the code may not compile or link. Once you've verified that the tree is open, run the following commands (using your directory in place of
c:/trunk):
cd c:/trunk
gclient config
http://src.chromium.org/svn/trunk/src
gclient sync
You can expect this to take about an hour.
gclient config only needs to be run once to set up your working directory. It creates a
.gclient file in your source directory that identifies the corresponding structure to pull from the repository.
gclient sync will create several subdirectories in your tip directory. To update your tree in the future, you only need to run
gclient syncfrom that directory. More information about gclient is available from the gclient wiki.
Building Chromium
Open the
chrome/chrome.sln solution file in Visual Studio and
build the solution. This can take from 15 to 40 minutes.
If you just want the Chromium browser, and none of the tests, you can speed up your
build by right-clicking
chrome_exe in the solution explorer and selecting
Build. You may want to make sure this project is the
Startup project (which will display as bold) by right-clicking it and selecting
Set as Startup Project. This will make Chromium (as opposed to some random test)
build and run when you press F5.
Accelerating the build
In decreasing order of speedup:
- Install Microsoft hotfix 935225.
- Use a true multicore processor (ie. an Intel Core Duo 2; not a Pentium 4 HT).
- Use 3 parallel builds. In Visual Studio 2005, you will find the option in Tools > Options... > Projects and Solutions > Build and Run > maximum number of parallel project builds.
- Disable your anti-virus software for .ilk, .pdb, .cc, .h files and only check for viruses on modify. Disable scanning the directory where your sources reside. Don't do anything stupid.
- Store and build the Chromium code on a second hard drive. It won't really speed up the build but at least your computer will stay responsive when you do gclient sync or a build.
- Defragment your hard drive regularly.
- Disable virtual memory.
Optional
Rebuild / Clean
You can use
Rebuild and
Clean on individual projects to rebuild them. However, because of the large number of files generated by the
build system, avoid using
Rebuild All or
Clean All - these do
not erase everything! Instead delete the entire output directory (
chrome/Debug or
chrome/Release).
Build Chromium with JavaScriptCore
Our default solution file is
chrome.sln which includes the V8 JavaScript engine. If you need to make a reference
build of Chromium using JavaScriptCore, you should use the
chrome_kjs.sln solution file. You will also need to set
JS_ENGINE_TYPE=_kjs in your environment, then run Visual Studio (
devenv) from that same command line. From the command line, type:
C:/trunk/src/chrome> set JS_ENGINE_TYPE=_kjs
C:/trunk/src/chrome> devenv chrome_kjs.sln
If the
devenv command isn't found, run the
Visual Studio 2005 Command Promptin your
Start menu (by default, under
Microsoft Visual Studio 2005 > Tools). This will set up the correct environment to run Visual Studio from the command line.
In Cygwin, use the following command:
$ JS_ENGINE_TYPE=_kjs devenv chrome_kjs.sln
Troubleshooting
Build failures on Vista
If you
build on Vista, watch out for security issues. Make sure that the folder where you checked out your files is writable for users and not only for admins.
Compilation failures
Some common things to think about when you have weird compilation failures:
- Make sure you have SP1 for Visual Studio 2005. It's required. Really.
- Sometimes Visual Studio does the wrong thing when building Chromium and gets stuck on a bogus error. A good indication of this is if it is only failing for one person but others (including the Buildbots) are not complaining. To resolve this, try the following steps:
- Close Visual Studio.
- Sync to the tip of tree and ensure there are no conflicts ("svn st" should not show any "C"s in front of files that you've changed).
- If there were conflicts, sync again after resolving them.
- Manually erase the output directory (chrome/Debug and chrome/Release. Using the command line, you can use "erase /S /Q Debug Release" from the chrome directory to do this, or "rm -rf Debug Release" if you have Unix-like tools installed.
- Restart Visual Studio and open the Chromium solution.
- Rebuild the solution.
If it still doesn't work, repeating this process probably won't help.
chrome_kjs.sln tempfile problems
If, while building
JavaScriptCore, you see errors like:
3>Error in tempfile() using /tmp/dftables-XXXXXXXX.in: Parent directory (/tmp/) is not writable
3> at /cygdrive/c/b/slave/WEBKIT~1/build/webkit/third_party/JavaScriptCore/pcre/dftables line 236
3>make: *** [chartables.c] Error 255
...it's because the Cygwin installation included in the Chromium source is having trouble mapping the NT ACL to POSIX permissions. This seems to happen when Chromium is checked out into a directory for which Cygwin can't figure out the permissions in the first place, possibly when the directory is created from within a Cygwin environment before running
mkpasswd. Cygwin then imposes its own access control, which is incorrectly restrictive. As a workaround, do one of the following:
- Edit the NT permissions on third_party/cygwin/tmp to allow Modify and Writeactions for Everyone and machine/Users. Cygwin is able to figure this out. Or,
- Figure out what went wrong with your checkout and try again - try doing the checkout from cmd instead of from a Cygwin shell, then verify that the permissions aren't completely blank in your Cygwin installation. Or,
- Bypass Cygwin's access control (NT's will still be in effect) by editingwebkit/build/JavaScriptCore/prebuild.bat and webkit/build/WebCore/prebuild.bat to include the following line before invoking anything that uses Cygwin:
set CYGWIN=nontsec
Only one of these solutions should be needed.