このページでは、bazel build
、bazel run
、bazel test
などのさまざまな Bazel コマンドで使用できるオプションについて説明します。このページは、Bazel を使用したビルドの Bazel コマンドのリストに対応するものです。
ターゲットの構文
build
や test
などの一部のコマンドは、ターゲットのリストに対して操作できます。ラベルよりも柔軟な構文を使用します。これは、ビルドするターゲットの指定で説明されています。
オプション
以下のセクションでは、ビルド中に使用できるオプションについて説明します。ヘルプコマンドで --long
を使用すると、オンライン ヘルプ メッセージに、各オプションの意味、タイプ、デフォルト値に関する概要情報が表示されます。
ほとんどのオプションは 1 回のみ指定できます。複数回指定すると、最後のインスタンスが優先します。複数回指定できるオプションは、オンライン ヘルプで「複数回使用可能」というテキストで示されています。
パッケージの場所
--package_path
警告: --package_path
オプションは非推奨になりました。Bazel では、メイン リポジトリのパッケージがワークスペースのルートにあることを推奨しています。
このオプションは、特定のパッケージの BUILD ファイルを検索するために検索されるディレクトリのセットを指定します。
Bazel は、パッケージパスを検索してパッケージを見つけます。これは、各部分ソースツリーのルートである Bazel ディレクトリのコロンで区切られた順序付きリストです。
--package_path
オプションを使用してカスタム パッケージ パスを指定するには:
% bazel build --package_path %workspace%:/some/other/root
パッケージパス要素は、次の 3 つの形式で指定できます。
- 最初の文字が
/
の場合、パスは絶対パスです。 - パスが
%workspace%
で始まる場合、パスは最も近いバゼル ディレクトリを基準として相対的に取られます。たとえば、作業ディレクトリが/home/bob/clients/bob_client/bazel/foo
の場合、package-path の文字列%workspace%
は/home/bob/clients/bob_client/bazel
に展開されます。 - それ以外は、作業ディレクトリを基準とする相対パスになります。通常、これは意図した動作ではなく、Bazel ワークスペースの下のディレクトリから Bazel を使用すると、予期しない動作をする可能性があります。たとえば、package-path 要素
.
を使用して/home/bob/clients/bob_client/bazel/foo
ディレクトリに cd すると、パッケージは/home/bob/clients/bob_client/bazel/foo
ディレクトリから解決されます。
デフォルト以外のパッケージパスを使用する場合は、便宜上、Bazel 構成ファイルで指定します。
Bazel では、現在のディレクトリにパッケージが存在する必要はありません。そのため、必要なすべてのパッケージがパッケージパスのどこかに見つかれば、空の bazel ワークスペースからビルドできます。
例: 空のクライアントからビルドする
% mkdir -p foo/bazel % cd foo/bazel % touch MODULE.bazel % bazel build --package_path /some/other/path //foo
--deleted_packages
このオプションでは、Bazel が削除されたと見なすパッケージのカンマ区切りリストを指定します。このリストに指定されたパッケージは、パッケージパスのディレクトリから読み込まれません。これを使用して、パッケージを実際に削除せずにパッケージの削除をシミュレートできます。このオプションは複数回渡すことができます。この場合、個々のリストが連結されます。
エラーチェック
これらのオプションは、Bazel のエラーチェックや警告を制御します。
--[no]check_visibility
このオプションを false に設定した場合、公開設定チェックは警告に降格されます。 このオプションのデフォルト値は true であるため、デフォルトで可視性のチェックが実行されます。
--output_filter=regex
--output_filter
オプションでは、正規表現に一致するターゲットのビルドとコンパイルの警告のみが表示されます。ターゲットが指定された正規表現と一致せず、その実行が成功すると、標準出力と標準エラーが破棄されます。
このオプションの一般的な値は次のとおりです。
`--output_filter='^//(first/project|second/project):'` | 指定したパッケージの出力を表示します。 |
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'` | 指定したパッケージの出力を表示しません。 |
`--output_filter=` | すべて表示。 |
`--output_filter=DONT_MATCH_ANYTHING` | 何も表示しない。 |
ツールのフラグ
これらのオプションは、Bazel が他のツールに渡すオプションを制御します。
--copt=cc-option
このオプションは、コンパイラに渡す引数を取ります。 この引数は、C、C++、またはアセンブラ コードの前処理、コンパイル、アセンブルのために呼び出されるたびにコンパイラに渡されます。リンク時に渡されることはありません。
このオプションは複数回使用できます。例:
% bazel build --copt="-g0" --copt="-fpic" //foo
デバッグ テーブルなしで foo
ライブラリをコンパイルし、位置に依存しないコードを生成します。
--host_copt=cc-option
このオプションは、exec 構成でコンパイルされるソースファイルのコンパイラに渡す引数を受け取ります。これは --copt
オプションに似ていますが、exec 構成にのみ適用されます。
--host_conlyopt=cc-option
このオプションは、exec 構成でコンパイルされる C ソースファイルのコンパイラに渡す引数を受け取ります。これは --conlyopt
オプションに似ていますが、exec 構成にのみ適用されます。
--host_cxxopt=cc-option
このオプションは、exec 構成でコンパイルされる C++ ソースファイルのコンパイラに渡す引数を受け取ります。これは --cxxopt
オプションに似ていますが、exec 構成にのみ適用されます。
--host_linkopt=linker-option
このオプションは、exec 構成でコンパイルされたソースファイルのリンカーに渡される引数を受け取ります。これは --linkopt
オプションに似ていますが、exec 構成にのみ適用されます。
--conlyopt=cc-option
このオプションは、C ソースファイルをコンパイルするときにコンパイラに渡す引数を受け取ります。
これは --copt
に似ていますが、C コンパイルにのみ適用され、C++ コンパイルやリンクには適用されません。そのため、--conlyopt
を使用して C 固有のオプション(-Wno-pointer-sign
など)を渡すことができます。
--cxxopt=cc-option
このオプションは、C++ ソースファイルをコンパイルするときにコンパイラに渡す引数を受け取ります。
これは --copt
と似ていますが、C++ コンパイルにのみ適用され、C コンパイルとリンクには適用されません。そのため、--cxxopt
を使用して C++ 固有のオプション(-fpermissive
や -fno-implicit-templates
など)を渡すことができます。
例:
% bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code
--linkopt=linker-option
このオプションは、リンク時にコンパイラに渡される引数を受け取ります。
これは --copt
に似ていますが、コンパイルにではなく、リンクにのみ適用されます。そのため、--linkopt
を使用して、リンク時にのみ意味のあるコンパイラ オプション(-lssp
や -Wl,--wrap,abort
など)を渡すことができます。例:
% bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code
ビルドルールでは、属性にリンク オプションを指定することもできます。このオプションの設定が常に優先されます。cc_library.linkopts もご覧ください。
--strip (always|never|sometimes)
このオプションは、-Wl,--strip-debug
オプションを指定してリンカーを呼び出すことで、Bazel がすべてのバイナリと共有ライブラリからデバッグ情報を削除するかどうかを決定します。--strip=always
は、デバッグ情報を常に削除することを意味します。--strip=never
は、デバッグ情報を削除しないことを意味します。デフォルト値の --strip=sometimes
は、--compilation_mode
が fastbuild
の場合に削除することを意味します。
% bazel build --strip=always //foo:bar
は、生成されたすべてのバイナリからデバッグ情報を削除しながら、ターゲットをコンパイルします。
Bazel の --strip
オプションは ld の --strip-debug
オプションに対応しています。デバッグ情報のみが削除されます。なんらかの理由で、デバッグ シンボルだけでなくすべてのシンボルを削除する場合は、ld の --strip-all
オプションを使用する必要があります。これは、--linkopt=-Wl,--strip-all
を Bazel に渡します。また、Bazel の --strip
フラグを設定すると --linkopt=-Wl,--strip-all
がオーバーライドされるため、どちらか一方のみを設定する必要があります。
1 つのバイナリのみをビルドし、すべてのシンボルを削除する場合は、--stripopt=--strip-all
を渡して、ターゲットの //foo:bar.stripped
バージョンを明示的にビルドすることもできます。--stripopt
のセクションで説明したように、これは、ビルドのすべてのリンク アクションに削除を含めるのではなく、最終バイナリがリンクされた後に削除アクションを適用します。
--stripopt=strip-option
これは、*.stripped
バイナリを生成するときに strip
コマンドに渡す追加オプションです。デフォルトは -S -p
です。このオプションは複数回使用できます。
--fdo_instrument=profile-output-dir
--fdo_instrument
オプションを使用すると、ビルドされた C/C++ バイナリが実行されたときに FDO(フィードバック指向の最適化)プロファイル出力を生成できます。GCC の場合、指定された引数は、各 .o ファイルのプロファイル情報を含む .gcda ファイルのオブジェクトごとのファイル ディレクトリ ツリーのディレクトリ接頭辞として使用されます。
プロファイル データツリーが生成されたら、そのプロファイル ツリーを圧縮して --fdo_optimize=profile-zip
Bazel オプションに提供し、FDO に最適化されたコンパイルを有効にします。
LLVM コンパイラの場合、この引数は、未加工の LLVM プロファイル データ ファイルがダンプされるディレクトリでもあります。例: --fdo_instrument=/path/to/rawprof/dir/
。
--fdo_instrument
オプションと --fdo_optimize
オプションを同時に使用することはできません。
--fdo_optimize=profile-zip
--fdo_optimize
オプションを使用すると、オブジェクト ファイルごとのプロファイル情報を使用して、コンパイル時に FDO(フィードバック指向の最適化)を実行できます。GCC の場合、指定された引数は、各 .o ファイルのプロファイル情報を含む .gcda ファイルのファイルツリーが含まれている zip ファイルです。
また、指定された引数は、拡張子 .afdo で識別される自動プロファイルを指すことができます。
LLVM コンパイラの場合、指定された引数は、llvm-profdata ツールによって準備されたインデックス付き LLVM プロファイル出力ファイルを指す必要があります。また、拡張子は .profdata にする必要があります。
オプション --fdo_instrument
と --fdo_optimize
を同時に使用することはできません。
--java_language_version=version
このオプションでは、Java ソースのバージョンを指定します。例:
% bazel build --java_language_version=8 java/com/example/common/foo:all
コンパイルし、Java 8 仕様と互換性のあるコンストラクトのみを許可します。デフォルト値は 11 です。-->
有効な値は 8、9、10、11、17、21 です。default_java_toolchain
を使用してカスタム Java ツールチェーンを登録することで、拡張できます。
--tool_java_language_version=version
ビルド中に実行されるツールのビルドに使用される Java 言語バージョン。デフォルト値は 11 です。
--java_runtime_version=version
このオプションは、コードの実行とテストの実行に使用する JVM のバージョンを指定します。次に例を示します。
% bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application
リモート リポジトリから JDK 11 をダウンロードし、それを使用して Java アプリケーションを実行します。
デフォルト値は local_jdk
です。有効な値は local_jdk
、local_jdk_version
、remotejdk_11
、remotejdk_17
、remotejdk_21
です。値を拡張するには、local_java_repository
または remote_java_repository
リポジトリ ルールを使用してカスタム JVM を登録します。
--tool_java_runtime_version=version
ビルド中に必要なツールの実行に使用される JVM のバージョン。デフォルト値は remotejdk_11
です。
--jvmopt=jvm-option
このオプションを使用すると、オプション引数を Java VM に渡すことができます。1 つの大きな引数で使用することも、個別の引数で複数回使用することもできます。例:
% bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all
サーバー VM を使用してすべての Java バイナリを起動し、VM の起動ヒープサイズを 256 MB に設定します。
--javacopt=javac-option
このオプションを使用すると、オプション引数を javac に渡すことができます。1 つの大きな引数で使用することも、個別の引数で複数回使用することもできます。例:
% bazel build --javacopt="-g:source,lines" //myprojects:prog
は、javac のデフォルトのデバッグ情報(bazel のデフォルトではなく)を使用して java_binary を再ビルドします。
このオプションは、javac の Bazel 組み込みデフォルト オプションの後、ルールごとのオプションの前に javac に渡されます。javac へのオプションの最後の仕様が優先されます。javac のデフォルトのオプションは次のとおりです。
-source 8 -target 8 -encoding UTF-8
--strict_java_deps (default|strict|off|warn|error)
このオプションは、javac が直接依存関係の欠落を確認するかどうかを制御します。Java ターゲットでは、直接使用されるすべてのターゲットを明示的に依存関係として宣言する必要があります。このフラグは、各 java ファイルの型チェックに実際に使用された jar を特定し、現在のターゲットの直接的な依存関係の出力でない場合は警告/エラーを示すように javac に指示します。
off
は、チェックが無効であることを意味します。warn
は、javac が不足している直接依存関係ごとに[strict]
タイプの標準 Java 警告を生成することを意味します。default
、strict
、error
はすべて、javac が警告ではなくエラーを生成することを意味します。不足している直接依存関係が見つかった場合、現在のターゲットのビルドは失敗します。これは、フラグが指定されていない場合のデフォルトの動作でもあります。
ビルド セマンティクス
これらのオプションは、ビルドコマンドや出力ファイルの内容に影響します。
--compilation_mode (fastbuild|opt|dbg)
(-c)
--compilation_mode
オプション(多くの場合、-c
と短縮されます。特に -c opt
と省略されます)は、fastbuild
、dbg
、または opt
の引数を取り、最適化レベルやデバッグ テーブルの完全性など、さまざまな C/C++ コード生成オプションに影響します。Bazel では、コンパイル モードごとに異なる出力ディレクトリが使用されるため、毎回完全な再ビルドを行わなくても、モードを切り替えることができます。
fastbuild
は、できるだけ速くビルドすることを意味します。最小限のデバッグ情報(-gmlt -Wl,-S
)を生成し、最適化は行いません。これがデフォルトです。注:-DNDEBUG
は設定されません。dbg
は、デバッグを有効にしてビルドすることを意味します(-g
)。これにより、gdb(または別のデバッガ)を使用できます。opt
は、最適化を有効にしてassert()
呼び出しを無効にしたビルド(-O2 -DNDEBUG
)を意味します。--copt -g
も渡さない限り、opt
モードではデバッグ情報は生成されません。
--cpu=cpu
このオプションは、ビルド中にバイナリのコンパイルに使用するターゲット CPU アーキテクチャを指定します。
--action_env=VAR=VALUE
すべてのアクションの実行中に使用できる環境変数のセットを指定します。変数は名前で指定できます。この場合、値は呼び出し環境から取得されます。また、name=value
ペアで指定することもできます。この場合、値は呼び出し環境から独立して設定されます。
この --action_env
フラグは複数回指定できます。複数の --action_env
フラグで同じ変数に値が割り当てられている場合は、最新の割り当てが優先されます。
--experimental_action_listener=label
experimental_action_listener
オプションは、label で指定された action_listener
ルールの詳細を使用して、extra_actions
をビルドグラフに挿入するよう Bazel に指示します。
--[no]experimental_extra_action_top_level_only
このオプションを true に設定した場合、 --experimental_action_listener
コマンドライン オプションで指定された追加のアクションは、トップレベル ターゲットに対してのみスケジュールされます。
--experimental_extra_action_filter=regex
experimental_extra_action_filter
オプションは、extra_actions
のスケジュールを設定するターゲットセットをフィルタするように Bazel に指示します。
このフラグは、--experimental_action_listener
フラグと組み合わせてのみ適用されます。
デフォルトでは、リクエストされたビルド対象の推移閉包内のすべての extra_actions
が実行のスケジュールに登録されます。--experimental_extra_action_filter
は、所有者のラベルが指定された正規表現に一致する extra_actions
にスケジューリングを制限します。
次の例では、所有者のラベルに「/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 プラットフォームを定義して使用する必要があります。
--android_platforms
で指定されたプラットフォームごとに 1 つの .so
ファイルが作成され、APK にパッケージ化されます。.so
ファイルの名前は、android_binary
ルールの名前の先頭に「lib」を付けます。たとえば、android_binary
の名前が「foo」の場合、ファイルは libfoo.so
です。
--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...
存在する場合、包含正規表現のいずれかに一致し、除外正規表現のいずれにも一致しないラベルまたは実行パスを持つ C++ ファイルは、指定されたオプションでビルドされます。ラベルの照合では、正規形式のラベル(//package
:label_name
など)を使用します。
実行パスは、C++ ファイルのベース名(拡張子を含む)を含むワークスペース ディレクトリへの相対パスです。また、プラットフォームに依存するプレフィックスも含まれます。
生成されたファイル(genrule の出力など)と一致させるには、Bazel は実行パスのみを使用できます。この場合、実行パスと一致しないため、正規表現を「//」で始めることはできません。パッケージ名は --per_file_copt=base/.*\.pb\.cc@-g0
のように使用できます。これにより、base
というディレクトリ内のすべての .pb.cc
ファイルが一致します。
このオプションは複数回使用できます。
このオプションは、使用するコンパイル モードに関係なく適用されます。たとえば、--compilation_mode=opt
でコンパイルし、より強力な最適化を有効にしたファイルや、最適化を無効にしたファイルを個別にコンパイルできます。
注意点: 一部のファイルがデバッグ シンボルを使用して選択的にコンパイルされると、リンク中にシンボルが削除される可能性があります。この問題は、--strip=never
を設定することで回避できます。
構文: [+-]regex[,[+-]regex]...@option[,option]...
。ここで、regex
は正規表現を表します。この正規表現の前に +
を追加すると、含めるパターンを識別できます。-
を追加すると、除外するパターンを識別できます。option
は、C++ コンパイラに渡される任意のオプションを表します。オプションに ,
が含まれている場合は、\,
のように引用符で囲む必要があります。正規表現とオプションを区切るために使用されるのは最初の @
のみであるため、オプションに @
を含めることもできます。
例: --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs
は、file.cc
を除く //foo/
内のすべての .cc
ファイルに対して、C++ コンパイラのコマンドラインに -O0
オプションと -fprofile-arcs
オプションを追加します。
--dynamic_mode=mode
ビルドルールの linkstatic 属性と連携して、C++ バイナリを動的にリンクするかどうかを決定します。
モード:
default
: 動的にリンクするかどうかを Bazel が選択できるようにします。詳細については、linkstatic をご覧ください。fully
: すべてのターゲットを動的にリンクします。これにより、リンク時間が短縮され、生成されるバイナリのサイズが小さくなります。off
: すべてのターゲットをほとんど静的モードでリンクします。linkopts で-static
が設定されている場合、ターゲットは完全に静的になります。
--fission (yes|no|[dbg][,opt][,fastbuild])
Fission を有効にします。Fission は C++ デバッグ情報を .o ファイルではなく専用の .dwo ファイルに書き込みます。これにより、リンクへの入力サイズが大幅に削減され、リンク時間を短縮できます。
[dbg][,opt][,fastbuild]
に設定した場合(例: --fission=dbg,fastbuild
)、Fission は指定されたコンパイルモードのセットでのみ有効になります。これは bazelrc 設定に役立ちます。yes
に設定すると、Fission が普遍的に有効になります。no
に設定すると、Fission は普遍的に無効になります。デフォルトは no
です。
--force_ignore_dash_static
このフラグが設定されている場合、cc_*
ルールの BUILD ファイルの linkopts の -static
オプションは無視されます。これは、C++ 強化ビルドの回避策としてのみ使用してください。
--[no]force_pic
有効にすると、すべての C++ コンパイルで位置独立コード(「-fPIC」)が生成され、リンクでは PIC 以外のライブラリよりも PIC ビルド済みライブラリが優先され、リンクで位置独立実行可能ファイル(「-pie」)が生成されます。デフォルトは無効になっています。
--android_resource_shrinking
android_binary ルールに対してリソース圧縮を実行するかどうかを選択します。android_binary ルールの shrink_resources 属性のデフォルトを設定します。詳細については、そのルールのドキュメントをご覧ください。デフォルトはオフです。
--custom_malloc=malloc-library-target
指定した場合は、常に指定された malloc 実装を使用し、すべての malloc="target"
属性をオーバーライドします(malloc
を指定しないでデフォルトを使用するターゲットを含む)。
--crosstool_top=label
このオプションは、ビルド中のすべての C++ コンパイルに使用するクロスツール コンパイラ スイートの場所を指定します。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 関連のルールのビルドに使用する Android SDK/プラットフォーム ツールチェーンと Android ランタイム ライブラリを指定します。
WORKSPACE ファイルで android_sdk_repository
ルールが定義されている場合、Android SDK が自動的に選択されます。
--java_toolchain=label
NOP。下位互換性のためだけに保持されています。
--host_java_toolchain=label
NoOps。下位互換性のためにのみ保持されます。
--javabase=(label)
NoOps。下位互換性のためにのみ保持されます。
--host_javabase=label
NOP。下位互換性のためだけに保持されています。
実行戦略
これらのオプションは、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
はsandboxed
戦略で「Compiling //foo/bar/baz」を実行しますが、順序を逆にするとlocal
で実行されます。 - 例:
--strategy_regexp='Compiling.*/bar=local,sandboxed'
はlocal
戦略で「Compiling //foo/bar/baz」を実行し、失敗した場合はsandboxed
にフォールバックします。
--genrule_strategy=strategy
これは --strategy=Genrule=strategy
の非推奨の省略形です。
--jobs=n
(-j)
このオプションは整数の引数を取り、ビルドの実行フェーズで同時に実行するジョブ数の上限を指定します。
--progress_report_interval=n
Bazel は、まだ完了していないジョブ(長時間実行のテストなど)に関する進行状況レポートを定期的に出力します。このオプションはレポートの頻度を設定します。進捗状況は n
秒ごとに出力されます。
デフォルトは 0 で、増分アルゴリズムです。最初のレポートは 10 秒後に出力され、次に 30 秒後に出力され、その後は 1 分ごとに出力されます。
bazel がカーソル コントロールを使用している場合(--curses
で指定)、進行状況は 1 秒ごとに報告されます。
--local_{ram,cpu}_resources resources or resource expression
これらのオプションでは、ローカルで実行するビルド アクティビティとテスト アクティビティのスケジュール設定時に Bazel が考慮できるローカル リソースの量(RAM(MB)と CPU 論理コア数)を指定します。整数またはキーワード(HOST_RAM または HOST_CPUS)を指定します。必要に応じて、[-|*
浮動小数点数]
(--local_cpu_resources=2
、--local_ram_resources=HOST_RAM*.5
、--local_cpu_resources=HOST_CPUS-1
など)を指定します。フラグは独立しており、1 つまたは両方を設定できます。デフォルトでは、Bazel はローカル システムの構成から RAM の量と CPU コア数を直接推定します。
--[no]build_runfile_links
このオプションはデフォルトで有効になっています。テストとバイナリの runfile シンボリック リンクを出力ディレクトリにビルドするかどうかを指定します。--nobuild_runfile_links
を使用すると、ランファイル ツリーをビルドするオーバーヘッドが発生することなく、すべてのターゲットがコンパイルされるかどうかを検証できます。
テスト(またはアプリケーション)が実行されると、そのランタイム データの依存関係が 1 か所に集められます。Bazel の出力ツリー内では、この「runfiles」ツリーは通常、対応するバイナリまたはテストの兄弟としてルートされます。テスト実行中、runfile には $TEST_SRCDIR/canonical_repo_name/packagename/filename
形式のパスを使用してアクセスできます。runfiles ツリーにより、テストは宣言された依存関係を持つすべてのファイルにアクセスできます。デフォルトでは、必要なファイルへのシンボリック リンクのセットを構築することで、runfiles ツリーが実装されます。リンクのセットが大きくなると、このオペレーションのコストも増加します。大規模なビルドでは、テスト(またはアプリケーション)ごとに独自の runfile ツリーが必要になるため、ビルド時間全体に著しく影響する可能性があります。
--[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
このオプションを使用すると、Bazel による java_library
ターゲットのコンパイル方法が変更されます。Bazel は、依存する java_library
ターゲットのコンパイルに java_library
の出力を使用する代わりに、非公開でないメンバーの署名(public、Protected、デフォルト(パッケージ)のアクセス メソッドとフィールド)のみを含むインターフェース JAR を作成し、そのインターフェース JAR を使用して依存ターゲットをコンパイルします。これにより、クラスのメソッド本体またはプライベート メンバーにのみ変更を加えた場合に、再コンパイルを回避できます。
--[no]interface_shared_objects
このオプションを使用すると、インターフェース共有オブジェクトが有効になり、バイナリや他の共有ライブラリは、共有オブジェクトの実装ではなく、そのインターフェースに依存するようになります。実装のみが変更された場合、Bazel は変更された共有ライブラリに依存するターゲットを不必要に再ビルドしないようにできます。
出力の選択
これらのオプションは、ビルドまたはテストする内容を決定します。
--[no]build
このオプションを使用すると、ビルドの実行フェーズが実行されます。デフォルトでオンになっています。オフにすると、実行フェーズはスキップされ、最初の 2 つのフェーズ(読み込みと分析)のみが実行されます。
このオプションは、実際にビルドせずに BUILD ファイルを検証し、入力のエラーを検出する場合に便利です。
--[no]build_tests_only
指定すると、Bazel は、サイズ、タイムアウト、タグ、言語が原因でフィルタされなかった *_test
ルールと test_suite
ルールの実行に必要なものだけをビルドします。指定した場合、Bazel はコマンドラインで指定された他のターゲットを無視します。
デフォルトでは、このオプションは無効になっており、テストから除外された *_test
ルールと test_suite
ルールを含む、リクエストされたすべてのものが Bazel によってビルドされます。これは、bazel test --build_tests_only foo/...
の実行で foo
ツリー内のすべてのビルドの破損が検出されない可能性があるため便利です。
--[no]check_up_to_date
このオプションを使用すると、Bazel はビルドを実行せず、指定されたすべてのターゲットが最新かどうかをチェックするだけです。その場合、通常どおりビルドが正常に完了します。ただし、ファイルが古い場合、ビルドされる代わりにエラーが報告され、ビルドは失敗します。このオプションは、ビルドの費用を発生させることなく、ビルドがソース編集よりも最近に実行されたかどうかを判断する場合に役立ちます(送信前のチェックなど)。
--check_tests_up_to_date
もご覧ください。
--[no]compile_one_dependency
引数ファイルの単一の依存関係をコンパイルします。これは、IDE でソースファイルの構文チェックを行う場合に便利です。たとえば、ソースファイルに依存する単一のターゲットを再ビルドして、編集/ビルド/テスト サイクルでできるだけ早くエラーを検出できます。この引数は、フラグ以外のすべての引数の解釈方法に影響します。各引数は、現在の作業ディレクトリを基準とするファイル ターゲット ラベルまたはプレーンなファイル名にする必要があります。また、各ソースファイル名に依存する 1 つのルールが作成されます。C++ ソースと Java ソースの場合、同じ言語空間内のルールが優先的に選択されます。優先度が同じ複数のルールがある場合は、BUILD ファイルで最初に出現するルールが選択されます。ソースファイルを参照しない明示的に指定されたターゲット パターンは、エラーになります。
--save_temps
--save_temps
オプションを使用すると、コンパイラからの一時出力が保存されます。これには、.s ファイル(アセンブラ コード)、.i(プリプロセッサ処理済み C)、.ii(プリプロセッサ処理済み C++)ファイルが含まれます。これらの出力は、デバッグに役立ちます。テンプレートは、コマンドラインで指定されたターゲット セットに対してのみ生成されます。
--save_temps
フラグは現在、cc_* ルールでのみ機能します。
Bazel が追加の出力ファイルの場所を出力するようにするには、--show_result n
の設定が十分に高いことを確認します。
--build_tag_filters=tag[,tag]*
指定すると、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 は、必須タグが 1 つ以上(いずれかが指定されている場合)あり、除外タグが含まれていないテストターゲットのみをテストします(--build_tests_only
も指定されている場合はビルドします)。テストタグ フィルタは、タグキーワードのカンマ区切りのリストとして指定します。必要に応じて、除外タグを示す「-」記号を先頭に追加します。必須タグの前に「+」記号を付けることもできます。
次に例を示します。
% bazel test --test_tag_filters=performance,stress,-flaky //myproject:all
performance
タグまたは stress
タグが付いているが、flaky
タグが付いていないターゲットをテストします。
デフォルトでは、テストタグのフィルタリングは適用されません。この方法で、テストの size
タグと local
タグでフィルタリングすることもできます。
--test_lang_filters=string[,string]*
テストルール クラスの名前を参照する文字列のカンマ区切りリストを指定します。ルールクラス foo_test
を参照するには、文字列「foo」を使用します。Bazel は、参照されたルールクラスのターゲットのみをテストします(--build_tests_only
も指定されている場合はビルドします)。これらのターゲットを除外するには、文字列「-foo」を使用します。次に例を示します。
% bazel test --test_lang_filters=foo,bar //baz/...
//baz/...
内の foo_test
または bar_test
のインスタンスであるターゲットのみがテストされますが、
% bazel test --test_lang_filters=-foo,-bar //baz/...
は、foo_test
インスタンスと bar_test
インスタンスを除く、//baz/...
内のすべてのターゲットをテストします。
--test_filter=filter-expression
テストランナーが実行するテストのサブセットの選択に使用できるフィルタを指定します。呼び出しで指定されたすべてのターゲットがビルドされますが、式によっては一部のターゲットのみ実行される場合があります。また、特定のテストメソッドのみが実行される場合もあります。
filter-expression の特定の解釈は、テストを実行するテスト フレームワークによって異なります。グロブ、サブ文字列、正規表現にすることができます。--test_filter
は、さまざまな --test_arg
フィルタ引数を渡すよりも便利ですが、すべてのフレームワークがサポートしているわけではありません。
読み上げの詳細設定
これらのオプションは、ターミナルまたは追加のログファイルへの Bazel の出力の詳細度を制御します。
--explain=logfile
このオプションはファイル名引数を必要とし、bazel build
の実行フェーズの依存関係チェッカーによって、各ビルドステップについて、実行されている理由または最新の状態が説明されます。説明は logfile に書き込まれます。
予期しない再ビルドが発生した場合は、このオプションを使用して原因を把握できます。これを .bazelrc
に追加して後続のすべてのビルドでロギングが行われるようにし、実行ステップが予期せず実行された場合はログを調べます。このオプションを使用するとパフォーマンスが若干低下する可能性があるため、不要になった場合は削除することをおすすめします。
--verbose_explanations
このオプションを使用すると、--explain オプションが有効になっているときに生成される説明の詳細度が増加します。
特に、詳細な説明が有効になっていて、出力ファイルの作成に使用されたコマンドが変更されたために出力ファイルが再ビルドされた場合、説明ファイルの出力には、新しいコマンドの詳細がすべて含まれます(少なくともほとんどのコマンドについて)。
このオプションを使用すると、生成される説明ファイルの長さと、--explain
の使用によるパフォーマンスの低下が大幅に増加する可能性があります。
--explain
が有効になっていない場合、--verbose_explanations
は効果がありません。
--profile=file
このオプションはファイル名引数を受け取ります。これにより、Bazel はプロファイリング データをファイルに書き込みます。その後、bazel analyze-profile
コマンドを使用してデータを分析または解析できます。ビルド プロファイルは、Bazel の build
コマンドが時間をかけている場所を把握するのに役立ちます。
--[no]show_loading_progress
このオプションを使用すると、Bazel はパッケージの読み込みの進行状況メッセージを出力します。無効になっている場合、メッセージは表示されません。
--[no]show_progress
このオプションをオンにすると、進行状況メッセージが表示されます。デフォルトでオンになっています。無効にすると、進行状況メッセージが抑制されます。
--show_progress_rate_limit=n
このオプションを使用すると、bazel は n
秒ごとに最大 1 つの進行状況メッセージを表示します。ここで、n は実数です。このオプションのデフォルト値は 0.02 です。つまり、bazel は進行状況メッセージを 0.02 秒ごとに 1 つに制限します。
--show_result=n
このオプションは、bazel build
コマンドの終了時に結果情報を出力するかどうかを制御します。デフォルトでは、単一のビルド ターゲットが指定されている場合、Bazel は、ターゲットが正常に更新されたかどうか、更新された場合はターゲットが作成した出力ファイルのリストを示すメッセージを出力します。複数のターゲットが指定されている場合、結果情報は表示されません。
結果情報は、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
を渡して、コマンドの引数を 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 つのバケットに分割します。(「安定」と「揮発性」という名前は直感に反しているため、あまり気にしないでください)。
Bazel は、Key-Value ペアを次の 2 つのファイルに書き込みます。
bazel-out/stable-status.txt
には、キー名がSTABLE_
で始まるすべてのキーと値が含まれます。bazel-out/volatile-status.txt
には、残りのキーとその値が含まれます。
契約は次のとおりです。
「安定」なキーの値は、可能であれば変更しないでください。
bazel-out/stable-status.txt
の内容が変更されると、Bazel はそれに依存するアクションを無効にします。つまり、安定したキーの値が変更されると、Bazel はスタンプされたアクションを再実行します。したがって、安定したステータスにはタイムスタンプなどの値を含めないでください。タイムスタンプは常に変化し、Bazel はビルドごとにスタンプ付きアクションを再実行するためです。Bazel は常に次の安定したキーを出力します。
BUILD_EMBED_LABEL
:--embed_label
の値BUILD_HOST
: Bazel が実行されているホストマシンの名前BUILD_USER
: Bazel が実行されているユーザーの名前
「揮発性」キーの値は頻繁に変更される可能性があります。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 では、--workspace_status_command=/bin/true
を渡してワークスペースのステータスの取得を無効にできます。これは、true
は何も実行せず(ゼロで終了し)、出力を表示しないためです。Windows では、MSYS の true.exe
のパスを渡して同じ効果を得ることができます。
なんらかの理由でワークスペースのステータス コマンドが失敗した場合(ゼロ以外の値で終了した場合)、ビルドは失敗します。
Git を使用した Linux のプログラムの例:
#!/bin/bash echo "CURRENT_TIME $(date +%s)" echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)" echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)" echo "STABLE_USER_NAME $USER"
このプログラムのパスを --workspace_status_command
で渡すと、安定したステータス ファイルには STABLE 行が含まれ、残りの行は揮発性のステータス ファイルに含まれます。
--[no]stamp
このオプションは、stamp
ルール属性と組み合わせて、ビルド情報をバイナリに埋め込むかどうかを制御します。
スタンプは、stamp
属性を使用してルールごとに明示的に有効または無効にできます。詳しくは、Build Encyclopedia をご覧ください。ルールで stamp = -1
(*_binary
ルールのデフォルト)が設定されている場合、このオプションによってスタンプが有効かどうかが決まります。
Bazel は、このオプションや stamp
属性に関係なく、exec 構成用にビルドされたバイナリにスタンプを押すことはありません。stamp =
0
(*_test
ルールのデフォルト)を設定するルールの場合、--[no]stamp
に関係なくスタンプが無効になります。--stamp
を指定しても、依存関係が変更されていない場合、ターゲットの再ビルドは強制されません。
一般に、--nostamp
を設定すると、入力の不安定性が軽減され、ビルド キャッシュが最大化されるため、ビルドのパフォーマンスが向上します。
プラットフォーム
これらのオプションを使用すると、ビルドの動作を構成するホスト プラットフォームとターゲット プラットフォームを制御し、Bazel ルールで使用できる実行プラットフォームとツールチェーンを制御できます。
--platforms=labels
現在のコマンドのターゲット プラットフォームを記述するプラットフォーム ルールのラベル。
--host_platform=label
ホストシステムを記述するプラットフォーム ルールのラベル。
--extra_execution_platforms=labels
アクションの実行に使用できる実行プラットフォーム。プラットフォームは、完全なターゲットまたはターゲット パターンとして指定できます。これらのプラットフォームは、register_execution_platforms() によって MODULE.bazel ファイルで宣言されたプラットフォームよりも前に考慮されます。このオプションでは、優先順位順にプラットフォームをカンマ区切りのリストで指定できます。フラグが複数回渡された場合は、最新のフラグがオーバーライドされます。
--extra_toolchains=labels
ツールチェーン解決時に考慮されるツールチェーン ルール。ツールチェーンは、正確なターゲットまたはターゲット パターンで指定できます。これらのツールチェーンは、register_toolchains() によって MODULE.bazel ファイルで宣言されたツールチェーンの前に考慮されます。
--toolchain_resolution_debug=regex
ツールチェーンタイプが正規表現と一致する場合、ツールチェーンを検索するときにデバッグ情報を出力します。複数の正規表現をカンマで区切って指定できます。正規表現を否定するには、先頭に -
を使用します。これは、ツールチェーンの不足が原因で失敗した Bazel ルールまたは Starlark ルールのデバッグに役立ちます。
その他
--flag_alias=alias_name=target_path
長い Starlark ビルド設定を短い名前にバインドするために使用される便利なフラグ。詳細については、Starlark 構成をご覧ください。
--symlink_prefix=string
生成される便利なシンボリック リンクの接頭辞を変更します。シンボリック リンク プレフィックスのデフォルト値は bazel-
です。これにより、シンボリック リンク bazel-bin
、bazel-testlogs
、bazel-genfiles
が作成されます。
なんらかの理由でシンボリック リンクを作成できない場合は、警告が出されますが、ビルドは成功と見なされます。特に、読み取り専用ディレクトリや書き込み権限のないディレクトリをビルドできます。ビルドの完了時に情報メッセージに出力されたパスは、シンボリック リンクが想定された場所を指している場合のみ、シンボリック リンク相対短縮形を使用します。つまり、作成されるシンボリック リンクに依存できない場合でも、これらのパスの正確性を信頼できます。
このオプションの一般的な値は次のとおりです。
シンボリック リンクの作成を抑制:
--symlink_prefix=/
を使用すると、Bazel はbazel-out
シンボリック リンクやbazel-<workspace>
シンボリック リンクなど、シンボリック リンクを作成または更新しません。このオプションを使用すると、シンボリック リンクの作成を完全に抑制できます。混乱を軽減:
--symlink_prefix=.bazel/
を使用すると、Bazel は非表示のディレクトリ.bazel
内にbin
というシンボリック リンクを作成します。
--platform_suffix=string
出力ディレクトリの決定に使用される構成の短い名前に接尾辞を追加します。このオプションを異なる値に設定すると、ファイルが異なるディレクトリに配置されます。たとえば、相互の出力ファイルを上書きするビルドのキャッシュ ヒット率を改善したり、出力ファイルを比較用に保持したりできます。
--default_visibility=(private|public)
bazel のデフォルトの公開設定の変更をテストするための一時的なフラグ。一般的な用途を意図したものではありませんが、完全性のために文書化しています。
--starlark_cpu_profile=_file_
このフラグ(値はファイル名)を使用すると、Bazel はすべての Starlark スレッドの CPU 使用率に関する統計情報を収集し、名前付きファイルに pprof 形式でプロファイルを書き込みます。
このオプションを使用すると、過剰な計算により読み込みと分析が遅くなる Starlark 関数を特定できます。例:
$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/... $ pprof /tmp/pprof.gz (pprof) top Type: CPU Time: Feb 6, 2020 at 12:06pm (PST) Duration: 5.26s, Total samples = 3.34s (63.55%) Showing nodes accounting for 3.34s, 100% of 3.34s total flat flat% sum% cum cum% 1.86s 55.69% 55.69% 1.86s 55.69% sort_source_files 1.02s 30.54% 86.23% 1.02s 30.54% expand_all_combinations 0.44s 13.17% 99.40% 0.44s 13.17% range 0.02s 0.6% 100% 3.34s 100% sorted 0 0% 100% 1.38s 41.32% my/project/main/BUILD 0 0% 100% 1.96s 58.68% my/project/library.bzl 0 0% 100% 3.34s 100% main
同じデータの異なるビューについては、pprof
コマンド svg
、web
、list
を試してください。
リリースに Bazel を使用する
Bazel は、開発サイクル中のソフトウェア エンジニアと、本番環境へのデプロイ用のバイナリを準備するリリース エンジニアの両方によって使用されます。このセクションでは、Bazel を使用するリリース エンジニア向けのヒントを紹介します。
重要なオプション
リリースビルドに Bazel を使用すると、ビルドを実行する他のスクリプトと同じ問題が発生します。詳細については、スクリプトから Bazel を呼び出すをご覧ください。特に、次のオプションを強くおすすめします。
次のオプションも重要です。
--package_path
--symlink_prefix
: 複数の構成のビルドを管理する場合は、各ビルドを個別の識別子(「64bit」と「32bit」など)で区別すると便利です。このオプションは、bazel-bin
などのシンボリック リンクを区別します。
テストの実行
bazel でテストをビルドして実行するには、bazel test
の後にテストターゲットの名前を入力します。
デフォルトでは、このコマンドはビルドとテストのアクティビティを同時に実行します。指定されたすべてのターゲット(コマンドラインで指定されたテスト以外のターゲットを含む)をビルドし、*_test
ターゲットと test_suite
ターゲットの前提条件がビルドされるとすぐにテストします。つまり、テストの実行はビルドと交互に行われます。これにより、通常は大幅な速度向上が得られます。
「bazel test
」のオプション
--cache_test_results=(yes|no|auto)
(-t
)
このオプションが「auto」(デフォルト)に設定されている場合、Bazel は次のいずれかの条件が適用された場合にのみテストを再実行します。
- Bazel がテストまたはその依存関係の変更を検出する
- テストが
external
とマークされている --runs_per_test
で複数のテスト実行がリクエストされました- テストが失敗しました。
「no」の場合、すべてのテストが無条件で実行されます。
「yes」の場合、キャッシュの動作は自動と同じですが、--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 は、サイズが暗黙的または明示的に設定されているかどうかにかかわらず、テストのサイズからタイムアウトの上限を推測して、すべてのテストでこれらのタイムアウトを使用します。
サイズとは異なるタイムアウト カテゴリを明示的に指定したテストでは、そのタイムアウトがサイズタグによって暗黙的に設定された場合と同じ値が返されます。したがって、「長い」タイムアウトを宣言するサイズ「small」のテストでは、「大規模な」テストと同じ有効なタイムアウトが設定されますが、明示的なタイムアウトはありません。
--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
各テストのテスト環境に挿入する必要がある追加の変数を指定します。value が指定されていない場合は、bazel test
コマンドの起動に使用されたシェル環境から継承されます。
環境には、System.getenv("var")
(Java)、getenv("var")
(C または C++)を使用してテスト内からアクセスできます。
--run_under=command-prefix
これにより、テストランナーがテストコマンドの前に挿入する接頭辞を指定します。command-prefix は Bourne シェルのトークン化ルールを使用して単語に分割され、単語のリストが実行されるコマンドの先頭に追加されます。
最初の単語が完全修飾ラベル(//
で始まる)の場合、その単語がビルドされます。その後、ラベルは、他の単語とともに実行されるコマンドの先頭に追加される、対応する実行可能ファイルの場所に置き換えられます。
いくつかの注意点があります。
- テストの実行に使用される PATH は、環境の PATH と異なる場合があります。そのため、
--run_under
コマンド(command-prefix の最初の単語)に絶対パスを使用する必要がある場合があります。 stdin
が接続されていないため、--run_under
をインタラクティブ コマンドに使用できません。
例:
--run_under=/usr/bin/strace --run_under='/usr/bin/strace -c' --run_under=/usr/bin/valgrind --run_under='/usr/bin/valgrind --quiet --num-callers=20'
テストの選択
出力の選択オプションで説明されているように、テストはサイズ、タイムアウト、タグ、言語でフィルタできます。便利な一般名フィルタは、特定のフィルタ引数をテストランナーに転送できます。
「bazel test
」のその他のオプション
構文と残りのオプションは bazel build
とまったく同じです。
実行可能ファイルの実行
bazel run
コマンドは bazel build
に似ていますが、単一のターゲットのビルドと実行に使用されます。一般的なセッションは次のとおりです(//java/myapp:myapp
が 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 ツリーになります。
バイナリがテストの場合、現在の作業ディレクトリが exec ルートになり、通常テストが実行される環境を可能な限り再現します。ただし、エミュレーションは完全ではなく、複数のシャードを含むテストはこのように実行できません(--test_sharding_strategy=disabled
コマンドライン オプションを使用して回避できます)。
バイナリでは、次の追加の環境変数も使用できます。
BUILD_WORKSPACE_DIRECTORY
: ビルドが実行されたワークスペースのルート。BUILD_WORKING_DIRECTORY
: Bazel の実行元となった現在の作業ディレクトリ。BUILD_ID
:bazel run
呼び出しのビルド ID。これは通常一意ですが、Bazel が--script_path
で実行され、生成されたスクリプトが再利用される場合を除きます。BUILD_EXECROOT
:bazel run
呼び出しの実行ルート。
たとえば、コマンドライン上のファイル名をユーザー フレンドリーな方法で解釈するために使用できます。
「bazel run
」のオプション
--run_under=command-prefix
これは bazel test
の --run_under
オプション(上記を参照)と同じ効果があります。ただし、bazel test
によって実行されるテストではなく、bazel
run
によって実行されるコマンドに適用され、ラベルでは実行できない点が異なります。
Bazel からのロギング出力のフィルタリング
bazel run
を使用してバイナリを呼び出すと、Bazel は Bazel 自体と呼び出し中のバイナリからのロギング出力を出力します。ログのノイズを減らすには、--ui_event_filters
フラグと --noshow_progress
フラグを使用して Bazel 自体の出力を抑制します。
次に例を示します。bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp
テストの実行
bazel run
はテスト バイナリを実行することもできます。これにより、テストの作成で説明されている環境に近い状態でテストを実行できます。この方法でテストを実行する場合、--test_arg
を除く --test_*
引数は影響しません。
ビルド出力のクリーンアップ
clean
コマンド
Bazel には、Make と同様の clean
コマンドがあります。この Bazel インスタンスによって実行されたすべてのビルド構成の出力ディレクトリ、またはこの Bazel インスタンスによって作成された作業ツリー全体が削除され、内部キャッシュがリセットされます。コマンドライン オプションを指定せずに実行すると、すべての構成の出力ディレクトリがクリーンアップされます。
各 Bazel インスタンスは単一のワークスペースに関連付けられているため、clean
コマンドは、そのワークスペースでその Bazel インスタンスを使用して行ったすべてのビルドの出力をすべて削除します。
Bazel インスタンスによって作成された作業ツリー全体を完全に削除するには、--expunge
オプションを指定します。--expunge
で実行すると、clean コマンドは出力ベースツリー全体を削除します。このツリーには、ビルド出力に加えて、Bazel によって作成されたすべての一時ファイルが含まれています。また、shutdown
コマンドと同等の処理が完了してから Bazel サーバーを停止します。たとえば、Bazel インスタンスのディスク トレースおよびメモリ トレースをすべてクリーンアップするには、次のように指定します。
% bazel clean --expunge
または、--expunge_async
を使用してバックグラウンドで消去することもできます。非同期消去の実行中に、同じクライアントで Bazel コマンドを呼び出しても安全です。
clean
コマンドは主に、不要になったワークスペースのディスク容量を再利用する手段として提供されています。Bazel の増分再ビルドは完璧ではない可能性があるため、問題が発生したときに clean
を使用して一貫した状態を復元できます。
Bazel の設計では、こうした問題は修正可能であり、修正すべきバグは優先度の高いバグです。間違った増分ビルドが見つかった場合は、clean
ではなく、バグレポートを提出してツールでバグを報告してください。
依存関係グラフのクエリ
Bazel には、ビルド中に使用される依存関係グラフに関する質問を行うためのクエリ言語が含まれています。クエリ言語は、query と cquery の 2 つのコマンドで使用されます。2 つのコマンドの主な違いは、クエリが読み込みフェーズの後に実行され、cquery が分析フェーズの後に実行されることです。これらのツールは、多くのソフトウェア エンジニアリング タスクに欠かせないものです。
このクエリ言語は、グラフに対する代数演算の概念に基づいています。詳細については、
Bazel クエリ リファレンス。リファレンス、例、クエリ固有のコマンドライン オプションについては、そのドキュメントをご覧ください。
クエリツールは、いくつかのコマンドライン オプションを受け入れます。--output
: 出力形式を選択します。--[no]keep_going
(デフォルトで無効)を使用すると、エラーが発生したときにクエリの処理を続行できます。エラーの発生時に不完全な結果を許容できない場合、この動作は無効になる場合があります。
デフォルトで有効になっている --[no]tool_deps
オプションを使用すると、ターゲット以外の構成の依存関係が、クエリが実行される依存関係グラフに含まれます。
デフォルトで有効になっている --[no]implicit_deps
オプションを使用すると、クエリが実行される依存関係グラフに暗黙的な依存関係が含まれます。暗黙的な依存関係とは、BUILD ファイルで明示的に指定されていないが、bazel によって追加される依存関係です。
例: 「PEBL ツリー内のすべてのテストをビルドするために必要なすべての genrule の定義(BUILD ファイル内)のロケーションを表示します。」
bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'
アクショングラフのクエリ
aquery
コマンドを使用すると、ビルドグラフ内のアクションをクエリできます。分析後に構成されたターゲット グラフで動作し、アクション、アーティファクト、それらの関係に関する情報を公開します。
このツールは、いくつかのコマンドライン オプションを受け入れます。--output
: 出力形式を選択します。デフォルトの出力形式(text
)は人が読める形式です。機械が読み取れる形式にするには、proto
または textproto
を使用します。特に、aquery コマンドは通常の Bazel ビルド上で実行され、ビルド中に使用可能なオプションのセットを継承します。
従来の query
で使用できる関数セット(siblings
、buildfiles
、tests
を除く)をサポートしています。
詳細については、アクション グラフ クエリをご覧ください。
その他のコマンドとオプション
help
help
コマンドにはオンライン ヘルプがあります。デフォルトでは、Bazel を使用したビルドに示すように、使用可能なコマンドとヘルプトピックの概要が表示されます。引数を指定すると、特定のトピックに関する詳細なヘルプが表示されます。ほとんどのトピックは、build
や query
などの Bazel コマンドですが、コマンドに対応していない追加のヘルプトピックもあります。
--[no]long
(-l
)
デフォルトでは、bazel help [topic]
はトピックに関連するオプションの概要のみを出力します。--long
オプションを指定した場合は、各オプションの型、デフォルト値、詳細な説明も出力されます。
shutdown
Bazel サーバー プロセスは、shutdown
コマンドを使用して停止できます。このコマンドは、Bazel サーバーがアイドル状態になると(たとえば、現在進行中のビルドや他のコマンドの完了後など)に終了します。詳細については、クライアント/サーバーの実装をご覧ください。
Bazel サーバーはアイドル タイムアウト後に自動的に停止するため、このコマンドが必要になることはほとんどありません。ただし、特定のワークスペースでそれ以上のビルドが行われないことがわかっているスクリプトで役立ちます。
shutdown
は 1 つのオプション(--iff_heap_size_greater_than _n_
)を受け入れます。このオプションには整数引数(MB 単位)が必要です。指定すると、すでに消費されているメモリ量に基づいてシャットダウンが条件となります。これは、多くのビルドを開始するスクリプトにとって便利です。Bazel サーバーでメモリリークが発生すると、まれにクラッシュが発生する可能性があります。条件付き再起動を実行すると、この状態を回避できます。
info
info
コマンドは、Bazel サーバー インスタンスまたは特定のビルド構成に関連付けられたさまざまな値を出力します。(これらは、ビルドを実行するスクリプトで使用できます)。
info
コマンドでは、1 つの引数(オプション)を指定することもできます。これは、以下のリストに示すキーのいずれかの名前です。この場合、bazel info key
は 1 つのキーの値のみを出力します。(これは、結果を sed -ne /key:/s/key://p
にパイプする必要がないため、Bazel のスクリプト作成時に特に便利です。
構成に依存しないデータ
release
: この Bazel インスタンスのリリースラベル。リリース済みバイナリでない場合は「開発版」です。workspace
ベース ワークスペース ディレクトリの絶対パス。install_base
: この Bazel インスタンスが現在のユーザーに使用しているインストール ディレクトリの絶対パス。Bazel は、内部で必要な実行可能ファイルをこのディレクトリの下にインストールします。output_base
: 現在のユーザーとワークスペースの組み合わせに対してこの Bazel インスタンスで使用されるベース出力ディレクトリの絶対パス。Bazel は、すべてのスクラッチ出力とビルド出力をこのディレクトリの下に配置します。execution_root
: output_base の下にある実行ルート ディレクトリの絶対パス。このディレクトリは、ビルド中に実行されるコマンドがアクセスできるすべてのファイルのルートであり、それらのコマンドの作業ディレクトリです。ワークスペース ディレクトリが書き込み可能である場合、このディレクトリを参照するbazel-<workspace>
という名前のシンボリック リンクが配置されます。output_path
: ビルドコマンドの実行結果として実際に生成されるすべてのファイルに使用される、実行ルート内の出力ディレクトリの絶対パス。ワークスペース ディレクトリが書き込み可能である場合、このディレクトリを参照するbazel-out
という名前のシンボリック リンクが配置されます。server_pid
: Bazel サーバー プロセスのプロセス ID。server_log
: Bazel サーバーのデバッグログ ファイルへの絶対パス。このファイルには、Bazel サーバーの生存期間中のすべてのコマンドのデバッグ情報が含まれます。これは、Bazel デベロッパーとパワーユーザーが使用することを目的としています。command_log
: コマンド ログファイルの絶対パス。最新の Bazel コマンドのインターリーブされた stdout ストリームと stderr ストリームが含まれます。bazel info
を実行すると、このファイルの内容が最新の Bazel コマンドになるため、このファイルの内容が上書きされます。ただし、--output_base
オプションまたは--output_user_root
オプションの設定を変更しない限り、コマンドログ ファイルの場所は変更されません。used-heap-size
、committed-heap-size
、max-heap-size
: さまざまな JVM ヒープサイズ パラメータを報告します。それぞれ、現在使用されているメモリ、システムから JVM が使用できることが保証されているメモリ、最大可能な割り当てです。gc-count
、gc-time
: この Bazel サーバーを起動してからのガベージ コレクションの累積数と実行にかかった時間。これらの値は、ビルドの開始時にリセットされないことに注意してください。package_path
: bazel によってパッケージが検索されるパスのカンマ区切りリスト。--package_path
ビルド コマンドライン引数と同じ形式です。
例: Bazel サーバーのプロセス ID。
% bazel info server_pid 1285
構成固有のデータ
これらのデータは、bazel info
に渡された構成オプション(--cpu
、--compilation_mode
など)の影響を受ける場合があります。info
コマンドは、依存関係分析を制御するすべてのオプションを受け入れます。これらのオプションの一部は、ビルドの出力ディレクトリの場所やコンパイラの選択などを決定するためです。
bazel-bin
、bazel-testlogs
、bazel-genfiles
: ビルドによって生成されたプログラムが配置されているbazel-*
ディレクトリへの絶対パスを報告します。これは通常、ビルドが成功した後にベース ワークスペース ディレクトリに作成されたbazel-*
シンボリック リンクと同じですが、必ずしも同じではありません。ただし、ワークスペース ディレクトリが読み取り専用の場合、bazel-*
シンボリック リンクは作成できません。シンボリック リンクの存在を前提とせず、bazel info
によって報告された値を使用するスクリプトは、より堅牢になります。- 完全な 「Make」環境。
--show_make_env
フラグが指定されている場合、現在の構成の「Make」環境内のすべての変数(CC
、GLIBC_VERSION
など)も表示されます。これらは、BUILD ファイル内の$(CC)
構文またはvarref("CC")
構文を使用してアクセスされる変数です。
例: 現在のコンフィグレーション用の C++ コンパイラ。これは「Make」環境の $(CC)
変数であるため、--show_make_env
フラグが必要です。
% bazel info --show_make_env -c opt COMPILATION_MODE opt
例: 現在の構成の bazel-bin
出力ディレクトリ。これは、なんらかの理由で bazel-bin
シンボリック リンクを作成できない場合(読み取り専用ディレクトリからビルドしている場合など)でも、正しいことが保証されます。
% bazel info --cpu=piii bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin % bazel info --cpu=k8 bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin
version
、--version
version コマンドは、ビルドされた Bazel バイナリのバージョンの詳細(ビルドされた変更リストと日付など)を出力します。これは、最新の Bazel を使用しているかどうかや、バグを報告しているかどうかを判断する場合に特に役立ちます。興味深い値の例を次に示します。
changelist
: このバージョンの Bazel がリリースされた変更リスト。label
: この Bazel インスタンスのリリースラベル。リリース済みバイナリでない場合は「開発版」です。バグを報告する際に非常に役立ちます。
他の引数なしで bazel --version
を実行すると、Bazel サーバーの起動やサーバー アーカイブの解凍などの副作用を除き、bazel version --gnu_format
と同じ出力が生成されます。bazel --version
はどこからでも実行できます。ワークスペース ディレクトリは必要ありません。
mobile-install
mobile-install
コマンドは、モバイル デバイスにアプリをインストールします。現在のところ、ART を搭載した Android デバイスのみがサポートされています。
詳細については、bazel mobile-install をご覧ください。
次のオプションがサポートされています。
--incremental
設定すると、Bazel はアプリを増分インストールしようとします。つまり、前回のビルド以降に変更された部分のみをインストールします。これにより、AndroidManifest.xml
、ネイティブ コード、Java リソース(Class.getResource()
で参照されるリソースなど)から参照されるリソースを更新することはできません。これらのものが変更された場合は、このオプションを省略する必要があります。Bazel の精神に反し、Android プラットフォームの制限により、このコマンドで十分な場合と完全なインストールが必要な場合を判断するのはユーザーの責任です。
Marshmallow 以降を搭載したデバイスを使用している場合は、--split_apks
フラグを検討してください。
--split_apks
分割 APK を使用してデバイスにアプリをインストールして更新するかどうか。Marshmallow 以降を搭載したデバイスでのみ動作します。--split_apks
を使用する場合、--incremental
フラグは必要ありません。
--start_app
インストール後にクリーンな状態でアプリを起動します。--start=COLD
と同じです。
--debug_app
デバッガが接続されるまで待ってから、インストール後にクリーンな状態でアプリを起動します。--start=DEBUG
と同じです。
--start=_start_type_
アプリのインストール後にアプリを起動する方法。サポートされている _start_type_s:
NO
アプリを起動しません。これがデフォルトです。COLD
インストール後にクリーンな状態からアプリを起動します。WARM
増分インストール時にアプリの状態を保持、復元します。DEBUG
インストール後にクリーンな状態でアプリを起動する前に、デバッガを待機します。
--adb=path
使用する adb
バイナリを示します。
デフォルトでは、--android_sdk
で指定された Android SDK の adb が使用されます。
--adb_arg=serial
adb
の追加引数。これらはコマンドラインのサブコマンドの前に配置され、通常はインストール先のデバイスを指定するために使用されます。たとえば、使用する Android デバイスまたはエミュレータを選択するには:
% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef
adb
を
adb -s deadbeef install ...
--incremental_install_verbosity=number
増分インストールの詳細度。デバッグ ロギングをコンソールに出力するには、1 に設定します。
dump
dump
コマンドは、Bazel サーバーの内部状態のダンプ stdout に出力します。このコマンドは、主に Bazel デベロッパーによる使用を想定しているため、このコマンドの出力は示されておらず、変更される可能性があります。
デフォルトでは、このコマンドは Bazel の状態の特定の部分をダンプするためのオプションの概要を示すヘルプ メッセージを出力します。内部状態をダンプするには、少なくとも 1 つのオプションを指定する必要があります。
次のオプションがサポートされています。
--action_cache
は、アクション キャッシュの内容をダンプします。--packages
は、パッケージ キャッシュの内容をダンプします。--skyframe
は、内部 Bazel 依存関係グラフの状態をダンプします。--rules
は、各ルールとアスペクト クラスのルールの概要(カウントとアクション カウントを含む)を出力します。これには、ネイティブ ルールと Starlark ルールの両方が含まれます。メモリ トラッキングが有効になっている場合は、ルールのメモリ使用量も出力されます。--skylark_memory
は、pprof 互換の .gz ファイルを指定されたパスにダンプします。この機能を利用するには、メモリ トラッキングを有効にする必要があります。
メモリのトラッキング
一部の dump
コマンドでは、メモリ トラッキングが必要です。これを有効にするには、起動フラグを Bazel に渡す必要があります。
--host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
--host_jvm_args=-DRULE_MEMORY_TRACKER=1
java-agent は、third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
で Bazel にチェックインされるため、Bazel リポジトリを保持する場所に合わせて $BAZEL
を調整してください。
コマンドごとにこれらのオプションを Bazel に渡すことを忘れないでください。忘れると、サーバーが再起動します。
例:
% bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ build --nobuild <targets> # Dump rules % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --rules # Dump Starlark heap and analyze it with pprof % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --skylark_memory=$HOME/prof.gz % pprof -flame $HOME/prof.gz
analyze-profile
analyze-profile
コマンドは、以前に Bazel の呼び出し中に収集された JSON トレース プロファイルを分析します。
canonicalize-flags
canonicalize-flags
コマンド。Bazel コマンドのオプションのリストを受け取ると、同じ効果を持つオプションのリストを返します。新しいオプションのリストが正規のリストです。たとえば、同じ効果を持つ 2 つのオプション リストは、同じ新しいリストに正規化されます。
--for_command
オプションを使用すると、さまざまなコマンドを選択できます。現時点では、build
と test
のみがサポートされています。指定されたコマンドがサポートしていないオプションを使用すると、エラーが発生します。
例:
% bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint" --config=any_name --test_tag_filters=-lint
起動オプション
このセクションで説明するオプションは、Bazel サーバー プロセスで使用される Java 仮想マシンの起動に影響し、そのサーバーで処理される後続のすべてのコマンドに適用されます。すでに実行中の Bazel サーバーがあり、起動オプションが一致しない場合、そのサーバーは再起動されます。
このセクションで説明するオプションはすべて、--key=value
または --key value
構文を使用して指定する必要があります。また、これらのオプションは Bazel コマンドの名前の前に表示する必要があります。startup --key=value
を使用して、これらを .bazelrc
ファイルにリストします。
--output_base=dir
このオプションにはパス引数が必要です。書き込み可能なディレクトリを指定する必要があります。Bazel はこの場所にすべての出力を書き込みます。出力ベースは、クライアントが Bazel サーバーを検索するキーでもあります。出力ベースを変更すると、コマンドを処理するサーバーが変更されます。
デフォルトでは、出力ベースはユーザーのログイン名とワークスペース ディレクトリの名前(実際には MD5 ダイジェスト)から取得されるため、一般的な値は /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e
のようになります。
例:
OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base % bazel --output_base ${OUTPUT_BASE}1 build //foo & bazel --output_base ${OUTPUT_BASE}2 build //bar
このコマンドでは、シェルの &
演算子により、2 つの Bazel コマンドが同時に実行されます。各コマンドは、異なる Bazel サーバー インスタンスを使用します(出力ベースが異なるため)。一方、両方のコマンドでデフォルトの出力ベースが使用されている場合、両方のリクエストが同じサーバーに送信され、サーバーはリクエストを順番に処理します。まず //foo
をビルドし、次に //bar
の増分ビルドを行います。
--output_user_root=dir
出力ベースとインストール ベースが作成されるルート ディレクトリを参照します。ディレクトリが存在しない場合、または呼び出し元のユーザーが所有している必要があります。以前は、さまざまなユーザー間で共有されるディレクトリを指定することが許可されていましたが、現在は許可されなくなりました。これは、問題 #11100 に対処すると許可される可能性があります。
--output_base
オプションを指定すると、--output_user_root
を使用して出力ベースを計算するオーバーライドが適用されます。
インストール ベースの場所は、--output_user_root
と Bazel 埋め込みバイナリの MD5 ID に基づいて計算されます。
ファイル システム レイアウト内に適切な場所がある場合は、--output_user_root
オプションを使用して、Bazel のすべての出力(インストール ベースと出力ベース)の代わりのベース ロケーションを選択できます。
--server_javabase=dir
Bazel 自体が実行される Java 仮想マシンを指定します。値には、JDK または JRE を含むディレクトリのパスを指定する必要があります。ラベルは使用できません。このオプションは、Bazel コマンドの前に表示されます。次に例を示します。
% bazel --server_javabase=/usr/local/buildtools/java/jdk build //foo
このフラグは、Bazel サブプロセス(アプリケーション、テスト、ツールなど)で使用される JVM には影響しません。代わりに、ビルド オプション --javabase または --host_javabase を使用してください。
このフラグは、以前は --host_javabase
という名前(「左側」の --host_javabase
と呼ばれることもあります)でしたが、ビルドフラグ --host_javabase(「右側」の --host_javabase
と呼ばれることもあります)との混同を避けるために名前が変更されました。
--host_jvm_args=string
Bazel 自体が実行される Java 仮想マシンに渡す起動オプションを指定します。これを使用して、スタックサイズを設定できます。次に例を示します。
% bazel --host_jvm_args="-Xss256K" build //foo
このオプションは、個別の引数を指定して複数回使用できます。このフラグの設定が必要になることはほとんどありません。スペース区切りの文字列リストを渡すこともできます。各文字列は個別の JVM 引数として解釈されますが、この機能はまもなく非推奨になります。
これは、Bazel のサブプロセス(アプリケーション、テスト、ツールなど)で使用される JVM には影響しません。bazel
run
で実行するかコマンドラインで実行するかにかかわらず、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
を使用すると、Bazel を実行する明示的な JRE を選択できます。
--batch
バッチモードでは、Bazel は標準のクライアント/サーバー モードを使用しません。代わりに、単一のコマンドに対して bazel java プロセスを実行します。これは、シグナル処理、ジョブ制御、環境変数の継承に関してより予測可能なセマンティクスに使用され、chroot ジャイルで bazel を実行するために必要です。
バッチモードでは、同じ output_base 内で適切なキュー セマンティクスが保持されます。つまり、同時呼び出しは重複することなく順番に処理されます。実行中のサーバーが存在するクライアントでバッチモードの Bazel を実行すると、まずサーバーが強制終了してからコマンドが処理されます。
バッチモードや上記の代替手段を使用すると、Bazel の実行速度が遅くなります。 これは、特に、ビルドファイルのキャッシュがメモリ常駐であり、連続したバッチ呼び出し間で保持されないためです。 したがって、連続ビルドなど、パフォーマンスが重要でない場合には、バッチモードを使用するほうが合理的です。
--max_idle_secs=n
このオプションは、最後のクライアント リクエスト後に Bazel サーバー プロセスが終了するまでの待機時間を秒単位で指定します。デフォルト値は 10,800(3 時間)です。--max_idle_secs=0
を指定すると、Bazel サーバー プロセスが無期限に保持されます。
このオプションは、Bazel を呼び出すスクリプトで使用できます。これにより、Bazel サーバー プロセスがユーザーのマシンに残されないようにします。たとえば、送信前スクリプトで bazel query
を呼び出して、ユーザーの保留中の変更によって不要な依存関係が導入されないようにすることができます。ただし、ユーザーがそのワークスペースで最近ビルドを行っていない場合、その日残りの時間アイドル状態のままになる Bazel サーバーを presubmit スクリプトで起動するのは望ましくありません。クエリ リクエストで小さな値の --max_idle_secs
を指定すると、スクリプトによって、新しいサーバーが起動された場合、そのサーバーがすぐに終了します。一方、すでにサーバーが実行されている場合は、通常のアイドル状態になるまでそのサーバーが実行を続けます。もちろん、既存のサーバーのアイドル タイマーはリセットされます。
--[no]shutdown_on_low_sys_mem
有効で --max_idle_secs
を正の期間に設定した場合、ビルドサーバーがしばらくアイドル状態になった後、システムのメモリが少なくなったときにサーバーをシャットダウンします。Linux のみ。
ビルドサーバーは、max_idle_secs に対応するアイドル状態チェックを実行するだけでなく、サーバーが一定時間アイドル状態になった後に、使用可能なシステム メモリのモニタリングを開始します。使用可能なシステム・メモリが極端に少なくなると、サーバーは終了します。
--[no]block_for_lock
Bazel を有効にした場合、Bazel はサーバーロックを保持している他の Bazel コマンドが完了するのを待ってから、次に進みます。無効にすると、ロックをすぐに取得して続行できない場合、Bazel はエラーで終了します。
デベロッパーは、同じクライアント内の別の Bazel コマンドによる長時間の待機を回避するために、送信前チェックでこれを使用できます。
--io_nice_level=n
ベスト エフォート I/O スケジューリングのレベルを 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
からオプションも取得します。複数回指定して、複数の構成セクションのフラグを追加できます。展開は他の定義を参照できます(展開を連結できます)。
--curses (yes|no|auto)
このオプションは、Bazel が画面出力でカーソル コントロールを使用するかどうかを決定します。これにより、データのスクロールが減り、Bazel からの出力ストリームがコンパクトで読みやすいものになります。これは --color
とよく連携します。
このオプションが yes
に設定されている場合、カーソル操作が有効になります。このオプションを no
に設定すると、カーソル制御の使用が無効になります。このオプションを auto
に設定すると、--color=auto
の場合と同じ条件でカーソル コントロールの使用が有効になります。
--[no]show_timestamps
指定すると、Bazel によって生成された各メッセージに、メッセージが表示された時間を示すタイムスタンプが追加されます。