BazelCon 2024 登録の受け付けを開始しました。

このページは Cloud Translation API によって翻訳されました。

Bazel を使用してプログラムをビルドする

問題を報告ソースを表示ナイトリー · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

このページでは、Bazel を使用したプログラムのビルド方法、ビルドコマンドの構文、ターゲットパターンの構文。

クイックスタート

Bazel を実行するには、ベース workspace ディレクトリに移動します。または「bazel」と入力します。新しいワークスペースを作成する必要がある場合は、build をご覧ください。

bazel help
                             [Bazel release bazel version]
Usage: bazel command options ...

使用できるコマンド

analyze-profile: ビルドプロファイルデータを分析します。
aquery: 分析後のアクショングラフに対してクエリを実行します。
build: 指定されたターゲットをビルドします。
canonicalize-flags: Bazel フラグを正規化します。
clean: 出力ファイルを削除し、必要に応じてサーバーを停止します。
cquery: 分析後の依存関係グラフクエリを実行します。
dump: Bazel サーバープロセスの内部状態をダンプします。
help: コマンドまたはインデックスのヘルプを出力します。
info: bazel サーバーに関するランタイム情報を表示します。
fetch: ターゲットのすべての外部依存関係を取得します。
mobile-install: モバイルデバイスにアプリをインストールします。
query: 依存関係グラフのクエリを実行します。
run: 指定されたターゲットを実行します。
shutdown: Bazel サーバーを停止します。
test: 指定されたテストターゲットをビルドして実行します。
version: Bazel のバージョン情報を出力します。

困ったときは

bazel help command: command のヘルプとオプションを出力します。
bazel helpstartup_options: Bazel をホストする JVM のオプション。
bazel helptarget-syntax: ターゲットの指定方法について説明します。
bazel help info-keys: info コマンドによって使用されるキーのリストを表示します。

bazel ツールは、コマンドと呼ばれる多くの機能を実行します。最もよく使用されるのは bazel build と bazel test です。bazel help を使用してオンラインヘルプメッセージを参照できます。

1 つのターゲットをビルドする

ビルドを開始する前に、ワークスペースが必要です。ワークスペースとはアプリケーションのビルドに必要なすべてのソースファイルを含む説明します。Bazel を使用すると、完全に読み取り専用のコンテナからビルドをできます。

Bazel でプログラムをビルドするには、bazel build と続けてビルドするターゲットを入力します。

bazel build //foo

//foo をビルドするコマンドを実行すると、次のような出力が表示されます。

INFO: Analyzed target //foo:foo (14 packages loaded, 48 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
  bazel-bin/foo/foo
INFO: Elapsed time: 9.905s, Critical Path: 3.25s
INFO: Build completed successfully, 6 total actions

まず、Bazel はターゲットの依存関係グラフ内のすべてのパッケージを読み込みます。これには、宣言された依存関係（ターゲットの BUILD ファイルに直接リストされているファイル）と伝播依存関係（ターゲットの依存関係の BUILD ファイルにリストされているファイル）が含まれます。すべての依存関係を特定した後、Bazel は依存関係の正確性を分析し、ビルドアクションを作成します。最後に、Bazel の実行を行います。ビルドのコンパイルやその他のツールが含まれます。

ビルドの実行フェーズで、Bazel は進行状況メッセージを出力します。進行状況メッセージには、開始時の現在のビルドステップ（コンパイラやリンカーなど）と、完了したビルドアクションの合計数が表示されます。ビルドの開始時に、Bazel がアクショングラフ全体を検出すると、合計アクション数が増加することがよくありますが、数秒以内に安定します。

ビルドの終了時に、リクエストされたターゲット、正常にビルドされたかどうか、正常にビルドされた場合は出力ファイルの場所が Bazel によって出力されます。ビルドを実行するスクリプトはこの出力を確実に解析できます。詳細については、--show_result をご覧ください。

