The original address: chromium.googlesource.com/chromium/sr…

Original author:

Published: March 28, 2021

There are links to other platforms on the page where you get the code.

Note from a Google employee

Are you a Googler? See go/building- Chrome-win.

content

  • Tips for Google Employees
  • System requirements
  • Set up Windows
    • Visual Studio
  • The installation
  • Checking the Python installation
  • Get the code
  • Setting up the build
    • Faster setup
    • Why is my build slow?
  • Build Chromium
  • Run the Chromium
  • Run the test target
  • Update your Check out
    • Use Visual Studio IDE for editing and debugging

System requirements

  • 64-bit Intel machine with at least 8GB of RAM. More than 16GB is strongly recommended.
  • An NTFS hard disk must have at least 100GB free space. FAT32 will not be available because some Git package files are larger than 4GB.
  • A suitable version of Visual Studio, as described below.
  • Windows 10 or later.

Set up Windows

Visual Studio

Chromium requires Visual Studio 2017 (>=15.7.2) to build, but VS2019 is preferred (>=16.0.0). Visual Studio can also be used to debug Chromium, with VS2019 being the first choice as it can better handle Chromium’s extensive debugging information. Use the Clang-CL compiler, but use Visual Studio header files, libraries, and some tools. If its license is right for you, Visual Studio Community Edition should be available. You must install the “desktop development with C++” component and the “MFC/ATL support “sub-component. The installation can be done from the command line by passing these parameters to the Visual Studio installer (see ARM64 instructions below).

$ PATH_TO_INSTALLER.EXE ^
--add Microsoft.VisualStudio.Workload.NativeDesktop ^
--add Microsoft.VisualStudio.Component.VC.ATLMFC ^
--includeRecommended
Copy the code

If you want to build for ARM64 Win32, you will need some extra parameters. In this case, the complete set of parameters 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
Copy the code

You must have the Windows 10 SDK 10.0.19041 or later installed. You can install it separately, or you can select the appropriate box in the Visual Studio installer.

You must also install SDK debugging tools. If the Windows 10 SDKS were installed through the Visual Studio installer, you can install them as follows. Control Panel → Programs → Programs and Features → Select “Windows Software Development Kit “→ Change → Change → Check “Windows Debugging Tools “→ Change. Alternatively, you can download a separate SDK installer and use it to install debugging tools.

The installationdepot_tools

Download the depot_tools bundle and unzip it.

Warning. Do not extract from explorer using drag and drop or copy and paste. Doing so does not extract the hidden “.git “folder that is required for depot_tools to automatically update. You can use “Extract all…” in the right-click menu. .

Add depot_tools to your PATH (must be before any Python installation). Assuming you unzip to C:\ SRC /depot_tools, open it.

Control Panel → System and Security → System → Advanced System Settings

If you have administrator privileges, change the PATH system variable to put C:\ SRC \depot_tools in front of it (or at least in front of any directory that might already have a copy of Python or Git).

If you don’t have Administrator privileges, you can add a user-level PATH environment variable and put C: SRC \depot_tools in front of it, but if you have Python in your system PATH, you’re out of luck.

Also, add a DEPOT_TOOLS_WIN_TOOLCHAIN system variable in the same way and set it to 0. This will tell depot_Tools to use your locally installed version of Visual Studio (by default, Depot_tools will try using the Google-internal version).

You may also need to set the variables VS2017_install or VS2019_install to your Visual Studio 2017 or 19 installation path, Set vs2019_install=C: Program Files (x86)\Microsoft Visual Studio\2019\Professional for Visual Studio 2019

From the cmd.exe shell, run the command gclient (no arguments). On the first run, gClient installs all the Windows-specific bits needed to use the code, including Msysgit and Python.

  • If you run GClient from a non-cmd shell(such as Cygwin, PowerShell), it may look like it will work, but msysgit, Python, and other tools may not be installed correctly.
  • If you see strange errors in the file system the first time you run GClient, you may want to disable Windows indexes.

Checking the Python installation

After running gclient, open a command prompt, type Where python, and confirm that depot_tools python.bat is ahead of any copy of python.exe. Failure to ensure this can lead to over-build when using GN – see crbug.com/611087.

Application execution aliases may conflict with other Python installers on your system, so you can disable “python.exe “and “python3.exe” by opening the” Application Execution Aliases “section of the control panel and unchecking the box next to” Application Setup “.

Get the code

First, configure Git.

$ git config --global user.name "My Name"
$ git config --global user.email "[email protected]"
$ git config --global core.autocrlf false
$ git config --global core.filemode false
$ git config --global branch.autosetuprebase always
Copy the code

