コマンドとオプション

問題を報告する ソースを表示

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

ターゲット構文

build や test などの一部のコマンドは、ターゲットのリストに対して機能します。ラベルよりも構文の構文が優れています。詳しくは、ビルドするターゲットを指定するをご覧ください。

オプション

以降のセクションでは、ビルドで使用できるオプションについて説明します。--long を help コマンドで使用すると、オンライン ヘルプのメッセージは、各オプションの意味、種類、デフォルト値の概要を示します。

ほとんどのオプションは 1 回しか指定できません。複数回指定すると、最後のインスタンスが優先されます。複数回指定できるオプションは、「複数回使用できる」というオンライン ヘルプで確認できます。

パッケージの場所

--package_path

このオプションでは、特定のパッケージの 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 ディレクトリに移動した場合、パッケージは /home/bob/clients/bob_client/bazel/foo ディレクトリから解決されます。

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

Bazel はパッケージを現在のディレクトリに置く必要はないため、必要なパッケージがすべてパッケージパスの他の場所にある場合は、空の Bazel ワークスペースからビルドできます。

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

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch WORKSPACE
  % 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 はデバッグ情報を除去しないことを意味します。 --compilation_mode が fastbuild の場合、--strip=sometimes のデフォルト値はストリップです。

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

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

Bazel の --strip オプションは ld の --strip-debug オプションに対応し、デバッグ情報のみを削除します。なんらかの理由で、デバッグ シンボルだけでなく、すべてのシンボルを削除するには、ld の --strip-all オプションを使用する必要があります。これを行うには、--linkopt=-Wl,--strip-all を Bazel に渡します。また、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、14、15 で、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 です。値を拡張するには、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

（bazel のデフォルトではなく）javac のデフォルト デバッグ情報で java_binary を再ビルドします。

このオプションは、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 と短縮されます）。特に --compilation_mode、-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 アーキテクチャの名前を指定します。

--fat_apk_cpu=cpu[,cpu]*

android_binary ルールの推移的な deps で C/C++ ライブラリをビルドするための CPU。その他の C/C++ ルールは影響を受けません。たとえば、cc_library が android_binary ルールと cc_binary ルールの推移的な deps に含まれている場合、cc_library は少なくとも 2 回ビルドされます（android_binary ルールに --fat_apk_cpu で指定された CPU ごとに 1 回、cc_binary ルールに --cpu で指定された CPU に 1 回）。

デフォルト値は armeabi-v7a です。

--fat_apk_cpu で指定された各 CPU 用に 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 は、file.cc を除く //foo/ 内のすべての .cc ファイルの C++ コンパイラのコマンドラインに -O0 オプションと -fprofile-arcs オプションを追加します。

--dynamic_mode=mode

ビルドルールで linkstatic 属性を使用して、C++ バイナリを動的にリンクするかどうかを指定します。

モード:

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

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

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

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

--force_ignore_dash_static

このフラグが設定されている場合、cc_* ルールの BUILD ファイルの linkopt で指定される -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 を指定せずに、デフォルトを使用するターゲットを含むすべての malloc="target" 属性をオーバーライドします。

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

objc*、ios ios apple、apple ルールの推移的な deps で C/C++ ルールのコンパイルに使用する crosstool。*これらのターゲットでは、このフラグによって --crosstool_top が上書きされます。

--android_crosstool_top=label

android_binary ルールの推移的な deps ルールで C/C++ ルールをコンパイルするために使用する crosstool。これは、ビルド内の他のターゲットに異なるクロスツールが必要な場合に役立ちます。デフォルトでは、WORKSPACE ファイルの android_ndk_repository ルールによって生成された crosstool が使用されます。関連情報: --fat_apk_cpu.

--compiler=version

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

--android_sdk=label

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

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

--java_toolchain=label

このオプションでは、Java ソースファイルのコンパイルに使用する java_ツールチェーン ラベルを指定します。

--host_java_toolchain=label

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

--javabase=(label)

このオプションは、bazel run、bazel test、および java_binary ルールと java_test ルールでビルドされた Java バイナリに使用する Java の基本インストールのラベルを設定します。JAVABASE 変数と JAVA 変数は、このオプションから派生します。

--host_javabase=label

このオプションは、exec 構成（JavaBuilder や Singlejar などのホストビルド ツールなど）で使用するベース Java インストールのラベルを設定します。

