このページでは、Bazel でプログラムをビルドする方法、ビルドコマンドの構文、ターゲット パターンの構文について説明します。
クイックスタート
Bazel を実行するには、ベースのワークスペース ディレクトリまたはそのサブディレクトリに移動して 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 help
startup_options
: Bazel をホストする JVM のオプション。bazel help
target-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 のターゲット パターンは複数のターゲットを指定します。ターゲット パターンは、ワイルドカードを使用してターゲットのセットのラベル構文を一般化したものです。最も単純なケースでは、有効なラベルは有効なターゲット パターンでもあり、1 つのターゲットのセットを識別します。
//
で始まるターゲット パターンはすべて、現在のワークスペースを基準に解決されます。
//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 |
ワークスペースのルートに BUILD ファイルがある場合、最上位パッケージ内のすべてのターゲット。 |
//
で始まらないターゲット パターンは、現在の作業ディレクトリを基準に解決されます。次の例では、作業ディレクトリが foo
であることを前提としています。
:foo |
//foo:foo に相当します。 |
bar:wiz |
//foo/bar:wiz と同じです。 |
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/...
はパッケージのワイルドカードで、ディレクトリ 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
がある場合、後者は前者のビルドの一部としてビルドされます。
bazel build
や bazel test
などのコマンドで指定された場合、tags = ["manual"]
を含むターゲットはワイルドカード ターゲット パターン(...
、:*
、: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 を実行する必要はありません。ただし、ワークスペース ディレクトリの外部で何かを使用している場合、Bazel は bazel build
の実行前に bazel fetch
を自動的に実行します。
リポジトリ キャッシュ
Bazel は、同じファイルが異なるワークスペースで必要である場合や、外部リポジトリの定義が変更されたが、ダウンロードに同じファイルが必要な場合でも、同じファイルを複数回取得しないようにします。これを行うために、bazel はダウンロードしたすべてのファイルをリポジトリ キャッシュにキャッシュに保存します。デフォルトでは、このキャッシュは ~/.cache/bazel/_bazel_$USER/cache/repos/v1/
にあります。ロケーションは --repository_cache
オプションで変更できます。キャッシュは、すべてのワークスペースとインストールされているバージョンの bazel で共有されます。エントリは、Bazel が正しいファイルのコピーがあることを明確に認識している場合にキャッシュから取得されます。つまり、ダウンロード リクエストに指定されたファイルの SHA256 の合計があり、そのハッシュを持つファイルがキャッシュにある場合です。したがって、外部ファイルごとにハッシュを指定することは、セキュリティの観点からだけでなく、不要なダウンロードを回避するためにも適切な方法です。
キャッシュ ヒットごとに、キャッシュ内のファイルの変更時間が更新されます。これにより、キャッシュを手動でクリーンアップするなど、キャッシュ ディレクトリ内のファイルの最終使用日を簡単に特定できます。キャッシュには、アップストリームで利用できなくなったファイルのコピーが含まれている可能性があるため、キャッシュは自動的にクリーンアップされません。
ディストリビューション ファイル ディレクトリ
ディストリビューション ディレクトリは、不要なダウンロードを回避するためのもう 1 つの Bazel メカニズムです。Bazel は、リポジトリ キャッシュの前にディストリビューション ディレクトリを検索します。主な違いは、ディストリビューション ディレクトリを手動で準備する必要があることです。
--distdir=/path/to-directory
オプションを使用すると、読み取り専用のディレクトリを追加して、ファイルを取得するのではなく検索できます。ファイル名が URL のベース名と一致し、さらにファイルのハッシュがダウンロード リクエストで指定されたハッシュと一致する場合、そのようなディレクトリからファイルが取得されます。これは、ファイルハッシュが WORKSPACE 宣言で指定されている場合にのみ機能します。
ファイル名の条件は正確性のために必要ありませんが、指定したディレクトリごとに候補ファイルの数を 1 つに減らすことができます。この方法では、そのようなディレクトリ内のファイル数が大きくなっても、ディストリビューション ファイル ディレクトリの指定は効率的です。
エアギャップ環境で Bazel を実行する
Bazel のバイナリサイズを小さく保つため、Bazel の暗黙的な依存関係は、初めて実行するときにネットワーク経由で取得されます。これらの暗黙的な依存関係には、すべてのユーザーに必要でないツールチェーンとルールが含まれています。たとえば、Android ツールは、Android プロジェクトのビルド時にのみバンドル解除され、フェッチされます。
ただし、これらの暗黙的な依存関係は、WORKSPACE の依存関係をすべてベンダー化しても、エアギャップ環境で Bazel を実行するときに問題を引き起こす可能性があります。この問題を解決するには、ネットワークにアクセスできるマシンにこれらの依存関係を含むディストリビューション ディレクトリを準備し、オフライン アプローチでエアギャップ環境に転送します。
ディストリビューション ディレクトリを準備するには、--distdir
フラグを使用します。暗黙的な依存関係はリリースごとに異なる可能性があるため、新しい Bazel バイナリ バージョンごとに 1 回行う必要があります。
エアギャップ環境の外部でこれらの依存関係をビルドするには、まず、適切なバージョンの Bazel ソースツリーをチェックアウトします。
git clone https://github.com/bazelbuild/bazel "$BAZEL_DIR"
cd "$BAZEL_DIR"
git checkout "$BAZEL_VERSION"
次に、その特定の Bazel バージョンの暗黙的なランタイム依存関係を含む tarball をビルドします。
bazel build @additional_distfiles//:archives.tar
この tarball を、エアギャップ環境にコピーできるディレクトリにエクスポートします。--distdir
はディレクトリのネストレベルで非常に繊細な動作になる可能性があるため、--strip-components
フラグに注意してください。
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 構成オプションなどです。環境データの完全なセットを「構成」と呼びます。
特定のビルドには、複数の構成が存在する場合があります。クロスコンパイルについて考えてみましょう。64 ビット アーキテクチャ用の //foo:bin
実行ファイルをビルドしますが、ワークステーションは 32 ビット マシンです。ビルドでは、64 ビットの実行可能ファイルを作成できる toolchain を使用して //foo:bin
をビルドする必要がありますが、ビルドシステムはビルド中に使用されるさまざまなツール(ソースからビルドされ、その後 genrule などで使用されるツールなど)もビルドする必要があります。これらのツールは、ワークステーションで実行するようにビルドする必要があります。したがって、2 つの構成を特定できます。実行構成は、ビルド中に実行されるツールのビルドに使用されます。ターゲット構成(またはリクエスト構成。この言葉にはすでに多くの意味がありますが、より一般的には「ターゲット構成」と呼ばれます)は、最終的にリクエストしたバイナリのビルドに使用されます。
通常、リクエストされたビルド ターゲット(//foo:bin
)と 1 つ以上のツール(一部のベース ライブラリなど)の両方の前提条件となるライブラリが多数あります。このようなライブラリは、実行構成とターゲット構成用に複数回ビルドする必要があります。Bazel は、すべてのバリアントをビルドし、干渉を回避するために派生ファイルを分離します。通常、このようなターゲットは相互に独立しているため、同時にビルドできます。特定のターゲットが複数回ビルドされていることを示す進行状況メッセージが表示される場合、これが原因である可能性が高いです。
exec 構成は、次のようにターゲット構成から派生します。
- リクエスト ターゲットの実行プラットフォームが、exec 構成のターゲット プラットフォームになります。
--host_crosstool_top
が指定されていない限り、リクエスト構成で指定されたバージョンの Crosstool(--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 は堅牢ではありません。現在の Make の実行は失敗しますが、その後の Make の呼び出しでは、切り捨てられた出力ファイルが有効であると盲目的に想定され(入力ファイルよりも新しいため)、再ビルドされません。同様に、Make プロセスが強制終了された場合も、同様の状況が発生する可能性があります。
Bazel では、このような前提条件を回避します。Bazel は、以前に行われたすべての作業のデータベースを維持します。ビルドステップの入力ファイルのセット(およびそのタイムスタンプ)と、そのビルドステップのコンパイル コマンドがデータベース内の 1 つと完全に一致し、データベース エントリの出力ファイルのセット(およびそのタイムスタンプ)がディスク上のファイルのタイムスタンプと完全に一致する場合にのみ、ビルドステップを省略します。入力ファイルまたは出力ファイル、またはコマンド自体に変更を加えると、ビルドステップが再実行されます。
正しい増分ビルドを使用すると、混乱による無駄な時間が減ります。(また、make
clean
の使用による再ビルドの待ち時間が短縮されます。これは、再ビルドが必要な場合でも、先行型の場合でも同様です)。
ビルドの整合性と増分ビルド
正式には、想定される出力ファイルがすべて存在し、その作成に必要な手順またはルールで指定されているように内容が正しい場合、ビルドの状態は整合性があると定義されます。ソースファイルを編集すると、ビルドの状態は不整合になり、次にビルドツールを実行して正常に完了するまで不整合のままになります。この状況は一時的なもので、ビルドツールを実行すると整合性が復元されるため、不安定な不整合と呼ばれます。
有害な不整合がもう 1 つあります。それは安定した不整合です。ビルドが安定した不整合状態に達すると、ビルドツールを繰り返し正常に呼び出しても整合性が復元されません。ビルドは「停止」し、出力は引き続き正しくありません。安定した不整合状態は、Make(および他のビルドツール)のユーザーが make clean
を入力する主な理由です。ビルドツールがこのように失敗したことを検出して復元するには、時間がかかり、非常にイライラする可能性があります。
概念的には、一貫したビルドを実現する最も簡単な方法は、以前のビルド出力をすべて破棄して最初からやり直すことです。つまり、すべてのビルドをクリーンビルドにします。このアプローチは、(リリース エンジニアを除き)明らかに時間がかかりすぎるため実用的ではありません。そのため、有用であるためには、ビルドツールが整合性を損なうことなく増分ビルドを実行できる必要があります。
正しい増分依存関係分析は困難です。前述のように、他の多くのビルドツールは、増分ビルド中に安定した不整合状態を回避するのが苦手です。一方、Bazel では、編集を行わずにビルドツールを正常に呼び出した後、ビルドが一貫した状態になることが保証されます。(ビルド中にソースファイルを編集した場合、Bazel は現在のビルドの結果の一貫性を保証しません。ただし、次回のビルドの結果で整合性が復元されることは保証されます)。
すべての保証と同様に、細かい条件があります。Bazel で安定した不整合状態になる既知の方法がいくつかあります。増分依存関係分析でバグを意図的に見つけようとした結果生じる問題については、調査を保証するものではありませんが、ビルドツールの通常の使用または「合理的な」使用から生じる安定した不整合状態については、すべて調査し、修正するよう最善を尽くします。
Bazel で安定した不整合状態が検出された場合は、バグを報告してください。
サンドボックス化された実行
Bazel はサンドボックスを使用して、アクションが密閉状態で正しく実行されるようにします。Bazel は、ツールの処理に必要な最小限のファイルセットのみを含むサンドボックスでスポーン(大まかに言えばアクション)を実行します。現在、サンドボックスは、CONFIG_USER_NS
オプションが有効になっている Linux 3.12 以降、および macOS 10.11 以降で動作します。
システムがサンドボックス化をサポートしていない場合、Bazel は警告を表示します。これは、ビルドが完全であることが保証されず、未知の方法でホストシステムに影響する可能性があることを警告するためのものです。この警告を無効にするには、--ignore_unsupported_sandboxing
フラグを Bazel に渡します。
Google Kubernetes Engine クラスタノードや Debian などの一部のプラットフォームでは、セキュリティ上の懸念から、ユーザー Namespace はデフォルトで無効になっています。これは、ファイル /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
のようなメッセージが出力される失敗が症状として現れます。その場合は、--strategy=Genrule=standalone
を使用して genrules のサンドボックスを無効にし、--spawn_strategy=standalone
を使用して他のルールのサンドボックスを無効にしてみてください。また、Google が調査し、今後のリリースで修正できるように、Issue Tracker でバグを報告し、使用している Linux ディストリビューションもお知らせください。
ビルドのフェーズ
Bazel では、ビルドは 3 つの異なるフェーズで実行されます。ユーザーは、これらのフェーズの違いを理解することで、ビルドを制御するオプションを把握できます(以下を参照)。
読み込みフェーズ
1 つ目は読み込みです。このフェーズでは、初期ターゲットに必要なすべての BUILD ファイルと、それらの依存関係の推移閉包が読み込まれ、解析、評価、キャッシュに保存されます。
Bazel サーバーの起動後の最初のビルドでは、多くの BUILD ファイルがファイル システムから読み込まれるため、通常、読み込みフェーズに数秒かかります。後続のビルドでは、特に BUILD ファイルが変更されていない場合は、読み込みが非常に高速に行われます。
このフェーズで報告されるエラーには、パッケージが見つからない、ターゲットが見つからない、BUILD ファイルの語彙や文法のエラー、評価エラーなどがあります。
分析フェーズ
2 つ目のフェーズである分析では、各ビルドルールのセマンティック分析と検証、ビルド依存関係グラフの構築、ビルドの各ステップで行う作業を正確に決定します。
読み込みと同様に、分析も全体を計算すると数秒かかります。ただし、Bazel はビルド間で依存関係グラフをキャッシュに保存し、必要なもののみを再分析します。これにより、パッケージが前回のビルドから変更されていない場合は、増分ビルドを非常に高速に行うことができます。
このステージで報告されるエラーには、不適切な依存関係、ルールへの無効な入力、ルール固有のエラー メッセージが含まれます。
読み込みフェーズと分析フェーズは高速です。このステージでは Bazel が不要なファイル I/O を回避し、実行する作業を決定するために BUILD ファイルのみを読み取るためです。これは設計上の特性であり、Bazel は、読み込みフェーズ上に実装された Bazel の query コマンドなどの分析ツールの優れた基盤となります。
実施フェーズ
ビルドの 3 つ目の最終フェーズは実行です。このフェーズでは、必要に応じてコンパイル / リンクなどのツールを再実行し、ビルドの各ステップの出力が入力と一致するようにします。このステップでビルドの大部分の時間が費やされます。時間は、大規模なビルドの場合は数秒から 1 時間以上に及ぶことがあります。このフェーズで報告されるエラーには、ソースファイルがない、ビルドアクションによって実行されたツールのエラー、ツールが想定される出力セットを生成できなかったなどがあります。