コマンドとオプション

問題を報告する ソースを表示 Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

このページでは、bazel build、bazel run、bazel test などのさまざまな Bazel コマンドで使用できるオプションについて説明します。このページは、Bazel を使用したビルドの Bazel コマンドのリストの補足です。

ターゲットの構文

build や test などの一部のコマンドは、ターゲットのリストに対して動作できます。ラベルよりも柔軟な構文を使用します。この構文については、ビルドするターゲットの指定で説明しています。

オプション

以降のセクションでは、ビルド中に使用可能なオプションについて説明します。ヘルプ コマンドで --long を使用すると、オンライン ヘルプ メッセージに、各オプションの意味、型、デフォルト値に関する概要情報が表示されます。

ほとんどのオプションは 1 回のみ指定できます。複数回指定された場合は、最後のインスタンスが優先されます。複数回指定できるオプションは、オンライン ヘルプで「複数回使用可能」というテキストで識別されます。

パッケージの場所

--package_path

警告: --package_path オプションは非推奨です。Bazel では、メイン リポジトリのパッケージはワークスペース ルートの下に配置することが推奨されています。

このオプションは、特定のパッケージの BUILD ファイルを検索するディレクトリのセットを指定します。

Bazel は、パッケージ パスを検索してパッケージを見つけます。これは、コロンで区切られた bazel ディレクトリの順序付きリストです。各ディレクトリは部分的なソースツリーのルートです。

--package_path オプションを使用してカスタム パッケージ パスを指定するには:

  % bazel build --package_path %workspace%:/some/other/root

パッケージ パス要素は、次の 3 つの形式で指定できます。

  1. 最初の文字が / の場合、パスは絶対パスです。
  2. パスが %workspace% で始まる場合、パスは最も近い囲み bazel ディレクトリを基準とする相対パスとみなされます。たとえば、作業ディレクトリが /home/bob/clients/bob_client/bazel/foo の場合、package-path の文字列 %workspace% は /home/bob/clients/bob_client/bazel に展開されます。
  3. それ以外はすべて作業ディレクトリを基準とします。通常、これは意図した動作ではありません。bazel ワークスペースより下のディレクトリから Bazel を使用すると、予期しない動作をする可能性があります。たとえば、package-path 要素 . を使用して /home/bob/clients/bob_client/bazel/foo ディレクトリに cd すると、パッケージは /home/bob/clients/bob_client/bazel/foo ディレクトリから解決されます。

デフォルト以外のパッケージ パスを使用する場合は、便宜上、Bazel 構成ファイルで指定します。

Bazel では、パッケージが現在のディレクトリにある必要はありません。そのため、必要なパッケージがパッケージ パスの別の場所にある場合は、空の Bazel ワークスペースからビルドを実行できます。

例: 空のクライアントからビルドする

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch MODULE.bazel
  % bazel build --package_path /some/other/path //foo

--deleted_packages

このオプションは、Bazel が削除済みと見なして、パッケージ パスのどのディレクトリからも読み込もうとしないパッケージのカンマ区切りリストを指定します。これは、パッケージを実際に削除せずに削除をシミュレートするために使用できます。このオプションは複数回渡すことができます。その場合、個々のリストが連結されます。

エラー チェック

これらのオプションは、Bazel のエラーチェックや警告を制御します。

--[no]check_visibility

このオプションが false に設定されている場合、可視性チェックは警告に降格されます。このオプションのデフォルト値は true です。したがって、デフォルトでは可視性チェックが行われます。

--output_filter=regex

--output_filter オプションは、正規表現に一致するターゲットのビルドとコンパイルの警告のみを表示します。ターゲットが指定された正規表現と一致せず、実行が成功した場合、その標準出力と標準エラーは破棄されます。

このオプションの一般的な値は次のとおりです。

`--output_filter='^//(first/project|second/project):'` 指定したパッケージの出力を表示します。
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'` 指定されたパッケージの出力を表示しません。
`--output_filter=` すべてを表示します。
`--output_filter=DONT_MATCH_ANYTHING` 何も表示しない。

ツールフラグ

これらのオプションは、Bazel が他のツールに渡すオプションを制御します。

--copt=cc-option

このオプションは、コンパイラに渡される引数を取ります。この引数は、C、C++、アセンブラ コードのプリプロセス、コンパイル、アセンブルのためにコンパイラが呼び出されるたびに渡されます。リンク時に渡されません。

このオプションは複数回使用できます。次に例を示します。

  % bazel build --copt="-g0" --copt="-fpic" //foo

は、デバッグ テーブルなしで foo ライブラリをコンパイルし、位置独立コードを生成します。

--host_copt=cc-option

このオプションは、exec 構成でコンパイルされるソースファイルのコンパイラに渡される引数を取ります。これは --copt オプションに似ていますが、exec 構成にのみ適用されます。

--host_conlyopt=cc-option

このオプションは、exec 構成でコンパイルされる C ソースファイルのコンパイラに渡される引数を取ります。これは --conlyopt オプションに似ていますが、exec 構成にのみ適用されます。

--host_cxxopt=cc-option

このオプションは、exec 構成でコンパイルされる C++ ソースファイルのコンパイラに渡される引数を取ります。これは --cxxopt オプションに似ていますが、exec 構成にのみ適用されます。

--host_linkopt=linker-option

このオプションは、exec 構成でコンパイルされるソースファイルのリンカーに渡される引数を取ります。これは --linkopt オプションに似ていますが、exec 構成にのみ適用されます。

--conlyopt=cc-option

このオプションは、C ソースファイルをコンパイルするときにコンパイラに渡される引数を取ります。

これは --copt と同様ですが、C コンパイルにのみ適用され、C++ コンパイルやリンクには適用されません。そのため、--conlyopt を使用して C 固有のオプション（-Wno-pointer-sign など）を渡すことができます。

--cxxopt=cc-option

このオプションは、C++ ソースファイルのコンパイル時にコンパイラに渡される引数を取ります。

これは --copt と同様ですが、C++ のコンパイルにのみ適用され、C のコンパイルやリンクには適用されません。そのため、--cxxopt を使用して C++ 固有のオプション（-fpermissive や -fno-implicit-templates など）を渡すことができます。

次に例を示します。

  % bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code

--linkopt=linker-option

このオプションは、リンク時にコンパイラに渡される引数を取ります。

これは --copt に似ていますが、コンパイルではなくリンクにのみ適用されます。そのため、--linkopt を使用して、リンク時にのみ意味のあるコンパイラ オプション（-lssp や -Wl,--wrap,abort など）を渡すことができます。次に例を示します。

  % bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code

ビルドルールでは、属性でリンク オプションを指定することもできます。このオプションの設定は常に優先されます。cc_library.linkopts もご覧ください。

--strip (always|never|sometimes)

このオプションは、-Wl,--strip-debug オプションを指定してリンカーを呼び出すことで、Bazel がすべてのバイナリと共有ライブラリからデバッグ情報を削除するかどうかを決定します。--strip=always は、デバッグ情報を常に削除することを意味します。--strip=never は、デバッグ情報を削除しないことを意味します。--strip=sometimes のデフォルト値は、--compilation_mode が fastbuild の場合はストリップを意味します。

  % bazel build --strip=always //foo:bar

は、生成されたすべてのバイナリからデバッグ情報を削除しながら、ターゲットをコンパイルします。

Bazel の --strip オプションは ld の --strip-debug オプションに対応しており、デバッグ情報のみを削除します。なんらかの理由で、デバッグ シンボルだけでなく、すべてのシンボルを削除する場合は、ld の --strip-all オプションを使用する必要があります。これは、Bazel に --linkopt=-Wl,--strip-all を渡すことで実行できます。また、Bazel の --strip フラグを設定すると --linkopt=-Wl,--strip-all がオーバーライドされるため、いずれか一方のみを設定する必要があります。

単一のバイナリのみをビルドし、すべてのシンボルを削除する場合は、--stripopt=--strip-all を渡して、ターゲットの //foo:bar.stripped バージョンを明示的にビルドすることもできます。--stripopt のセクションで説明したように、これは、すべてのビルドのリンク アクションにストリッピングを含めるのではなく、最終バイナリがリンクされた後にストリップ アクションを適用します。

--stripopt=strip-option

これは、*.stripped バイナリを生成するときに strip コマンドに渡す追加オプションです。デフォルトは -S -p です。 このオプションは複数回使用できます。

--fdo_instrument=profile-output-dir

--fdo_instrument オプションを使用すると、ビルドされた C/C++ バイナリの実行時に FDO（フィードバックに基づく最適化）プロファイル出力の生成が有効になります。GCC の場合、指定された引数は、各 .o ファイルのプロファイル情報を含む .gcda ファイルのオブジェクト ファイル ディレクトリ ツリーのディレクトリ接頭辞として使用されます。

プロファイル データツリーが生成されたら、プロファイル ツリーを圧縮して、--fdo_optimize=profile-zip Bazel オプションに指定し、FDO 最適化コンパイルを有効にします。

LLVM コンパイラの場合、引数は未加工の LLVM プロファイル データ ファイルがダンプされるディレクトリでもあります。例: --fdo_instrument=/path/to/rawprof/dir/。

--fdo_instrument オプションと --fdo_optimize オプションを同時に使用することはできません。

--fdo_optimize=profile-zip

--fdo_optimize オプションを使用すると、コンパイル時にオブジェクト ファイルごとのプロファイル情報を使用して FDO（フィードバックに基づく最適化）最適化を実行できます。GCC の場合、指定される引数は、各 .o ファイルのプロファイル情報を含む .gcda ファイルの以前に生成されたファイルツリーを含む zip ファイルです。

また、指定された引数は、拡張子 .afdo で識別される自動プロファイルを指すこともできます。

LLVM コンパイラの場合、指定する引数は llvm-profdata ツールで準備されたインデックス付き LLVM プロファイル出力ファイルを指し、拡張子は .profdata である必要があります。

--fdo_instrument オプションと --fdo_optimize オプションを同時に使用することはできません。

--java_language_version=version

このオプションは、Java ソースのバージョンを指定します。次に例を示します。

  % bazel build --java_language_version=8 java/com/example/common/foo:all

コンパイルし、Java 8 仕様と互換性のある構成のみを許可します。デフォルト値は 11 です。--> 使用可能な値は 8、9、10、11、17、21 です。default_java_toolchain を使用してカスタム Java ツールチェーンを登録することで拡張できます。

--tool_java_language_version=version

ビルド中に実行されるツールのビルドに使用される Java 言語のバージョン。デフォルト値は 11 です。

--java_runtime_version=version

このオプションは、コードの実行とテストの実行に使用する JVM のバージョンを指定します。次に例を示します。

  % bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application

リモート リポジトリから JDK 11 をダウンロードし、それを使用して Java アプリケーションを実行します。

デフォルト値は local_jdk です。有効な値は、local_jdk、local_jdk_version、remotejdk_11、remotejdk_17、remotejdk_21 です。local_java_repository または remote_java_repository リポジトリ ルールを使用してカスタム JVM を登録することで、値を拡張できます。

--tool_java_runtime_version=version

ビルド中に必要なツールを実行するために使用される JVM のバージョン。デフォルト値は remotejdk_11 です。

--jvmopt=jvm-option

このオプションを使用すると、オプション引数を Java VM に渡すことができます。1 つの大きな引数で使用することも、個別の引数で複数回使用することもできます。次に例を示します。

  % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all

は、すべての Java バイナリの起動にサーバー VM を使用し、VM の起動ヒープサイズを 256 MB に設定します。

--javacopt=javac-option

