コマンドとオプション

<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

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

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

--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 要素 . を使用する場合、 cd コマンドを使用して /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=&#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++、Java、Python の前処理、コンパイル、アセンブルを 記述できます。リンク時には渡されません。

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

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

デバッグ テーブルなしで foo ライブラリをコンパイルし、 使用できます。

--host_copt=cc-option

このオプションは、ソースファイルのコンパイラに渡す引数を受け取ります。 コンパイルされます。これは --copt オプションですが、 できます。

--host_conlyopt=cc-option

このオプションは、C ソースファイルのコンパイラに渡す引数を受け取ります。 コンパイルされます。これは --conlyopt オプションですが、適用されるのは ホスト構成に追加します。

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

このオプションは、ソースファイルのリンカーに渡す引数を受け取ります。 コンパイルされます。これは --linkopt オプション。ただし、このオプションは ホスト構成を変更できます。

--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 オプションを使用すると、 新しい FDO（Feedback Directed Optimization）プロファイルが ビルドされた C/C++ バイナリが実行されます。GCC では、指定した引数が .gcda ファイルのオブジェクトごとのファイル ディレクトリ ツリーのディレクトリ接頭辞 各.o ファイルのプロファイル情報が含まれています。

プロファイル データツリーが生成されると、プロファイル ツリーは 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 を指す必要がある llvm-profdata ツールによって準備されたプロファイル出力ファイル。.profdata が あります。

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

--[no]output_symbol_counts

有効にすると、C++実行バイナリのゴールド呼び出しリンクごとに シンボル カウント ファイル（--print-symbol-counts ゴールドを使用） オプション）。各リンカー入力について、このファイルには、 バイナリに使用されたシンボルの数などです。 この情報を使用して、不要なリンクの依存関係を追跡できます。 シンボル カウント ファイルは、バイナリの出力パスに、 [targetname].sc。

このオプションはデフォルトでは無効になっています。

--java_language_version=version

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

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

はコンパイルされ、Java 8 仕様と互換性のある構造のみが許可されます。 デフォルト値は 11 です。--&gt; 有効な値は 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 アプリケーションを実行します。

デフォルト値は localjdk です。 有効な値: localjdk、localjdk_version、 remotejdk_11、remote_jdk17。 値を拡張するには、次のいずれかの方法を使用してカスタム JVM を登録し、 local_java_repository または remote_java_repostory リポジトリ ルール。

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

このオプションを使用すると、オプション引数を Java VM に渡すことができます。使用可能な 複数の引数を指定することも可能です。例:

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

サーバー VM を使用してすべての Java バイナリを起動し、 VM の起動ヒープサイズを 256 MB に引き上げます。

--javacopt=javac-option

このオプションを使用すると、オプションの引数を javac に渡すことができます。使用可能な 複数の引数を指定することも可能です。例:

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

javac のデフォルトのデバッグ情報で java_binary が再ビルドされる （Bazel デフォルトを使用しません）。

このオプションは、Bazel の組み込みデフォルト オプションの後に javac に渡されます。 ルールごとのオプションの前に挿入します。最後の javac に対するどのオプションも優先します。javac のデフォルトのオプションは次のとおりです。

  -source 8 -target 8 -encoding UTF-8

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

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

  • 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） opt モードではデバッグ情報は生成されません ただし、--copt -g も渡す場合は除きます。

--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 オプションは、Bazel に次の動作を指示します。 extra_actions をスケジュールするターゲットのセットをフィルタします。

このフラグは、 --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]*

一時的な deps で C/C++ ライブラリをビルドする CPU android_binary ルール。他の C/C++ ルールは影響を受けません。たとえば、 cc_library は、deps ルールの推移的android_binary に出現し、 cc_binary ルールの場合、cc_library は少なくとも 2 回ビルドされます。 リクエストに対して --fat_apk_cpu で指定された CPU ごとに 1 回ずつ android_binary ルールで指定され、指定された CPU に対して 1 回、 cc_binary ルールの --cpu。

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

1 つの .so ファイルが作成され、次の APK にパッケージ化されます。 --fat_apk_cpu で指定された各 CPU。.so ファイルの名前 android_binary ルールの名前の先頭に「lib」を付けます。たとえば、 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。これはすべての .pb.cc ファイルは base というディレクトリにあります。

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

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