Create a Chromium directory for Checkout and change it to the Chromium directory (you can call it whatever you like and put it wherever you like, as long as there are no Spaces in the full path).

$ mkdir chromium && cd chromium
Copy the code

Run the FETCH tool in depot_tools to examine the code and its dependencies.

$ fetch chromium
Copy the code

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

Even in the case of fast connections, this command takes 30 minutes and hours in the slower case.

When the fetch completes, it creates a hidden.gclient file and a directory named SRC in the working directory. The rest of the instructions assume you have switched to the SRC directory.

$ cd src
Copy the code

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 the primary build tool and GN to generate.ninja files. You can create any number of compile directories with different configurations. Create a compile directory.

$ gn gen out/Default
Copy the code
  • For each new build directory, you only need to run it once, and Ninja will update the build files as needed.
  • You can use other names insteadDefaultBut it should beoutA subdirectory of.
  • For other build parameters, including release Settings or using alternative versions of Visual Studio, see GN Build Configuration. By default, a debug component will be built that matches the current host operating system and CPU.
  • For more information about GN, run it on the command linegn helpOr readQuick 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 you have, the better (20 or more is fine), and you need a lot of memory (64GB is fine).

There are some GN flags to speed up builds. You can specify these flags in the editor that appears when you create the output directory (gn args out/Default), Or specify it in gn Gen command line (gn Gen out/Default –args=” IS_Component_build = true is_debug = true”). Some useful Settings to consider are include.is_Component_build = true.

  • is_component_build = true– This will use more, smaller DLLs and incremental links.
  • enable_nacl = false– This will disable Native builds that are not normally needed.
  • target_cpu = "x86"– x86 builds are slightly faster than X64 builds and support incremental linking of more targets. Note that if you set this but don’t set enable_nacl = false, the compile time may be worse.
  • blink_symbol_level = 0– Turn off blink source level debugging to reduce build time, which is appropriate if you don’t plan to debug Blink.

To speed up linking, you can set symbol_level = 1 or symbol_level = 0– these options reduce the work of the compiler and linker. In the case of symbol_level = 1, the compiler emits file name and line number information, so you can still debug at the source level, but without local variable or type information. When symbol_level = 0, there is no source-level debugging, but the call stack still has function names. Changing symbol_level requires recompiling everything.

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, you must pass ninja a large -j value. A good default is 10numCores to 20numCores. If you run Autoninja, it will automatically pass an appropriate -j value to Ninja for Goma to use.

$ autoninja -C out/default chrome
Copy the code

When calling NINJA, specify ‘Chrome’ as the target to avoid building all the test binaries.

On many machines, however, compilation takes many hours.

Why is my build slow?

Many things can cause builds to be slow, and Windows Defender is a common culprit that slows processes to start. Did you make sure the entire Chromium SRC directory was kept out of the reach of anti-virus software (on Google machines, that means putting it in the SRC directory at the root of the drive)? Have you tried the different Settings listed above, including different link Settings and -j values? Did you ask on the chromium-Dev mailing list to see if you were compiling slower than your machine’s specifications expected?

The next step is to collect some data. If you set the NINJA_SUMMARIZE_BUILD environment variable to 1, Autoninja does three things. First, it sets the NINJA_STATUS environment variable so Ninja will print out additional information when building Chrome. It shows how many build processes are running at any given time, how many build steps have been completed, how many build steps have been 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/[email protected] /s: 31.785s] LINK(DLL) base.dll base.dll. Lib base.dllCopy the code

This way, slow process creation will immediately show up, allowing you to quickly determine if the build is running slower than normal.

In addition, setting NINJA_SUMMARIZE_BUILD=1 tells Autoninja to print a build performance summary after the build is complete, showing the slowest build step and the slowest build step type, as shown in the figure.

$ setNINJA_SUMMARIZE_BUILD=1 $ autoninja -C out\Default base Longest build steps: Obj (elapsed time) 0.1 weighted s to build obj/base/base/trace_log.obj (elapsed time) 0.2 weighted s to build nasm.exe, Nasm.exe.pdb (elapsed time) 0.3s weighted s to build obj/base/ win_util. Obj (elapsed time) 1.2s C to Build Base.dll, base.dll. Lib (elapsed time) time by Build-steptype: 0.0s weighted time to generate 6. Lib files (0.1s Elapsed time sum) 0.1s weighted time to generate 25. Stamp files O files (2.8s Elapsed time sum) 1.7s weighted time to generate 20.o files (2.8s Elapsed time sum) 1.7s weighted time to Generate 4 PEFile (linking) files (2.0s Elapsed time sum) 23.9s weighted time to generate 770.obj files (974.8s) Elapsed time sum) 75s weighted time (elapsed time sum, 75s x Parallelism) 75s Build steps completed, Average of 32.17 / sCopy the code

