chromiumのビルドとデバッグの手順（Visual Studio）

前書き

chromeブラウザの動作確認のためchromiumをビルドしてデバッグをする必要がありましたので、
Visual Studio上でビルドとデバッグをするための手順を備忘録として残しておきます。

基本的には公式の手順をChat GPTによって翻訳したものになります。説明が不足している箇所は「補足」として書き足しています。

Windowsのセットアップ

Visual Studio

ChromiumのビルドにはVisual Studio 2022 (>=17.0.0)が必要です。また、Visual Studioを使用してChromiumをデバッグすることも可能です。ビルドにはclang-clコンパイラを使用しますが、Visual Studioのヘッダーファイル、ライブラリ、一部のツールが必要です。

Visual Studio Community Editionも使用できますが、ライセンス条件が適切であることを確認してください。以下のコンポーネントをインストールする必要があります:

“Desktop development with C++”
“MFC/ATL support”

これらは、Visual Studioインストーラーに以下の引数を渡すことでコマンドラインからインストールできます（ARM64の手順は後述）。

1
2
3
4


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

Visual Studioの補足

コマンドラインだとなんのこっちゃってなる方が多いと思うので、GUIのインストーラーでは「デスクトップとモバイル」の「C++ によるデスクトップ開発」にチェックを入れて、
右側の「インストールの詳細」の「最新 v143 ビルドツールの C++ MFC (x86 & x64)」にチェックを入れてインストールすればOKです。
「Microsoft.VisualStudio.Workload.NativeDesktop」が「C++ によるデスクトップ開発」、
「最新 v143 ビルドツールの C++ MFC (x86 & x64)」が「Microsoft.VisualStudio.Component.VC.ATLMFC」ということになります。
「C++ によるデスクトップ開発」と「最新 v143 ビルドツールの C++ MFC (x86 & x64)」

ARM64 Win32向けのビルド

ARM64 Win32向けにビルドする場合は、以下の追加引数が必要です。

1
2
3
4
5
6


$ 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

ARM64 Win32向けのビルドの補足

ARM向けのコンポーネントは右側の「インストールの詳細」には表示されないため、上部の「個別のコンポーネント」タブをクリックします。

「コンポーネントを検索する」のテキストボックスに「ARM64/ARM64EC」と入力します。
「最新 v143 ビルドツール用 C++ MFC (ARM64/ARM64EC)」が「Microsoft.VisualStudio.Component.VC.MFC.ARM64」、
「MSVC v143 - VS 2022 C++ ARM64/ARM64EC ビルドツール (最新)」が「Microsoft.VisualStudio.Component.VC.Tools.ARM64」になりますのでチェックを入れます。
（※「最新 v143 ビルドツール用 C++ ATL (ARM64/ARM64EC)」はMFCのコンポーネントに必須のため自動的にチェックが入ります）
「最新 v143 ビルドツール用 C++ MFC (ARM64/ARM64EC)」と「MSVC v143 - VS 2022 C++ ARM64/ARM64EC ビルドツール (最新)」

インストールを実行

必要なコンポーネントにチェックを付けたら「インストール」（または「変更」）を実行しましょう。
Visual Studio 2022の「インストールを実行」

結構時間がかかるので気長に待ちます。
Visual Studio 2022の「インストールを実行中…」

必要条件

Windows 11 SDK (バージョン10.0.22621.2428)

個別にインストールするか、Visual Studioインストーラーで適切なボックスをチェックしてください。

Windows 11 SDKの補足

「C++ によるデスクトップ開発」を選択した時点でチェックがついているはずなので気にしなくていいです。
Windows 11 SDKのチェック確認

SDKデバッグツール (バージョン10.0.22621.755以上)

Chromeが4 GiBを超えるPDBをサポートするために、大ページPDBを読み取るデバッグツールが必要です。これをインストールするには、該当するWindows SDKバージョンをインストール後、以下を行います:
1. コントロールパネル -> プログラムと機能 -> Windows Software Development Kit [バージョン]
2. 変更 -> Debugging Tools for Windows

