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

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

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

<ph type="x-smartling-placeholder"></ph> 問題を報告するソースを表示夜間 · 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。

これに対して、labels を使用すると、ターゲット（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 のスーパーセットであることを示すことを意味します。潜在的に混乱を招くため、この構文ではおなじみの :all ワイルドカードを _deploy.jar などのビルドターゲットは望ましくない一般的なビルド。

さらに、Bazel では、ラベル構文。これは、多くの場合、Bash ファイル名の展開を使用するときに便利です。たとえば、foo/bar/wiz は //foo/bar:wiz と同等です（パッケージ foo/bar）または //foo:bar/wiz（パッケージ foo がある場合）に移動します。

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

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

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

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

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

ただし、この方法で目標値を引き算しても、ターゲットの依存関係の可能性があるため、ビルドされないことを保証する減らされなかった割合ですたとえば、ターゲット //foo:all-apis があるとします。 //foo/bar:api に依存する場合、後者は次のようにビルドされます。構築の一部になります

tags = ["manual"] が指定されたターゲットは、ワイルドカードターゲットパターンに含まれません。（...、:*、:all など）になります。 bazel build、bazel testそのような場合は Bazel が必要な場合は、コマンドラインで明示的なターゲットパターンを使用してテストターゲットを作成します構築/テストできます。一方、bazel query は何も実行しません。フィルタリングが自動的に行われるため、 bazel query）。

外部依存関係の取得

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

ビルド中に取得を禁止し、Bazel が新しい外部 IP アドレスを検出した場合依存関係があると、ビルドは失敗します。

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

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

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

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

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

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

bazel fetch //...

利用できるツールがすべて揃っていれば、bazel 取得を実行する必要は一切ありません。を使用して（ライブラリ JAR から JDK 自体に）をワークスペースのルートで参照します。ただし、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 つ目の種類は、ユーザーまたはユーザーから提供された外部データまたは環境データです。ターゲットアーキテクチャ、コンパイル、リンクの選択ツールチェーン構成オプションが含まれます。Google Kubernetes Engine の構成として環境データをまとめます。

1 つのビルドに複数の構成が存在する場合があります。検討すべき事項クロスコンパイル（64 ビット用の //foo:bin 実行可能ファイルをビルドします）ワークステーションは 32 ビットマシンです。ビルドによって 64 ビットを作成できるツールチェーンを使用して //foo:bin をビルドする必要がある実行時に使用するさまざまなツールをビルドシステムで構築する必要もあります。たとえば、ソースからビルドされ、その後にツールがこれらはワークステーションで実行するように構築する必要があります。したがって 2 つの構成を識別できます。1 つはホスト構成です。これはビルド中に実行するツールをビルドするためのターゲット構成 （リクエスト構成でもかまいませんが、「ターゲット構成」と呼ぶこともあります。その単語にはすでに多くの意味がありますが）に基づき、バイナリが分割されます。

通常、リクエストされた両方の前提条件となるライブラリは多数あります。ビルドターゲット（//foo:bin）と 1 つ以上のホストツール（例: 使用できます。このようなライブラリは、ホスト用に 1 回、合計 2 回ビルドする必要があります。ターゲット構成で 1 回です。Bazel がお客様のデータを両方のバリアントがビルドされ、派生ファイルが保持されるようにします。干渉を避けるために分離する。通常、このようなターゲットは同時にビルドできます。これらは互いに独立しているからです進行状況に関するメッセージが表示される場合特定のターゲットが 2 回ビルドされていることを示します。この場合、説明します。

Bazel では、ホスト構成の選択に 2 つの方法のいずれかが使用されます。 --distinct_host_configuration オプション。このブール値のオプションはややわかりにくいため、この設定により、ビルドの速度が改善（または悪化）する可能性があります。

`--distinct_host_configuration=false`

このオプションが false の場合、ホストとリクエストの構成は同じになります。ビルド時に必要なツールはすべて、ビルド時にビルドされるターゲットプログラムです。この設定により、ライブラリを 2 回ビルドする必要がなくなります。 1 回ビルドします。