同じコマンドをもう一度入力すると、ビルドははるかに速く完了します。

bazel build //foo
INFO: Analyzed target //foo:foo (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
  bazel-bin/foo/foo
INFO: Elapsed time: 0.144s, Critical Path: 0.00s
INFO: Build completed successfully, 1 total action

これはnull ビルドです。変更されていないため、再読み込みするパッケージも、実行するビルドステップもありません。「foo」の値が変更された場合または作成された場合、Bazel は一部のビルドアクションを再実行するか、 増分ビルド:

複数のターゲットのビルド

Bazel では、ビルドするターゲットを指定する方法がいくつかあります。総称してこれらはターゲットパターンと呼ばれます。この構文は、build、test、query などのコマンドで使用されます。

ラベルは、BUILD ファイルで依存関係を宣言する場合など、個々のターゲットを指定するために使用されますが、Bazel のターゲットパターンは複数のターゲットを指定します。ターゲットパターンは、ワイルドカードを使用してターゲットのセットのラベル構文を一般化したものです。最も単純なケースでは有効なラベルも有効なターゲットパターンで、あります。

// で始まるターゲットパターンはすべて、現在のできます。

`//foo/bar:wiz`	単一のターゲット `//foo/bar:wiz` のみ。
`//foo/bar`	`//foo/bar:bar` と同じです。
`//foo/bar:all`	パッケージ `foo/bar` 内のすべてのルールターゲット。
`//foo/...`	ディレクトリ `foo` の下のすべてのパッケージ内のすべてのルールターゲット。
`//foo/...:all`	ディレクトリ `foo` の下にあるすべてのパッケージ内のすべてのルールターゲット。
`//foo/...:*`	`foo` ディレクトリの下にあるすべてのパッケージ内のすべてのターゲット（ルールとファイル）。
`//foo/...:all-targets`	ディレクトリ `foo` の下のすべてのパッケージ内のすべてのターゲット（ルールとファイル）。
`//...`	ワークスペース内のパッケージ内のすべてのターゲット。これにはターゲットは含まれません。外部リポジトリから。
`//:all`	トップレベルパッケージ内のすべてのターゲット（アクセスできます。

// で始まらないターゲットパターンは、現在の作業ディレクトリを基準に解決されます。以下の例では、foo の作業ディレクトリを想定しています。

`:foo`	`//foo:foo` に相当します。
`bar:wiz`	`//foo/bar:wiz` と同じです。
`bar/wiz`	次と同等です。 <ph type="x-smartling-placeholder"> </ph> `foo/bar/wiz` がパッケージの場合は `//foo/bar/wiz:wiz` `foo/bar` がパッケージの場合は `//foo/bar:wiz` それ以外の場合は `//foo:bar/wiz`
`bar:all`	`//foo/bar:all` に相当します。
`:all`	`//foo:all` に相当します。
`...:all`	`//foo/...:all` に相当します。
`...`	`//foo/...:all` に相当します。
`bar/...:all`	`//foo/bar/...:all` に相当します。

デフォルトでは、再帰ターゲットパターンのディレクトリシンボリックリンクに従いますが、出力ベースの下にポイントするものは除きます。ワークスペースのルートディレクトリに作成されるシンボリックリンク。

また、Bazel が再帰ターゲットを評価する際にシンボリックリンクを追跡しない次のような名前のファイルがあるディレクトリでは、このパターンが検索されます。 DONT_FOLLOW_SYMLINKS_WHEN_TRAVERSING_THIS_DIRECTORY_VIA_A_RECURSIVE_TARGET_PATTERN

foo/... は packages に対するワイルドカードで、すべてのパッケージを再帰的に指定します。 foo ディレクトリの下（パッケージパスのすべてのルート）に配置します。:all は ターゲットに対するワイルドカード。パッケージ内のすべてのルールに一致します。この 2 つは foo/...:all のように結合できます。両方のワイルドカードを使用する場合は、 foo/... と省略されます。