このオプションを使用すると、オプション引数を javac に渡すことができます。1 つの大きな引数で使用することも、個別の引数で複数回使用することもできます。次に例を示します。

  % bazel build --javacopt="-g:source,lines" //myprojects:prog

は、javac のデフォルトのデバッグ情報（bazel のデフォルトではなく）を使用して java_binary を再構築します。

このオプションは、javac の Bazel 組み込みデフォルト オプションの後、ルールごとのオプションの前に javac に渡されます。javac に渡されたオプションの最後の仕様が優先されます。javac のデフォルト オプションは次のとおりです。

  -source 8 -target 8 -encoding UTF-8

--strict_java_deps (default|strict|off|warn|error)

このオプションは、javac が直接依存関係の欠落をチェックするかどうかを制御します。Java ターゲットは、直接使用されるすべてのターゲットを依存関係として明示的に宣言する必要があります。このフラグは、各 Java ファイルの型チェックに実際に使用される JAR を特定し、それらが現在のターゲットの直接依存関係の出力でない場合に警告またはエラーを生成するよう javac に指示します。

  • off は、チェックが無効になっていることを意味します。
  • warn は、javac が欠落している直接的な依存関係ごとに [strict] タイプの標準 Java 警告を生成することを意味します。
  • default、strict、error はすべて、javac が警告ではなくエラーを生成することを意味します。これにより、直接依存関係が見つからない場合、現在のターゲットのビルドが失敗します。このフラグが指定されていない場合も、これがデフォルトの動作になります。

ビルドのセマンティクス

これらのオプションは、ビルドコマンドや出力ファイルの内容に影響します。

--compilation_mode (fastbuild|opt|dbg)（-c）

--compilation_mode オプション（多くの場合 -c に短縮されます。特に -c opt）は、fastbuild、dbg、または opt の引数を取り、最適化のレベルやデバッグ テーブルの完全性など、さまざまな C/C++ コード生成オプションに影響します。Bazel はコンパイル モードごとに異なる出力ディレクトリを使用するため、毎回フルビルドを行う必要なくモードを切り替えることができます。

  • fastbuild は、できるだけ高速にビルドすることを意味します。最小限のデバッグ情報（-gmlt -Wl,-S）を生成し、最適化は行いません。これがデフォルトです。注: -DNDEBUG は設定されません。
  • dbg は、デバッグを有効にして（-g）ビルドすることを意味します。これにより、gdb（または別のデバッガ）を使用できます。
  • opt は、最適化を有効にして assert() 呼び出しを無効（-O2 -DNDEBUG）にしてビルドすることを意味します。--copt -g も渡さない限り、opt モードではデバッグ情報は生成されません。

--cpu=cpu

このオプションは、ビルド中にバイナリのコンパイルに使用するターゲット CPU アーキテクチャを指定します。

--action_env=VAR=VALUE

すべてのアクションの実行時に使用できる環境変数のセットを指定します。変数は名前で指定できます。この場合、値は呼び出し環境から取得されます。また、name=value ペアで指定することもできます。この場合、値は呼び出し環境とは無関係に設定されます。

この --action_env フラグは複数回指定できます。複数の --action_env フラグで同じ変数に値が割り当てられている場合、最後に割り当てられた値が優先されます。

--experimental_action_listener=label

experimental_action_listener オプションは、label で指定された action_listener ルールの詳細を使用して、extra_actions をビルドグラフに挿入するよう Bazel に指示します。

--[no]experimental_extra_action_top_level_only

このオプションが true に設定されている場合、 --experimental_action_listener コマンドライン オプションで指定された追加のアクションは、最上位のターゲットに対してのみスケジュールされます。

--experimental_extra_action_filter=regex

experimental_extra_action_filter オプションは、スケジュールするターゲットのセットをフィルタして extra_actions を指定するよう Bazel に指示します。

このフラグは、--experimental_action_listener フラグと組み合わせてのみ適用されます。

デフォルトでは、ビルド対象としてリクエストされたターゲットの推移閉包内のすべての extra_actions が実行のスケジュール設定されます。--experimental_extra_action_filter は、所有者のラベルが指定された正規表現に一致する extra_actions にスケジューリングを制限します。

次の例では、extra_actions のスケジューリングを、所有者のラベルに「/bar/」が含まれるアクションにのみ適用するように制限します。

% bazel build --experimental_action_listener=//test:al //foo/... \
  --experimental_extra_action_filter=.*/bar/.*

--host_cpu=cpu

このオプションは、ホストツールをビルドするために使用する CPU アーキテクチャの名前を指定します。

--android_platforms=platform[,platform]*

android_binary ルールの推移的 deps をビルドするプラットフォーム（特に C++ などのネイティブ依存関係の場合）。たとえば、android_binary ルールの推移的 deps に cc_library が含まれている場合、android_binary ルールの --android_platforms で指定された各プラットフォームに対して 1 回ビルドされ、最終出力に含まれます。

このフラグにはデフォルト値はありません。カスタム Android プラットフォームを定義して使用する必要があります。

--android_platforms で指定されたプラットフォームごとに 1 つの .so ファイルが作成され、APK にパッケージ化されます。.so ファイルの名前は、android_binary ルールの名前の前に「lib」を付けます。たとえば、android_binary の名前が「foo」の場合、ファイルは libfoo.so になります。

--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...

存在する場合、包含正規表現のいずれかに一致し、除外正規表現のいずれにも一致しないラベルまたは実行パスを持つ C++ ファイルは、指定されたオプションでビルドされます。ラベルのマッチングでは、ラベルの正規形（//package:label_name）が使用されます。

実行パスは、ワークスペース ディレクトリへの相対パスで、C++ ファイルのベース名（拡張子を含む）が含まれます。プラットフォーム依存の接頭辞も含まれます。

生成されたファイル（genrule 出力など）を照合するために、Bazel は実行パスのみを使用できます。この場合、正規表現は実行パスと一致しないため、'//' で始めるべきではありません。パッケージ名は --per_file_copt=base/.*\.pb\.cc@-g0 のように使用できます。これにより、base というディレクトリ内のすべての .pb.cc ファイルが一致します。

このオプションは複数回使用できます。

このオプションは、使用されるコンパイル モードに関係なく適用されます。たとえば、--compilation_mode=opt でコンパイルし、一部のファイルを選択的にコンパイルして、より強力な最適化を有効にしたり、最適化を無効にしたりできます。

注意: 一部のファイルがデバッグ シンボル付きで選択的にコンパイルされている場合、リンク中にシンボルが削除される可能性があります。これは、--strip=never を設定することで防止できます。

構文: [+-]regex[,[+-]regex]...@option[,option]...。ここで、regex は正規表現を表します。正規表現の前に + を付けると包含パターンが識別され、- を付けると除外パターンが識別されます。option は、C++ コンパイラに渡される任意のオプションを表します。オプションに , が含まれている場合は、\, のように引用符で囲む必要があります。最初の @ のみが正規表現とオプションの区切りに使用されるため、オプションに @ を含めることもできます。

例: --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs は、//foo/ の file.cc 以外のすべての .cc ファイルについて、C++ コンパイラのコマンドラインに -O0 オプションと -fprofile-arcs オプションを追加します。

--dynamic_mode=mode

C++ バイナリを動的にリンクするかどうかを決定し、ビルドルールの linkstatic 属性と連携します。

モード:

  • default: bazel が動的にリンクするかどうかを選択できるようにします。詳しくは、linkstatic をご覧ください。
  • fully: すべてのターゲットを動的にリンクします。これにより、リンク時間が短縮され、生成されるバイナリのサイズが縮小されます。
  • off: ほぼ静的モードですべてのターゲットをリンクします。linkopts で -static が設定されている場合、ターゲットは完全に静的になります。

--fission (yes|no|[dbg][,opt][,fastbuild])

Fission を有効にします。これにより、C++ デバッグ情報が、通常書き込まれる .o ファイルではなく、専用の .dwo ファイルに書き込まれます。これにより、リンクへの入力サイズが大幅に削減され、リンク時間を短縮できます。

[dbg][,opt][,fastbuild]（例: --fission=dbg,fastbuild）に設定すると、指定されたコンパイル モードのセットでのみ Fission が有効になります。これは bazelrc 設定に役立ちます。yes に設定すると、Fission がグローバルに有効になります。no に設定すると、Fission はグローバルに無効になります。デフォルトは no です。

--force_ignore_dash_static

このフラグが設定されている場合、cc_* ルールの BUILD ファイルの linkopts の -static オプションは無視されます。これは、C++ 強化ビルドの回避策としてのみ使用することを目的としています。

--[no]force_pic

有効にすると、すべての C++ コンパイルで位置独立コード（「-fPIC」）が生成され、リンクでは PIC ビルド済みライブラリが非 PIC ライブラリよりも優先され、リンクでは位置独立実行可能ファイル（「-pie」）が生成されます。デフォルトは無効になっています。

--android_resource_shrinking

android_binary ルールでリソースの縮小を行うかどうかを選択します。android_binary ルールの shrink_resources 属性のデフォルトを設定します。詳細については、そのルールのドキュメントをご覧ください。デフォルトはオフです。

--custom_malloc=malloc-library-target

指定すると、常に指定された malloc 実装が使用され、すべての malloc="target" 属性がオーバーライドされます。これには、デフォルトを使用するターゲット（malloc を指定しないターゲット）も含まれます。

--crosstool_top=label

このオプションは、ビルド中のすべての C++ コンパイルで使用される crosstool コンパイラ スイートの場所を指定します。Bazel はその場所で CROSSTOOL ファイルを探し、それを使用して --compiler の設定を自動的に決定します。

--host_crosstool_top=label

指定しない場合、Bazel は --crosstool_top の値を使用して、ビルド中に実行されるツールなどの実行構成でコードをコンパイルします。このフラグの主な目的は、クロス コンパイルを有効にすることです。

--apple_crosstool_top=label

objc*、ios*、apple* ルールの推移的 deps で C/C++ ルールのコンパイルに使用する crosstool。これらのターゲットの場合、このフラグは --crosstool_top をオーバーライドします。

--compiler=version

このオプションは、ビルド中にバイナリのコンパイルに使用する C/C++ コンパイラのバージョン（gcc-4.1.0 など）を指定します。カスタムの crosstool でビルドする場合は、このフラグを指定する代わりに CROSSTOOL ファイルを使用する必要があります。

--android_sdk=label

非推奨です。これは直接指定しないでください。

このオプションは、Android 関連のルールをビルドするために使用される Android SDK/プラットフォーム ツールチェーンと Android ランタイム ライブラリを指定します。

WORKSPACE ファイルで android_sdk_repository ルールが定義されている場合、Android SDK は自動的に選択されます。

--java_toolchain=label

何もしません。下位互換性のためにのみ保持されます。

--host_java_toolchain=label

何もしません。下位互換性のためにのみ保持されます。

--javabase=(label)

何もしません。下位互換性のためにのみ保持されます。

--host_javabase=label

何もしません。下位互換性のためにのみ保持されます。

実行戦略

これらのオプションは、Bazel がビルドを実行する方法に影響します。ビルドで生成される出力ファイルに大きな影響を与えることはありません。通常、主な影響はビルドの速度に及びます。

--spawn_strategy=strategy

このオプションは、コマンドの実行場所と実行方法を制御します。

  • standalone は、コマンドをローカル サブプロセスとして実行します。この値は非推奨です。代わりに local を使用してください。
  • sandboxed を指定すると、ローカルマシンのサンドボックス内でコマンドが実行されます。これには、すべての入力ファイル、データ依存関係、ツールが srcs、data、tools 属性で直接依存関係としてリストされている必要があります。Bazel は、サンドボックス実行をサポートするシステムで、デフォルトでローカル サンドボックスを有効にします。
  • local を使用すると、コマンドがローカル サブプロセスとして実行されます。
  • worker を指定すると、コマンドは永続ワーカーを使用して実行されます（使用可能な場合）。
  • docker を指定すると、ローカルマシンの Docker サンドボックス内でコマンドが実行されます。これには、Docker がインストールされている必要があります。
  • remote を指定すると、コマンドがリモートで実行されます。これは、リモート実行ツールが個別に構成されている場合にのみ使用できます。