SDKデバッグツールの補足

「Debugging Tools for Windows」を有効にするには下記を実施してください。

コントロールパネルを起動

コントロールパネル

プログラムを選択

コントロールパネル → プログラム

プログラムと機能を選択

コントロールパネル → プログラム → プログラムと機能

「プログラムと機能の検索」テキストボックスに「Windows Software Development Kit」と入力

コントロールパネル → プログラム → プログラムと機能

複数出てきたら、「インストール日」が最新のものを選択

コントロールパネル → プログラム → プログラムと機能

選択後上部の「変更」をクリック

コントロールパネル → プログラム → プログラムと機能

「Change」を選択後「Next」をクリック

コントロールパネル → プログラム → プログラムと機能 → Windows Software Development Kit → 変更

「Debugging Tools for Windows」にチェックを入れて「Change」をクリック

コントロールパネル → プログラム → プログラムと機能 → Windows Software Development Kit → 変更
しばらく待ちます。（そんなに時間はかかりません）

下記画面が表示されれば変更完了です。

ARM64 Windowsでのデバッグツール

ARM64 Windowsでビルドする場合、他のマシンからDebuggers\x64ディレクトリを手動でコピーする必要があります。このディレクトリはARM64にはインストールされず、Chromiumをx64またはARM64向けにビルドする際に必要です。

注意事項

古いバージョンのWindows (1909以前) では、dawnまたは関連コンポーネントが26100 SDK使用時にD3d関連エラーを引き起こす可能性があります。
- 原因: 新しいSDKに含まれるd3dcompiler_47.dllが、古いシステムにデフォルトで存在しないバージョンのUniversal C Runtime (UCRT) を動的リンクするためです。
- 解決方法:
  - システムのUCRTを更新する
  - 22612 SDKをインストールし、そこに含まれる静的リンクされたd3dcompiler_47.dllを使用する

この問題は、__CxxFrameHandler4を読み込めないDLLエラーとしても現れる可能性があります。

gitのインストール

gitをインストールする

まだgitを直接インストールしていない場合は、Gitの公式サイトから、最新バージョンのGit for Windows用スタンドアロンインストーラーをダウンロードできます。

Git for Windowsに関する詳細情報は、こちらをご覧ください。

gitを更新する

注記: このセクションは、gitを直接インストールしている場合に適用されます。depot_toolsが近い将来gitをバンドルしなくなるためです。

現在インストールされているgitのバージョンによって、最新バージョンへの更新方法が異なります。まず、gitのバージョンを確認します。cmd.exeシェルで次のコマンドを実行してください:

1

$ git version

バージョン別の更新方法

現在のバージョン	更新方法
2.14.1以前	Gitを手動でアンインストールし、上記のインストール手順に従って再インストールしてください。
2.14.2 ～ 2.16.1	cmd.exeシェルで以下のコマンドを実行してください: `git update`
2.16.1(2)以降	cmd.exeシェルで以下のコマンドを実行してください: `git update-git-for-windows`

depot_toolsのインストール

depot_tools は、Googleが作った ソースコード管理とビルド補助ツールのセット です。

主な使い道：

Googleの大規模プロジェクト（例: Chrome、V8、WebRTC）のコードをダウンロード、管理、ビルドする。
依存ライブラリを自動でまとめて取ってきたり、設定したりする。

ざっくり言うとGoogle製プロジェクトを簡単に触れるようにする便利ツール箱です。

注意:
2024年9月23日以降、depot_toolsにはGit for Windowsが同梱されなくなります。この変更に備えて、それ以前にGitを直接インストールしてください。

1. depot_toolsのダウンロードと解凍

depot_tools バンドルをダウンロードし、任意の場所に解凍します（例: C:\src\depot_tools）。
注意: エクスプローラーでドラッグ＆ドロップやコピー＆ペーストで解凍しないでください。これでは隠しフォルダー「.git」が解凍されず、depot_toolsの自動更新ができなくなります。ただし、コンテキストメニューの「すべて展開」を使用することは可能です。