注意点: 一部のファイルがデバッグ シンボルを使用して選択的にコンパイルされると、シンボルが 削除される可能性があります。これを回避するには、 --strip=never。

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

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

--dynamic_mode=mode

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

モード:

  • auto: プラットフォーム依存モードに変換されます。 Linux の場合は default、cygwin の場合は off です。
  • 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 の値を使用してコンパイルします。 コード（ビルド中に実行されるツールなど）がコードに含まれるようになります。このフラグの主な目的は クロスコンパイルを有効にすることです。

--apple_crosstool_top=label

次の推移的 deps で C/C++ ルールをコンパイルするために使用するクロスツール 3 つのルールがあります。*、apple*そうしたターゲットの場合、このフラグは --crosstool_top。

--android_crosstool_top=label

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

--compiler=version

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

--android_sdk=label

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

このオプションは、bazel run に使用するベース Java インストールのラベルを設定します。 bazel テスト。java_binary とによってビルドされた Java バイナリでは、 java_test 個のルール。JAVABASE と JAVA 「メーカー」変数は、このオプションから派生します。

--host_javabase=label

このオプションは、ホスト構成で使用する Java の基本インストールのラベルを設定します。 たとえば、JavaBuilder や Singlejar などのホストビルド ツールを利用できます。

Java のコンパイルに使用する Java コンパイラは選択されません。 表示されます。コンパイラを選択するには、Python コードを --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 とニーモニック Genrule）で呼び出せます。詳しくは、 --spawn_strategy（サポートされている場合） その効果について学びました。

--strategy_regexp=&lt;filter,filter,...&gt;=&lt;strategy&gt;

このオプションでは、説明を含むコマンドを実行する際に使用する戦略を指定します。 特定のregex_filterに一致詳しくは、 --per_file_copt: regex_filter 一致。詳しくは、 --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/workspace/packagename/filename。 runfiles ツリーにより、テストがすべてのファイルにアクセスできることが保証される それ以外は何もありません。方法 runfiles ツリーは、 必要なファイルへのシンボリック リンクを提供します。リンクが増えるにつれて このオペレーションのコストは発生しますが、一部の大規模なビルドでは、 全体的なビルド時間に大きく影響します。特に、 個々のテスト（またはアプリケーション）には、独自の runfiles ツリーが必要です。

--[no]build_runfile_manifests

このオプション（デフォルトで有効）は、Runfile マニフェストを 出力ツリーに書き込む必要があります。 無効にすると、--nobuild_runfile_links を指定したことになります。

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

--[no]discard_analysis_cache

このオプションを有効にすると、Bazel は分析キャッシュを破棄します 追加のメモリを解放することが （約 10%）実行フェーズ。 デメリットは、それ以上の増分ビルドは遅くなることです。関連項目 メモリ節約モード。

--[no]keep_going（-k）

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

このオプションは通常 複数のターゲットが存在する場合、それは分析フェーズにも 指定することもできますが、指定できるのは一部のみ 正常に分析されると、ビルドはエラーで停止します。 --keep_going が指定されている場合は除きます。この場合、 ビルドは実行フェーズに進むが、ターゲット 分析できました

--[no]use_ijars

このオプションは、java_library ターゲットの方法を変更します Bazel によってコンパイルされています。出力を使用する代わりに、 java_library（依存関係をコンパイルするため） java_library ターゲットの場合、Bazel はインターフェース JAR を作成します 非プライベート メンバー（公開、 デフォルト（パッケージ）のアクセス メソッドとフィールド）を指定し、 インターフェース 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 の場合はビルド）します も指定されている場合）は、指定されたサイズのテスト ターゲットのみを実行します。テストサイズ フィルタ は、許可されるテストサイズ値（小、 （中、大、巨大）、必要に応じて先頭に「-」を付ける記号の意味は、 除外されたテストサイズです次に例を示します。

  % 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=lang[,lang]*

公式の *_test ルールを持つ言語のテスト言語のカンマ区切りリストを指定します。 （全一覧については、Build の百科事典をご覧ください）。各 言語の前に「-」を付けることもできます。「新規顧客の獲得」目標を 対応しています。各言語に使用される名前は、 *_test ルールの言語接頭辞（例: cc、java、または sh。

指定すると、Bazel がテスト（--build_tests_only の場合はビルド）します も指定されている場合）は、指定した言語のターゲットのみをテストします。