ただし、リクエストの構成を変更すると、ツールが再構築され、その後、すべてのツールが必要となります。そのため、たとえば、ビルド間でリンカーオプションを変更すると、すべてのツールが再リンクされる可能性があります。すべてのアクションが再実行されて行います。

`--distinct_host_configuration=true`（デフォルト）

このオプションが true の場合、完全に異なるホスト構成が使用されます。ホスト構成は、以下のようにターゲット構成から派生します。

以下で指定されているのと同じバージョンの 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_* オプションを参照）。
その他の値はすべてデフォルトのままにします。

多くの理由から、個別のホストを選択することをおすすめします。取得されます。中には難解すぎるものもあり、そのうちの 2 つは指摘しておく価値があります

まず、ストリップされて最適化されたバイナリを使用することで、ツールのリンクと実行、ツールが占有するディスク容量、分散ビルドでのネットワーク I/O 時間。

次に、すべてのビルドでホストとリクエストの構成を分離することで、環境に小さな変更を加えることによる高コストの構成（リンカーオプションの変更など）は、挙げられます

とはいえ、ビルドによってはこのオプションが妨げになる場合があります。特に構成の変更頻度が低いビルド（特に特定の Java では、ホストとバックエンドの両方で構築する必要があるコードの量がターゲット構成のサイズが大きいため、メリットがない可能性があります。

増分再ビルドを修正

Bazel プロジェクトの主な目標の 1 つは、構成されます。以前のビルドツール、特に Make をベースとしたビルドツールは、思い込みが合わないという問題がありました。

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

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

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

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

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

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

出力ファイルが存在し、その内容が手順またはルールを作成できます。ソースファイルを編集すると、ビルドは「不整合」と見なされ、次回の実行まで一貫性がない状態を保ちます。ビルドツールが正常に完了します。この状況は「不安定」と表現されます。不整合。これはあくまで一時的なものであり、整合性はビルドツールを実行します

有害な別の種類の不整合があります。それは安定です。不整合。ビルドが整合性のない安定した状態に達した場合は、ビルドツールを正常に呼び出しても整合性は復元されません。つまり、出力は正しくないままです安定版の不整合な状態これが、Make や他のビルドツールのユーザーが make clean をタイプする主な理由です。この方法でビルドツールに失敗したことが判明した場合（その後、復元する）作成に多大な時間と労力がかかる可能性があります。

概念的には、一貫したビルドを実現する最も簡単な方法は、すべてのビルドをクリーンビルドにします。この方法は明らかに時間がかかりすぎて実用的ではありません（ただし、ため、これを有効に活用するためには、ビルドツールで整合性を損なうことなく増分ビルドを実行できます

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

すべての保証と同様に、注意点があります。既知の方法はいくつかあります。安定した不整合状態になりますただし、バグを意図的に探し出すことで生じる問題を調査し増分依存関係分析ですが、Google が調査し、修正に向けて最善を尽くします。通常または「妥当」な状態から生じる、一貫性のないすべての状態使用ビルドツールを使用します。

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

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

Bazel ではサンドボックスを使用して、アクションが密閉型で実行され、確認します。Bazel は、次のようなサンドボックスでスポーン（大まかに言うとアクション）を実行します。ツールが機能を実行するために必要な最小限のファイルのみを含む。現在サンドボックス化は、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 ファイルに変更がない場合）は読み込みが発生するあります。

このフェーズで報告されるエラーには、「package not found」、「target not found」、 BUILD ファイル内の語彙や文法の誤り、評価の誤りなど、

分析フェーズ

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

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

この段階で報告されるエラーには、不適切な依存関係、無効などがあります。ルール固有のエラーメッセージがすべて表示されます。

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

実施フェーズ

ビルドの 3 番目かつ最後のフェーズは実行です。このフェーズでは各ステップの出力が入力と一致していることを確認し、コンパイル / リンクなどツールが用意されています。このステップでは数秒から大規模なイベントの場合は 1 時間以上に構築できます。このフェーズで報告されるエラー: ソースファイルの欠落、エラーなんらかのビルドアクションによって実行されたツール、出力のセットです。