2. PATHに depot_tools を追加

PATH環境変数の先頭にdepot_toolsを追加します（Pythonのインストールパスより前に配置する必要があります）。
手順:
1. C:\src\depot_toolsに解凍した場合:
  コントロールパネル → システムとセキュリティ → システムを開く。
  Win + R キーを押して「ファイル名を指定して実行」を開きます。
  「SystemPropertiesAdvanced」を入力し、「OK」をクリックします。
2. PATH変数の編集:
  - 管理者権限がある場合:
    システムの詳細設定 → 環境変数 → システム変数セクションのPathを選択して編集します。
  - 管理者権限がない場合:
    「アカウントの環境変数を編集」を検索して開き、ユーザー変数セクションのPathを選択して編集します。
3. Pathに以下を追加:
  C:\src\depot_toolsを先頭（またはPythonがインストールされているディレクトリより前）に追加します。
  注意: ユーザーレベルのPATHしか変更できず、システムPATHにPythonが含まれる場合、競合が発生する可能性があります。

3. DEPOT_TOOLS_WIN_TOOLCHAIN環境変数を追加

同じ方法で環境変数DEPOT_TOOLS_WIN_TOOLCHAINを追加し、値を0に設定します。これにより、depot_toolsがローカルにインストールされたVisual Studioを使用するようになります（デフォルトではGoogle内部のバージョンを使用しようとします）。

4. Visual Studio 2022のパスを設定

必要に応じて、環境変数vs2022_installをVisual Studio 2022のインストールパスに設定します。例:
1

set vs2022_install=C:\Program Files\Microsoft Visual Studio\2022\Community

システム環境変数に「vs2022_install」を追加

5. gclientの実行

cmd.exeシェルで次のコマンドを実行します:

1
2


$ cd c:\src\depot_tools
$ gclient

初回実行時に、コードの作業に必要なWindows固有のツール（msysgitやpythonなど）がインストールされます。
注意: cmd.exe以外のシェル（例: CygwinやPowerShell）から実行すると、一見正しく動作しているように見えても、msysgitやpythonなどが正しくインストールされない場合があります。
初回実行時にファイルシステムで奇妙なエラーが発生する場合は、Windowsインデックスサービスを無効にすることを検討してください。

Pythonのインストール確認

gclientを実行後、コマンドプロンプトで次のコマンドを入力し、確認します:

1

$ where python3

結果に表示されるpython3.bat（depot_toolsに含まれるもの）が、他のpython3.exeよりも優先されていることを確認してください。これを怠ると、gn使用時に過剰なビルドが発生する可能性があります（詳細はcrbug.com/611087 を参照）。

下記のようにpython3.batが一番上に表示されていることを確認してください。

1
2
3


$ c:\src\depot_tools>where python3
c:\src\depot_tools\python3.bat
C:\Users\xxxx\AppData\Local\Microsoft\WindowsApps\python3.exe

アプリ実行エイリアス（App Execution Aliases）の無効化

システム上の他のPythonインストールと競合する可能性があるため、アプリ実行エイリアス（App Execution Aliases）を無効化します。
手順:
1. コントロールパネル → アプリ実行エイリアス（App Execution Aliases）を開く。
2. python.exeおよびpython3.exeのチェックボックスをオフにします（App Installerを指しているもの）。

アプリ実行エイリアス（App Execution Aliases）の無効化の補足

python.exeおよびpython3.exeのアプリ実行エイリアスをオフにする手順は下記を実施してください。

Windowsの設定を開く

Windows → 設定

アプリを押下し「アプリの詳細設定」を開く

Windows → 設定 → アプリ

アプリ実行エイリアスを開く

Windows → 設定 → アプリ → アプリ実行エイリアス

一覧からpython.exeおよびpython3.exeを探してチェックボックスをオフにします。
私の環境では存在しませんでした。
Windows → 設定 → アプリ → アプリ実行エイリアス

コードの取得

1. Gitの設定

まず、Gitを以下のように設定します:

1
2
3
4
5
6
7


$ 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