Java ソースファイルのコンパイルに使用される Java コンパイラは選択されません。コンパイラは、--java_toolchain オプションを設定することで選択できます。

実行戦略

これらのオプションは、Bazel によるビルドの実行方法に影響します。 ビルドによって生成された出力ファイルに大きな影響はありません。通常、主な効果はビルドの速度です。

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

このオプションは、コマンドの実行場所と方法を制御します。--spawn_strategy（および、--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 戦略で「//foo/bar/baz」をコンパイルしますが、順序を逆にすると、local で実行されます。
  • 例: --strategy_regexp='Compiling.*/bar=local,sandboxed' は、local 戦略で「//foo/bar/baz」をコンパイルします。失敗した場合は sandboxed にフォールバックします。

--genrule_strategy=strategy

これは --strategy=Genrule=strategy の非推奨の省略形です。

--jobs=n（-j）

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

--progress_report_interval=n

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

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

bazel がカーソル コントロールを使用している場合（--curses で指定）、1 秒ごとに進行状況が報告されます。

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

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

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

テスト（またはアプリケーション）を実行すると、それらのランタイムのデータ依存関係が 1 か所に集約されます。Bazel の出力ツリー内では、この「runfiles」ツリーは通常、対応するバイナリまたはテストの兄弟要素にルートします。テスト実行中は、$TEST_SRCDIR/workspace/packagename/filename という形式のパスを使用して実行ファイルにアクセスできます。runfiles ツリーで、テストでは依存関係が宣言されたすべてのファイルにアクセスでき、それ以上アクセスすることはできません。デフォルトでは、runfiles ツリーは、必要なファイルへの一連のシンボリック リンクを構築することで実装されます。リンクセットが大きくなると、このオペレーションのコストも増加します。一部の大規模なビルドでは、特に個々のテスト（またはアプリケーション）ごとに独自の runfiles ツリーが必要になるため、全体的なビルドに大きく影響します。

--[no]build_runfile_manifests

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

runfile ツリーはメモリ内マニフェストからリモートで作成されるため、テストをリモートで実行するときに無効にできます。

--[no]discard_analysis_cache

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

--[no]keep_going（-k）

GNU Make と同様に、最初のエラーが発生すると、ビルドの実行フェーズが停止します。エラーが生じた場合でも、可能な限り多くのビルドを行うことが有用な場合があります。このオプションを有効にすると、ビルドが前提条件を正常にビルドしたすべてのターゲットのビルドが試みられますが、エラーは無視されます。

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

--[no]use_ijars

このオプションにより、Bazel による java_library ターゲットのコンパイル方法が変更されます。Bazel は、java_library の出力を使用して、依存する java_library ターゲットをコンパイルする代わりに、限定公開以外のメンバー（公開、保護、デフォルト（パッケージ）アクセスのメソッドとフィールド）のシグネチャのみを含むインターフェース 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、efairmous）として指定します。前に除外テストサイズを示す場合は、前に「-」記号を付けます。次に例を示します。

  % 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 も指定されている場合はビルドします）。テストのタイムアウト フィルタは、許可するテスト タイムアウト値のカンマ区切りリスト（短い、中程度、長い、または永続的な）として指定します。必要に応じて、除外されているテスト タイムアウトを示す前に「-」記号を付けます。構文の例については、--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 の具体的な解釈は、テストの実行を担当するテスト フレームワークによって異なります。glob、部分文字列、正規表現を指定できます。--test_filter は、異なる --test_arg フィルタ引数を渡すよりも便利ですが、すべてのフレームワークでサポートされているわけではありません。

読み上げの詳細設定

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

--explain=logfile

このオプションはファイル名引数を必要とするため、bazel build の実行フェーズの依存関係チェッカーで、ビルドステップが実行される理由または最新であるということが説明されます。説明は logfile に書き込まれます。

予期しない再ビルドが発生した場合、このオプションがその理由を理解するために役立ちます。これを以降のすべてのビルドでロギングするように .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 シェルと互換性のある構文で出力されます。これは、シェル プロンプトにコピーして貼り付けるのに適しています。

ワークスペースのステータス

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

--workspace_status_command=program

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

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

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

Bazel は「安定版」と「揮発性」の 2 つのバケットに鍵を分割します。「安定版」と「揮発性」は、少し直感的にはわかりにくいため、あまり考慮しないでください。

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

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