次に例を示します。

  % bazel test --test_lang_filters=cc,java foo/...

C/C++ テストと Java テストのみをテストします（ cc_test ルールと java_test ルール） foo/...では

  % bazel test --test_lang_filters=-sh,-java foo/...

foo/... のすべてのテストが実行されます。ただし、 sh_test テストと java_test テスト。

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

--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 コマンドの引数。デフォルトでは、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」）にする必要があります。表示されます。

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

Bazel は、キーを 2 つのバケット（stable）に分割します。「volatile」です。（名前が「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: ビルド時刻。形式は次のとおりです。 yyyy MMM d HH mm ss EEE（例: 2023 Jun 2 01 44 29 Fri）を UTC で表記します。

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 行が含まれ、volatile ステータス ファイルに残りの行が含まれます。

--[no]stamp

このオプションは、stamp ルール属性と組み合わせて使用して、 ビルド情報をバイナリに埋め込むことができます。

スタンプの有効 / 無効は、 stamp 属性。詳細については、Build エンサイクロペディアをご覧ください。日時 ルールで stamp = -1（*_binary ルールのデフォルト）が設定されている場合、このオプション スタンプが有効かどうかを決定します

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

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

プラットフォーム

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

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

--platforms=labels

ターゲットとするプラットフォームを記述するプラットフォーム ルールのラベル 確認できます。

--host_platform=label

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

--extra_execution_platforms=labels

アクションを実行する実行プラットフォームとして利用できるプラットフォーム。 プラットフォームは正確なターゲットで、またはターゲット パターンとして指定できます。これらの 各プラットフォームは、WORKSPACE ファイルで宣言されたものよりも先に register_execution_platforms()。

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

ツールチェーン タイプが一致した場合にツールチェーンを検索しながらデバッグ情報を出力 使用します。複数の正規表現はカンマで区切ることができます。この正規表現には、 最初に - を使用して否定します。デベロッパーにとって ツールチェーンの欠落によるデバッグエラーがある Bazel ルールまたは Starlark ルール。

その他

--flag_alias=alias_name=target_path

長い Starlark ビルド設定を短い名前にバインドするために使用されるコンビニエンス フラグ。詳細 詳しくは、 Starlark の構成。

生成されたコンビニエンス シンボリック リンクの接頭辞を変更します。「 シンボリック リンク接頭辞のデフォルト値は bazel- で、 シンボリック リンク bazel-bin、bazel-testlogs、 bazel-genfiles。

なんらかの理由でシンボリック リンクを作成できない場合は、 そのビルドは成功とみなされます。特に これにより、読み取り専用のディレクトリや、まだ作成されていないディレクトリにビルドできます。 許可する権限を制限できます。情報提供の目的で出力されるパス メッセージはビルドの最後に シンボリック リンクが想定されたものを指す場合は、シンボリック リンク相対短縮形 location言い換えれば、これらのデータの正確性を信頼して、 作成されているシンボリック リンクに依存できない場合でも同じです。

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

  • シンボリック リンクの作成を抑制する: --symlink_prefix=/ に設定すると、Bazel は シンボリック リンクを作成または更新する（bazel-out や bazel-&lt;workspace&gt; シンボリック リンク。このオプションを使用すると、シンボリック リンクの作成を完全に抑制できます。

  • すっきりする: --symlink_prefix=.bazel/ を指定すると、Bazel で 非表示のディレクトリ .bazel 内の bin などと呼ばれるシンボリック リンク。

--platform_suffix=string

構成の略称に接尾辞を追加します。接尾辞は、構成の略称として使用されます。 出力ディレクトリです。このオプションを別の値に設定すると、ファイルは たとえば、キャッシュ ヒット率を向上させるために、 他の出力ファイルを上書きするか、出力ファイルが 比較できます。

--default_visibility=(private|public)

bazel のデフォルトの公開設定の変更をテストするための一時的なフラグ。一般的な用途向けではありません 完全性のために文書化していますあります。

--[no]use_action_cache

このオプションはデフォルトで有効になっています。無効にした場合、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。

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

--check_tests_up_to_date