必須ではありませんが、WindowsのMAX_PATH制限を超えた長いパスのサポートを有効にすることをお勧めします:

1

$ git config --global core.longpaths true

2. チェックアウト用のディレクトリ作成

Chromiumのコードをチェックアウトするためのディレクトリを作成し、その中に移動します。このディレクトリ名は自由に決められますが、パスにスペースが含まれないようにしてください。
Google社員の場合は、C:\src\配下に配置するとパフォーマンスの向上が期待できます（詳しくは「Why is my build slow?」を参照）。

1

$ mkdir chromium && cd chromium

3. コードと依存関係の取得

depot_toolsのfetchツールを使用してコードと依存関係をチェックアウトします:

1

$ fetch chromium

注意: 履歴全体を取得したくない場合、--no-historyフラグを付けることで時間を大幅に短縮できます:

1

$ fetch --no-history chromium

所要時間: 高速なインターネット接続でも1時間以上かかり、低速な接続ではさらに時間がかかることがあります。取得中にPCがスリープまたは休止状態になるとエラーが発生する可能性があるため、スリープを無効にしてください。
エラーが発生した場合:
サブリポジトリの取得中にエラーが発生した場合、以下の手順で対応できます:
- 再試行する。
- または、chromium/srcディレクトリに移動して次のコマンドを実行する:

1

$ gclient sync

python関連のエラーが発生した場合

python関連のエラーが発生した場合は、たいていパスが通ってないケースがほとんどかと思います。
下記でちゃんとc:\src\depot_toolsにパスが通っているか改めて確認してみましょう。

1

$ echo %PATH%

4. チェックアウト後の構成

fetchコマンドが完了すると、作業ディレクトリに隠しファイル.gclientとsrcディレクトリが作成されます。以降の手順ではsrcディレクトリに移動していることを前提とします:

1

$ cd src

5. （オプション）APIキーのインストール

Googleサービスとやり取りするためにビルドにAPIキーをインストールすることもできます。ただし、ほとんどの開発やテストでは必要ありません。

ビルドのセットアップ

Chromiumは、主要なビルドツールとしてNinjaを使用し、.ninjaファイルを生成するためにGNを併用します。異なる設定で任意の数のビルドディレクトリを作成できます。

ビルドディレクトリの作成

下記コマンドでc:\src\chromium\src直下にビルドディレクトリを作成します。

1

$ gn gen out\Default

このコマンドは、新しいビルドディレクトリごとに一度だけ実行する必要があります。以降、Ninjaは必要に応じてビルドファイルを更新します。
**Default**は任意の名前に置き換え可能ですが、必ずoutディレクトリのサブディレクトリにする必要があります。
リリース設定やVisual Studioの別バージョンを使用する場合などのビルド引数については、GNビルド設定を参照してください。
デフォルト設定は、現在のホストOSとCPUに一致するデバッグ用のコンポーネントビルドです。
GNに関する詳細は、コマンドラインでgn helpを実行するか、クイックスタートガイドを参照してください。

高速化のための工夫

ファイルシステムのオーバーヘッドを削減
- ビルドディレクトリをウイルス対策ソフトやインデックスソフトウェアの除外対象に設定します。
- ビルドツリーを高速ディスク（推奨: SSD）に保存します。
ハードウェアの最適化
- 多くのコア（20コア以上でも問題なし）と大量のRAM（64GB以上も推奨）が必要です。
GNフラグの活用
- 以下のフラグを使用することでビルド速度を向上できます。
  フラグは、gn args out\Defaultで表示されるエディターに入力するか、gn genコマンドの引数として指定します:
  1
  
  gn gen out\Default --args="is_component_build = true is_debug = true"