契約書は次のとおりです。

  • 「安定」キーの値はほとんど変更されません。bazel-out/stable-status.txt の内容が変更されると、Bazel はそれに依存するアクションを無効にします。つまり、安定したキーの値が変更された場合、Bazel はスタンプされたアクションを再実行します。そのため、Stable ステータスにはタイムスタンプなどが含まれません。タイムスタンプは常時変更され、Bazel はビルドごとにスタンプ付きアクションを再実行するからです。

    Bazel は常に次の安定鍵を出力します。

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

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

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

    • BUILD_TIMESTAMP: ビルドの時刻（Unix エポックからの経過秒数）（System.currentTimeMillis() の値を 1,000 で割った値）
    • FORMATTED_DATE: ビルドの時間（UTC の形式、2023 年 6 月 2 日 44 日 29 日など）。FORMATTED_DATEyyyy MMM d HH mm ss EEE

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 ステータス ファイルに 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() によって WORKSPACE ファイルに宣言されているプラットフォームよりも先に考慮されます。このオプションには、優先順位のカンマ区切りのリストを指定できます。フラグが複数回渡された場合、最新のオーバーライドが適用されます。

--extra_toolchains=labels

ツールチェーンの解決中に考慮されるツールチェーン ルール。ツールチェーンは、正確なターゲットまたはターゲット パターンで指定できます。これらのツールチェーンは、register_ツールチェーン s() によって WORKSPACE ファイルで宣言される前に実行されます。

--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: 複数の構成のビルドを管理する場合は、「64 ビット」と「32 ビット」などの一意の識別子で各ビルドを識別すると便利です。このオプションにより、bazel-bin などのシンボリック リンクが区別されます。

テストの実行

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

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

「bazel test」のオプション

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

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

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

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

「はい」の場合、キャッシングの動作は自動テストと同じです。ただし、テストの失敗と --runs_per_test によるテスト実行がキャッシュに保存される可能性があります。

.bazelrc ファイルでこのオプションをデフォルトで有効にしているユーザーは、特定の実行でデフォルトをオーバーライドする際に、-t（オン）または -t-（オフ）という略称を使用する場合があります。

--check_tests_up_to_date

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