--strategy mnemonic=strategy

このオプションは、コマンドの実行場所と実行方法を制御し、--spawn_strategy（およびニーモニック Genrule を使用した --genrule_strategy）をニーモニックごとにオーバーライドします。サポートされている戦略とその効果については、--spawn_strategy をご覧ください。

--strategy_regexp=<filter,filter,...>=<strategy>

このオプションは、特定の regex_filter に一致する説明を持つコマンドを実行するために使用する戦略を指定します。regex_filter の照合について詳しくは、--per_file_copt をご覧ください。サポートされている戦略とその効果については、--spawn_strategy をご覧ください。

説明に一致する最後の regex_filter が使用されます。このオプションは、戦略を指定する他のフラグをオーバーライドします。

  • 例: --strategy_regexp=//foo.*\\.cc,-//foo/bar=local は、説明が //foo.*.cc に一致し、//foo/bar に一致しない場合に、local 戦略を使用してアクションを実行することを意味します。
  • 例: --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed は sandboxed 戦略で「Compiling //foo/bar/baz」を実行しますが、順序を逆にすると local で実行します。
  • 例: --strategy_regexp='Compiling.*/bar=local,sandboxed' は local 戦略で「Compiling //foo/bar/baz」を実行し、失敗した場合は sandboxed にフォールバックします。

--genrule_strategy=strategy

これは --strategy=Genrule=strategy の非推奨の短縮形です。

--jobs=n（-j）

このオプションは整数引数を取り、ビルドの実行フェーズで同時に実行されるジョブの数の上限を指定します。

--progress_report_interval=n

Bazel は、まだ完了していないジョブ（長時間実行されるテストなど）の進捗レポートを定期的に出力します。このオプションはレポートの頻度を設定します。進捗状況は n 秒ごとに表示されます。

デフォルトは 0 です。これは増分アルゴリズムを意味します。最初のレポートは 10 秒後に、次のレポートは 30 秒後に、それ以降は 1 分ごとに進行状況が報告されます。

--curses で指定されているように、bazel がカーソル制御を使用している場合、進捗状況は 1 秒ごとに報告されます。

--local_{ram,cpu}_resources resources or resource expression

これらのオプションは、ローカルで実行するビルド アクティビティとテスト アクティビティのスケジュール設定時に Bazel が考慮できるローカル リソースの量（RAM の MB 数と CPU 論理コア数）を指定します。整数またはキーワード（HOST_RAM または HOST_CPUS）を取り、必要に応じて [-|*float] を続けます（例: --local_cpu_resources=2、--local_ram_resources=HOST_RAM*.5、--local_cpu_resources=HOST_CPUS-1）。フラグは独立しており、1 つまたは両方を設定できます。デフォルトでは、Bazel はローカル システムの構成から RAM の量と CPU コア数を直接見積もります。

このオプションはデフォルトで有効になっており、テストとバイナリのランファイル シンボリック リンクを出力ディレクトリにビルドするかどうかを指定します。--nobuild_runfile_links を使用すると、ランファイル ツリーのビルドのオーバーヘッドを発生させることなく、すべてのターゲットがコンパイルされるかどうかを検証できます。

テスト（またはアプリケーション）が実行されると、実行時のデータ依存関係が 1 か所に集められます。Bazel の出力ツリー内では、この「runfiles」ツリーは通常、対応するバイナリまたはテストの兄弟としてルート化されます。テスト実行中に、$TEST_SRCDIR/canonical_repo_name/packagename/filename 形式のパスを使用して runfile にアクセスできます。runfiles ツリーにより、テストは宣言された依存関係を持つすべてのファイルにアクセスでき、それ以外のファイルにはアクセスできないことが保証されます。デフォルトでは、必要なファイルへのシンボリック リンクのセットを構築することで、runfiles ツリーが実装されます。リンクのセットが増えるにつれて、このオペレーションのコストも増加します。大規模なビルドでは、特に個々のテスト（またはアプリケーション）に独自の runfiles ツリーが必要なため、ビルド全体の時間に大きく影響する可能性があります。

--[no]build_runfile_manifests

このオプションはデフォルトで有効になっており、runfiles マニフェストを出力ツリーに書き込むかどうかを指定します。無効にすると、--nobuild_runfile_links が適用されます。

テストをリモートで実行する場合は、runfiles ツリーがインメモリ マニフェストからリモートで作成されるため、無効にできます。

--[no]discard_analysis_cache

このオプションを有効にすると、Bazel は実行の直前に分析キャッシュを破棄するため、実行フェーズ用に約 10% の追加メモリが解放されます。欠点は、以降の増分ビルドが遅くなることです。メモリ節約モードもご覧ください。

--[no]keep_going (-k)

GNU Make と同様に、ビルドの実行フェーズは最初のエラーが発生した時点で停止します。エラーが発生しても、できるだけ多くをビルドしようとすることが役立つ場合があります。このオプションを有効にすると、この動作が有効になります。このオプションを指定すると、前提条件が正常にビルドされたすべてのターゲットのビルドが試行されますが、エラーは無視されます。

通常、このオプションはビルドの実行フェーズに関連付けられていますが、分析フェーズにも影響します。ビルドコマンドで複数のターゲットが指定されているが、その一部しか正常に分析できない場合、--keep_going が指定されていないと、ビルドはエラーで停止します。--keep_going が指定されている場合は、ビルドは実行フェーズに進みますが、正常に分析されたターゲットに対してのみ実行されます。

--[no]use_ijars

このオプションは、Bazel による java_library ターゲットのコンパイル方法を変更します。Bazel は、依存する java_library ターゲットをコンパイルするために java_library の出力を使用する代わりに、非プライベート メンバー（public、protected、default（package）アクセス メソッドとフィールド）のシグネチャのみを含むインターフェース jar を作成し、インターフェース jar を使用して依存するターゲットをコンパイルします。これにより、メソッド本体またはクラスのプライベート メンバーのみが変更された場合に、再コンパイルを回避できます。

--[no]interface_shared_objects

このオプションを有効にすると、インターフェース共有オブジェクトが有効になり、バイナリやその他の共有ライブラリが、共有オブジェクトの実装ではなく、そのインターフェースに依存するようになります。実装のみが変更された場合、Bazel は変更された共有ライブラリに依存するターゲットの不要な再ビルドを回避できます。

出力の選択

これらのオプションは、ビルドまたはテストする対象を決定します。

--[no]build

このオプションを指定すると、ビルドの実行フェーズが実行されます。デフォルトでオンになっています。オフにすると、実行フェーズはスキップされ、最初の 2 つのフェーズ（読み込みと分析）のみが行われます。

このオプションは、実際にビルドを行わずに、BUILD ファイルを検証し、入力のエラーを検出する場合に便利です。

--[no]build_tests_only

指定した場合、Bazel は、サイズ、タイムアウト、タグ、または言語によってフィルタされなかった *_test ルールと test_suite ルールを実行するために必要なものだけをビルドします。指定した場合、Bazel はコマンドラインで指定された他のターゲットを無視します。デフォルトでは、このオプションは無効になっており、Bazel はテストから除外された *_test ルールや test_suite ルールなど、リクエストされたすべてのものをビルドします。これは、bazel test --build_tests_only foo/... を実行しても foo ツリー内のすべてのビルドの破損が検出されない可能性があるため、有用です。

--[no]check_up_to_date

このオプションを指定すると、Bazel はビルドを実行せず、指定されたすべてのターゲットが最新かどうかを確認するだけになります。その場合、ビルドは通常どおり正常に完了します。ただし、ファイルが古い場合は、ビルドされずにエラーが報告され、ビルドが失敗します。このオプションは、ビルドのコストを発生させることなく、ビルドがソース編集よりも最近実行されたかどうかを判断する（送信前チェックなど）場合に便利です。

--check_tests_up_to_date もご覧ください。

--[no]compile_one_dependency

引数ファイルの単一の依存関係をコンパイルします。これは、IDE でソースファイルの構文をチェックする場合に便利です。たとえば、ソースファイルに依存する単一のターゲットを再ビルドして、編集/ビルド/テスト サイクルのできるだけ早い段階でエラーを検出します。この引数は、フラグ以外のすべての引数の解釈方法に影響します。各引数は、現在の作業ディレクトリを基準としたファイル ターゲット ラベルまたはプレーン ファイル名である必要があり、各ソース ファイル名に依存する 1 つのルールがビルドされます。C++ と Java のソースの場合、同じ言語空間のルールが優先的に選択されます。優先度が同じ複数のルールがある場合は、BUILD ファイルで最初に出現するルールが選択されます。ソースファイルを参照しない明示的に名前が付けられたターゲット パターンは、エラーになります。

--save_temps

--save_temps オプションを指定すると、コンパイラからの一時的な出力が保存されます。これには、.s ファイル（アセンブラ コード）、.i（プリプロセスされた C）、.ii（プリプロセスされた C++）ファイルが含まれます。これらの出力は、デバッグに役立つことがよくあります。一時ファイルは、コマンドラインで指定されたターゲットのセットに対してのみ生成されます。

--save_temps フラグは現在、cc_* ルールでのみ機能します。

Bazel が追加の出力ファイルの場所を出力するようにするには、--show_result n 設定が十分に高いことを確認します。

--build_tag_filters=tag[,tag]*

指定した場合、Bazel は、少なくとも 1 つの必須タグ（指定されている場合）を持ち、除外タグを持たないターゲットのみをビルドします。ビルドタグフィルタは、タグキーワードのカンマ区切りリストとして指定します。除外するタグを示す「-」記号を先頭に付けることもできます。必須タグには、先頭に「+」記号が付いている場合もあります。

テストを実行する場合、Bazel はテスト ターゲットの --build_tag_filters を無視します。テスト ターゲットは、このフィルタに一致しない場合でもビルドされて実行されます。ビルドを回避するには、--test_tag_filters を使用してテスト ターゲットをフィルタするか、明示的に除外します。

--test_size_filters=size[,size]*

指定した場合、Bazel は指定されたサイズのテスト ターゲットのみをテストします（--build_tests_only も指定されている場合はビルドします）。テストサイズ フィルタは、許可されるテストサイズの値（small、medium、large、enormous）のカンマ区切りリストとして指定します。除外するテストサイズを示す「-」記号を先頭に付けることもできます。次に例を示します。

  % bazel test --test_size_filters=small,medium //foo:all

と

  % bazel test --test_size_filters=-large,-enormous //foo:all

は、//foo 内の小規模テストと中規模テストのみをテストします。

デフォルトでは、テストサイズのフィルタリングは適用されません。

--test_timeout_filters=timeout[,timeout]*

指定した場合、Bazel は指定されたタイムアウトでテスト ターゲットのみをテストします（--build_tests_only も指定されている場合はビルドします）。テスト タイムアウト フィルタは、許可されるテスト タイムアウト値（short、moderate、long、eternal）のカンマ区切りリストとして指定されます。オプションで、除外されるテスト タイムアウトを示すために使用される「-」記号が前に付くことがあります。構文の例については、--test_size_filters をご覧ください。

デフォルトでは、テスト タイムアウト フィルタリングは適用されません。

--test_tag_filters=tag[,tag]*