:*（または :all-targets）は、すべてのターゲットに一致するワイルドカードです。（通常はルールによってビルドされないファイルを含む）が、一致するパッケージに java_binary ルールに関連付けられた _deploy.jar ファイルなど。

これは、:* が :all のスーパーセットを表すことを意味します。混乱を招く可能性がありますが、この構文では、_deploy.jar などのビルドターゲットが不要な一般的なビルドで、使い慣れた :all ワイルドカードを使用できます。

また、Bazel では、ラベル構文で必要なコロンの代わりにスラッシュを使用できます。これは、Bash ファイル名展開を使用する場合に便利です。たとえば、foo/bar/wiz は //foo/bar:wiz（パッケージ foo/bar がある場合）または //foo:bar/wiz（パッケージ foo がある場合）と同じです。

多くの Bazel コマンドはターゲットパターンのリストを引数として受け取ります。接頭辞否定演算子 - に従います。これは、前の引数で指定されたセットからターゲットのセットを減算するために使用できます。これは順序が重要です。次に例を示します。

bazel build foo/... bar/...

「foo の下のすべてのターゲットと、bar の下のすべてのターゲットをビルドする」ことを意味します。

bazel build -- foo/... -foo/bar/...

は、「foo/bar の下にあるターゲットを除く foo の下のすべてのターゲットをビルドする」ことを意味します。- で始まる後続の引数が追加オプションとして解釈されないようにするには、-- 引数が必要です。

ただし、このようにターゲットを除外しても、除外されたターゲットの依存関係である可能性があるため、ターゲットがビルドされないとは限りません。たとえば、//foo/bar:api に依存するターゲット //foo:all-apis がある場合、後者は前者のビルドの一部としてビルドされます。

tags = ["manual"] を含むターゲットは、bazel build や bazel test などのコマンドで指定した場合、ワイルドカードターゲットパターン（...、:*、:all など）に含まれません。Bazel でビルドまたはテストする場合は、コマンドラインで明示的なターゲットパターンを使用してこのようなテスト対象を指定する必要があります。一方、bazel query はそのようなフィルタリングを自動的に実行しません（これは bazel query の目的を無効にします）。

外部依存関係の取得

デフォルトでは、Bazel はプロジェクト中に外部依存関係をダウンロードしてシンボリックリンクします。構築できます。ただし、新しい外部依存関係が追加されたときを知りたい場合や、依存関係を「プリフェッチ」する場合（オフラインになるフライトの前に行うなど）は、この方法は望ましくありません。ビルド中に新しい依存関係が追加されないようにするには、--fetch=false フラグを指定します。このフラグは、ローカルファイルシステム内のディレクトリを指していないリポジトリルールにのみ適用されます。local_repository、new_local_repository、Android SDK と NDK のリポジトリルールへの変更は、--fetch の値に関係なく常に有効になります。

ビルド中にフェッチを禁止し、Bazel が新しい外部依存関係を見つけると、ビルドは失敗します。

bazel fetch を実行すると、依存関係を手動で取得できます。条件ビルド中に許可しない場合は、bazel fetch を実行する必要があります。

初めてビルドする前に
新しい外部依存関係を追加した後。

一度実行すると、WORKSPACE 関数が実行されるまで再度実行する必要はありません。おすすめします。

fetch は、依存関係をフェッチするターゲットのリストを受け取ります。対象たとえば、//foo:bar のビルドに必要な依存関係を取得します。および //bar:baz:

bazel fetch //foo:bar //bar:baz

ワークスペースのすべての外部依存関係を取得するには、次のコマンドを実行します。

bazel fetch //...

使用しているすべてのツール（ライブラリ JAR から JDK 自体まで）がワークスペースのルートにある場合は、bazel fetch を実行する必要はありません。ただし、Workspace ディレクトリ以外で使用している場合は、Bazel による実行前に bazel fetch が自動的に実行されます bazel build。

リポジトリキャッシュ

