chromium在windows上的编译构建 Checking out and Building Chromium for Windows

1. 安装vs 2022

1.1 下载vs 2022的安装文件installer.exe

执行：这样才能装全需要的vc工具

C:\Users\xxx\Downloads>vs_community__99e705c49dda475888351e04486a9c2d.exe ^
--add Microsoft.VisualStudio.Workload.NativeDesktop ^
--add Microsoft.VisualStudio.Component.VC.ATLMFC ^
--includeRecommended

1.2 安装 Debugging Tools For Windows

The SDK Debugging Tools must also be installed. If the Windows 10 SDK was installed via the Visual Studio installer, then they can be installed by going to: Control Panel → Programs → Programs and Features → Select the “Windows Software Development Kit” → Change → Change → Check “Debugging Tools For Windows” → 点Change.

1.3 vs2019不是安装在默认路径需要指定。windows sdk不在默认路径

set vs2019_install=D:\Program Files (x86)\Microsoft Visual Studio\2019\Community
set WINDOWSSDKDIR=D:\Windows Kits\10

chromium 以前的编译不支持 vs2022_install，替换成2019的可以：set vs2019_install=C:\Program Files\Microsoft Visual Studio\2022\Community

打成安装包：

$ autoninja -C out\Default mini_installer

1.3 加速编译用：SCCACHE

这个是编译器的包装器，包装了gcc，msvc等。将编译结果存在cache里面，下次不用重新编译。具体看文档sccache 。需要下载安装软件 sscache。编译时添加参数：

cc_wrapper = "sccache" - assuming the sccache binary is in your %PATH%
chrome_pgo_phase = 0

缓存可以存储在本地或者文件服务器（s2, mem cache...)上。

本地的话：SCCACHE_DIR 设置存储路径: ~/.cache/sccache on Linux, %LOCALAPPDATA%\Mozilla\sccache on Windows, ~/Library/Caches/Mozilla.sccache on MacOS.

默认大小10G. 改变用 set SCCACHE_CACHE_SIZE ="1G".

最后的环境脚本设置 env.bat

set DEPOT_TOOLS_WIN_TOOLCHAIN=0
set depot_tools=c:\dev\chromium96\depot_tools
set PATH=%depot_tools%;C:\software\chromium-dev;%PATH%;

set SCCACHE_DIR=C:\temp\sscache
set SCCACHE_CACHE_SIZE ="40G"

cd  c:\dev\chromium96\src

rem gn gen --ide=vs --filters=//chrome --no-deps out\Default  --args="is_component_build=true is_debug=true enable_nacl=false target_cpu=\"x86\" v8_symbol_level=0 cc_wrapper =\"sccache\" chrome_pgo_phase = 0"
rem autoninja -C out\Default chrome

1.4 执行生成vs2022的sln文件和.ninja文件文件：

c:\dev\chromium96\src>gn gen --ide=vs --filters=//chrome --no-deps out\Default  --args="is_component_build=true is_debug=true enable_nacl=false target_cpu=\"x86\" v8_symbol_level=0 cc_wrapper =\"sccache\" chrome_pgo_phase = 0"
Generating Visual Studio projects took 2ms
Done. Made 16863 targets from 2892 files in 22310ms

1.5 build构建