指定した場合、Bazel は、少なくとも 1 つの必須タグ（指定されている場合）があり、除外タグがないテスト ターゲットのみをテストします（--build_tests_only も指定されている場合はビルドします）。テストタグフィルタは、タグキーワードのカンマ区切りリストとして指定します。除外タグを示す「-」記号を先頭に付けることもできます。必須タグには、先頭に「+」記号が付いている場合もあります。

次に例を示します。

  % bazel test --test_tag_filters=performance,stress,-flaky //myproject:all

performance または stress タグでタグ付けされているが、flaky タグでタグ付けされていないターゲットをテストします。

デフォルトでは、テストタグのフィルタリングは適用されません。この方法で、テストの size タグと local タグでフィルタすることもできます。

--test_lang_filters=string[,string]*

テストルールのクラス名を参照する文字列のカンマ区切りリストを指定します。ルールクラス foo_test を参照するには、文字列「foo」を使用します。Bazel は、参照されるルールクラスのターゲットのみをテストします（--build_tests_only も指定されている場合はビルドします）。代わりにこれらのターゲットを除外するには、文字列「-foo」を使用します。次に例を示します。

  % bazel test --test_lang_filters=foo,bar //baz/...

は、//baz/... の foo_test または bar_test のインスタンスであるターゲットのみをテストします。

  % bazel test --test_lang_filters=-foo,-bar //baz/...

foo_test インスタンスと bar_test インスタンスを除く、//baz/... 内のすべてのターゲットをテストします。

--test_filter=filter-expression

テストランナーが実行するテストのサブセットを選択するために使用できるフィルタを指定します。呼び出しで指定されたすべてのターゲットがビルドされますが、式によっては一部のみが実行されることがあります。場合によっては、特定のテストメソッドのみが実行されます。

filter-expression の具体的な解釈は、テストの実行を担当するテスト フレームワークに委ねられます。グロブ、サブストリング、正規表現のいずれかになります。--test_filter は、さまざまな --test_arg フィルタ引数を渡すよりも便利ですが、すべてのフレームワークがサポートしているわけではありません。

詳細度

これらのオプションは、ターミナルまたは追加のログファイルへの Bazel の出力の冗長性を制御します。

--explain=logfile

このオプションでは、ファイル名引数が必要になります。このオプションを指定すると、bazel build の実行フェーズの依存関係チェッカーが、各ビルドステップについて、実行される理由か、最新の状態であることを説明します。説明はログファイルに書き込まれます。

予期しない再構築が発生している場合は、このオプションを使用すると理由を把握できます。.bazelrc に追加して、以降のすべてのビルドでロギングが行われるようにします。実行ステップが予期せず実行された場合は、ログを調べます。このオプションにはパフォーマンスの低下が伴う可能性があるため、不要になったら削除することをおすすめします。

--verbose_explanations

このオプションを使用すると、--explain オプションが有効になっている場合に生成される説明の冗長性が高まります。

特に、詳細な説明が有効になっていて、ビルドに使用されたコマンドが変更されたために出力ファイルが再ビルドされた場合、説明ファイル内の出力には新しいコマンドの詳細がすべて含まれます（少なくともほとんどのコマンドで）。

このオプションを使用すると、生成される説明ファイルの長さと --explain の使用によるパフォーマンスの低下が大幅に増加する可能性があります。

--explain が有効になっていない場合、--verbose_explanations は効果がありません。

--profile=file

このオプションは、ファイル名引数を受け取り、Bazel がプロファイリング データをファイルに書き込むようにします。データは、bazel analyze-profile コマンドを使用して分析または解析できます。ビルド プロファイルは、Bazel の build コマンドがどこで時間を費やしているかを把握するのに役立ちます。

--[no]show_loading_progress

このオプションを指定すると、Bazel はパッケージ読み込みの進行状況メッセージを出力します。無効になっている場合、メッセージは表示されません。

--[no]show_progress

このオプションを選択すると、進行状況メッセージが表示されます。デフォルトではオンになっています。無効にすると、進行状況のメッセージは表示されません。

--show_progress_rate_limit=n

このオプションを指定すると、bazel は n 秒ごとに最大 1 つの進行状況メッセージを表示します。ここで、n は実数です。このオプションのデフォルト値は 0.02 です。つまり、bazel は進行状況メッセージを 0.02 秒ごとに 1 つに制限します。

--show_result=n

このオプションは、bazel build コマンドの最後に結果情報を出力するかどうかを制御します。デフォルトでは、単一のビルド ターゲットが指定されている場合、Bazel はターゲットが正常に最新の状態になったかどうかを示すメッセージを出力します。最新の状態になった場合は、ターゲットが作成した出力ファイルのリストも出力します。複数のターゲットが指定されている場合、結果情報は表示されません。

結果情報は、単一のターゲットまたは少数のターゲットのビルドには役立つ可能性がありますが、大規模なビルド（最上位のプロジェクト ツリー全体など）では、この情報が多すぎて混乱を招く可能性があります。このオプションを使用すると、この情報を制御できます。--show_result は、完全な結果情報を出力するターゲットの最大数を示す整数引数を取ります。デフォルトでは、値は 1 です。このしきい値を超えると、個々のターゲットの結果情報は表示されません。したがって、ゼロを指定すると結果情報が常に抑制され、非常に大きな値を指定すると結果が常に印刷されます。

ユーザーは、少数のターゲットのビルド（コンパイル、編集、テストのサイクルなど）と多数のターゲットのビルド（新しいワークスペースの確立や回帰テストの実行など）を定期的に切り替える場合は、中間の値を選択することをおすすめします。前者の場合は結果情報が非常に有用ですが、後者の場合はそれほど有用ではありません。他のすべてのオプションと同様に、このオプションは .bazelrc ファイルで暗黙的に指定できます。

ファイルは、ファイル名をシェルにコピーして貼り付け、ビルドされた実行可能ファイルを実行しやすいように印刷されます。各ターゲットの「最新」または「失敗」のメッセージは、ビルドを駆動するスクリプトで簡単に解析できます。

--sandbox_debug

このオプションを指定すると、アクション実行にサンドボックスを使用する際に、Bazel が追加のデバッグ情報を出力します。このオプションではサンドボックス ディレクトリも保持されるため、実行中にアクションに表示されるファイルを調べることができます。

--subcommands（-s）

このオプションを指定すると、Bazel の実行フェーズで、各コマンドの実行前に完全なコマンドラインが出力されます。

  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
    exec env - \
    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)

可能な限り、コマンドは Bourne シェル互換の構文で出力されるため、シェル コマンド プロンプトに簡単にコピーして貼り付けることができます。（周囲の括弧は、シェルを cd 呼び出しと exec 呼び出しから保護するために提供されています。必ずコピーしてください）。ただし、シンボリック リンク ツリーの作成など、一部のコマンドは Bazel 内で内部的に実装されています。これらについては、表示するコマンドラインはありません。

--subcommands=pretty_print を渡すと、コマンドの引数が 1 行ではなくリストとして出力されます。これにより、長いコマンドラインを読みやすくすることができます。

下記の --verbose_failures もご覧ください。

ツールに適した形式でサブコマンドをファイルにロギングする方法については、--execution_log_json_file と --execution_log_binary_file をご覧ください。

--verbose_failures

このオプションを指定すると、Bazel の実行フェーズで、失敗したコマンドの完全なコマンドラインが出力されます。これは、失敗したビルドのデバッグに非常に役立ちます。

失敗したコマンドは、Bourne シェル互換の構文で出力されます。これは、シェル プロンプトにコピーして貼り付けるのに適しています。

Workspace のステータス

これらのオプションは、Bazel でビルドされたバイナリに「スタンプ」を付けるために使用します。たとえば、ソース管理のリビジョンやワークスペース関連のその他の情報などの追加情報をバイナリに埋め込むことができます。このメカニズムは、genrule、cc_binary など、stamp 属性をサポートするルールで使用できます。

--workspace_status_command=program

このフラグを使用すると、各ビルドの前に Bazel が実行するバイナリを指定できます。プログラムは、現在のソース管理リビジョンなど、ワークスペースのステータスに関する情報をレポートできます。

フラグの値は、ネイティブ プログラムのパスにする必要があります。Linux/macOS では、任意の実行可能ファイルを使用できます。Windows では、これはネイティブ バイナリ（通常は「.exe」、「.bat」、「.cmd」ファイル）である必要があります。

プログラムは、ゼロ以上のキーと値のペアを標準出力に出力し、各行に 1 つのエントリを出力してから、ゼロで終了する必要があります（そうしないとビルドが失敗します）。キー名は任意ですが、大文字とアンダースコアのみを使用できます。キー名の後の最初のスペースは、キー名と値を区切ります。値は行の残りの部分（追加の空白を含む）です。キーと値のどちらも複数行にまたがることはできません。キーは重複してはなりません。

Bazel は、鍵を「安定」と「揮発性」の 2 つのバケットに分割します。（「stable」と「volatile」という名前は少し直感的ではないので、あまり深く考えないでください）。

Bazel は、Key-Value ペアを次の 2 つのファイルに書き込みます。

  • bazel-out/stable-status.txt キーの名前が STABLE_ で始まるすべてのキーと値が含まれています
  • bazel-out/volatile-status.txt 残りのキーとその値が含まれています

契約は次のとおりです。

  • 「stable」キーの値は、可能な限り変更しないようにしてください。bazel-out/stable-status.txt の内容が変更されると、Bazel はそれに依存するアクションを無効にします。つまり、安定したキーの値が変更されると、Bazel はスタンプ付きアクションを再実行します。そのため、安定したステータスにはタイムスタンプなどの常に変化するものは含めるべきではありません。これらが含まれていると、Bazel はビルドごとにスタンプ付きアクションを再実行することになります。

    Bazel は常に次の安定したキーを出力します。

    • BUILD_EMBED_LABEL: --embed_label の値
    • BUILD_HOST: Bazel が実行されているホストマシンの名前
    • BUILD_USER: Bazel が実行されているユーザーの名前

  • 「volatile」キーの値は頻繁に変更される可能性があります。Bazel は、タイムスタンプのように常に変更されることを想定しており、bazel-out/volatile-status.txt ファイルを適切に更新します。ただし、スタンプ付きアクションが常に再実行されるのを避けるため、Bazel は揮発性ファイルが変更されないと見なします。つまり、揮発性ステータス ファイルの内容のみが変更された場合、Bazel はそれに依存するアクションを無効にしません。アクションの他の入力が変更された場合、Bazel はそのアクションを再実行し、アクションは更新された揮発性ステータスを確認しますが、揮発性ステータスのみが変更されてもアクションは無効になりません。

    Bazel は常に次の揮発性キーを出力します。

    • BUILD_TIMESTAMP: ビルドの時刻（Unix エポックからの経過秒数）（System.currentTimeMillis() の値を 1,000 で割った値）
    • FORMATTED_DATE: ビルドの時刻。UTC で yyyy MMM d HH mm ss EEE 形式（例: 2023 年 6 月 2 日 01 時 44 分 29 秒 金曜日）でフォーマットされます。

Linux/macOS では、--workspace_status_command=/bin/true を渡してワークスペース ステータスの取得を無効にできます。これは、true が何も行わず、正常に（ゼロで終了）出力も行わないためです。Windows では、同じ効果を得るために MSYS の true.exe のパスを渡すことができます。

なんらかの理由でワークスペース ステータス コマンドが失敗した場合（ゼロ以外の終了）、ビルドは失敗します。

Git を使用する Linux のサンプル プログラム:

#!/bin/bash
echo "CURRENT_TIME $(date +%s)"
echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)"
echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)"
echo "STABLE_USER_NAME $USER"