The weighted “time” is the elapsed time of each build step divided by the number of tasks running in parallel. This makes it a good approximation of how “important” a slow step is. The weighted time of a fully or mostly serialized link will be the same or similar to its elapsed time. A compiler running in parallel with 999 other compilers would have a very small weighted time.

You can also manually run scripts to generate these reports after compilation.

$ python depot_tools/post_build_ninja_summary.py -C out/Default...
Copy the code

Finally, NINJA_SUMMARIZE_BUILD=1 tells Autoninja to tell Ninja to report its spending by passing “-d STATS “. For example, it helps if the process creation (shown in StartEdge metrics) makes the build slow, perhaps because clang-Cl is not in the excluded directory and is being interfered with by anti-virus software.

$ 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
Copy the code

You can also get visual reports on build performance via NinjatRacing. This converts the. Ninja_log file to a. Json file and loads it into Chrome :// Tracing.

$ python ninjatracing out/Default/.ninja_log >build.json
Copy the code

Build Chromium

Build Chromium (the “Chrome” target) using Ninja.

$ autoninja -C out/Default chrome
Copy the code

Autoninja is a wrapper that automatically provides the best value for the parameters passed to Ninja.

You can get a list of all the other compilation targets in GN by running GN ls out/Default on the command line. To compile a target, pass the GN tag to Ninja without the prefix “//” (so for // Chrome /test:unit_tests, use Ninja -c out/Default chrome/test:unit_tests’).

Run the Chromium

Once built, you can run the browser directly.

$ outDefault\chrome.exe.
Copy the code

The “.exe “suffix in the command is actually optional.

Run the test target

You can run these tests in the same way. You can also use –gtest_filter arg to limit the test to run, for example:

$ out/Default/unit_tests.exe --gtest_filter="PushClientTest.*"
Copy the code

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

Update your Check out

To update an existing checkout method, you can perform

$ git rebase-update
$ gclient sync -D
Copy the code

The first command is to update the Chromium source library and re-establish your local branch on top of the tree (i.e. Origin/Master for Git branches). If you don’t want to use this script, you can also use Git pull or other common Git commands to update your repository.

The second command synchronizes the subrepository to the appropriate version, removes the versions that are no longer needed, and reruns the hooks as needed.

Use Visual Studio IDE for editing and debugging

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

Use Visual Studio Intellisense

If you want to use Visual Studio Intellisense while developing Chromium, use the — IDE command line argument to GN Gen (as described on the Get Code page) when you generate the output directory.

$ gn gen --ide=vs out/default
$devenv out/Default/all.sln
Copy the code

GN will generate an all.sln file in your build directory. It will compile internally using Ninja, while still allowing most IDE functions to work (there is no native Visual Studio compilation mode). If you run “gen” manually again, you will need to resupply this parameter, but GN will usually automatically keep the build files and IDE files up to date as you build.

The resulting solution will contain thousands of projects and will be slow to load. Use the –filters parameter to limit the generated project file to contain only the code you are interested in. While this also limits the files that appear in the project Explorer, debugging still works, and you can set breakpoints in manually opened files. A minimal solution is to let you compile and run Chrome in the IDE without showing any source files.

$ gn gen --ide=vs --filters=//chrome --no-deps out/Default
Copy the code

You can optionally add other directories you care about to the filter, like this. –filter=//chrome; //third_party/WebKit/*; / / the gpu / *.

There are other options to control how the solution is generated by running GN Help Gen to view the current documentation.

Use Visual Studio without Intellisense

You can also debug and develop the Chrome browser in Visual Studio without the overhead of multi-project solution files. Simply use File->Open->Project/Solution to “Open” your Chrome.exe binary, or Open it from the Visual Studio command prompt like this: Devenv /debugexe out/Debug\ Chrom.exe

Many of Visual Studio’s code exploration features are not available in this configuration, but by installing the VsChromium Visual Studio extension, you can have the source code appear in the Solution Explorer window along with other useful features such as code search. You can go to File->Add->Existing Project… Add multiple executable files of interest (base_unittests.exe, browser_tests.exe) to your solution, And change which one will be debugged by right clicking on them in the Solution Explorer and selecting Set as Startup Project. You can also change their Properties, including command-line parameters, by right-clicking them in the Solution Explorer and selecting Properties.

By default, when you start debugging in Visual Studio, the debugger is only attached to the main browser process. To debug all Chrome browsers, install Microsoft’s Child Process Debugging Power Tool. You also need to run Visual Studio as an administrator, or it will silently fail to attach to some of Chrome’s child processes.

Translation via www.DeepL.com/Translator (free version)