c:\dev\chromium96\src>autoninja -C out\Default chrome
"C:\dev\chromium96\depot_tools\ninja.exe" -C out\Default chrome -j 34
ninja: Entering directory `out\Default'
[215/50025] CC obj/third_party/boringssl/boringssl/socket.obj

2. 调试工具安装

自动附加到chrome所有进程，可以启动就调试。

安装 Microsoft's Child Process Debugging Power Tool 来启动chrome自动附加它的子进程。插件装好后，需要到 debug 菜单下：

vs2022:

打开后：

把 “Enable Child process debugging” 打开。

Checking out and Building Chromium for Windows

There are instructions for other platforms linked from the get the code page.

Instructions for Google Employees

Are you a Google employee? See go/building-chrome-win instead.

System requirements

An x86-64 machine with at least 8GB of RAM. More than 16GB is highly recommended.
At least 100GB of free disk space on an NTFS-formatted hard drive. FAT32 will not work, as some of the Git packfiles are larger than 4GB.
An appropriate version of Visual Studio, as described below.
Windows 10 or newer.

Setting up Windows

Visual Studio

Chromium requires Visual 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 ^
--add Microsoft.VisualStudio.Workload.NativeDesktop ^
--add Microsoft.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 ^
--add Microsoft.VisualStudio.Workload.NativeDesktop ^
--add Microsoft.VisualStudio.Component.VC.ATLMFC ^
--add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^
--add Microsoft.VisualStudio.Component.VC.MFC.ARM64 ^
--includeRecommended

Required

Windows 11 SDK version 10.0.22621.2428. This can be installed separately or by checking the appropriate box in the Visual Studio Installer.
(Windows 11) SDK Debugging Tools 10.0.22621.755 or higher. This version of the Debugging tools is needed in order to support reading the large-page PDBs that Chrome uses to allow greater-than 4 GiB PDBs. This can be installed after the matching Windows SDK version is installed, from: Control Panel -> Programs and Features -> Windows Software Development Kit [version] -> Change -> Debugging Tools for Windows. If building on ARM64 Windows then you will need to manually copy the Debuggers\x64 directory from another machine because it does not get installed on ARM64 and is needed, whether you are building Chromium for x64 or ARM64 on ARM64.

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 22612 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.

git installation

Install git

If you haven't installed git directly before, you can download a standalone installer for the latest version of Git For Windows from the Git website at https://git-scm.com/download/win.

For more information on Git for Windows (which is a separate project from Git), see https://gitforwindows.org.

Note: if you are a Google employee, see go/building-chrome-win#install-git.

Update git

Note: this section is about updating a direct installation of git because depot_tools will soon stop bundling git.

Updating to the latest version of git will depend on which version you currently have installed. First, check your git 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 to install git
`2.14.2` to `2.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`

Install `depot_tools`

Warning: depot_tools will stop bundling Git for Windows from Sep 23, 2024 onwards. To prepare for this change, Windows users should install Git directly before then.

Download the depot_tools bundle and extract it somewhere (eg: C:\src\depot_tools).

Warning: DO NOT use drag-n-drop or copy-n-paste extract from Explorer, this will not extract the hidden “.git” folder which is necessary for depot_tools to autoupdate itself. You can use “Extract all…” from the context menu though.

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).

Assuming you unzipped the bundle to C:\src\depot_tools, open: Control Panel → System and Security → System
Select which PATH variable to edit.
- If you have Administrator access, you can edit the system PATH. Click Advanced system settings → Environment Variables. Under “System variables”, select the Path variable for editing.
- If you don't have Administrator access, you can edit your user-level PATH. Search for “Edit environment variables for your account”. Under “User variables for %USER%”, select the Path variable for editing.
Modify the Path variable by adding C:\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 variable vs2022_install to your installation path of Visual Studio 2022, like set vs2022_install=C:\Program Files\Microsoft Visual Studio\2022\Professional.

From a cmd.exe shell, run:

$ gclient

On first run, gclient will install all the Windows-specific bits needed to work with the code, including msysgit and python.

If you run gclient from a non-cmd shell (e.g., cygwin, PowerShell), it may appear to run properly, but msysgit, python, and other tools may not get installed correctly.
If you see strange errors with the file system on the first run of gclient, you may want to disable Windows Indexing.

Check python install

After running gclient open a command prompt and type where python3 and confirm that the depot_tools python3.bat comes ahead of any copies of python3.exe. Failing to ensure this can lead to overbuilding when using gn - see crbug.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’.

Get the code

First, configure Git:

$ git config --global user.name "My Name"
$ git config --global user.email "my-name@chromium.org"
$ git config --global core.autocrlf false
$ git config --global core.filemode false
$ git config --global core.preloadindex true
$ git config --global core.fscache true
$ 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.longpaths true

Create a chromium 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 under C:\src\ (See Why is my build slow?).

$ mkdir chromium && cd chromium

Run the fetch tool from depot_tools to check out the code and its dependencies.

$ fetch chromium

If you don't want the full repo history, you can save a lot of time by adding the --no-history flag to fetch.

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 sync

When fetch completes, it will have created a hidden .gclient file and a directory called src in the working directory. The remaining instructions assume you have switched to the src directory:

$ cd src

Optional: You can also install API keys if you want your build to talk to some Google services, but this is not necessary for most development and testing purposes.

Setting up the build

Chromium uses Ninja as its main build tool along with a tool called GN to generate .ninja files. You can create any number of build directories with different configurations. To create a build directory:

$ gn gen out\Default

You only have to run this once for each new build directory, Ninja will update the build files as needed.
You can replace Default with another name, but it should be a subdirectory of out.
For other build arguments, including release settings or using an alternate version of Visual Studio, see GN build configuration. The default will be a debug component build matching the current host operating system and CPU.
For more info on GN, run gn help on the command line or read the quick start guide.

Faster builds

Reduce file system overhead by excluding build directories from antivirus and indexing software.
Store the build tree on a fast disk (preferably SSD).
The more cores the better (20+ is not excessive) and lots of RAM is needed (64 GB is not excessive).

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 set enable_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 set symbol_level = 1 or symbol_level = 0 - these options reduce the work the compiler and linker have to do. With symbol_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. With symbol_level = 0 there is no source-level debugging but call stacks still have function names. Changing symbol_level requires recompiling everything.

When invoking ninja, specify ‘chrome’ as the target to avoid building all test binaries as well.

Use Reclient

In addition, Google employees should use Reclient, a distributed compilation system. Detailed information is available internally but the relevant gn arg is:

use_remoteexec = true

Google employees can visit go/building-chrome-win#setup-remote-execution for more information. For external contributors, Reclient does not support Windows builds.

Use SCCACHE

You might be able to use sccache for the build process by enabling the following arguments:

cc_wrapper = "sccache" - assuming the sccache binary is in your %PATH%

Why is my build slow?

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 a src 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's Performance analyzer for Microsoft Defender Antivirus to investigate in detail.

The next step is to gather some data. If you set the NINJA_SUMMARIZE_BUILD environment variable to 1 then autoninja will do three things. First, it will set the NINJA_STATUS environment variable so that ninja will print additional information while building Chrome. It will show 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 build has been running, as shown here:

$ set NINJA_SUMMARIZE_BUILD=1
$ autoninja -C out\Default base
ninja: Entering directory `out\Default'
[1 processes, 86/86 @ 2.7/s : 31.785s ] 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, setting NINJA_SUMMARIZE_BUILD=1 tells autoninja 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 -C out\Default base
Longest 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 build base.dll, base.dll.lib (1.2 s elapsed time)
Time by build-step type:
       0.0 s weighted time to generate 6 .lib files (0.3 s elapsed time sum)
       0.1 s weighted time to generate 25 .stamp files (1.2 s elapsed time sum)
       0.2 s weighted time to generate 20 .o files (2.8 s elapsed time sum)
       1.7 s weighted time to generate 4 PEFile (linking) files (2.0 s elapsed
time sum)
      23.9 s weighted time to generate 770 .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 of 32.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 -C out\Default