Bazel は、同じファイルであっても、同じファイルを複数回取得することを回避しようとします。別のワークスペースでファイルが必要な場合や、外部 IP アドレスの定義がリポジトリが変更されましたが、同じファイルをダウンロードする必要があります。そのためには、 bazel は、リポジトリキャッシュにダウンロードしたすべてのファイルをキャッシュに保存します。デフォルトでは、 ~/.cache/bazel/_bazel_$USER/cache/repos/v1/ にあります。「 --repository_cache オプションでロケーションを変更できます。キャッシュは、すべてのワークスペースとインストールされているバージョンの bazel で共有されます。エントリは、Bazel が正しいファイルのコピーがあることを明確に認識している場合にキャッシュから取得されます。つまり、ダウンロードリクエストに指定されたファイルの SHA256 の合計があり、そのハッシュを持つファイルがキャッシュにある場合です。したがって、外部ファイルごとにハッシュを指定することは、セキュリティの観点からだけでなく、不要なダウンロードを回避するためにも適切な方法です。

キャッシュがヒットするたびに、キャッシュ内のファイルの変更時刻が更新しました。これにより、キャッシュディレクトリ内のファイルが最後に使用された際に、キャッシュを手動でクリーンアップするなど選択できますキャッシュには、アップストリームで利用できなくなったファイルのコピーが含まれている可能性があるため、キャッシュは自動的にクリーンアップされません。

配布ファイルのディレクトリ

ディストリビューションディレクトリは、不要なダウンロードを回避するための Bazel のメカニズムです。Bazel は、リポジトリキャッシュの前にディストリビューションディレクトリを検索します。主な違いは配布ディレクトリには手動の学習しました。

--distdir=/path/to-directory オプションを使用すると、読み取り専用のディレクトリを追加して、ファイルを取得するのではなく検索できます。ファイル名が URL のベース名と一致し、さらにファイルのハッシュがダウンロードリクエストで指定されたハッシュと一致する場合、そのようなディレクトリからファイルが取得されます。この方法は、ファイルハッシュは WORKSPACE 宣言で指定されます。

ファイル名の条件は正確性に必須ではありませんが、候補ファイルの数を、指定したディレクトリごとに 1 つに減らします。この配布ファイルディレクトリを指定するのは、そのようなディレクトリ内のファイルの数が大きくなります。

エアギャップのある環境での Bazel の実行

Bazel のバイナリサイズを小さく保つため、Bazel の暗黙的な依存関係は、初めて実行するときにネットワーク経由で取得されます。これらの暗黙的な依存関係には、すべてのユーザーに必要でないツールチェーンとルールが含まれています。対象たとえば、Android ツールはバンドルされておらず、Android のビルド時にのみ取得されます。できます。

ただし、これらの暗黙的な依存関係により、実行時に問題が発生する可能性があります。すべての Bazel をベンダリングしたとしても、エアギャップのある環境で WORKSPACE の依存関係これを解決するには、配布ディレクトリを用意し、ネットワークアクセスを備えたマシン上にこれらの依存関係を格納し、クローズド・アプローチでクローズドな環境に移行する必要があるからです

ディストリビューションディレクトリを準備するには、--distdir フラグを使用します。暗黙的な依存関係はリリースごとに異なる可能性があるため、新しい Bazel バイナリバージョンごとに 1 回行う必要があります。

エアギャップのある環境の外でこれらの依存関係を構築するには、まず、適切なバージョンの Bazel ソースツリーを確認します。

git clone https://github.com/bazelbuild/bazel "$BAZEL_DIR"
cd "$BAZEL_DIR"
git checkout "$BAZEL_VERSION"

次に、その依存関係の暗黙的なランタイム依存関係を含む tarball をビルドします。該当する Bazel バージョン:

bazel build @additional_distfiles//:archives.tar