- 有効な設定例:
  - is_component_build = true
    小さなDLLを多く生成することで、chrome.dllの再リンクを回避できる場合があります。
  - enable_nacl = false
    Native Clientを無効化（通常ローカルビルドでは不要）。
  - target_cpu = "x86"
    x86ビルドはx64ビルドより若干速くなる場合があります。ただし、enable_nacl = falseを設定しないとビルド時間が悪化する場合があります。
  - blink_symbol_level = 0
    Blinkのソースレベルデバッグを無効化してビルド時間を短縮（Blinkのデバッグを予定していない場合に適切）。
  - v8_symbol_level = 0
    V8のソースレベルデバッグを無効化してビルド時間を短縮（V8のデバッグを予定していない場合に適切）。
  - symbol_level = 1またはsymbol_level = 0
    リンク速度を向上させる設定。
    - symbol_level = 1: ファイル名や行番号情報は残し、ローカル変数や型情報を省略（ソースレベルのデバッグは可能）。
    - symbol_level = 0: ソースレベルのデバッグを無効化するが、コールスタックに関数名は残る。
      注意: この設定を変更するとすべてを再コンパイルする必要があります。
Ninjaのターゲット指定
- ninjaを実行する際、chromeをターゲットとして指定すると、テストバイナリ全体のビルドを回避できます。

SCCACHEの利用

SCCACHEを有効にすることでビルドプロセスを高速化できる可能性があります。以下の引数を設定してください:
1

cc_wrapper = "sccache" # SCCACHEの実行ファイルが%PATH%に含まれていることが前提

ビルドが遅い原因と対処法

ビルドが遅い原因

ビルドが遅くなる原因はさまざまですが、特にWindows Defenderによるプロセス起動の遅延がよく挙げられます。以下の点を確認してください:

Chromiumのsrcディレクトリ全体をウイルススキャンの対象外に設定していますか？
- Googleの環境では、ドライブのルートディレクトリ（例: C:\src）に配置すると効果的です。
上記で説明した設定（リンク設定や-jオプションの値）を試しましたか？
chromium-devメーリングリストで、マシンのスペックに対してビルドが遅いかどうかを確認しましたか？

Windows Defenderがビルドを遅くしていると疑われる場合、Microsoftが提供するPerformance Analyzer for Microsoft Defender Antivirus を使用して詳しく調査することができます。

データ収集の方法

NINJA_SUMMARIZE_BUILDの設定
- 環境変数NINJA_SUMMARIZE_BUILDを1に設定すると、autoninjaが以下の情報を出力します:
  - 現在実行中のビルドプロセス数
  - 完了したビルドステップの数
  - 毎秒完了したビルドステップ数
  - ビルドの実行時間
コマンド例:
1 2

$ 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
```
- これにより、プロセス作成の遅延が明確に分かり、ビルドが通常より遅いかどうかをすぐに判断できます。
ビルド完了後のパフォーマンスサマリー
- 環境変数NINJA_SUMMARIZE_BUILD=1を設定すると、ビルド完了時に以下の情報が出力されます:
  - 最も遅いビルドステップ
  - 各ビルドステップの種類別の合計時間
出力例:
```
Longest build steps:
    0.1 weighted s to build obj/base/base/trace_log.obj (6.7 s elapsed time)
Time by build-step type:
    23.9 s weighted time to generate 770 .obj files (974.8 s elapsed time sum)