Finally, setting NINJA_SUMMARIZE_BUILD=1 tells autoninja to tell Ninja to report on its own overhead by passing “-d stats”. This can be helpful if, for instance, process creation (which shows up in the StartEdge metric) is making builds slow, perhaps due to antivirus interference due to clang-cl not being in an excluded directory:

$ set NINJA_SUMMARIZE_BUILD=1
$ autoninja -C out\Default base
metric                  count   avg (us)        total (ms)
.ninja parse            3555    1539.4          5472.6
canonicalize str        1383032 0.0             12.7
canonicalize path       1402349 0.0             11.2
lookup node             1398245 0.0             8.1
.ninja_log load         2       118.0           0.2
.ninja_deps load        2       67.5            0.1
node stat               2516    29.6            74.4
depfile load            2       1132.0          2.3
StartEdge               88      3508.1          308.7
FinishCommand           87      1670.9          145.4
CLParser::Parse         45      1889.1          85.0

You can also get a visual report of the build performance with ninjatracing. This converts the .ninja_log file into a .json file which can be loaded into chrome://tracing:

$ python ninjatracing out\Default\.ninja_log >build.json

Build Chromium

Build Chromium (the “chrome” target) with Ninja using the command:

$ autoninja -C out\Default chrome

autoninja is a wrapper that automatically provides optimal values for the arguments passed to ninja.

