There are instructions for other platforms linked from theget the code page.
Are you a Google employee? Seego/building-chrome-win instead.
Chromium requiresVisual Studio 2022 (>=17.0.0) to build. Visual Studio can also be used to debug Chromium. The clang-cl compiler is used but Visual Studio's header files, libraries, and some tools are required. Visual Studio Community Edition should work if its license is appropriate for you. You must install the “Desktop development with C++” component and the “MFC/ATL support” sub-components. This can be done from the command line by passing these arguments to the Visual Studio installer (see below for ARM64 instructions):
$ PATH_TO_INSTALLER.EXE^--addMicrosoft.VisualStudio.Workload.NativeDesktop^--addMicrosoft.VisualStudio.Component.VC.ATLMFC^--includeRecommended
If you want to build for ARM64 Win32 then some extra arguments are needed. The full set for that case is:
$ PATH_TO_INSTALLER.EXE^--addMicrosoft.VisualStudio.Workload.NativeDesktop^--addMicrosoft.VisualStudio.Component.VC.ATLMFC^--addMicrosoft.VisualStudio.Component.VC.Tools.ARM64^--addMicrosoft.VisualStudio.Component.VC.MFC.ARM64^--includeRecommended
Required
WARNING: On sufficiently old versions of Windows (1909 or earlier), dawn or related components may fail with a D3d-related error when using the 26100 SDK. This is because the d3dcompiler_47.dll file in the new SDK attempts to dynamically link versions of the Universal C Runtime which are not present by default on older systems. If you experience these errors, you can either update the UCRT on your system, or install the 22621 SDK and use the d3dcompiler_47.dll file included there, which statically links the UCRT.
This problem may also manifest as a DLL failure to load__CxxFrameHandler4.
If you haven't installedgit directly before, you can download a standalone installer for the latest version of Git For Windows from the Git website athttps://git-scm.com/download/win.
For more information on Git for Windows (which is a separate project from Git), seehttps://gitforwindows.org.
Note: if you are a Google employee, see git installation instructions atgo/building-chrome-win.
Note: this section is about updating a direct installation ofgit becausedepot_tools will soon stop bundlinggit.
Updating to the latest version ofgit will depend on which version you currently have installed. First, check yourgit version. From a cmd.exe shell, run:
$ git version| Current version | How to update to latest |
|---|---|
2.14.1 or earlier | You will need to manually uninstall Git, then follow the instructions above toinstall git |
2.14.2 to2.16.1 | In a cmd.exe shell, run:git update |
2.16.1(2) and later | In a cmd.exe shell, run:git update-git-for-windows |
depot_toolsFrom a command shell, navigate to the directory where you want to putdepot_tools and clone thedepot_tools repository. For example, if you want it to be cloned toC:\src\depot_tools:
$ cd C:\src$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
Add depot_tools to the start of your PATH (must be ahead of any installs of Python. Note that environment variable names are case insensitive).
C:\src\depot_tools, open: Control Panel → System and Security → SystemC:\src\depot_tools at the front (or at least in front of any directory that might already have a copy of Python). Note: If you can only modify your user-level PATH and the system PATH has a Python in it, you will be out of luck.Also, add a DEPOT_TOOLS_WIN_TOOLCHAIN environment variable in the same way, and set it to 0. This tells depot_tools to use your locally installed version of Visual Studio (by default, depot_tools will try to use a google-internal version).
You may also have to set variablevs2022_install to your installation path of Visual Studio 2022, likeset vs2022_install=C:\Program Files\Microsoft Visual Studio\2022\Professional.
From a cmd.exe shell, run:
$ gclientOn first run, gclient will install all the Windows-specific bits needed to work with the code, including msysgit and python.
After running gclient open a command prompt and typewhere python3 and confirm that the depot_toolspython3.bat comes ahead of any copies of python3.exe. Failing to ensure this can lead to overbuilding when using gn - seecrbug.com/611087.
App Execution Aliases can conflict with other installations of python on the system so disable these for ‘python.exe’ and ‘python3.exe’ by opening ‘App execution aliases’ section of Control Panel and unticking the boxes next to both of these that point to ‘App Installer’.
First, configure Git:
$ git config--global user.name"My Name"$ git config--global user.email"my-name@chromium.org"$ git config--global core.autocrlffalse$ git config--global core.filemodefalse$ git config--global core.preloadindextrue$ git config--global core.fscachetrue$ git config--global branch.autosetuprebase always
While not necessarily required it can be helpful to configure git to allow long path support (beyond the Windows MAX_PATH limit):
git config--global core.longpathstrue
Create achromium directory for the checkout and change to it. You can call this whatever you like and put it wherever you like, as long as the full path has no spaces. However there are some performance benefits for Googlers in placing the directory underC:\src\ (SeeWhy is my build slow?).
$ mkdir chromium&& cd chromium
Run thefetch tool fromdepot_tools to check out the code and its dependencies.
$ fetch chromiumIf you don't want the full repo history, you can save a lot of time by adding the--no-history flag tofetch.
Expect the command to take over an hour on even a fast connection, and many hours on slower ones. You should configure your PC so that it doesn't sleep or hibernate during the fetch or else errors may occur. If errors occur while fetching sub-repos then you can start over, or you may be able to correct them by going to the chromium/src directory and running this command:
$ gclient syncWhenfetch completes, it will have created a hidden.gclient file and a directory calledsrc in the working directory. The remaining instructions assume you have switched to thesrc directory:
$ cd srcOptional: You can alsoinstall API keys if you want your build to talk to some Google services, but this is not necessary for most development and testing purposes.
Chromium usesSiso as its main build tool along with a tool calledGN to generate.ninja files. You can create any number ofbuild directories with different configurations. To create a build directory:
$ gn genout\Default
Default with another name, but it should be a subdirectory ofout.gn help on the command line or read thequick start guide.There are some gn flags that can improve build speeds. You can specify these in the editor that appears when you create your output directory (gn args out\Default) or on the gn gen command line (gn gen out\Default --args="is_component_build = true is_debug = true"). Some helpful settings to consider using include:
is_component_build = true - this uses more, smaller DLLs, and may avoid having to relink chrome.dll after every change.enable_nacl = false - this disables Native Client which is usually not needed for local builds.target_cpu = "x86" - x86 builds may be slightly faster than x64 builds. Note that if you set this but don't setenable_nacl = false then build times may get worse.blink_symbol_level = 0 - turn off source-level debugging for blink to reduce build times, appropriate if you don't plan to debug blink.v8_symbol_level = 0 - turn off source-level debugging for v8 to reduce build times, appropriate if you don't plan to debug v8.In order to speed up linking you can setsymbol_level = 1 orsymbol_level = 0 - these options reduce the work the compiler and linker have to do. Withsymbol_level = 1 the compiler emits file name and line number information so you can still do source-level debugging but there will be no local variable or type information. Withsymbol_level = 0 there is no source-level debugging but call stacks still have function names. Changingsymbol_level requires recompiling everything.
When you build, specifychrome as the target to avoid building all test binaries as well.
In addition, Google employees should use RBE, a remote execution system. Detailed information is available internally but the relevant gn arg is:
use_remoteexec = trueGoogle employees can visitgo/building-chrome-win#setup-remote-execution for more information. For external contributors, remote execution for Windows builds is not supported.
You might be able to usesccache for the build process by enabling the following arguments:
cc_wrapper = "sccache" - assuming thesccache binary is in your%PATH%Many things can make builds slow, with Windows Defender slowing process startups being a frequent culprit. Have you ensured that the entire Chromium src directory is excluded from antivirus scanning (on Google machines this means putting it in asrc directory in the root of a drive)? Have you tried the different settings listed above, including different link settings and -j values? Have you asked on the chromium-dev mailing list to see if your build is slower than expected for your machine's specifications?
If you suspect that Defender is slowing your build then you can try Microsoft'sPerformance analyzer for Microsoft Defender Antivirus to investigate in detail.
Siso prints progress while building Chrome. It shows how many build processes are running at any given time, how many build steps have completed, how many build steps have completed per second, and how long the entire build and the longest build step has been running, as shown here:
$ autoninja-Cout\Defaultbaseninja:Entering directory`out\Default'...pre:0 local:0 remote:6461 15.6/s cache: 0.00% fallback:0[3829/64499] 4m47.48s 4m00.35s[remote]: LINK(DLL) base.dll base.dll.lib base.dll.pdb
This makes slow process creation immediately obvious and lets you tell quickly if a build is running more slowly than normal.
In addition, settingNINJA_SUMMARIZE_BUILD=1 tellsautoninja to print a build performance summary when the build completes, showing the slowest build steps and slowest build-step types, as shown here:
$set NINJA_SUMMARIZE_BUILD=1$ autoninja-Cout\DefaultbaseLongest build steps:0.1 weighted s to build obj/base/base/trace_log.obj(6.7 s elapsed time)0.2 weighted s to build nasm.exe, nasm.exe.pdb(0.2 s elapsed time)0.3 weighted s to build obj/base/base/win_util.obj(12.4 s elapsed time)1.2 weighted s to buildbase.dll,base.dll.lib(1.2 s elapsed time)Timeby build-step type:0.0 s weighted time to generate6.lib files(0.3 s elapsed time sum)0.1 s weighted time to generate25.stamp files(1.2 s elapsed time sum)0.2 s weighted time to generate20.o files(2.8 s elapsed time sum)1.7 s weighted time to generate4PEFile(linking) files(2.0 s elapsedtime sum)23.9 s weighted time to generate770.obj files(974.8 s elapsed time sum)26.1 s weighted time(982.9 s elapsed time sum,37.7x parallelism)839 build steps completed, average of32.17/s
The “weighted” time is the elapsed time of each build step divided by the number of tasks that were running in parallel. This makes it an excellent approximation of how “important” a slow step was. A link that is entirely or mostly serialized will have a weighted time that is the same or similar to its elapsed time. A compile that runs in parallel with 999 other compiles will have a weighted time that is tiny.
You can also generate these reports by manually running the script after a build:
$ python depot_tools\post_build_ninja_summary.py-Cout\Default
You can also get a visual report of the build performance withperfetto by uploading.ninja_log orsiso_trace.json.
Build Chromium (the “chrome” target) with Ninja using the command:
$ autoninja-Cout\Default chrome
autoninja is a wrapper that automatically provides optimal values for the arguments passed toninja.
You can get a list of all of the other build targets from GN by runninggn ls out\Default from the command line. To compile one, pass to Ninja the GN label with no preceding “//” (so for//chrome/test:unit_tests useautoninja -C out\Default chrome/test:unit_tests).
Ninja supports a specialsyntax^ to compile a single object file specifying the source file. For example,ninja -C out/Default ../../base/logging.cc^ compilesobj/base/base/logging.o.
With autoninja, you need to add^^ to preserve the trailing^.
$ autoninja-Cout\Default..\..\base\logging.cc^^
In addition tofoo.cc^^, Siso also supportsfoo.h^^ syntax to compile the correspondingfoo.o if it exists.
If you run abash shell, you can use the following script to ease invocation:
#!/bin/shfiles=("${@/#/..\/..\/}")autoninja-Cout/Default ${files[@]/%/^^}
This script assumes it is run fromsrc and your output dir isout/Default; it invokesautoninja to compile all given files. If you place it in your$PATH and name it e.g.compile, you can invoke like this:
$ pwd# Just to illustrate where this is run from/c/src$ compilebase/time/time.ccbase/time/time_unittest.cc...[0/47]5.56s S CXX obj/base/base/time.obj...[2/3]9.27s S CXX obj/base/base_unittests/time_unittest.obj...
Once it is built, you can simply run the browser:
$out\Default\chrome.exe
(The “.exe” suffix in the command is actually optional).
Tests are split into multiple test targets based on their type and where they exist in the directory structure. To see what target a given unit test or browser test file corresponds to, the following command can be used:
$ gn refsout\Default--testonly=true--type=executable--all chrome\browser\ui\browser_list_unittest.cc//chrome/test:unit_tests
In the example above, the target is unit_tests. The unit_tests binary can be built by running the following command:
$ autoninja-Cout\Default unit_tests
You can run the tests by running the unit_tests binary. You can also limit which tests are run using the--gtest_filter arg, e.g.:
$out\Default\unit_tests.exe--gtest_filter="BrowserListUnitTest.*"
You can find out more about GoogleTest at itsGitHub page.
Build themini_installer target to create a self-contained installer. This has everything needed to install your browser on a machine.
$ autoninja-Cout\Default mini_installer
See//chrome/installer/setup/README.md and//chrome/installer/mini_installer/README.md for more information.
To update an existing checkout, you can run
$ git rebase-update$ gclient sync-D
The first command updates the primary Chromium source repository and rebases any of your local branches on top of tip-of-tree (aka the Git branchorigin/main). If you don't want to use this script, you can also just usegit pull or other common Git commands to update the repo.
The second command syncs the subrepositories to the appropriate versions, deleting those that are no longer needed, and re-runs the hooks as needed.
You can use the Visual Studio IDE to edit and debug Chrome, with or without Intellisense support.
If you want to use Visual Studio Intellisense when developing Chromium, use the--ide command line argument togn gen when you generate your output directory (as described on theget the code page). This is an example when your checkout isC:\src\chromium and your output directory isout\Default:
$ gn gen--ide=vs--ninja-executable=autoninjaout\Default$ devenvout\Default\all.sln
GN will produce a fileall.sln in your build directory. It will internally use Ninja to compile while still allowing most IDE functions to work (there is no native Visual Studio compilation mode). If you manually run “gen” again you will need to resupply this argument, but normally GN will keep the build and IDE files up to date automatically when you build.
The generated solution will contain several thousand projects and will be very slow to load. Use the--filters argument to restrict generating project files for only the code you're interested in. Although this will also limit what files appear in the project explorer, debugging will still work and you can set breakpoints in files that you open manually. A minimal solution that will let you compile and run Chrome in the IDE but will not show any source files is:
$ gn gen --ide=vs --ninja-executable=autoninja --filters=//chrome --no-deps out\Default
You can selectively add other directories you care about to the filter like so:--filters=//chrome;//third_party/WebKit/*;//gpu/*.
There are other options for controlling how the solution is generated, rungn help gen for the current documentation.
It is also possible to debug and develop Chrome in Visual Studio without the overhead of a multi-project solution file. Simply “open” your chrome.exe binary withFile->Open->Project/Solution, or from a Visual Studio command prompt like so:devenv /debugexe out\Debug\chrome.exe <your arguments>. Many of Visual Studio's code exploration features will not work in this configuration, but by installing theVsChromium Visual Studio Extension you can get the source code to appear in the solution explorer window along with other useful features such as code search. You can add multiple executables of interest (base_unittests.exe, browser_tests.exe) to your solution withFile->Add->Existing Project... and change which one will be debugged by right-clicking on them inSolution Explorer and selectingSet as Startup Project. You can also change their properties, including command line arguments, by right-clicking on them inSolution Explorer and selectingProperties.
By default when you start debugging in Visual Studio the debugger will only attach to the main browser process. To debug all of Chrome, installMicrosoft's Child Process Debugging Power Tool. You will also need to run Visual Studio as administrator, or it will silently fail to attach to some of Chrome's child processes.
Try running
$ git update-index--test-untracked-cache
If the output ends withOK, then the following may also improve performance ofgit status:
$ git config core.untrackedCachetrue
You can significantly speed up git by usingfsmonitor. You should enable fsmonitor in large repos, such as Chromium and v8. Enabling it globally will launch many processes and consume excess commit/memory and probably isn't worthwhile. The command to enable fsmonitor in the current repo is:
$ git config core.fsmonitortrue