このプログラムのパスを --workspace_status_command で渡すと、安定版ステータス ファイルには STABLE 行が含まれ、揮発性ステータス ファイルには残りの行が含まれます。

--[no]stamp

このオプションは、stamp ルール属性と組み合わせて、ビルド情報をバイナリに埋め込むかどうかを制御します。

スタンピングは、stamp 属性を使用して、ルールごとに明示的に有効または無効にできます。詳しくは、Build Encyclopedia を参照してください。ルールで stamp = -1（*_binary ルールのデフォルト）が設定されている場合、このオプションでスタンピングを有効にするかどうかを指定します。

Bazel は、このオプションや stamp 属性に関係なく、exec 構成用にビルドされたバイナリにスタンプを付けません。stamp = 0（*_test ルールのデフォルト）を設定するルールの場合、--[no]stamp に関係なくスタンピングは無効になります。--stamp を指定しても、依存関係が変更されていない場合、ターゲットの再ビルドは強制されません。

--nostamp を設定すると、入力の変動が減り、ビルド キャッシュが最大化されるため、一般的にビルド パフォーマンスが向上します。

プラットフォーム

これらのオプションを使用して、ビルドの動作を構成するホスト プラットフォームとターゲット プラットフォームを制御し、Bazel ルールで使用できる実行プラットフォームとツールチェーンを制御します。

プラットフォームとツールチェーンの背景情報をご覧ください。

--platforms=labels

現在のコマンドのターゲット プラットフォームを記述するプラットフォーム ルールのラベル。

--host_platform=label

ホストシステムを説明するプラットフォーム ルールのラベル。

--extra_execution_platforms=labels

アクションを実行するための実行プラットフォームとして使用できるプラットフォーム。プラットフォームは、正確なターゲットとして指定することも、ターゲット パターンとして指定することもできます。これらのプラットフォームは、register_execution_platforms() によって MODULE.bazel ファイルで宣言されたプラットフォームよりも前に考慮されます。このオプションでは、優先順位順にプラットフォームのカンマ区切りリストを指定します。フラグが複数回渡された場合は、最新のものが優先されます。

--extra_toolchains=labels

ツールチェーン解決時に考慮されるツールチェーン ルール。ツールチェーンは、正確なターゲットとして指定することも、ターゲット パターンとして指定することもできます。これらのツールチェーンは、register_toolchains() によって MODULE.bazel ファイルで宣言されたツールチェーンよりも前に考慮されます。

--toolchain_resolution_debug=regex

ツールチェーンのタイプが正規表現と一致する場合、ツールチェーンの検索中にデバッグ情報を出力します。複数の正規表現を指定する場合は、カンマで区切ります。正規表現の先頭に - を使用すると、正規表現を否定できます。これは、ツールチェーンの欠落によるデバッグの失敗を解決するうえで、Bazel または Starlark ルールのデベロッパーに役立つ可能性があります。

その他

--flag_alias=alias_name=target_path

長い Starlark ビルド設定を短い名前にバインドするために使用される便利なフラグ。詳細については、Starlark 構成をご覧ください。

生成される便利なシンボリック リンクの接頭辞を変更します。シンボリック リンクの接頭辞のデフォルト値は bazel- です。これにより、シンボリック リンク bazel-bin、bazel-testlogs、bazel-genfiles が作成されます。

なんらかの理由でシンボリック リンクを作成できない場合は、警告が発行されますが、ビルドは成功と見なされます。特に、読み取り専用ディレクトリや書き込み権限のないディレクトリにビルドできます。ビルドの終了時に情報メッセージで出力されるパスは、シンボリック リンクが想定される場所を指している場合にのみ、シンボリック リンク相対の短縮形を使用します。つまり、シンボリック リンクの作成を信頼できない場合でも、これらのパスの正確性を信頼できます。

このオプションの一般的な値は次のとおりです。

  • シンボリック リンクの作成を抑制する: --symlink_prefix=/ を指定すると、Bazel は bazel-out や bazel-<workspace> などのシンボリック リンクを作成または更新しません。このオプションを使用すると、シンボリック リンクの作成を完全に抑制できます。

  • クラッターを減らす: --symlink_prefix=.bazel/ を指定すると、Bazel は非表示ディレクトリ .bazel 内に bin などのシンボリック リンクを作成します。

--platform_suffix=string

構成の短い名前に接尾辞を追加します。これは、出力ディレクトリを決定するために使用されます。このオプションに異なる値を設定すると、ファイルが異なるディレクトリに配置されます。たとえば、出力ファイルが互いに上書きされるビルドのキャッシュ ヒット率を改善したり、比較用に出力ファイルを保持したりできます。

--default_visibility=(private|public)

bazel のデフォルトの公開設定の変更をテストするための一時的なフラグ。一般的な利用は意図していませんが、完全性を期すためにドキュメント化されています。

--starlark_cpu_profile=_file_

このフラグ（値はファイルの名前）を指定すると、Bazel はすべての Starlark スレッドの CPU 使用率に関する統計情報を収集し、指定されたファイルに pprof 形式でプロファイルを書き込みます。

このオプションを使用すると、過剰な計算により読み込みと分析が遅くなる Starlark 関数を特定できます。次に例を示します。

$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/...
$ pprof /tmp/pprof.gz
(pprof) top
Type: CPU
Time: Feb 6, 2020 at 12:06pm (PST)
Duration: 5.26s, Total samples = 3.34s (63.55%)
Showing nodes accounting for 3.34s, 100% of 3.34s total
      flat  flat%   sum%        cum   cum%
     1.86s 55.69% 55.69%      1.86s 55.69%  sort_source_files
     1.02s 30.54% 86.23%      1.02s 30.54%  expand_all_combinations
     0.44s 13.17% 99.40%      0.44s 13.17%  range
     0.02s   0.6%   100%      3.34s   100%  sorted
         0     0%   100%      1.38s 41.32%  my/project/main/BUILD
         0     0%   100%      1.96s 58.68%  my/project/library.bzl
         0     0%   100%      3.34s   100%  main

同じデータの異なるビューについては、pprof コマンド svg、web、list を試してください。

リリースに Bazel を使用する

Bazel は、開発サイクルのソフトウェア エンジニアと、本番環境へのデプロイ用のバイナリを準備するリリース エンジニアの両方で使用されます。このセクションでは、Bazel を使用するリリース エンジニア向けのヒントの一覧を示します。

重要なオプション

リリースビルドに Bazel を使用する場合、ビルドを実行する他のスクリプトと同様の問題が発生します。詳しくは、スクリプトから Bazel を呼び出すをご覧ください。特に、次のオプションを強くおすすめします。

次のオプションも重要です。

  • --package_path
  • --symlink_prefix: 複数の構成のビルドを管理する場合、各ビルドを「64bit」と「32bit」などの異なる識別子で区別すると便利です。このオプションは、bazel-bin などのシンボリック リンクを区別します。

テストの実行

bazel でテストをビルドして実行するには、bazel test に続けてテスト ターゲットの名前を入力します。

デフォルトでは、このコマンドはビルドとテストのアクティビティを同時に実行し、指定されたすべてのターゲット（コマンドラインで指定されたテスト以外のターゲットを含む）をビルドし、前提条件がビルドされるとすぐに *_test ターゲットと test_suite ターゲットをテストします。つまり、テストの実行はビルドと交互に行われます。通常、これにより大幅な速度向上が得られます。

「bazel test」のオプション

--cache_test_results=(yes|no|auto)（-t）

このオプションが「auto」（デフォルト）に設定されている場合、Bazel は次のいずれかの条件が適用される場合にのみテストを再実行します。

  • Bazel はテストまたはその依存関係の変更を検出します
  • テストは external とマークされます。
  • --runs_per_test で複数のテスト実行がリクエストされた
  • テストが失敗しました。

「no」の場合、すべてのテストが無条件で実行されます。

「yes」の場合、キャッシュ保存の動作は auto と同じになりますが、--runs_per_test を使用したテストの失敗とテスト実行がキャッシュに保存される可能性があります。

.bazelrc ファイルでこのオプションをデフォルトで有効にしているユーザーは、特定の実行でデフォルトをオーバーライドする際に、-t（オン）または -t-（オフ）の省略形が便利です。

--check_tests_up_to_date

このオプションは、テストを実行せずに、キャッシュに保存されたテスト結果をチェックしてレポートするよう Bazel に指示します。以前にビルドして実行されていないテストや、テスト結果が古いテスト（ソースコードやビルド オプションが変更されたなど）がある場合、Bazel はエラー メッセージ（「test result is not up-to-date」）を報告し、テストのステータスを「NO STATUS」（カラー出力が有効な場合は赤色）として記録し、ゼロ以外の終了コードを返します。

このオプションは、--check_up_to_date の動作も暗黙的に示します。

このオプションは送信前のチェックに役立ちます。

--test_verbose_timeout_warnings

このオプションは、テストのタイムアウトがテストの実際の実行時間よりも大幅に長い場合に、ユーザーに明示的に警告するよう Bazel に指示します。テストのタイムアウトは、不安定にならないように設定する必要がありますが、タイムアウトが過度に長くなると、予期せず発生する実際の問題が隠れてしまう可能性があります。

たとえば、通常 1 ～ 2 分で実行されるテストのタイムアウトを ETERNAL や LONG に設定するのは、あまりにも長すぎます。

このオプションは、ユーザーが適切なタイムアウト値を決定したり、既存のタイムアウト値をサニティチェックしたりするのに役立ちます。

--[no]test_keep_going

デフォルトでは、すべてのテストが完了まで実行されます。ただし、このフラグが無効になっている場合、合格しないテストがあるとビルドは中止されます。後続のビルドステップとテスト呼び出しは実行されず、処理中の呼び出しはキャンセルされます。--notest_keep_going と --keep_going の両方を指定しないでください。

--flaky_test_attempts=attempts

このオプションは、なんらかの理由でテストが失敗した場合に、テストを再試行する最大回数を指定します。最初は失敗したが最終的に成功したテストは、テストの概要で FLAKY として報告されます。ただし、Bazel の終了コードや合格したテストの合計数を特定する際には、合格と見なされます。許可された試行をすべて失敗したテストは、失敗と見なされます。

デフォルトでは（このオプションが指定されていない場合、またはデフォルトに設定されている場合）、通常のテストでは 1 回の試行のみが許可され、flaky 属性が設定されたテストルールでは 3 回の試行が許可されます。整数値を指定して、テスト試行回数の上限をオーバーライドできます。Bazel では、システムの不正使用を防ぐため、テストの試行回数は最大 10 回に制限されています。

--runs_per_test=[regex@]number

このオプションは、各テストを実行する回数を指定します。すべてのテスト実行は個別のテストとして扱われます（フォールバック機能はそれぞれに個別に適用されます）。

実行に失敗したターゲットのステータスは、--runs_per_test_detects_flakes フラグの値によって異なります。

  • 指定しない場合、失敗した実行があると、テスト全体が失敗します。
  • 同じシャードの 2 つの実行が PASS と FAIL を返した場合、テストは不安定なステータスを受け取ります（他の失敗した実行が原因で失敗しない限り）。

単一の数値を指定すると、すべてのテストがその回数だけ実行されます。また、正規表現は regex@number 構文を使用して指定することもできます。これにより、--runs_per_test の効果が正規表現に一致するターゲットに制限されます（--runs_per_test=^//pizza:.*@4 は //pizza/ の下にあるすべてのテストを 4 回実行します）。この形式の --runs_per_test は複数回指定できます。

--[no]runs_per_test_detects_flakes