You can get a list of all of the other build targets from GN by running gn 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 use autoninja -C out\Default chrome/test:unit_tests).

Compile a single file

Ninja supports a special syntax ^ to compile a single object file specifying the source file. For example, ninja -C out/Default ../../base/logging.cc^ compiles obj/base/base/logging.o.

With autoninja, you need to add ^^ to preserve the trailing ^.

$ autoninja -C out\Default ..\..\base\logging.cc^^

In addition to foo.cc^^, Siso also supports foo.h^^ syntax to compile the corresponding foo.o if it exists.

If you run a bash shell, you can use the following script to ease invocation:

#!/bin/sh
files=("${@/#/..\/..\/}")
autoninja -C out/Default ${files[@]/%/^^}

This script assumes it is run from src and your output dir is out/Default; it invokes autoninja 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
$ compile base/time/time.cc base/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
...

Run Chromium

Once it is built, you can simply run the browser:

$ out\Default\chrome.exe

(The “.exe” suffix in the command is actually optional).

Running test targets

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 refs out\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 -C out\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 its GitHub page.

Build an Installer

Build the mini_installer target to create a self-contained installer. This has everything needed to install your browser on a machine.

$ autoninja -C out\Default mini_installer

See //chrome/installer/setup/README.md and //chrome/installer/mini_installer/README.md for more information.

Update your checkout

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 branch origin/main). If you don't want to use this script, you can also just use git 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.

Editing and Debugging With the Visual Studio IDE

You can use the Visual Studio IDE to edit and debug Chrome, with or without Intellisense support.

Using Visual Studio Intellisense

If you want to use Visual Studio Intellisense when developing Chromium, use the --ide command line argument to gn gen when you generate your output directory (as described on the get the code page). This is an example when your checkout is C:\src\chromium and your output directory is out\Default:

$ gn gen --ide=vs --ninja-executable=C:\src\chromium\src\third_party\ninja\ninja.exe out\Default
$ devenv out\Default\all.sln

GN will produce a file all.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=C:\src\chromium\src\third_party\ninja\ninja.exe --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, run gn help gen for the current documentation.

Using Visual Studio without Intellisense

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 with File->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 the VsChromium 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 with File->Add->Existing Project... and change which one will be debugged by right-clicking on them in Solution Explorer and selecting Set as Startup Project. You can also change their properties, including command line arguments, by right-clicking on them in Solution Explorer and selecting Properties.

By default when you start debugging in Visual Studio the debugger will only attach to the main browser process. To debug all of Chrome, install Microsoft'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.

Improving performance of git commands

Configure git to use an untracked cache

Try running

$ git update-index --test-untracked-cache

If the output ends with OK, then the following may also improve performance of git status:

$ git config core.untrackedCache true

Configure git to use fsmonitor

You can significantly speed up git by using fsmonitor. 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.fsmonitor true

Checking out and Building Chromium for Windows

There are instructions for other platforms linked from the get the code page.

Instructions for Google Employees

Are you a Google employee? See go/building-chrome-win instead.

Visual Studio

Editing and Debugging With the Visual Studio IDE

System requirements

A 64-bit Intel machine with at least 8GB of RAM. More than 16GB is highly recommended.
At least 100GB of free disk space on an NTFS-formatted hard drive. FAT32 will not work, as some of the Git packfiles are larger than 4GB.
An appropriate version of Visual Studio, as described below.
Windows 10 or newer.

Setting up Windows

Visual Studio

Chromium requires Visual Studio 2017 (>=15.7.2) to build, but Visual Studio 2019 (>=16.0.0) is preferred. Visual Studio can also be used to debug Chromium, and version 2019 is preferred for this as it handles Chromium‘s large debug information much better. 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 ^
--add Microsoft.VisualStudio.Workload.NativeDesktop ^
--add Microsoft.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 ^
--add Microsoft.VisualStudio.Workload.NativeDesktop ^
--add Microsoft.VisualStudio.Component.VC.ATLMFC ^
--add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^
--add Microsoft.VisualStudio.Component.VC.MFC.ARM64 ^
--includeRecommended

-You must have the version 10.0.19041 or higher Windows 10 SDK installed. This can be installed separately or by checking the appropriate box in the Visual Studio Installer.