この tarball を、エアギャップのあるディレクトリにコピーできるディレクトリにエクスポートします。できます。--strip-components フラグに注意してください。--distdir は、ディレクトリのネストレベルについては、かなり細かな作業が可能です。

tar xvf bazel-bin/external/additional_distfiles/archives.tar \
  -C "$NEW_DIRECTORY" --strip-components=3

最後に、エアギャップ環境で Bazel を使用する場合は、ディレクトリを指す --distdir フラグを渡します。便宜上、.bazelrc エントリとして追加することもできます。

build --distdir=path/to/directory

ビルド構成とクロスコンパイル

特定のビルドの動作と結果を指定するすべての入力は、大きく 2 つに分類されます1 つ目の種類は、組み込み型プロジェクトの BUILD ファイルに保存されている情報（ビルドルール、その属性値、推移的依存関係の完全なセットです。 2 つ目の種類は、ユーザーまたはビルドツールから提供される外部データまたは環境データです。ターゲットアーキテクチャの選択、コンパイルオプションとリンクオプション、その他の toolchain 構成オプションなどです。Google Kubernetes Engine の構成として環境データをまとめます。

特定のビルドには、複数の構成が存在する場合があります。検討すべき事項クロスコンパイル（64 ビット用の //foo:bin 実行可能ファイルをビルドします）ワークステーションは 32 ビットマシンです。ビルドでは、64 ビットの実行可能ファイルを作成できるツールチェーンを使用して //foo:bin をビルドする必要がありますが、ビルドシステムはビルド自体で使用されるさまざまなツール（ソースからビルドされ、その後 genrule などで使用されるツールなど）もビルドする必要があります。これらのツールは、ワークステーションで実行するようにビルドする必要があります。したがって、2 つの構成を特定できます。実行構成は、ビルド中に実行されるツールのビルドに使用されます。ターゲット構成（またはリクエスト構成。この言葉にはすでに多くの意味がありますが、より一般的には「ターゲット構成」と呼ばれます）は、最終的にリクエストされたバイナリのビルドに使用されます。

通常、リクエストされた両方の前提条件となるライブラリは多数あります。ビルドターゲット（//foo:bin）と 1 つ以上のツール（一部のベースなど）使用できます。このようなライブラリは、exec と target で複数回ビルドする必要があるできます。Bazel は、すべてのバリアントが確実にビルドされるようにします。干渉を避けるために、派生ファイルを分離して維持すること。通常は複数のターゲットは互いに独立しているため、同時にビルドできます。条件特定のターゲットが複数回ビルドされていることを示す進行状況メッセージが表示されます。これが理由である可能性が高いです。

exec 構成は、次のようにターゲット構成から派生します。

リクエストターゲットの実行プラットフォームは、変更します。
以下で指定されているのと同じバージョンの Crosstool（--crosstool_top）を使用します。構成をリクエストします（--host_crosstool_top が指定されていない場合）。
--cpu には --host_cpu の値を使用します（デフォルト: k8）。
リクエストで指定されているのと同じこれらのオプションの値を使用します。構成: --compiler、--use_ijars、--host_crosstool_top の場合使用されている場合は、--host_cpu の値を使用してホストの Crosstool の default_toolchain（--compiler を無視）できます。
--javabase には --host_javabase の値を使用します。
--java_toolchain には --host_java_toolchain の値を使用します。
C++ コード用に最適化されたビルドを使用します（-c opt）。
デバッグ情報を生成しない（--copt=-g0）。
実行可能ファイルと共有ライブラリからデバッグ情報を削除する（--strip=always）。
すべての派生ファイルを、構成できます。
ビルドデータによるバイナリのスタンプ付けを抑制します（--embed_* オプションを参照）。
その他の値はすべてデフォルトのままにします。

増分再ビルドを修正する

Bazel プロジェクトの主な目標の 1 つは、構成されます。以前のビルドツール（特に Make ベースのツール）では、増分ビルドの実装でいくつかの安全でない前提が設定されています。