このオプションは、テストを実行せず、単にチェックとレポートを送信するように Bazel に指示します キャッシュに保存されたテスト結果まだ実施されていないテストがある場合 テストの結果が古く、 ソースコードやビルド オプションが変更されている場合）は、Bazel による エラー メッセージ（「テスト結果は最新ではありません」）が表示され、テストの ステータスが「ステータスなし」（色出力が有効な場合は赤色）が表示され、 ゼロ以外の終了コードが返されます

このオプションは [--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 フラグ:

  • 存在しない場合、実行が失敗するとテスト全体が失敗します。
  • 同じシャードから 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 は、タイムアウトが暗黙的に設定されていた場合と同じ値を受け取ります。 指定します。サイズ「small」のテストは「long」を宣言するタイムアウトは 有効なタイムアウトは「large」フィールドと明示的に指定されていない あります。

--test_arg=arg

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

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

  % 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

これは、次の --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_* 引数は影響します。ただし、 --test_arg です。

ビルド出力のクリーニング

clean コマンド

Bazel には、Make と同様の clean コマンドがあります。 実行されたすべてのビルド構成の出力ディレクトリが削除されます。 この Bazel インスタンス、またはこの 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 には、次の方法について質問するためのクエリ言語が ビルド中に使用された依存関係グラフ。クエリ言語は、 クエリと cquery という 2 つのコマンドで使用できます。両者の主な違いは、 2 つのコマンドは、読み込みフェーズの後にクエリが実行される Cquery は分析フェーズの後に実行されます。これらのツールは 多くの SW エンジニアリングタスクに かけがえのない貴重な支援をしています

クエリ言語は、 グラフに対する代数演算詳しくは、このモジュールの

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 を使用したビルド。 引数を指定すると、特定の引数を指定すると、 説明します。ほとんどのトピックは build などの Bazel コマンドです または 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 コマンドでは、単一の（オプションの） 次のリストに示すキーのいずれかの名前です。 この場合、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-&lt;workspace&gt; という名前のシンボリック リンク このディレクトリを指すように配置されます。

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

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

  • server_log: Bazel サーバーのデバッグ ログファイルの絶対パス。 このファイルには、 Bazel サーバーであり、Bazel デベロッパーとパワーユーザーが使用することを想定しています。

  • command_log: コマンド ログファイルの絶対パス。 これには、インターリーブされた最新の stdout および stderr ストリームが含まれます。 Bazel コマンド。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 など）。 $(CC) を使用してアクセスする変数は次のとおりです。 BUILD ファイル内では 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 のリリースラベル 「development version」などリリースしていない場合 バイナリです。バグを報告する際に非常に便利です。

bazel --version は、他の引数がなければ、 bazel version --gnu_format（開始される可能性があるという副作用を除く） Bazel サーバーまたはサーバー アーカイブの解凍です。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_s:

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

--adb=path

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

デフォルトでは、 --android_sdk。

--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 コマンドは、インスタンスのダンプを stdout に出力します。 Bazel サーバーの内部状態。このコマンドは 主に 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 コマンドは、以前に収集されたデータを分析します。 --profile オプションを使用してビルド中に実行する。Kubernetes には、 オプションを使用してビルド実行の分析を行うか、 表示されます。

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

  • --dump は、収集されたすべてのデータを 記述できます。ただし、 他の形式はまだサポートされていません。

形式の詳細と使用方法については、 プロファイリング別のパフォーマンスのトラブルシューティング

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 の仮想マシンに 後続のコマンドはこのサーバーで処理されます。すでに 起動オプションが一致しない場合、 再起動されます。

このセクションで説明するオプションはすべて、 --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 引数として解釈されますが、この機能はまもなく 非推奨です。

これは、アプリケーションが使用する JVM に影響しないこと。 サブプロセス（アプリケーション、テスト、ツールなど）が含まれます。合格 bazel run で実行するかコマンドラインで実行するかにかかわらず、実行可能な Java プログラムへの JVM オプション。 --jvm_flags 引数。これは、 すべての java_binary および java_test プログラム サポート。または、テストの場合は bazel test --test_arg=--jvm_flags=foo ... を使用します。

--host_jvm_debug

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

--autodetect_server_javabase

このオプションを使用すると、インストールされた JDK を起動時に Bazel が自動的に検索します。 組み込みの 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 サーバー プロセスをユーザーのマシンに残さないようにする 実行されません。 たとえば 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 は すぐにロックを取得できない場合は、誤って終了し、 見てみましょう。

デベロッパーはこれを 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

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

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