Install `depot_tools`

Download the depot_tools bundle and extract it somewhere.

Add depot_tools to the start of your PATH (must be ahead of any installs of Python). Assuming you unzipped the bundle to C:\src\depot_tools, open:

Control Panel → System and Security → System → Advanced system settings

If you have Administrator access, Modify the PATH system variable and put C:\src\depot_tools at the front (or at least in front of any directory that might already have a copy of Python or Git).

If you don't have Administrator access, you can add a user-level PATH environment variable and put C:\src\depot_tools at the front, but if your system PATH has a Python in it, you will be out of luck.

Also, add a DEPOT_TOOLS_WIN_TOOLCHAIN system 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 variable vs2017_install or vs2019_install or vs2022_install to your installation path of Visual Studio 2017 or 19 or 22, like set vs2019_install=C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional for Visual Studio 2019, or set vs2022_install=C:\Program Files\Microsoft Visual Studio\2022\Professional for Visual Studio 2022.

From a cmd.exe shell, run:

$ gclient

On first run, gclient will install all the Windows-specific bits needed to work with the code, including msysgit and python.

If you run gclient from a non-cmd shell (e.g., cygwin, PowerShell), it may appear to run properly, but msysgit, python, and other tools may not get installed correctly.
If you see strange errors with the file system on the first run of gclient, you may want to disable Windows Indexing.

Check python install

After running gclient open a command prompt and type where python and confirm that the depot_tools python.bat comes ahead of any copies of python.exe. Failing to ensure this can lead to overbuilding when using gn - see crbug.com/611087.

Get the code

First, configure Git:

$ git config --global user.name "My Name"
$ git config --global user.email "my-name@chromium.org"
$ git config --global core.autocrlf false
$ git config --global core.filemode false
$ git config --global branch.autosetuprebase always

Create a chromium 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):

$ mkdir chromium && cd chromium

Run the fetch tool from depot_tools to check out the code and its dependencies.

$ fetch chromium

If you don't want the full repo history, you can save a lot of time by adding the --no-history flag to fetch.

Expect the command to take 30 minutes on even a fast connection, and many hours on slower ones.

$ cd src

Optional: You can also install API keys if you want your build to talk to some Google services, but this is not necessary for most development and testing purposes.

Setting up the build

$ gn gen out/Default

You only have to run this once for each new build directory, Ninja will update the build files as needed.
You can replace Default with another name, but it should be a subdirectory of out.
For other build arguments, including release settings or using an alternate version of Visual Studio, see GN build configuration. The default will be a debug component build matching the current host operating system and CPU.
For more info on GN, run gn help on the command line or read the quick start guide.

Faster builds

Reduce file system overhead by excluding build directories from antivirus and indexing software.
Store the build tree on a fast disk (preferably SSD).
The more cores the better (20+ is not excessive) and lots of RAM is needed (64 GB is not excessive).

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 incremental linking.
enable_nacl = false - this disables Native Client which is usually not needed for local builds.
target_cpu = "x86" - x86 builds are slightly faster than x64 builds and support incremental linking for more targets. Note that if you set this but don‘t’ set enable_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 addition, Google employees should use goma, a distributed compilation system. Detailed information is available internally but the relevant gn arg is:

use_goma = true

To get any benefit from goma it is important to pass a large -j value to ninja. A good default is 10*numCores to 20*numCores. If you run autoninja then it will automatically pass an appropriate -j value to ninja for goma or not.

$ autoninja -C out\Default chrome

When invoking ninja specify ‘chrome’ as the target to avoid building all test binaries as well.

Still, builds will take many hours on many machines.

Use SCCACHE

You might be able to use sccache for the build process by enabling the following arguments:

cc_wrapper = "sccache" - assuming the sccache binary is in your %PATH%
chrome_pgo_phase = 0

Why is my build slow?