まず、ファイルのタイムスタンプは単調に増加します。これは一般的なケースでは、この前提から外れることはとても簡単です。同期先そのファイルの変更時間が短くなる。 Make ベースのシステムは再構築されません。

一般的に、Make はファイルの変更を検出しますが、変更を検出しません。使用できます。特定のビルドでコンパイラに渡されるオプションを変更した場合 Make はコンパイラを再実行しないため、手動で破棄し、 make clean を使用した以前のビルドの無効な出力。

また Make は、いずれかの Pod の停止に失敗しても堅牢ではありません。そのサブプロセスが出力ファイルへの書き込みを開始した後、しばらく現在の Make の実行が失敗すると、後続の Make の呼び出しは、むやみに切り捨てられた出力ファイルが有効であると仮定する（再ビルドされることはありません。同様に Make プロセスが同様の状況が発生する可能性があります。

Bazel では、このような前提条件は回避されています。Bazel では、すべてのコンポーネントの実行され、そのセットが検出された場合にのみビルドステップが省略されます。そのビルドステップへの入力ファイルとそのタイムスタンプ、データベース内の 1 つのコマンドと完全に一致し、かつ、そのビルドステップがデータベースエントリの出力ファイルのセット（およびそのタイムスタンプ）がディスク上のファイルのタイムスタンプです。入力ファイルまたは出力ファイル、またはコマンド自体に変更を加えると、ビルドステップが再実行されます。

適切な増分ビルドを利用するユーザーにとってのメリットは、混同です。（また、make clean の使用によって発生する再ビルドの待機時間（必要な場合、またはプリエンプティブの場合）が短縮されます）。

ビルドの整合性と増分ビルド

正式には、想定される出力ファイルがすべて存在し、その作成に必要な手順またはルールで指定されているように内容が正しい場合、ビルドの状態は整合性があると定義されます。ソースファイルを編集すると、ビルドは「不整合」と見なされ、次回の実行まで一貫性がない状態を保ちます。ビルドツールが正常に完了します。この状況は一時的なもので、ビルドツールを実行すると整合性が復元されるため、不安定な不整合と呼ばれます。

有害な別の種類の不整合があります。それは安定です。不整合。ビルドが安定した不整合状態に達すると、ビルドツールを繰り返し正常に呼び出しても整合性が復元されません。ビルドは「停止」し、出力は引き続き正しくありません。安定版の不整合な状態これが、Make や他のビルドツールのユーザーが make clean をタイプする主な理由です。ビルドツールがこのように失敗したことを検出して復元するには、時間がかかり、非常に面倒な作業になる可能性があります。

概念的には、一貫したビルドを実現する最も簡単な方法は、すべてのビルドをクリーンビルドにします。このアプローチは、（リリースエンジニアを除き）実用的にするには時間がかかりすぎます。そのため、有用であるためには、ビルドツールが整合性を損なうことなく増分ビルドを実行できる必要があります。

増分依存関係を正しく分析するのは困難であり、前述のように、他のビルドツールでは、ビルド中に不安定な状態の安定した状態を回避できていない使用できます。これに対して、Bazel では次のことが保証されています。編集を行わなかったビルドツールの呼び出しが成功した場合は、整合性のある状態に維持されます。（ビルド中にソースファイルを編集した場合、Bazel は現在のビルドの結果の一貫性を保証しません。ただし、次のビルドの結果が復元力があります。）

すべての保証と同様に、注意点があります。既知の方法はいくつかあります。安定した不整合状態になります増分依存関係分析でバグを意図的に見つけようとした結果生じる問題については、調査を保証するものではありませんが、ビルドツールの通常の使用または「合理的な」使用から生じる安定した不整合状態については、すべて調査し、修正するよう最善を尽くします。

Bazel と一貫性のない状態を検出した場合は、バグを報告してください。

サンドボックス化された実行