このオプションが指定されている場合（デフォルトでは指定されていません）、Bazel は --runs_per_test を介して不安定なテストシャードを検出します。単一のシャードで 1 つ以上の実行が失敗し、同じシャードで 1 つ以上の実行が成功した場合、ターゲットはフラグ付きで不安定と見なされます。指定しない場合、ターゲットは失敗ステータスを報告します。

--test_summary=output_style

テスト結果の概要の表示方法を指定します。

  • short は、テストが失敗した場合、各テストの結果とテスト出力を含むファイルの名前を出力します。これがデフォルト値です。
  • terse は short と同様ですが、さらに短く、合格しなかったテストに関する情報のみを出力します。
  • detailed は、各テストだけでなく、失敗した個々のテストケースも出力します。テスト出力ファイルの名前は省略されています。
  • none はテストの概要を出力しません。

--test_output=output_style

テスト出力の表示方法を指定します。

  • summary には、各テストの合格または不合格の概要が表示されます。また、失敗したテストの出力ログファイル名も表示します。概要はビルドの最後に表示されます（ビルド中には、テストの開始、合格、不合格に関する簡単な進行状況メッセージのみが表示されます）。これはデフォルトの動作です。
  • errors は、失敗したテストの stdout/stderr の出力をテスト完了直後に stdout にのみ送信し、同時テストのテスト出力が相互にインターリーブされないようにします。上記のサマリー出力に従って、ビルド時にサマリーを出力します。
  • all は errors と似ていますが、合格したテストを含むすべてのテストの出力を出力します。
  • streamed は、各テストの stdout/stderr 出力をリアルタイムでストリーミングします。

--java_debug

このオプションを指定すると、Java テストの Java 仮想マシンは、テストを開始する前に JDWP 準拠のデバッガからの接続を待機します。このオプションは --test_output=streamed を意味します。

--[no]verbose_test_summary

デフォルトではこのオプションは有効になっており、テスト時間やその他の追加情報（テストの試行回数など）がテストの概要に出力されます。--noverbose_test_summary が指定されている場合、テストの概要にはテスト名、テストのステータス、キャッシュに保存されたテストのインジケーターのみが含まれ、可能な場合は 80 文字以内に収まるようにフォーマットされます。

--test_tmpdir=path

ローカルで実行されるテストの一時ディレクトリを指定します。各テストは、このディレクトリ内の個別のサブディレクトリで実行されます。ディレクトリは、各 bazel test コマンドの開始時にクリーンアップされます。デフォルトでは、bazel はこのディレクトリを Bazel 出力ベース ディレクトリの下に配置します。

--test_timeout=seconds または --test_timeout=seconds,seconds,seconds,seconds

指定された秒数を新しいタイムアウト値として使用して、すべてのテストのタイムアウト値をオーバーライドします。値が 1 つだけ指定されている場合は、すべてのテスト タイムアウト カテゴリに使用されます。

または、4 つのカンマ区切りの値を指定して、短時間、中時間、長時間、永続テストの個々のタイムアウトを指定することもできます（この順序で指定します）。どちらの形式でも、テストサイズのいずれかがゼロまたは負の値の場合、ページ「テストの作成」で定義されているように、指定されたタイムアウト カテゴリのデフォルトのタイムアウトに置き換えられます。デフォルトでは、Bazel はこれらのタイムアウトをすべてのテストで使用します。タイムアウトの上限は、テストのサイズから推測されます。サイズは暗黙的または明示的に設定されます。

タイムアウト カテゴリがサイズとは異なるものとして明示的に指定されているテストでは、サイズタグによってタイムアウトが暗黙的に設定された場合と同じ値が返されます。したがって、タイムアウトを「long」と宣言する「small」サイズのテストは、明示的なタイムアウトのない「large」サイズのテストと同じ有効タイムアウトになります。

--test_arg=arg

コマンドライン オプション/フラグ/引数を各テストプロセスに渡します。このオプションは、複数の引数を渡すために複数回使用できます。例: --test_arg=--logtostderr --test_arg=--v=3

bazel run コマンドとは異なり、bazel test -- target --logtostderr --v=3 のようにテスト引数を直接渡すことはできません。これは、bazel test に渡された余分な引数が追加のテスト ターゲットとして解釈されるためです。つまり、--logtostderr と --v=3 はそれぞれテスト ターゲットとして解釈されます。bazel run コマンドはターゲットを 1 つしか受け入れないため、このような曖昧さはありません。

--test_arg は bazel run コマンドに渡すことができますが、実行されるターゲットがテスト ターゲットでない限り無視されます。（他のフラグと同様に、-- トークンの後に bazel run コマンドで渡された場合、Bazel によって処理されず、実行されたターゲットにそのまま転送されます）。

--test_env=variable=_value_ または --test_env=variable

各テストのテスト環境に挿入する必要がある追加の変数を指定します。value が指定されていない場合は、bazel test コマンドの開始に使用されたシェル環境から継承されます。

環境には、テスト内から System.getenv("var")（Java）、getenv("var")（C または C++）を使用してアクセスできます。

--run_under=command-prefix

これは、テストランナーがテストコマンドの前に挿入して実行する接頭辞を指定します。command-prefix は Bourne シェルのトークン化ルールを使用して単語に分割され、単語のリストが実行されるコマンドの先頭に追加されます。

最初の単語が完全修飾ラベル（// で始まる）の場合、ビルドされます。ラベルは、他の単語とともに実行されるコマンドの先頭に付加される、対応する実行可能ファイルの場所に置き換えられます。

次のような点にご注意ください。

  • テストの実行に使用される PATH は環境内の PATH と異なる場合があるため、--run_under コマンド（command-prefix の最初の単語）に絶対パスを使用する必要がある場合があります。
  • stdin が接続されていないため、--run_under をインタラクティブ コマンドに使用できません。

例:

        --run_under=/usr/bin/strace
        --run_under='/usr/bin/strace -c'
        --run_under=/usr/bin/valgrind
        --run_under='/usr/bin/valgrind --quiet --num-callers=20'

テストの選択

出力選択オプションに記載されているように、サイズ、タイムアウト、タグ、言語でテストをフィルタできます。便利な一般的な名前フィルタを使用すると、特定のフィルタ引数をテストランナーに転送できます。

「bazel test」に関するその他のオプション

構文と残りのオプションは bazel build とまったく同じです。

実行可能ファイルの実行

bazel run コマンドは bazel build に似ていますが、単一のターゲットのビルドと実行に使用されます。一般的なセッションは次のとおりです（//java/myapp:myapp が挨拶して引数を出力します）。

  % bazel run java/myapp:myapp -- --arg1 --arg2
  INFO: Analyzed target //java/myapp:myapp (13 packages loaded, 27 targets configured).
  INFO: Found 1 target...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp/myapp
  INFO: Elapsed time: 14.290s, Critical Path: 5.54s, ...
  INFO: Build completed successfully, 4 total actions
  INFO: Running command line: bazel-bin/java/myapp/myapp <args omitted>
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

bazel run は Bazel によってビルドされたバイナリを直接呼び出すのと似ていますが、呼び出すバイナリがテストかどうかによって動作が異なります。

バイナリがテストでない場合、現在の作業ディレクトリはバイナリの runfiles ツリーになります。

バイナリがテストの場合、現在の作業ディレクトリは実行ルートになり、テストが通常実行される環境を再現しようとします。ただし、エミュレーションは完璧ではなく、複数のシャードがあるテストはこの方法で実行できません（--test_sharding_strategy=disabled コマンドライン オプションを使用して回避できます）。

バイナリでは、次の追加の環境変数も使用できます。

  • BUILD_WORKSPACE_DIRECTORY: ビルドが実行されたワークスペースのルート。
  • BUILD_WORKING_DIRECTORY: Bazel が実行された現在の作業ディレクトリ。
  • BUILD_ID: bazel run 呼び出しのビルド ID。通常は一意ですが、Bazel が --script_path で実行され、結果のスクリプトが再利用される場合は除きます。
  • BUILD_EXECROOT: bazel run 呼び出しの実行ルート。

これらは、たとえば、コマンドラインでファイル名をユーザーフレンドリーな方法で解釈するために使用できます。

「bazel run」のオプション

--run_under=command-prefix

これは、bazel test の --run_under オプション（上記を参照）と同じ効果がありますが、bazel test によって実行されるテストではなく、bazel run によって実行されるコマンドに適用され、ラベルの下で実行できない点が異なります。

Bazel からのロギング出力をフィルタする

bazel run でバイナリを呼び出すと、Bazel は Bazel 自体と呼び出し中のバイナリのロギング出力を出力します。ログのノイズを減らすには、--ui_event_filters フラグと --noshow_progress フラグを使用して、Bazel 自体の出力を抑制します。

次に例を示します。bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

テストの実行

bazel run はテスト バイナリを実行することもできます。これにより、テストの作成で説明されている環境に非常に近い環境でテストを実行できます。この方法でテストを実行する場合、--test_arg 以外の --test_* 引数はすべて無効になります。

ビルド出力のクリーンアップ

clean コマンド

Bazel には、Make のコマンドと同様の clean コマンドがあります。この Bazel インスタンスによって実行されたすべてのビルド構成の出力ディレクトリ、またはこの Bazel インスタンスによって作成された作業ツリー全体を削除し、内部キャッシュをリセットします。コマンドライン オプションを指定せずに実行すると、すべての構成の出力ディレクトリがクリーンアップされます。

各 Bazel インスタンスは単一のワークスペースに関連付けられているため、clean コマンドは、そのワークスペースでその Bazel インスタンスを使用して行ったすべてのビルドの出力をすべて削除します。

Bazel インスタンスによって作成された作業ツリー全体を完全に削除するには、--expunge オプションを指定します。--expunge で実行すると、clean コマンドは出力ベースツリー全体を削除します。このツリーには、ビルド出力に加えて、Bazel によって作成されたすべての一時ファイルが含まれています。また、クリーンアップ後に Bazel サーバーを停止します。これは shutdown コマンドと同等です。たとえば、Bazel インスタンスのディスクとメモリのトレースをすべてクリーンアップするには、次のように指定します。

  % bazel clean --expunge

または、--expunge_async を使用してバックグラウンドで削除することもできます。非同期削除が実行されている間、同じクライアントで Bazel コマンドを呼び出しても安全です。

clean コマンドは、主に不要になったワークスペースのディスク容量を再利用する手段として提供されています。Bazel の増分再ビルドは完全ではない可能性があるため、問題が発生した場合は clean を使用して一貫性のある状態を復元できます。

Bazel は、これらの問題を修正できるように設計されており、これらのバグは優先度の高い修正対象です。間違った増分ビルドを見つけた場合は、clean を使用するのではなく、バグレポートを提出し、ツールでバグを報告してください。

依存関係グラフのクエリ

Bazel には、ビルド中に使用される依存関係グラフに関する質問を行うためのクエリ言語が含まれています。クエリ言語は、query と cquery の 2 つのコマンドで使用されます。2 つのコマンドの主な違いは、query は読み込みフェーズの後に実行され、cquery は分析フェーズの後に実行されることです。これらのツールは、多くのソフトウェア エンジニアリング タスクに不可欠なツールです。

クエリ言語はグラフに対する代数演算の概念に基づいています。詳細については、

Bazel クエリ リファレンスをご覧ください。リファレンス、例、クエリ固有のコマンドライン オプションについては、そのドキュメントをご覧ください。

クエリツールは、いくつかのコマンドライン オプションを受け入れます。--output は出力形式を選択します。--[no]keep_going（デフォルトで無効）に設定すると、エラーが発生してもクエリツールは処理を続行します。エラーが発生した場合に結果が不完全になることが許容できない場合は、この動作を無効にできます。