$ set NINJA_SUMMARIZE_BUILD=1
$ autoninja -C out\Default base
ninja: Entering directory `out\Default'
[1 processes, 86/86 @ 2.7/s : 31.785s ] 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.

$ set NINJA_SUMMARIZE_BUILD=1
$ autoninja -C out\Default base
Longest 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 build base.dll, base.dll.lib (1.2 s elapsed time)
Time by build-step type:
       0.0 s weighted time to generate 6 .lib files (0.3 s elapsed time sum)
       0.1 s weighted time to generate 25 .stamp files (1.2 s elapsed time sum)
       0.2 s weighted time to generate 20 .o files (2.8 s elapsed time sum)
       1.7 s weighted time to generate 4 PEFile (linking) files (2.0 s elapsed
time sum)
      23.9 s weighted time to generate 770 .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 of 32.17/s

You can also generate these reports by manually running the script after a build:

$ python depot_tools\post_build_ninja_summary.py -C out\Default

$ set NINJA_SUMMARIZE_BUILD=1
$ autoninja -C out\Default base
"c:\src\depot_tools\ninja.exe" -C out\Default base -j 10 -d stats
metric                  count   avg (us)        total (ms)
.ninja parse            3555    1539.4          5472.6
canonicalize str        1383032 0.0             12.7
canonicalize path       1402349 0.0             11.2
lookup node             1398245 0.0             8.1
.ninja_log load         2       118.0           0.2
.ninja_deps load        2       67.5            0.1
node stat               2516    29.6            74.4
depfile load            2       1132.0          2.3
StartEdge               88      3508.1          308.7
FinishCommand           87      1670.9          145.4
CLParser::Parse         45      1889.1          85.0

You can also get a visual report of the build performance with ninjatracing. This converts the .ninja_log file into a .json file which can be loaded into chrome://tracing:

$ python ninjatracing out\Default\.ninja_log >build.json

Build Chromium

Build Chromium (the “chrome” target) with Ninja using the command:

$ autoninja -C out\Default chrome

autoninja is a wrapper that automatically provides optimal values for the arguments passed to ninja.

You can get a list of all of the other build targets from GN by running gn 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 use ninja -C out/Default chrome/test:unit_tests`).

Run Chromium

Once it is built, you can simply run the browser:

$ out\Default\chrome.exe

(The “.exe” suffix in the command is actually optional).

Running test targets

You can run the tests in the same way. You can also limit which tests are run using the --gtest_filter arg, e.g.:

$ out\Default\unit_tests.exe --gtest_filter="PushClientTest.*"

You can find out more about GoogleTest at its GitHub page.

Update your checkout

To update an existing checkout, you can run

$ git rebase-update
$ gclient sync -D

The second command syncs the subrepositories to the appropriate versions, deleting those that are no longer needed, and re-runs the hooks as needed.

Editing and Debugging With the Visual Studio IDE

You can use the Visual Studio IDE to edit and debug Chrome, with or without Intellisense support.

Using Visual Studio Intellisense

$ gn gen --ide=vs out\Default
$ devenv out\Default\all.sln

$ gn gen --ide=vs --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, run gn help gen for the current documentation.

Using Visual Studio without Intellisense

electron的：

构建步骤（Windows）

遵循下面的步骤, 在 Windows 平台上构建 Electron。

前提条件

Windows 10 / Server 2012 R2 或更高版本
Visual Studio 2017 15.7.2 或更高版本 - 免费下载 VS 2019 社区版
- 请参阅Chromium构建文档，以了解有哪些Visual Studio 组件需要安装等详细信息。
- 如果您的 Visual Studio 安装在非默认目录中，您需要设置几个环境变量来将工具链指向您的安装路径。
  - vs2019_install = DRIVE:\path\to\Microsoft Visual Studio\2019\Community，用您当前已安装版本替换2019和Community以及用您当前安装Visual Studio的驱动器号替换DRIVE: 一般情况下将会是C:。
  - WINDOWSSDKDIR = DRIVE:\path\to\Windows Kits\10, replacing DRIVE: with the drive that Windows Kits is on. 一般情况下将会是C:。