```
- “weighted"時間: ビルドステップの経過時間を並列実行中のタスク数で割った値。遅いステップの「重要度」を近似する指標です。
手動でレポートを生成
- ビルド後に以下のスクリプトを使用してパフォーマンスレポートを生成できます:
  1
  
  $ python depot_tools\post_build_ninja_summary.py -C out\Default

Ninjaのオーバーヘッドの分析

NINJA_SUMMARIZE_BUILD=1を設定すると、Ninjaが自身のオーバーヘッドをレポートするようになります。-d statsフラグを使用して、プロセス作成が遅い原因（例: clang-clが除外ディレクトリ外で動作しているためのウイルス対策干渉）を調査できます。

コマンド例:

1
2


$ set NINJA_SUMMARIZE_BUILD=1
$ autoninja -C out\Default base

出力例:

metric                  count   avg (us)        total (ms)
StartEdge               88      3508.1          308.7
FinishCommand           87      1670.9          145.4

視覚的なパフォーマンスレポートの生成

Ninjaの.ninja_logファイルを.json形式に変換し、Chromeのchrome://tracingで読み込むことができます。

コマンド例:

1

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

build.jsonファイルをchrome://tracingで開き、ビルドパフォーマンスを視覚化して分析します。

Chromiumのビルド

Chromiumのビルド方法

Chromium（chromeターゲット）をビルドするには、以下のコマンドを使用してNinjaでビルドします:

1

$ autoninja -C out\Default chrome

autoninjaは、Ninjaに渡される引数に最適な値を自動的に提供するラッパーツールです。

他のビルドターゲットの確認

コマンドラインで以下を実行すると、GNから利用可能なすべてのビルドターゲットのリストを取得できます:
1

$ gn ls out\Default
任意のターゲットをビルドするには、NinjaにGNラベルを渡します（//を除く）。
例: //chrome/test:unit_tests をビルドする場合:
1

$ autoninja -C out\Default chrome/test:unit_tests

単一ファイルのコンパイル

Ninjaには、特定のソースファイルを基に単一のオブジェクトファイルをコンパイルするための特殊な構文^があります。

例:

1

$ ninja -C out/Default ../../base/logging.cc^

これは、obj/base/base/logging.oをコンパイルします。

autoninjaを使用する場合:
- ^の後に^を追加して、末尾の^を保持する必要があります:

1

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

ヘッダーファイルにも対応:
- 例えば、foo.h^^で対応するfoo.oをコンパイル可能です（存在する場合）。

Bashスクリプトを使った簡略化

Bashシェルを使用している場合、以下のスクリプトで単一ファイルコンパイルの実行を簡略化できます:

スクリプト内容:

1
2
3


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

このスクリプトはsrcディレクトリで実行され、出力ディレクトリがout/Defaultであることを前提としています。
指定されたすべてのファイルをautoninjaでコンパイルします。

使い方:

スクリプトをファイルとして保存し、実行可能にします。
$PATHに配置し、例としてcompileという名前を付けます。

例:

1
2
3
4
5
6
7
8
9


$ pwd  # 実行ディレクトリを確認
/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
...

Chromiumの実行

ブラウザの起動

ビルドが完了したら、以下のコマンドでブラウザを実行できます:

1

$ out\Default\chrome.exe

注意: コマンドで「.exe」の拡張子を省略することも可能です。

テストターゲットの実行

テストターゲットの確認

テストは種類やディレクトリ構造に基づいて複数のターゲットに分かれています。特定のユニットテストやブラウザテストファイルがどのターゲットに対応しているかを確認するには、次のコマンドを使用します:

1

$ gn refs out\Default --testonly=true --type=executable --all chrome\browser\ui\browser_list_unittest.cc

例:

1

//chrome/test:unit_tests

この場合、対象のターゲットはunit_testsです。

ユニットテストのビルド

以下のコマンドでunit_testsバイナリをビルドします:

1

$ autoninja -C out\Default unit_tests

ユニットテストの実行

テストを実行するには、unit_testsバイナリを起動します。特定のテストだけを実行する場合、--gtest_filter引数を使用します:

例:

1

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

詳細は、GoogleTestのGitHubページを参照してください。

インストーラーのビルド

インストーラーの作成

自己完結型のインストーラーを作成するには、mini_installerターゲットをビルドします。このインストーラーには、ブラウザを別のマシンにインストールするために必要なすべてのファイルが含まれています。

コマンド:

1

$ autoninja -C out\Default mini_installer

詳細は以下のREADMEファイルを参照してください:
- //chrome/installer/setup/README.md
- //chrome/installer/mini_installer/README.md

チェックアウトの更新

既存のチェックアウトを更新する方法

以下のコマンドを実行して、既存のチェックアウトを更新できます:

1
2


$ git rebase-update
$ gclient sync -D

git rebase-update
- Chromiumのメインソースリポジトリを更新します。
- ローカルブランチを最新のツリートップ（origin/main）にリベースします。
- このスクリプトを使わない場合、git pullなどの通常のGitコマンドでもリポジトリを更新できます。
gclient sync -D
- サブリポジトリを適切なバージョンに同期します。
- 不要になったサブリポジトリを削除し、必要に応じてフックを再実行します。

Visual Studio IDEでの編集とデバッグ

Chromiumの編集とデバッグにはVisual Studio IDEを使用できます。Intellisenseのサポートを利用するかどうかを選べます。

Visual Studio Intellisenseを使用する場合

Chromiumの開発でIntellisenseを利用するには、出力ディレクトリを生成する際にgn genに--ide引数を付けます。

例:

チェックアウトパス: C:\src\chromium
出力ディレクトリ: out\Default

1
2


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

このコマンドはビルドディレクトリ内にall.slnファイルを生成します。
ビルドには内部的にNinjaを使用しますが、大半のIDE機能は利用可能です（ネイティブなVisual Studioのビルドモードはありません）。
再度gn genを手動で実行する場合、--ide引数を再指定する必要がありますが、通常GNは自動的にビルドファイルとIDEファイルを更新します。

プロジェクトの生成を制限する

ソリューションファイルには数千のプロジェクトが含まれるため、ロードが非常に遅くなることがあります。
--filters引数を使用して、必要なコードだけにプロジェクトファイルの生成を制限できます。

最小限のソリューション生成例:

1

$ gn gen --ide=vs --ninja-executable=C:\src\chromium\src\third_party\ninja\ninja.exe --filters=//chrome --no-deps out\Default

必要に応じて他のディレクトリもフィルタに追加できます:
1

--filters=//chrome;//third_party/WebKit/*;//gpu/*
その他のオプションについては、以下のコマンドで確認できます:
1

$ gn help gen

Intellisenseを使用しない場合

Visual Studioのマルチプロジェクトソリューションファイルを使用せずにデバッグと開発を行うことも可能です。

バイナリの直接オープン
- File -> Open -> Project/Solutionでchrome.exeバイナリを直接開きます。
- またはVisual Studioのコマンドプロンプトで以下を実行します:
  1
  
  $ devenv /debugexe out\Debug\chrome.exe <引数>
VsChromium拡張機能の利用
- Visual StudioのVsChromium拡張機能をインストールすることで、ソースコードをソリューションエクスプローラーに表示したり、コード検索などの便利な機能を利用できます。
複数の実行可能ファイルの追加
- File -> Add -> Existing Project...で追加できます（例: base_unittests.exe, browser_tests.exe）。
- デバッグ対象を変更するには、右クリックしてSet as Startup Projectを選択します。
- コマンドライン引数などのプロパティを変更するには、右クリックしてPropertiesを選択します。

Chrome全体のデバッグ

Visual Studioでは、デフォルトでメインのブラウザプロセスにのみデバッガがアタッチされます。
Chrome全体をデバッグするには:
- Microsoft Child Process Debugging Power Toolをインストールします。
- Visual Studioを管理者として実行します（管理者権限がない場合、一部の子プロセスへのアタッチが失敗します）。

Gitコマンドのパフォーマンス改善

未追跡キャッシュを使用するようにGitを設定

未追跡キャッシュを有効にすると、git statusなどのコマンドのパフォーマンスが向上する可能性があります。

未追跡キャッシュのテスト
次のコマンドを実行します:
1

$ git update-index --test-untracked-cache
- 出力がOKで終わる場合、以下の設定でパフォーマンスを改善できます。

未追跡キャッシュの有効化

1

$ git config core.untrackedCache true

fsmonitorを使用するようにGitを設定

fsmonitorを使用すると、Gitコマンドを大幅に高速化できます。特に、大規模なリポジトリ（例: Chromiumやv8）で有効にすることを推奨します。

注意:
- fsmonitorをグローバルに有効化すると、多くのプロセスが起動し、過剰なコミット/メモリ消費が発生する可能性があるため、リポジトリごとに有効化する方が適切です。
現在のリポジトリでfsmonitorを有効化するコマンド:
1

$ git config core.fsmonitor true