デフォルトで有効になっている --[no]tool_deps オプションを使用すると、ターゲット以外の構成の依存関係が、クエリが動作する依存関係グラフに含まれます。

デフォルトで有効になっている --[no]implicit_deps オプションを使用すると、クエリが実行される依存関係グラフに暗黙的な依存関係が含まれます。暗黙的な依存関係とは、BUILD ファイルで明示的に指定されていないが、bazel によって追加される依存関係のことです。

例: 「PEBL ツリー内のすべてのテストをビルドするために必要なすべての genrule の定義の場所（BUILD ファイル内）を表示します。」

  bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'

アクション グラフのクエリ

aquery コマンドを使用すると、ビルドグラフ内のアクションをクエリできます。構成された分析後のターゲット グラフで動作し、アクション、アーティファクト、それらの関係に関する情報を公開します。

このツールは、いくつかのコマンドライン オプションを受け入れます。--output は出力形式を選択します。デフォルトの出力形式（text）は人が読める形式です。マシンが読める形式には proto または textproto を使用します。特に、aquery コマンドは通常の Bazel ビルドの上に実行され、ビルド中に使用可能なオプションのセットを継承します。

従来の query で使用可能な関数と同じセットをサポートしますが、siblings、buildfiles、tests もサポートします。

詳しくは、アクション グラフクエリをご覧ください。

その他のコマンドとオプション

help

help コマンドはオンライン ヘルプを提供します。デフォルトでは、Bazel を使用したビルドで示されているように、利用可能なコマンドとヘルプトピックの概要が表示されます。引数を指定すると、特定のトピックに関する詳細なヘルプが表示されます。ほとんどのトピックは Bazel コマンド（build や query など）ですが、コマンドに対応しない追加のヘルプ トピックもあります。

--[no]long（-l）

デフォルトでは、bazel help [topic] はトピックに関連するオプションの概要のみを出力します。--long オプションを指定すると、各オプションの型、デフォルト値、詳細な説明も出力されます。

shutdown

Bazel サーバー プロセスは、shutdown コマンドを使用して停止できます。このコマンドにより、Bazel サーバーはアイドル状態になるとすぐに終了します（たとえば、現在進行中のビルドやその他のコマンドが完了した後など）。詳しくは、クライアント/サーバーの実装をご覧ください。

Bazel サーバーはアイドル タイムアウト後に自動的に停止するため、このコマンドはほとんど必要ありません。ただし、特定のワークスペースでこれ以上のビルドが発生しないことがわかっている場合は、スクリプトでこのコマンドを使用すると便利です。

shutdown は 1 つのオプション --iff_heap_size_greater_than _n_ を受け入れます。これには整数引数（MB 単位）が必要です。指定すると、シャットダウンはすでに使用されているメモリの量に応じて条件付きになります。これは、多くのビルドを開始するスクリプトに役立ちます。Bazel サーバーのメモリリークにより、サーバーが断続的にクラッシュする可能性があるためです。条件付き再起動を実行すると、この状態を回避できます。

info

info コマンドは、Bazel サーバー インスタンスまたは特定のビルド構成に関連付けられたさまざまな値を出力します。（これらは、ビルドを駆動するスクリプトで使用されることがあります）。

info コマンドでは、単一の（省略可能な）引数も使用できます。これは、次のリストにあるキーのいずれかの名前です。この場合、bazel info key はその 1 つのキーの値のみを出力します。（これは、Bazel のスクリプトを作成する際に特に便利です。sed -ne /key:/s/key://p を介して結果をパイプする必要がなくなります）。

構成に依存しないデータ

  • release: この Bazel インスタンスのリリースラベル。リリースされたバイナリでない場合は「開発バージョン」。
  • workspace: ベース ワークスペース ディレクトリの絶対パス。

  • install_base: 現在のユーザーのこの Bazel インスタンスで使用されるインストール ディレクトリへの絶対パス。Bazel は、内部的に必要な実行可能ファイルをこのディレクトリの下にインストールします。

  • output_base: 現在のユーザーとワークスペースの組み合わせに対して、この Bazel インスタンスで使用されるベース出力ディレクトリの絶対パス。Bazel は、スクラッチとビルドの出力をすべてこのディレクトリの下に配置します。

  • execution_root: output_base の下の実行ルート ディレクトリへの絶対パス。このディレクトリは、ビルド中に実行されるコマンドからアクセス可能なすべてのファイルのルートであり、これらのコマンドの作業ディレクトリです。ワークスペース ディレクトリが書き込み可能である場合、このディレクトリを指す bazel-<workspace> という名前のシンボリック リンクが配置されます。

  • output_path: ビルドコマンドの結果として実際に生成されたすべてのファイルに使用される実行ルートの下の出力ディレクトリの絶対パス。ワークスペース ディレクトリが書き込み可能である場合、bazel-out という名前のシンボリック リンクがこのディレクトリを指すように配置されます。

  • server_pid: Bazel サーバー プロセスのプロセス ID。

  • server_log: Bazel サーバーのデバッグ ログファイルへの絶対パス。このファイルには、Bazel サーバーの存続期間中のすべてのコマンドのデバッグ情報が含まれています。Bazel デベロッパーとパワーユーザーが使用することを想定しています。

  • command_log: コマンド ログファイルへの絶対パス。これには、最新の Bazel コマンドの stdout ストリームと stderr ストリームがインターリーブされています。bazel info を実行すると、このファイルの内容が上書きされます。これは、このファイルが最新の Bazel コマンドになるためです。ただし、--output_base オプションまたは --output_user_root オプションの設定を変更しない限り、コマンド ログファイルの場所は変更されません。

  • used-heap-size、committed-heap-size、max-heap-size: さまざまな JVM ヒープサイズのパラメータをレポートします。それぞれ、現在使用されているメモリ、システムから JVM で使用できることが保証されているメモリ、割り当て可能な最大メモリです。

  • gc-count、gc-time: この Bazel サーバーの起動以降のガベージ コレクションの累積数と、それらの実行に費やされた時間。これらの値は、ビルドの開始時にリセットされません。

  • package_path: bazel がパッケージを検索するパスのコロン区切りリスト。--package_path ビルド コマンドライン引数と同じ形式です。

例: Bazel サーバーのプロセス ID。

% bazel info server_pid
1285

構成固有のデータ

これらのデータは、bazel info に渡される構成オプション（--cpu、--compilation_mode など）の影響を受ける可能性があります。info コマンドは、依存関係分析を制御するすべてのオプションを受け入れます。これらのオプションの一部は、ビルドの出力ディレクトリの場所、コンパイラの選択などを決定するためです。

  • bazel-bin、bazel-testlogs、bazel-genfiles: ビルドで生成されたプログラムが配置されている bazel-* ディレクトリの絶対パスをレポートします。これは通常、ビルドが成功した後にベース ワークスペース ディレクトリに作成される bazel-* シンボリック リンクと同じですが、必ずしもそうとは限りません。ただし、ワークスペース ディレクトリが読み取り専用の場合、bazel-* シンボリック リンクは作成できません。シンボリック リンクの存在を前提とするのではなく、bazel info によって報告された値を使用するスクリプトは、より堅牢になります。
  • 完全な 「Make」環境。--show_make_env フラグが指定されている場合は、現在の構成の「Make」環境内のすべての変数（CC、GLIBC_VERSION など）も表示されます。これらは、BUILD ファイル内で $(CC) 構文または varref("CC") 構文を使用してアクセスされる変数です。

例: 現在の構成の C++ コンパイラ。これは「Make」環境の $(CC) 変数なので、--show_make_env フラグが必要です。

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

例: 現在の構成の bazel-bin 出力ディレクトリ。これは、何らかの理由で bazel-bin シンボリック リンクを作成できない場合（読み取り専用ディレクトリからビルドする場合など）でも、正しいことが保証されます。

% bazel info --cpu=piii bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin
% bazel info --cpu=k8 bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin

version、--version

version コマンドは、ビルドされた Bazel バイナリのバージョン詳細（ビルドされたチェンジリストと日付など）を出力します。これらは、最新の Bazel を使用しているかどうかを判断したり、バグを報告したりする場合に特に役立ちます。興味深い値は次のとおりです。

  • changelist: このバージョンの Bazel がリリースされたチェンジリスト。
  • label: この Bazel インスタンスのリリースラベル。リリースされたバイナリでない場合は「開発バージョン」。バグを報告する際に非常に役立ちます。

bazel --version（引数なし）は、bazel version --gnu_format と同じ出力を生成しますが、Bazel サーバーの起動やサーバー アーカイブの解凍といった副作用はありません。bazel --version はどこからでも実行できます。ワークスペース ディレクトリは必要ありません。

mobile-install

mobile-install コマンドは、モバイル デバイスにアプリをインストールします。現在、ART を実行している Android デバイスのみがサポートされています。

詳細については、bazel mobile-install をご覧ください。

次のオプションがサポートされています。

--incremental

設定されている場合、Bazel はアプリを増分インストールしようとします。つまり、前回のビルドから変更された部分のみをインストールします。AndroidManifest.xml、ネイティブ コード、Java リソース（Class.getResource() で参照されるものなど）から参照されるリソースは更新できません。これらが変更された場合は、このオプションを省略する必要があります。Bazel の精神とは異なり、Android プラットフォームの制限により、このコマンドで十分な場合と、完全なインストールが必要な場合を判断するのはユーザーの責任となります。

Marshmallow 以降のデバイスを使用している場合は、--split_apks フラグの使用をご検討ください。

--split_apks

分割 APK を使用してデバイスにアプリをインストールし、更新するかどうか。 Marshmallow 以降を搭載したデバイスでのみ動作します。--split_apks を使用する場合は、--incremental フラグは必要ありません。

--start_app

インストール後にアプリをクリーンな状態で起動します。--start=COLD と同じです。

--debug_app

インストール後にクリーンな状態でアプリを起動する前に、デバッガがアタッチされるまで待機します。--start=DEBUG と同じです。

--start=_start_type_

アプリのインストール後にアプリを起動する方法。サポートされている _start_type_s は次のとおりです。

  • NO アプリを起動しません。これがデフォルトです。
  • COLD インストール後にクリーンな状態からアプリを起動します。
  • WARM 増分インストールでアプリの状態を保持して復元します。
  • DEBUG インストール後にアプリをクリーンな状態で起動する前に、デバッガを待機します。

--adb=path

使用する adb バイナリを示します。

デフォルトでは、--android_sdk で指定された Android SDK の adb が使用されます。

--adb_arg=serial

adb への追加引数。これらはコマンドラインのサブコマンドの前に記述され、通常はインストール先のデバイスを指定するために使用されます。たとえば、使用する Android デバイスまたはエミュレータを選択するには:

% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef

adb を呼び出します

adb -s deadbeef install ...

--incremental_install_verbosity=number

増分インストールの詳細度。デバッグログをコンソールに出力する場合は 1 に設定します。

dump

dump コマンドは、Bazel サーバーの内部状態のダンプを stdout に出力します。このコマンドは主に Bazel デベロッパーが使用することを想定しているため、このコマンドの出力は指定されておらず、変更される可能性があります。

デフォルトでは、コマンドは Bazel 状態の特定の領域をダンプするためのオプションを説明するヘルプ メッセージを出力します。内部状態をダンプするには、少なくとも 1 つのオプションを指定する必要があります。

次のオプションがサポートされています。

  • --action_cache はアクション キャッシュの内容をダンプします。
  • --packages はパッケージ キャッシュの内容をダンプします。
  • --skyframe は、内部 Bazel 依存関係グラフの状態をダンプします。
  • --rules は、各ルールとアスペクト クラスのルール概要（カウントとアクション カウントを含む）をダンプします。これには、ネイティブ ルールと Starlark ルールの両方が含まれます。メモリ トラッキングが有効になっている場合は、ルールのメモリ使用量も出力されます。
  • --skylark_memory は、pprof 互換の .gz ファイルを指定されたパスにダンプします。この機能を有効にするには、メモリ トラッキングを有効にする必要があります。