- Python for Windows (pywin32) 扩展对于构建流程也是必需的。
Node.js
Git
Debugging Tools for Windows of Windows SDK 10.0.15063.468 if you plan on creating a full distribution since symstore.exe is used for creating a symbol store from .pdb files.
- 不同版本的SDK可以同时安装安装 SDK，打开 Visual Studio 安装程序，选择 更改→单个组件，向下滚动并选择适当的要安装的 Windows SDK 组件。另一个选择是查看 windows SDK 和仿真器存档并分别下载 SDK 的独立版本。
- 还必须安装 SDK 调试工具。如果已安装了 Windows 10 SDK 通过 Visual Studio 安装程序，然后可以用以下方式安装它们： 控制面板→程序→程序和功能→选择“Windows 软件开发工具包”→ 更改→更改→选中“Windows 调试工具”→更改。或者，您可以下载独立的 SDK 安装程序，并且使用它安装调试工具。

如果您当前没有安装 Windows， dev.microsoftedge.com 上有时间限制的 Windows 版本，你可以用来构建 Electron。

构建 Electron 完全由命令行脚本完成，无法通过 Visual Studio 完成。您可以使用任何编辑器开发 Electron，但将来将会使用 Visual Studio 构建支持。

注意: 即使 Visual Studio 不用于构建，但是仍然需要，因为我们需要它提供的构建工具链。

Exclude source tree from Windows Security

Windows Security doesn't like one of the files in the Chromium source code (see crbug.com/441184), so it will constantly delete it, causing gclient sync issues. You can exclude the source tree from being monitored by Windows Security by following these instructions.

构建

参照Build Instructions: GN

32 位构建

为了构建 32bit 版本，您需要通过 target_cpu = “x86" 作为 GN 参数。可以使用不同的 GN 输出目录（例如， out/Release-x86）和不同的参数，在 64 位目标旁边构建 32 位目标。

$ gn gen out/Release-x86 --args="import(\"//electron/build/args/release.gn\") target_cpu=\"x86\""

其他构建步骤完全一样。

Visual Studio 项目

要生成 Visual Studio 项目，可以传递 --ide=vs2017 参数给 gn gen：

$ gn gen out/Testing --ide=vs2017

故障排查

Command xxxx not found

如果你遇到了一个错误，类似 Command xxxx not found, 可以尝试使用 VS2015 Command Prompt 控制台来执行构建脚本.

Fatal internal compiler error: C1001

确保你已经安装了 Visual Studio 的最新安装包.

LNK1181: cannot open input file 'kernel32.lib'

重新安装 32位的 Node.js.

Error: ENOENT, stat 'C:\Users\USERNAME\AppData\Roaming\npm'

创建那个目录应该可以解决问题:

$ mkdir ~\AppData\Roaming\npm

node-gyp is not recognized as an internal or external command

如果你使用 Git Bash 来构建，或许会遇到这个错误，可以使用 PowerShell 或 VS2015 Command Prompt 来代替.

无法在“…”处创建目录：文件名太长

node.js 有一些极长的路径名，默认情况下，windows 上的 git 不能正确处理长路径名（即使 windows 支持它们）。这应该可以修复它：

$ git config --system core.longpaths true

刷新页面返回顶部

1. 安装vs 2022

1.1 下载vs 2022的安装文件installer.exe

1.2 安装 Debugging Tools For Windows

1.3 加速编译用：SCCACHE

1.4 执行生成vs2022的sln文件和.ninja文件文件：

1.5 build构建

2. 调试工具安装

最新 Checking out and Building Chromium for Windows

Checking out and Building Chromium for Windows

Instructions for Google Employees

System requirements

Setting up Windows

Visual Studio

git installation

Install git

Update git

Install depot_tools

Check python install

Get the code

Setting up the build

Faster builds

Use Reclient

Use SCCACHE

Why is my build slow?

Build Chromium

Compile a single file

Run Chromium

Running test targets

Build an Installer

Update your checkout

Editing and Debugging With the Visual Studio IDE

Using Visual Studio Intellisense

Using Visual Studio without Intellisense

Improving performance of git commands

Configure git to use an untracked cache

Configure git to use fsmonitor

Checking out and Building Chromium for Windows

Instructions for Google Employees

Contents

System requirements

Setting up Windows

Visual Studio

Install depot_tools

Check python install

Get the code

Setting up the build

Faster builds

Use SCCACHE

Why is my build slow?

Build Chromium

Run Chromium

Running test targets

Update your checkout

Editing and Debugging With the Visual Studio IDE

Using Visual Studio Intellisense

Using Visual Studio without Intellisense

Install `depot_tools`

Install `depot_tools`