コマンドとオプション

<ph type="x-smartling-placeholder"></ph> 問題を報告する ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

ターゲットの構文

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

オプション

以降のセクションでは、ビルド時に使用できるオプションについて説明します。help コマンドで --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=&#39;^//(first/project|second/project):&#39;` 指定したパッケージの出力を表示します。
`--output_filter=&#39;^//((?!(first/bad_project|second/bad_project):).)*$&#39;` 指定したパッケージの出力を表示しません。
`--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

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

このオプションは、C++ ソースファイルのコンパイラに渡す引数を受け取ります。 実行構成ファイル内にコンパイルされます。これは --cxxopt オプションですが、 exec 構成があります。

--host_linkopt=linker-option

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

--conlyopt=cc-option

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

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

--cxxopt=cc-option

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

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

例:

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

--linkopt=linker-option

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

これは --copt に似ていますが、リンクにのみ適用されます。 ありませんそのため、意味がある場合にのみコンパイラ オプションを リンク時（-lssp、-Wl,--wrap,abort など） --linkopt を使用します。例:

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

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

--strip (always|never|sometimes)

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

  % 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 がオーバーライドされるため、どちらか一方のみを設定する必要があります。

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

--stripopt=strip-option

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

--fdo_instrument=profile-output-dir

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

プロファイル データツリーが生成されると、プロファイル ツリーは ZIP 形式で圧縮し --fdo_optimize=profile-zip FDO 最適化コンパイルを有効にする Bazel オプション。

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

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

--fdo_optimize=profile-zip

--fdo_optimize オプションを使用すると、 FDO を実行するためのオブジェクトごとのファイル プロファイル情報（フィードバック） 有向最適化など）がコンパイル時に行われます。GCC の場合、 前に生成されたファイルツリーを含む zip ファイルが提供されます。 各 .o ファイルのプロフィール情報を含む .gcda ファイルの数。

自動プロファイルを引数として指定することもできます。 拡張子が.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 仕様と互換性のあるコンストラクトのみを許可します。デフォルト値は 8 です。--&gt; 有効な値は 8、9、10、11、14、15、21 で、 default_java_toolchain を使用したカスタム Java ツールチェーンの登録。

--tool_java_language_version=version

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

--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 です。値を拡張するには、次のいずれかの方法を使用してカスタム JVM を登録し、 local_java_repository または remote_java_repository リポジトリ ルール。

--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 のデフォルトのデバッグ情報で java_binary が再ビルドされる （Bazel デフォルトを使用しません）。

このオプションは、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 が次の標準 Java 警告を生成することを意味します。 欠落している直接依存関係ごとに [strict] と入力します。
  • 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 オプションは、Bazel に対して label で指定された action_listener ルールから ビルドグラフに extra_actions を挿入します。

--[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 個 使用します。

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

% 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 プラットフォームは、 使用されます。

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

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

包含正規表現のいずれかに一致するラベルまたは実行パスを持つ C++ ファイル（存在する場合） いずれかの除外式に一致しない場合にルールが 必要があります。ラベルの照合では、正規形式のラベルが使用されます。 （例: //package:label_name）。

実行パスは、ベース名を含むワークスペース ディレクトリへの相対パスです。 （拡張子を含む）を指定します。また、プラットフォームに依存するプレフィックスも含まれます。

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

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

このオプションは、使用するコンパイル モードに関係なく適用されます。たとえば --compilation_mode=opt でコンパイルし、一部を選択してコンパイルする [より強力な最適化] がオンか、または [オフ] に設定されているファイルを表示することもできます。

注意: 一部のファイルがデバッグ シンボルで選択的にコンパイルされている場合、リンク時にシンボルが削除されることがあります。これを回避するには、 --strip=never。

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

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

--dynamic_mode=mode

やり取りしながら C++ バイナリを動的にリンクするかどうかを決定します ビルドルールの linkstatic 属性。

モード:

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

--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

このフラグが設定されている場合、linkopt にある -static オプション cc_* ルールの BUILD ファイルは無視されます。これは単に C++ 強化ビルドの回避策です。

--[no]force_pic

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

--android_resource_shrinking

android_binary ルールでリソースの圧縮を行うかどうかを選択します。デフォルトの shrink_resources 属性（オン） android_binary ルールそのルールのドキュメントをご覧くださいデフォルトはオフです。

--custom_malloc=malloc-library-target

指定すると、指定された malloc の実装が常に使用され、 malloc="target" 属性（ （malloc を指定しないことにより）します。

--crosstool_top=label

このオプションは、ビルド中のすべての C++ コンパイルに使用するクロスツール コンパイラ スイートの場所を指定します。Bazel は、 CROSSTOOL ファイルの場所を指定し --compiler の設定。

--host_crosstool_top=label

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

--apple_crosstool_top=label

objc*、ios*、apple* ルールの伝播 deps で C/C++ ルールのコンパイルに使用するクロスツール。そうしたターゲットの場合、このフラグは --crosstool_top。

--compiler=version

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

--android_sdk=label

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

このオプションでは、Android SDK/プラットフォーム ツールチェーンを指定します および Android ランタイム ライブラリです。これらは、Android 関連の 適用できます。

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

--java_toolchain=label

NoOps。下位互換性のためにのみ保持されます。

--host_java_toolchain=label

NOP。下位互換性のためだけに保持されています。

--javabase=(label)

NOP。下位互換性のためだけに保持されています。

--host_javabase=label

NoOps。下位互換性のためにのみ保持されます。

実行戦略

これらのオプションは、Bazel によるビルドの実行方法に影響します。 出力ファイルに大きな影響はないはずです。 表示されます。通常 その主な効果は ビルドの速度が上がります。

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

このオプションは、コマンドが実行される場所と方法を制御し、メモニカごとに --spawn_strategy（および --genrule_strategy とメモニカ Genrule）をオーバーライドします。サポートされている戦略とその効果については、--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 「Compiling //foo/bar/baz」を実行sandboxed 戦略ですが、逆方向です。 注文では local を使用して実行されます。
  • 例: --strategy_regexp='Compiling.*/bar=local,sandboxed' 実行 'コンパイル //foo/bar/baz'local 戦略と一致し 失敗した場合は sandboxed。

--genrule_strategy=strategy

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

--jobs=n（-j）

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

--progress_report_interval=n

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

デフォルトは 0 で、増分アルゴリズムです。最初のレポートは 10 秒後に出力され、次に 30 秒後に出力され、その後は 1 分ごとに出力されます。

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

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

これらのオプションでは、ローカル リソースの量（MB 単位の RAM と CPU 論理コアの数）を指定します。 ローカルで実行するようにビルドとテストのアクティビティをスケジュールする際に、Bazel で考慮できるすべての点について説明します。料金 整数、またはキーワード（HOST_RAM または HOST_CPUS）（必要に応じてその後に [-|*float]） （例: --local_cpu_resources=2、--local_ram_resources=HOST_RAM*.5、 --local_cpu_resources=HOST_CPUS-1）。 フラグは独立しています。片方または両方を設定できます。デフォルトでは、Bazel は RAM の量と CPU コアの数をローカル システムの構成から直接取得します。

このオプション（デフォルトで有効）は、Runfile を実行するかどうかを テストとバイナリのシンボリック リンクを出力ディレクトリにビルドする必要があります。 --nobuild_runfile_links を使用すると、 オーバーヘッドを発生させることなくすべてのターゲットをコンパイルできるかどうかを検証 runfile ツリーを構築します。

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going（-k）

GNU Make と同様に、ビルドの実行フェーズは、最初の エラーが発生する。インフラストラクチャとして 最大限に活用できますこのオプションにより 指定されると、ビルドは実行を試行します。 前提条件が正常にビルドされたターゲットがすべてビルドされますが、 エラーは無視されます。

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

--[no]use_ijars

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

--[no]interface_shared_objects

このオプションを使用すると、インターフェース共有オブジェクトが有効になり、バイナリとオブジェクトが作成されます。 他の共有ライブラリは、共有オブジェクトのインターフェースに依存します。 理解することが重要です。実装のみが変更されると、Bazel は 変更された共有ライブラリに依存するターゲットの再構築を回避できる 防ぐことができます。

出力の選択

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

--[no]build

このオプションを使用すると、ビルドの実行フェーズが発生します。それは デフォルトで有効になっています。これをオフにすると、実行フェーズは スキップされ、最初の 2 つのフェーズ、読み込みと分析のみが発生します。

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

--[no]build_tests_only

指定した場合、Bazel は *_test の実行に必要なものだけをビルドします と test_suite 個のルールが、 size、 timeout、 タグ、または language。 指定した場合、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 でソースファイルの構文チェックを行う場合に便利です。たとえば、ソースファイルに依存する単一のターゲットを再ビルドして、編集 / ビルド / テスト サイクルでできるだけ早くエラーを検出できます。この引数は、 フラグ以外の引数は、解釈されます。各引数は、 file target ラベル、または現在の作業環境を基準とする書式なしファイル名 各ソースファイル名に依存する 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 の場合はビルド）します も指定されている場合）は、指定されたタイムアウトが設定されたテスト ターゲットのみを対象とします。テスト タイムアウト フィルタは、許可されるテスト タイムアウト値（短い、中程度、長い、永続）のカンマ区切りリストとして指定します。必要に応じて、除外するテスト タイムアウトを示すために「-」記号を先頭に追加します。構文の例については、--test_size_filters をご覧ください。

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

--test_tag_filters=tag[,tag]*

指定すると、Bazel がテスト（--build_tests_only の場合はビルド）します も指定されている場合）は、必須のタグが 1 つ以上あるテスト ターゲットのみ （いずれかが指定されていれば）含まれており、除外されているタグはありません。テストタグ フィルタは、タグキーワードのカンマ区切りのリストとして指定します。必要に応じて、除外タグを示すために「-」記号を先頭に追加します。必須のタグは 先頭に「+」が付いている表示されます。

次に例を示します。

  % 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/...

//baz/... のすべてのターゲット（foo_test と bar_test 個のインスタンス。

--test_filter=filter-expression

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

filter-expression の特定の解釈は、 テスト フレームワークです。グロブ、サブ文字列、正規表現にすることができます。--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 コマンドの引数。デフォルトでは、1 つの ビルド ターゲットを指定すると、Bazel は、 ターゲットが最新に正常に更新されているかどうか、 ターゲットによって作成された出力ファイルのリスト。複数の場合 ターゲットが指定された場合、結果情報は表示されません。

結果の情報は、1 つのコンテナのビルドに 大規模なビルドの場合（トップレベル ドメイン全体など）の場合は、 プロジェクト ツリーなど）にアクセスしようとすると、情報量が膨大で気が散るおそれがあります。 制御できるようになります。--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 を print に渡すことができる コマンドの引数を 1 行ではなくリストとして指定します。このため、 長いコマンドラインが読みやすくなります

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

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

--verbose_failures

このオプションを使用すると、Bazel の実行フェーズで、失敗したコマンドの完全なコマンドラインが出力されます。これは、サーバー コンポーネントをデバッグする際に 表示されます。

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

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

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

--workspace_status_command=program

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

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

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

Bazel は、キーを「安定」と「揮発性」の 2 つのバケットに分割します。（「stable」と 「volatile」直感に反するため、あまり気にしないでください）。

その後、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 は揮発性ファイルが決して 変更します。つまり、内容が変更されたファイルが揮発性のステータス ファイルのみの場合、Bazel はそれに依存するアクションを無効にしません。アクションのその他の入力が Bazel はそのアクションを再実行し、更新された volatile がアクションに表示されます。 volatile ステータスを変更しただけでは、アクションが無効になることはありません。

    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 では、true は何もせず、正常に終了（ゼロで終了）し、出力も出力しないため、--workspace_status_command=/bin/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

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

--extra_toolchains=labels

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

--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 を呼び出すをご覧ください。具体的には次のオプションを利用できます。 使用することを強くおすすめします。

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

  • --package_path
  • --symlink_prefix: 複数の構成のビルドを管理するための機能、 各ビルドを区別すると、 識別子（例: 「64bit」）「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 で複数のテスト実行がリクエストされた
  • テストが失敗しました。

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

「yes」の場合、キャッシュの動作は自動と同じですが、--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 が返されます。 （他の失敗した実行によって 失敗します）。

1 つの数値を指定すると、すべてのテストがその数回実行されます。または、構文を使用して正規表現を指定することもできます。 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 つ以上の実行が失敗し、同じシャードの 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 はすべてのテストでこれらのタイムアウトを使用します。 テストのサイズからタイムアウト制限を推測し、 明示的に設定することもできます。

テストでは、タイムアウト カテゴリと size は、タイムアウトが暗黙的に設定されていた場合と同じ値を受け取ります。 指定します。そのため、タイムアウトを「長い」と宣言するサイズが「小さい」テストは、明示的なタイムアウトのない「大きい」テストと同じ有効なタイムアウトになります。

--test_arg=arg

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

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

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

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

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

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

--run_under=command-prefix

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

最初の単語が完全修飾ラベル（ //）がビルドされます。ラベルは UDM フィールド値で コマンドの先頭に追加される、対応する実行可能な場所 他の単語と一緒に実行されます

いくつかの注意事項があります。

  • テストの実行に使用される 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'

テストの選択

出力選択オプションで説明されているように、 テストをサイズ、 timeout、 タグ、または language。利便性 一般名フィルタでは、特定のトピックを フィルタ引数をテストランナーに渡します。

bazel test のその他のオプション

構文と残りのオプションは bazel build。

実行可能ファイルの実行

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

  % 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 が実行された現在の作業ディレクトリ。

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

「bazel run」のオプション

--run_under=command-prefix

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

Bazel によるロギング出力をフィルタする

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

次に例を示します。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 つのコマンドの主な違いは、クエリが読み込みフェーズの後に実行され、cquery が分析フェーズの後に実行されることです。これらのツールは、多くのソフトウェア エンジニアリング タスクに欠かせないものです。

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

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

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

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

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

例: 「（BUILD ファイル内の）定義の場所を PEBL ツリー内のすべてのテストを構築するために必要なすべての genrules を定義できます。

  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 が承認 オプション --iff_heap_size_greater_than _n_ は、 整数の引数（MB 単位）が必要です。指定すると、すでに使用されているメモリの量に応じてシャットダウンが条件付きになります。これは、多くのビルドを開始するスクリプトにとって便利です。Bazel サーバーでメモリリークが発生すると、まれにクラッシュが発生する可能性があります。条件付き再起動を実行すると、この状態を回避できます。

info

info コマンドは、コマンドに関連付けられたさまざまな値を出力します。 特定のビルド構成で実行できます。 （これらは、ビルドを実行するスクリプトで使用できます）。

info コマンドでは、1 つの（省略可能な）引数も指定できます。これは、次のリストのいずれかのキーの名前です。この場合、bazel info key は そのキーの値を取得します。（これは、 Bazel を使用すると、結果をパイプ処理する必要がなくなります。 sed -ne /key:/s/key://p 経由:

構成に依存しないデータ

  • release: この Bazel のリリースラベル 「development version」などリリースしていない場合 バイナリです。
  • 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: コマンド ログファイルの絶対パス。 これには、インターリーブされた最新の stdout および stderr ストリームが含まれます。 Bazel コマンド。bazel info を実行すると、このファイルの内容が上書きされます。これは、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 によって報告された値を使用するスクリプトは、より堅牢になります。
  • 完全な 「メーカー」必要があります。--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 サーバーの起動やサーバー アーカイブの解凍などの副作用を除き、bazel version --gnu_format と同じ出力が生成されます。bazel --version は次から実行できます。 ワークスペース ディレクトリは不要です。

mobile-install

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

詳しくは、bazel モバイル インストールをご覧ください。

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

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

  • 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-agent は、以下の場所で Bazel にチェックインされます。 third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar なので、 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 コマンドは、 JSON トレース プロファイル Bazel 呼び出しで収集されたものです。

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

起動オプション

このセクションで説明するオプションは、Java 使用される VM で、Compute Engine の仮想マシンに 後続のコマンドはこのサーバーで処理されます。すでに実行中の Bazel サーバーが存在し、起動オプションが一致しない場合、サーバーは再起動されます。

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

--output_base=dir

このオプションを使用するには path 引数が必要です。パスの引数には、 ディレクトリに配置されます。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

出力ベースとインストール ベースが作成されるルート ディレクトリを指します。ディレクトリ 呼び出し元のユーザーに存在していないか、オーナーになっている必要があります。これまでは これにより、さまざまなユーザーが共有するディレクトリを指すことが許可されていました。 認められなくなりましたこれが許可されるのは 1 回だけです。 問題 #11100 に対処しています。

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

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

--output_user_root オプションを使用すると、 すべての Bazel 出力（インストール ベースと出力）の代替ベースの場所 （ベース）に指定します。

--server_javabase=dir

Bazel 自体が実行される Java 仮想マシンを指定します。値にはパスを ディレクトリに配置されます。ラベルにすることはできません。 このオプションは、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 で実行するかコマンドラインで実行するかにかかわらず、JVM オプションを実行可能 Java プログラムに渡すには、すべての 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 を使用すると、明示的な JRE を選択して、 Bazel を実行します。

--batch

バッチモードでは、Bazel は 標準クライアント/サーバーモードだが、bazel を実行する 単一のコマンドで処理できます。これは、以前より予測しやすいように、 シグナル処理、ジョブ制御、環境に関するセマンティクス 変数の継承によって維持され、chroot jail で bazel を実行するために必要です。

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

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

--max_idle_secs=n

このオプションでは、Bazel サーバー プロセスの時間を秒単位で指定します は、クライアントの最後のリクエストの後、終了するまでに待機する必要があります。「 デフォルト値は 10,800（3 時間）です。--max_idle_secs=0 の場合、 Bazel サーバー プロセスが無期限に存続するようにしました。

このオプションは、Bazel を呼び出すスクリプトで Bazel サーバー プロセスをユーザーのマシンに残さないようにする 実行されません。 たとえば、送信前スクリプトで 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 は すぐにロックを取得できない場合は、誤って終了し、 見てみましょう。

デベロッパーはこれを presubmit チェックで使用して、待ち時間が長くなるのを回避できる 同じクライアント内の別の 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

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

--color (yes|no|auto)

このオプションは、Bazel で色を使用してハイライト表示するかどうかを指定します 変換されます。

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

--config=name

追加の設定セクションを以下から選択 rc ファイル現在のcommand また、そのようなセクションが存在する場合は、command:name からオプションを取得します。可能 指定すると、複数の config セクションからフラグが追加されます。展開は、他の 1 つの （たとえば、拡張を連結できます）。

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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