メモリのトラッキング

一部の dump コマンドでは、メモリ トラッキングが必要です。これを有効にするには、起動フラグを Bazel に渡す必要があります。

  • --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar
  • --host_jvm_args=-DRULE_MEMORY_TRACKER=1

java-agent は third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar の Bazel にチェックインされているため、Bazel リポジトリを保存する場所に合わせて $BAZEL を調整してください。

これらのオプションは、すべてのコマンドで Bazel に渡す必要があります。そうしないと、サーバーが再起動します。

例:

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    build --nobuild <targets>

    # Dump rules
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --rules

    # Dump Starlark heap and analyze it with pprof
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --skylark_memory=$HOME/prof.gz
    % pprof -flame $HOME/prof.gz

analyze-profile

analyze-profile コマンドは、Bazel 呼び出し時に収集された JSON トレース プロファイルを分析します。

canonicalize-flags

canonicalize-flags コマンド。Bazel コマンドのオプションのリストを受け取り、同じ効果を持つオプションのリストを返します。新しいオプション リストは正規化されています。たとえば、同じ効果を持つ 2 つのオプション リストは、同じ新しいリストに正規化されます。

--for_command オプションを使用すると、さまざまなコマンドから選択できます。現時点では、build と test のみがサポートされています。指定されたコマンドでサポートされていないオプションを指定すると、エラーが発生します。

例: 

  % bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint"
  --config=any_name
  --test_tag_filters=-lint

起動オプション

このセクションで説明するオプションは、Bazel サーバー プロセスで使用される Java 仮想マシンの起動に影響し、そのサーバーで処理される後続のすべてのコマンドに適用されます。すでに実行中の Bazel サーバーがあり、起動オプションが一致しない場合は、再起動されます。

このセクションで説明するオプションはすべて、--key=value または --key value 構文を使用して指定する必要があります。また、これらのオプションは Bazel コマンド名の前に指定する必要があります。startup --key=value を使用して、これらの情報を .bazelrc ファイルに一覧表示します。

--output_base=dir

このオプションにはパス引数が必要です。この引数では、書き込み可能なディレクトリを指定する必要があります。Bazel はこの場所を使用して、すべての出力を書き込みます。出力ベースは、クライアントが Bazel サーバーを見つけるためのキーでもあります。出力ベースを変更すると、コマンドを処理するサーバーが変更されます。

デフォルトでは、出力ベースはユーザーのログイン名とワークスペース ディレクトリの名前（実際には MD5 ダイジェスト）から派生するため、一般的な値は /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e のようになります。

次に例を示します。

 OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base
% bazel --output_base ${OUTPUT_BASE}1 build //foo  &  bazel --output_base ${OUTPUT_BASE}2 build //bar

このコマンドでは、2 つの Bazel コマンドが同時に実行されます（シェル &amp; 演算子のため）。それぞれが異なる Bazel サーバー インスタンスを使用します（出力ベースが異なるため）。一方、両方のコマンドでデフォルトの出力ベースが使用された場合、両方のリクエストが同じサーバーに送信され、サーバーはそれらを順番に処理します。つまり、最初に //foo をビルドし、次に //bar の増分ビルドを行います。

--output_user_root=dir

出力とインストール ベースが作成されるルート ディレクトリを指します。ディレクトリが存在しないか、呼び出し元のユーザーが所有している必要があります。以前は、さまざまなユーザー間で共有されるディレクトリを指すことが許可されていましたが、現在は許可されていません。これは、問題 #11100 が解決されたら許可される可能性があります。

--output_base オプションを指定すると、--output_user_root を使用して出力ベースを計算する処理がオーバーライドされます。

インストール ベースの場所は、--output_user_root と Bazel 組み込みバイナリの MD5 ID に基づいて計算されます。

ファイル システム レイアウトに最適な場所がある場合は、--output_user_root オプションを使用して、Bazel のすべての出力（インストール ベースと出力ベース）の代替ベースの場所を選択できます。

--server_javabase=dir

Bazel 自体が実行される Java 仮想マシンを指定します。値は、JDK または JRE を含むディレクトリへのパスにする必要があります。ラベルにすることはできません。このオプションは、次のように Bazel コマンドの前に指定する必要があります。

  % bazel --server_javabase=/usr/local/buildtools/java/jdk build //foo

このフラグは、アプリケーション、テスト、ツールなどの Bazel サブプロセスで使用される JVM には影響しません。代わりに、ビルド オプション --javabase または --host_javabase を使用してください。

このフラグは以前は --host_javabase（左側の --host_javabase とも呼ばれます）という名前でしたが、ビルドフラグ --host_javabase（右側の --host_javabase とも呼ばれます）との混同を避けるため、名前が変更されました。

--host_jvm_args=string

Bazel 自体が実行される Java 仮想マシンに渡される起動オプションを指定します。これは、スタックサイズの設定に使用できます。例:

  % bazel --host_jvm_args="-Xss256K" build //foo

このオプションは、個別の引数を使用して複数回使用できます。このフラグの設定が必要になることはほとんどありません。スペース区切りの文字列のリストを渡すこともできます。各文字列は個別の JVM 引数として解釈されますが、この機能はまもなく非推奨になります。

Bazel のサブプロセス（アプリケーション、テスト、ツールなど）で使用される JVM には影響しません。bazel run またはコマンドラインで実行される実行可能 Java プログラムに JVM オプションを渡すには、すべての java_binary プログラムと java_test プログラムがサポートする --jvm_flags 引数を使用する必要があります。テストには bazel test --test_arg=--jvm_flags=foo ... を使用することもできます。

--host_jvm_debug

このオプションを指定すると、Java 仮想マシンは、JDWP 準拠のデバッガからの接続を待ってから、Bazel 自体の main メソッドを呼び出します。これは主に Bazel デベロッパーによる使用を想定しています。

--autodetect_server_javabase

このオプションを指定すると、Bazel は起動時にインストールされている JDK を自動的に検索し、埋め込み JRE が使用できない場合はインストールされている JRE にフォールバックします。--explicit_server_javabase を使用して、Bazel の実行に使用する明示的な JRE を選択できます。

--batch

バッチモードでは、Bazel は標準のクライアント/サーバー モードを使用せず、単一のコマンドに対して bazel java プロセスを実行します。これは、シグナル処理、ジョブ制御、環境変数継承に関してより予測可能なセマンティクスを実現するために使用されており、chroot jail で bazel を実行するために必要です。

バッチモードでは、同じ output_base 内で適切なキューイング セマンティクスが保持されます。つまり、同時呼び出しは重複することなく順番に処理されます。実行中のサーバーがあるクライアントでバッチモードの Bazel が実行されると、コマンドを処理する前にサーバーが強制終了されます。

バッチモードまたは上記の方法で Bazel を実行すると、処理速度が遅くなります。これは、ビルドファイル キャッシュがメモリ常駐型であるため、連続するバッチ呼び出し間で保持されないためです。そのため、バッチモードは、継続的ビルドなど、パフォーマンスがそれほど重要でない場合に適しています。

--max_idle_secs=n

このオプションは、Bazel サーバー プロセスが終了する前に、最後のクライアント リクエストから待機する時間を秒単位で指定します。デフォルト値は 10800（3 時間）です。--max_idle_secs=0 を指定すると、Bazel サーバー プロセスが永続的に存続します。

このオプションは、Bazel を呼び出すスクリプトで使用できます。これにより、Bazel サーバー プロセスが実行されていない場合に、ユーザーのマシンに残らないようにします。たとえば、送信前スクリプトで bazel query を呼び出して、ユーザーの保留中の変更によって不要な依存関係が導入されないようにすることができます。ただし、ユーザーがそのワークスペースで最近ビルドを行っていない場合、プレサブミット スクリプトが Bazel サーバーを起動して、そのサーバーが 1 日中アイドル状態になるのは望ましくありません。クエリ リクエストで --max_idle_secs の小さい値を指定すると、スクリプトは、新しいサーバーの起動が原因でそのサーバーがすぐに終了した場合でも、すでに実行中のサーバーが通常どおりのアイドル状態になるまで実行を継続することを保証できます。もちろん、既存のサーバーのアイドル タイマーはリセットされます。

--[no]shutdown_on_low_sys_mem

有効になっていて、--max_idle_secs が正の期間に設定されている場合、ビルドサーバーがしばらくアイドル状態になった後、システムのメモリが不足するとサーバーをシャットダウンします。Linux のみ。

max_idle_secs に対応するアイドル状態のチェックを実行するだけでなく、ビルドサーバーは、サーバーがしばらくアイドル状態になった後、使用可能なシステム メモリのモニタリングを開始します。使用可能なシステムメモリが非常に少なくなると、サーバーは終了します。

--[no]block_for_lock

有効にすると、Bazel はサーバーロックを保持している他の Bazel コマンドが完了するまで待機してから処理を進めます。無効にすると、Bazel はロックをすぐに取得して続行できない場合にエラーで終了します。

デベロッパーは、同じクライアント内の別の Bazel コマンドによって発生する長い待機時間を回避するために、この機能を事前送信チェックで使用する場合があります。

--io_nice_level=n

ベスト エフォート型 IO スケジューリングのレベルを 0 ～ 7 の範囲で設定します。0 が最も優先度が高く、7 が最も優先度が低くなります。予測スケジューラは優先度 4 までしか考慮しない場合があります。負の値は無視されます。

--batch_cpu_scheduling

Bazel に batch CPU スケジューリングを使用します。このポリシーは、非インタラクティブなワークロードで、nice 値を下げたくない場合に便利です。「man 2 sched_setscheduler」をご覧ください。このポリシーでは、Bazel のスループットを犠牲にして、システムのインタラクティブ性を向上させることができます。

その他のオプション

--[no]announce_rc

起動時に bazelrc ファイルから読み取られた起動オプションとコマンド オプションを Bazel がアナウンスするかどうかを制御します。

--color (yes|no|auto)

このオプションは、Bazel が画面上の出力をハイライト表示するために色を使用するかどうかを決定します。

このオプションが yes に設定されている場合、カラー出力が有効になります。このオプションが auto に設定されている場合、Bazel は、出力がターミナルに送信され、TERM 環境変数が dumb、emacs、xterm-mono 以外の値に設定されている場合にのみ、カラー出力を使用します。このオプションが no に設定されている場合、出力がターミナルに送信されるかどうか、TERM 環境変数の設定に関係なく、カラー出力は無効になります。

--config=name

rc ファイルから追加の構成セクションを選択します。現在の command では、そのようなセクションが存在する場合、command:name からオプションも取得します。複数回指定して、複数の構成セクションからフラグを追加できます。展開は他の定義を参照できます（たとえば、展開をチェーン化できます）。

--curses (yes|no|auto)

このオプションは、Bazel が画面出力でカーソル コントロールを使用するかどうかを決定します。これにより、スクロールするデータが減り、Bazel からの出力ストリームがよりコンパクトで読みやすくなります。これは --color とうまく連携します。

このオプションを yes に設定すると、カーソル コントロールの使用が有効になります。このオプションを no に設定すると、カーソル コントロールの使用が無効になります。このオプションが auto に設定されている場合、--color=auto と同じ条件でカーソル コントロールの使用が有効になります。

--[no]show_timestamps

指定されている場合、Bazel によって生成された各メッセージに、メッセージが表示された時刻を示すタイムスタンプが追加されます。