このオプションは、[--check_up_to_date](#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 フラグの値によって異なります。

  • 存在しない場合、実行に失敗すると、テスト全体が失敗します。
  • 存在し、同じシャードのリターン PASS と FAIL から 2 つの実行が存在する場合、テストは不安定なステータスを受け取ります（他の実行の失敗が原因で失敗する場合を除く）。

1 つの数値を指定すると、すべてのテストがその回数だけ実行されます。正規表現 {0/} の構文を使用して、正規表現を指定することもできます。これにより、--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 つ以上の実行が失敗し、同じシャードパスに対して 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

--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 に似ていますが、単一のターゲットをビルドして実行する点で異なります。一般的なセッションは次のとおりです。

  % bazel run java/myapp:myapp -- --arg1 --arg2
  Welcome to Bazel
  INFO: Loading package: java/myapp
  INFO: Loading package: foo/bar
  INFO: Loading complete.  Analyzing...
  INFO: Found 1 target...
  ...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp:myapp
  INFO: Elapsed time: 0.638s, Critical Path: 0.34s

  INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

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

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

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

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

  • BUILD_WORKSPACE_DIRECTORY: ビルドが実行されたワークスペースのルート。
  • BUILD_WORKING_DIRECTORY: Bazel の実行元となった現在の作業ディレクトリ。

たとえば、コマンドラインでファイル名をわかりやすくするために解釈できます。

「bazel run」のオプション

--run_under=command-prefix

この動作は、bazel test の --run_under オプションと同じです（上記を参照）。ただし、bazel test で実行中のテストではなく、bazel run で実行中のコマンドに適用され、ラベルで実行することはできません。

Bazel からのロギング出力のフィルタリング

Bazel は、bazel run を使用してバイナリを呼び出すと、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 インスタンスは 1 つのワークスペースに関連付けられているため、clean コマンドを使用すると、そのワークスペースで Bazel インスタンスに対して行ったすべてのビルドからのすべての出力が削除されます。

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

  % bazel clean --expunge

また、--expunge_async を使用してバックグラウンドで消去することもできます。非同期消去が継続している間に、同じクライアントで Bazel コマンドを呼び出すのは安全です。

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

Bazel の設計では、これらの問題は修正可能であり、修正には高い優先度が付けられます。間違った増分ビルドを見つけた場合は、clean を使用する代わりに、バグレポートを提出し、ツールでバグを報告してください。

依存関係グラフをクエリする

Bazel には、ビルド時に使用する依存関係グラフを質問するためのクエリ言語が含まれています。クエリ言語は、query と cquery の 2 つのコマンドで使用されます。2 つのコマンドの主な違いは、クエリが読み込みフェーズの後に実行されることと、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 を使用したビルドに示すように、使用可能なコマンドの概要とヘルプトピックが表示されます。引数を指定すると、特定のトピックの詳細なヘルプが表示されます。ほとんどのトピックは build や query などの Bazel コマンドですが、コマンドに対応していない追加のヘルプトピックもあります。

--[no]long（-l）

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

shutdown

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

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

shutdown は、整数引数（MB）を必要とする 1 つのオプション --iff_heap_size_greater_than _n_ を受け入れます。指定すると、すでにシャットダウンされたメモリの量に基づいてシャットダウンが行われます。Bazel サーバーでメモリリークが発生すると、偶発的にクラッシュが発生する可能性があるため、多くのビルドを開始するスクリプトで役立ちます。条件付き再起動を実行すると、この条件がプリエンプトされます。

info

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

info コマンドでは、以下のリストのいずれかのキーの名前を示す単一の引数（省略可）も指定できます。この場合、bazel info key はその 1 つのキーの値のみを出力します。sed -ne /key:/s/key://p を使用して結果をパイプする必要がないため、Bazel のスクリプティングで特に便利です。

構成に依存しないデータ

  • 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.0.jar
  • --host_jvm_args=-DRULE_MEMORY_TRACKER=1

Java エージェントは third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar で Bazel にチェックインされます。Bazel リポジトリを保管する場所に合わせて $BAZEL を調整してください。

コマンドごとにこれらのオプションを Bazel に渡してください。渡しないと、サーバーが再起動します。

例:

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.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.0.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.0.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

このコマンドでは、シェル &amp; 演算子により、2 つの Bazel コマンドが同時に実行されます（それぞれの出力ベースが異なるため、異なる 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/jdk11 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 自体のメインメソッドを呼び出します。これは主に Bazel デベロッパーが使用することを目的としています。

--autodetect_server_javabase

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

--batch

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

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

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

--max_idle_secs=n

このオプションは、Bazel サーバー プロセスが最後のクライアント リクエストから終了するまでに待機する時間を秒単位で指定します。デフォルト値は 10,800（3 時間）です。--max_idle_secs=0 を指定すると、Bazel サーバー プロセスが無期限に保持されます。

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

--[no]shutdown_on_low_sys_mem

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

max_idle_secs に対応するアイドル チェックを実行するだけでなく、サーバーがアイドル状態になるまでの時間が経過すると、ビルドサーバーは使用可能なシステムメモリのモニタリングを開始します。 使用可能なシステムメモリが大幅に不足すると、サーバーは終了します。

--[no]block_for_lock

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

デベロッパーは、同じクライアントの別の Bazel コマンドによる長時間の待機を回避するため、presubmit チェックでこれを使用できます。

--io_nice_level=n

0 から 7 までのレベルを設定して、ベスト エフォートの IO スケジューリングを行います。0 の優先度が最も高く、7 の優先度が最も低くなります。予測スケジューラは、優先度 4 までを尊重できます。負の値は無視されます。

--batch_cpu_scheduling

Bazel の batch CPU スケジューリングを使用します。このポリシーは、インタラクティブではないものの価値を低下させたくないワークロードに役立ちます。「man 2 sched_setscheduler」をご覧ください。このポリシーを使用することで、Bazel のスループットを犠牲にしてシステム操作を改善できます。

その他

--[no]announce_rc

起動時に Bazel が bazelrc ファイルから読み取ったコマンド オプションを通知するかどうかを制御します。（スタートアップのオプションは無条件に発表されます）。

--color (yes|no|auto)

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

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

--config=name

rc ファイルから追加の構成セクションを選択します。現在の command については、そのようなセクションが存在する場合、command:name のオプションも pull します。複数回指定すると、複数の構成セクションからフラグを追加できます。展開は他の定義を参照することもあります（拡張を連結するなど）。

--curses (yes|no|auto)

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

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

--[no]show_timestamps

指定すると、Bazel が生成した各メッセージにタイムスタンプが追加され、メッセージの表示時刻が指定されます。