Bazel ではサンドボックスを使用して、アクションが密閉型で実行され、確認します。Bazel は、次のようなサンドボックスでスポーンspawns（大まかに言うとアクション）を実行します。ツールが機能を実行するために必要な最小限のファイルのみを含む。現在サンドボックス化は、Linux 3.12 以降で CONFIG_USER_NS オプションを指定すると機能しますまた、macOS 10.11 以降でもあります。

システムがサンドボックス化をサポートしていない場合、Bazel は警告を出力するビルドが密閉型であることを保証しているわけではなく、ホストシステムに侵入します。この警告を無効にするには、 --ignore_unsupported_sandboxing フラグを Bazel に設定。

Google Kubernetes Engine（GKE）や Engine クラスタノードか Debian のどちらであるかにかかわらず、セキュリティ設定のため、デフォルトで無効になります。考えていますこれは、ファイルの内容と /proc/sys/kernel/unprivileged_userns_clone: 存在し、0 が含まれる場合、使用してユーザーの名前空間を sudo sysctl kernel.unprivileged_userns_clone=1。

システムの設定が原因で、Bazel サンドボックスがルールを実行できない場合があります。この症状は通常、次のようなメッセージが出力される障害です。 namespace-sandbox.c:633: execvp(argv[0], argv): No such file or directory。その場合は、属性で genrule のサンドボックスを無効にし、 --strategy=Genrule=standalone など、次の値を含むルールを --spawn_strategy=standalone。また、 Issue Tracker に送信し、使用している Linux ディストリビューションを明記してください。今後のリリースで調査して修正を提供します

ビルドのフェーズ

Bazel では、ビルドは 3 つの異なるフェーズで実行されます。ユーザーは、これらのフェーズの違いを理解することで、ビルドを制御するオプションを把握できます（以下を参照）。

読み込みフェーズ

1 つ目は読み込みで、その間に必要なビルドファイルがすべて初期ターゲット、およびその依存関係の推移的なクロージャが読み込まれ、キャッシュに保存されます

Bazel サーバーの起動後の最初のビルドでは、多くの BUILD ファイルがファイルシステムから読み込まれるため、通常、読み込みフェーズに数秒かかります。後続のビルドでは、特に BUILD ファイルが変更されていない場合は、読み込みが非常に高速に行われます。

このフェーズで報告されるエラーには、パッケージが見つからない、ターゲットが見つからない、BUILD ファイルの語彙や文法のエラー、評価エラーなどがあります。

分析フェーズ

2 番目のフェーズである分析では、セマンティック分析と検証を行います。各ビルドルール、ビルド依存関係グラフの構築、ビルドの各ステップで行う作業を正確に決定できます

読み込みと同様に、分析全体を計算するときにも数秒かかります。ただし、Bazel は、あるビルドから次のビルドまで依存関係グラフをキャッシュに保存します。内容を再分析します。これにより、インクリメンタルビルドを非常に速く以前のビルドからパッケージが変更されていない場合は

このステージで報告されるエラーには、不適切な依存関係、ルールへの無効な入力、ルール固有のすべてのエラーメッセージが含まれます。

Bazel が不要なファイルを回避するため、読み込みフェーズと分析フェーズが高速化されます。このステージの I/O、実行する作業を決定するために BUILD ファイルのみを読み取るできます。これは意図的なものであり、Bazel は分析ツールの優れた基盤となっています。（読み込み時に実装される Bazel の query コマンドなど）あります

実施フェーズ

ビルドの 3 つ目の最終フェーズは実行です。このフェーズでは、必要に応じてコンパイル / リンクなどのツールを再実行し、ビルドの各ステップの出力が入力と一致するようにします。このステップでビルドの大部分の時間が費やされます。時間は、大規模なビルドの場合は数秒から 1 時間以上に及ぶことがあります。このフェーズで報告されるエラーには、ソースファイルがない、ビルドアクションによって実行されたツールのエラー、ツールが想定どおりの出力セットを生成できなかったなどがあります。