一般的な定義

問題を報告 ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

このセクションでは、一般的な各種用語と概念を定義します。 作成ルールを使用します。

目次

• Bourne シェルのトークン化
• ラベルの拡張
• ほとんどのビルドルールで定義される一般的な属性
• すべてのビルドルールに共通する属性
• すべてのテストルールに共通する属性（*_test）
• すべてのバイナリルールに共通する属性（*_binary）
• 構成可能な属性
• 暗黙的な出力ターゲット

Bourne シェルのトークン化

一部のルールで、特定の文字列属性が複数に分割される Bourne シェルのトークン化ルールに従って単語が抽出されます。 スペースは引用符で囲まないで、個々の単語を区切り、 二重引用符とバックスラッシュは、 説明しました。

このトークン化の対象となる属性は、 使用しないでください。

「Make」の対象となる属性変数展開と Bourne シェル トークン化は通常、任意のオプションを その他のツールもサポートしています。このような属性の例として、 cc_library.copts と java_library.javacopts。 これらの置換により 構成固有のリストに展開する単一の文字列変数 できます。

ラベルの展開

ごく一部のルールでは、一部の文字列属性にラベルが適用される 展開: 文字列として有効なラベルが 部分文字列（//mypkg:target など）であり、そのラベルは 現在のルールの前提条件として宣言されている場合、 で表されるファイルのパス名 ターゲット //mypkg:target。

属性の例: genrule.cmd、 cc_binary.linkopts。詳細は、 相対ラベルの有無といった問題に対して 開いています。複数のファイルに展開されるラベルは ルール属性のドキュメントで、 あります。

ほとんどのビルドルールで定義される一般的な属性

このセクションでは、多くのビルドルールによって定義される属性について説明します。 すべてではありません

属性	説明
data	ラベルのリスト。デフォルトは [] です 実行時にこのルールで必要なファイル。ファイルまたはルールのターゲットをリストできます。一般 任意のターゲットを許可します。 data 属性内のターゲットのデフォルトの出力と実行ファイル 作成された実行可能ファイルの *.runfiles 領域に表示されるはずです。 またはこのターゲットとランタイム依存関係があります。これにはデータが含まれる場合があります ファイルまたはバイナリが、このターゲットの srcs が実行される。詳しくは、 データ依存関係 をご覧ください。 新しいルールで data 属性を処理する場合は、そのルールで 実行時に他の入力を使用する可能性のある入力です。ルール実装関数 また、ターゲットの IP アドレスに runfile を任意の data 属性の出力と runfile から追加する 任意の依存関係属性からのランファイルも指定できます。 依存関係が存在します。
deps	ラベルのリスト。デフォルトは [] です このターゲットの依存関係。通常は、ルール ターゲットのみをリストします。（ただし、 一部のルールでは、deps にファイルを直接リストすることが許可されます。 使用しないでください）。 通常、言語固有のルールにより、リストされるターゲットは、 特定のプロバイダ ターゲットが、Cloud KMS を使用して別のリソースに依存することの意味の正確なセマンティクスは、 deps はルールの種類に固有で、ルールに固有の ドキュメントをご覧ください。ソースコードを処理するルールの場合 deps は通常、Java 内のコードで使用されるコード依存関係を指定します。 srcs。 ほとんどの場合、deps 依存関係は、1 つのモジュールで 同じプログラミング言語で記述された別のモジュールで定義されているシンボルと、 個別にコンパイルします。言語をまたぐ依存関係も、多くの言語や たとえば、java_library ターゲットが C++ コードに依存する場合があります。 後者を cc_library ターゲットにリストすることで、 deps 属性。定義を表示 依存関係 をご覧ください。
licenses	文字列のリスト。設定不可 デフォルトは ["none"] です この特定のターゲットに使用されるライセンス タイプの文字列のリスト。 これは、Bazel で使用されなくなった非推奨のライセンス API の一部です。すべきでないこと 使用します。
srcs	ラベルのリスト。デフォルトは [] です このルールによって処理または追加されたファイル。通常、ファイルは直接リストされますが、 は、ルールのターゲット（filegroup、genrule など）をリスト化して、 出力が含まれます。 多くの場合、言語固有のルールにより、リストされたファイルには特定のルールが ファイル拡張子。

すべてのビルドルールに共通する属性

このセクションでは、すべてのビルドに暗黙的に追加される属性について説明します。 できます。

属性	説明
compatible_with	ラベルのリスト。 構成不可デフォルトは [] 以下に加えて、このターゲットを構築できる環境のリスト 環境に依存しています。 これは Bazel の制約システムの一部です。これにより、ユーザーはどの Pod が ターゲット同士の相互依存が可能です。たとえば、外部にデプロイ可能な バイナリは、企業秘密のコードを含むライブラリに依存すべきではありません。詳しくは、 ConstraintSemantics をご覧ください。
deprecation	String;設定不可デフォルトは None です このターゲットに関連付けられている、説明付きの警告メッセージ。 通常これは、ターゲットが古くなったことをユーザーに知らせるために使用されます。 別のルールに置き換わっている、特定のパッケージに限定公開されている なんらかの理由で有害と判断されます名前は、 ウェブページ、バグ番号、移行 CL の例などの参照情報を メッセージを回避するために必要な変更を簡単に確認できます。 交換の減少として使用できる新しい目標がある場合、それは 古いターゲットのすべてのユーザーを移行することをおすすめします この属性はビルド方法には影響しませんが、 ビルドツールの診断出力に影響することがあります。ビルドツールは deprecation 属性を含むルールが 別のパッケージ内のターゲットに依存します。 パッケージ内の依存関係はこの警告から除外されるため、 たとえば、非推奨のルールのテストを構築しても、 警告が表示されます。 非推奨のターゲットが別の非推奨のターゲットに依存している場合、警告は表示されません。 メッセージが発行されます。 ユーザーが使用をやめると、ターゲットを削除できます。
distribs	文字列のリスト。設定不可 デフォルトは [] です この特定のターゲットに使用される分散方法文字列のリスト。 これは、Bazel で使用されなくなった非推奨のライセンス API の一部です。すべきでないこと 使用します。
exec_compatible_with	ラベルのリスト。 構成不可デフォルトは [] リスト constraint_values このターゲットの実行プラットフォームに存在する必要があります。場所: ルールタイプによってすでに設定されている制約への追加が可能です。制約は 使用可能な実行プラットフォームのリストを制限します。詳しくは、 説明 ツールチェーンの解決。
exec_properties	文字列の辞書デフォルトは {} です。 このターゲットに対して選択されたプラットフォームの exec_properties に追加される文字列の辞書。platform ルールの exec_properties をご覧ください。 プラットフォーム レベルのプロパティとターゲット レベルのプロパティの両方にキーが存在する場合、値はターゲットから取得されます。
features	feature 文字列のリストデフォルトは [] です 機能とは、ターゲットで有効または無効にできる文字列タグです。「 対象物の意味はルール自体によって異なります。 この features 属性は、 パッケージ レベルの features 属性。たとえば 機能 ["a", "b"] がパッケージ レベルで有効になっており、ターゲットの features 属性には、["-a", "c"]、つまり ルールが「b」になります。あります。 例をご覧ください。
restricted_to	ラベルのリスト。 構成不可デフォルトは [] 代わりにこのターゲットを構築できる環境のリスト 環境に依存しています。 これは、Bazel の制約システムの一部です。詳しくは、 compatible_with をご覧ください。
tags	文字列のリスト。設定不可 デフォルトは [] です タグは任意のルールで使用できます。テストと検証のタグ test_suite ルールはテストを分類するのに役立ちます。 テスト以外のターゲットのタグを使用して、以下のプロダクトのサンドボックス化された実行を制御します。 genrule 秒と Starlark 人間による解析や外部ツールによる解析に使用されます。 Bazel は次の場合にサンドボックス コードの動作を変更します。 任意のテストまたは genrule の tags 属性内のキーワード ターゲット、または任意の Starlark の execution_requirements のキー できます。 no-sandbox キーワードの場合、アクションまたはテストは実行されない サンドボックス化引き続きキャッシュに保存することも、リモートで実行することもできます。no-cache を使用してください。 このいずれかまたは両方を防ぐには、no-remote を設定します。 no-cache キーワードの場合、アクションまたはテストは実行されない キャッシュ（リモートまたはローカル） no-remote-cache キーワードの場合、アクションまたはテストは実行されない リモートでキャッシュされる（ただし、ローカルにキャッシュすることも、リモートで実行することも可能）。 注: このタグでは、ディスク キャッシュはローカル キャッシュと見なされますが、 HTTP キャッシュと gRPC キャッシュはリモートとみなされます ローカル ディスク キャッシュとリモート キャッシュを組み合わせて使用する場合（組み合わせキャッシュ）、 リモート キャッシュとして扱われ、--incompatible_remote_results_ignore_disk でない限り完全に無効になります。 が設定されている場合は、ローカル コンポーネントが使用されます。 no-remote-exec キーワードの場合、アクションまたはテストは実行されない リモートで実行される（ただし、リモートにキャッシュされる可能性がある） no-remote キーワードは、アクションまたはテストがリモートで実行されないようにします。 リモートでキャッシュに保存されます。これは、両方のノードを使用するのと no-remote-cache と no-remote-exec。 no-remote-cache-upload キーワードは、spawn のリモート キャッシュの一部のアップロードを無効にします。 リモート実行が無効になることはありません。 local キーワードにより、アクションまたはテストがリモート キャッシュから排除される。 サンドボックス内で実行することもできます。 genrules と test の場合は、local = True でルールをマークします。 同じ効果があります。 requires-network キーワードを使用すると、外部リソースへのアクセスを サンドボックスから保護します。このタグはサンドボックス化されている場合にのみ 有効になります。 block-network キーワードにより、外部へのアクセスがブロックされます。 サンドボックスから保護します。ここでは通信のみが 許可されています。このタグが有効になるのは、サンドボックスが 有効にします。 requires-fakeroot は、テストまたはアクションを uid および gid 0（つまり、 できます。これは Linux でのみサポートされています。このタグは --sandbox_fake_username コマンドライン オプション。 テストのタグは通常、テストにおける役割にアノテーションを付けるために使用されます。 デバッグとリリースのプロセスを使用します通常、タグは C++ と Python で最も有用です このテストにはランタイム アノテーション機能がありません。タグとサイズの使用 要素を使用すると、コードベースに基づいてテストスイートを柔軟に組み合わせることができます。 チェックイン ポリシーが適用されます。 Bazel は、 テストルールの tags 属性: exclusive は、強制的にテストを実行します。 「排他的」他のテストが実行されていないことを確認します。 できます。このようなテストは、すべてのビルド後に順番に実行されます アクティビティと非独占的なテストが完了しました。リモート実行は、 Bazel はテストで何を制御するかは制御できないため、このようなテストでは リモートマシン上で実行されています exclusive-if-local は、強制的にテストを実行します。 「排他的」ローカルで実行する場合はモードになりますが、ローカルで実行している場合はテストを並行して実行します。 実行することもできます。 manual キーワードを指定すると、ターゲット パターンのワイルドカードの拡張からターゲットが除外されます （...、:*、:all など）と test_suite ルール ビルド/実行するトップレベル ターゲットのセットを計算するときにテストが明示的にリストされていない 。buildtestcoverage残念ながら、 他のコンテキストでは、ターゲット ワイルドカードやテストスイートの拡張に query コマンドを使用します。なお、manual は、ターゲットを 継続的なビルド/テストシステムで自動的にビルド/実行されない。たとえば、 特定のターゲットが必要なため、bazel test ... からターゲットを除外することが推奨されます。 Bazel フラグだが、適切に構成された presubmit または継続的テストに含まれている 実行されます external キーワードを指定すると、強制的にテストが無条件に行われます 実行（--cache_test_results に関係なく） あります。 詳しくは、 タグの規則 をご覧ください。
target_compatible_with	ラベルのリスト。デフォルトは [] です リスト constraint_value 秒 必須フィールドです。 互換性。これは、 選択します。ターゲット プラットフォームがリストされている制約をすべて満たしていない場合、 ターゲットは互換性がないと見なされます。互換性のないターゲットは ターゲット パターンが拡張されたときにビルドとテストではスキップされます （例: //...、:all）。Deployment で明示的に 互換性のないターゲットが原因で Bazel がエラーを出力し、 失敗します。 互換性のないターゲットに推移的に依存するターゲット自体 互換性がないと見なされますまた、ビルドとテストでもスキップされます。 空のリスト（デフォルト）は、ターゲットに互換性があることを示します。 すべてのプラットフォームに対応します Workspace ルール以外のすべてのルールでサポートされています。 属性です。 一部のルールでは、この属性は機能しません。たとえば、 target_compatible_with: cc_toolchain は役に立ちません。 詳しくは、 プラットフォーム 互換性のないターゲットのスキップに関する詳細をご覧ください。
testonly	ブール値設定不可デフォルトは False です （テストスイートとテストスイート ターゲットを除く） True の場合、testonly ターゲット（テストなど）のみがこのターゲットに依存できます。 同様に、testonly 以外のルールの場合、 testonly のルールに依存します。 テスト（*_test 個のルール） およびテストスイート（test_suite ルール） デフォルトは testonly です。 この属性は、ターゲットを バイナリに含まれているファイルです。 testonly は実行時ではなくビルド時に適用され、伝播するため 依存関係ツリーで拡散している場合は、慎重に適用する必要があります。対象 偽のスタブやフェイクなど、 単体テストや統合テストにも役立つ 本番環境にリリースされるのと同じバイナリが関係する testonly とマークすべきではありません。これとは逆に、 リンクさえも危険です 通常の動作をオーバーライドする場合は、必ず testonly とマークしてください。
toolchains	ラベルのリスト。 構成不可デフォルトは [] このターゲットの [Make 変数] が、 許可します。これらのターゲットは、特定のリソースへの TemplateVariableInfo、または Bazel に組み込まれているツールチェーン タイプの特別なターゲット。これらの 含める: @bazel_tools//tools/cpp:current_cc_toolchain @bazel_tools//tools/jdk:current_java_runtime これは、Terraform の概念は ツールチェーンの解決 これは、プラットフォームに依存する設定のルール実装で使用されます。これは使用できません。 特定の cc_toolchain または java_toolchain を決定する属性を 使用されます。
visibility	ラベルのリスト。 構成不可 デフォルトは default_visibility で、 package（指定した場合）、または "//visibility:private" ターゲットの visibility 属性は、そのターゲットを 他のパッケージでも使用できます。次のドキュメントをご覧ください: visibility:

すべてのテストルールに共通する属性（*_test）

このセクションでは、すべてのテストルールに共通する属性について説明します。

属性	説明
args	文字列のリスト。条件 $(location) と [変数を作成] で置換する Bourne Shell のトークン化:デフォルトは [] です Bazel がターゲットに渡すコマンドライン引数 bazel test で実行されます。 これらの引数は、--test_arg 値の前に渡されます。 bazel test コマンドラインで指定します。
env	文字列の辞書適用される $(location) と 「変数を作成」デフォルトは [] テストの実行時に設定する追加の環境変数を指定します。 bazel test。 この属性は、cc_test などのネイティブ ルールにのみ適用されます。 py_test、sh_test。適用対象外 Starlark が定義したテストルール。独自の Starlark ルールの場合は、環境変数に「env」と その属性を使用して TestEnvironment 。
env_inherit	文字列のリスト。デフォルトは [] です。 プロジェクトから継承する追加の環境変数を bazel test がテストを実行したときの外部環境。 この属性はネイティブ ルール（cc_test、py_test、 および sh_test。Starlark で定義されたテストルールには適用されません。
size	文字列 "enormous"、"large"、"medium"、または "small"、構成不可、 デフォルトは "medium" です テスト ターゲットの「重さ」、つまり実行に必要な時間/リソースを指定します。 単体テストは「小規模」、統合テストは「中」、エンドツーエンド テストは「大規模」と見なされますまたは 「enormous」です。Bazel はこのサイズを使用してデフォルトのタイムアウトを決定します。デフォルトのタイムアウトは timeout 属性。タイムアウトは、個々のテストではなく、ビルド ターゲット内のすべてのテストに適用される 表示されます。テストをローカルで実行する場合、さらに size が次の目的で使用されます。 Bazel は --local_{ram,cpu}_resources を尊重しようとしますが、 大量のテストを同時に実行してローカルマシンに負荷をかけます。 テストサイズは、以下のデフォルトのタイムアウトと想定されるピーク ローカル リソースに対応します。 用途: サイズ RAM（MB） CPU（CPU コア数） デフォルトのタイムアウト 小 20 1 短い（1 分） 中 100 1 中（5 分） 大 300 1 長い（15 分） 膨大な 800 1 eternal（60 分） 環境変数 TEST_SIZE は、 値を指定する必要があります。
timeout	文字列 "short"、"moderate"、"long"、または "eternal"、構成不可、デフォルトは テストの size 属性から 返される前に予想されるテスト実行時間。 テストのサイズ属性はリソースの見積もりを制御しますが、テストのサイズ属性はリソースの見積もりを 個別に設定できます。明示的に指定しない場合、 タイムアウトはテストサイズに基づきます。テスト タイムアウトは --test_timeout フラグでオーバーライドできます。次に例を示します。 特定の状況下で動作することは 遅くなりますテストのタイムアウト値 次の期間に対応します。 タイムアウト値 期間 short 1 分 中 5 分 long 15 分 永遠 60 分 上記以外の時間では、テストのタイムアウトは --test_timeout bazel フラグ。例:手動で実行する場合の 予測します。--test_timeout 値 秒単位です。たとえば、--test_timeout=120 はテストを設定します。 2 分にタイムアウトします 環境変数 TEST_TIMEOUT は、テストの生成時にテストのタイムアウト（秒単位）に設定されます。
flaky	ブール値設定不可 デフォルトは False です テストを「不安定」としてマークします。 設定すると、テストが 3 回まで実行され、失敗した場合にのみ不合格としてマークされます 失敗します。デフォルトでは、この属性は False に設定されており、テストは 1 回だけ実行されます。なお、この属性は、通常は使用しないことをおすすめします。 テストは、アサーションが維持されていれば、確実に合格する必要があります。
shard_count	50 以下の正の整数。デフォルトは -1 です。 並列シャードの数を指定します 使用できます。 設定した場合、この値は、インプレッションの数を決めるために使用される テスト実行に使用する並列シャードを指定します一部のテストでは このパラメータは、シャーディングの有効化に あります。--test_sharding_strategy もご覧ください。 テストのシャーディングが有効になっている場合、テストの生成時に環境変数 TEST_TOTAL_SHARDS がこの値に設定されます。 シャーディングを行うには、テストランナーがテストのシャーディング プロトコルをサポートしている必要があります。 そうでない場合は、すべてのシャードですべてのテストが実行される可能性が高いため、 意図したものではありません。 詳しくは、 テストのシャーディング をご覧ください。
local	ブール値設定不可 デフォルトは False です テストをサンドボックス化せずにローカルで強制的に実行します。 True に設定すると、「local」を指定するのと同じ結果になります。タグとして （tags=["local"]）。

すべてのバイナリルールに共通する属性（*_binary）

このセクションでは、すべてのバイナリルールに共通する属性について説明します。

属性	説明
args	文字列のリスト。条件 $(location) と [変数を作成] で置換する Bourne Shell のトークン化: 構成不可、 デフォルトは [] Bazel の実行時にターゲットに渡すコマンドライン引数 run コマンドで指定するか、テストとして指定します。これらの引数は、 bazel run で指定されたものよりも前に渡されます。 bazel test コマンドライン。 注: ターゲットの実行時に引数は渡されません。 Bazel 以外（たとえば、Terraform でバイナリを手動で実行する、 bazel-bin/）。
env	文字列の辞書適用される $(location) と 「変数を作成」デフォルトは {} ターゲットの作成時に設定する追加の環境変数を指定します。 bazel run が実行します。 この属性はネイティブ ルール（cc_binary、py_binary、 および sh_binary。Starlark で定義されている実行可能ファイルには適用されません。 注: ターゲットの実行時に環境変数は設定されません。 Bazel 以外（たとえば、Terraform でバイナリを手動で実行する、 bazel-bin/）。
output_licenses	文字列のリスト。デフォルトは [] です。 このバイナリが生成する出力ファイルのライセンス。 これは、Bazel で使用されなくなった非推奨のライセンス API の一部です。すべきでないこと 使用します。

構成可能な属性

ほとんどの属性は「構成可能」です。つまり、実行時に値が変更されることがあります。 ターゲットはさまざまな方法で構築されます。具体的には、構成可能な属性が Bazel コマンドラインに渡されるフラグ、または 下流の依存関係がターゲットをリクエストしています。これは 複数のプラットフォームやコンパイル モードに応じてターゲットをカスタマイズできます。

次の例では、ターゲットごとに異なるソースを宣言しています 構築できますbazel build :multiplatform_lib --cpu x86 実行中 x86_impl.cc を使用してターゲットをビルドし、 --cpu arm を指定すると、代わりに arm_impl.cc が使用されます。

cc_library(
    name = "multiplatform_lib",
    srcs = select({
        ":x86_mode": ["x86_impl.cc"],
        ":arm_mode": ["arm_impl.cc"]
    })
)
config_setting(
    name = "x86_mode",
    values = { "cpu": "x86" }
)
config_setting(
    name = "arm_mode",
    values = { "cpu": "arm" }
)

select() 関数 構成可能な属性の代替値が選択されます。 対象: config_setting または constraint_value ターゲットの構成が満たしている条件を定義します。

Bazel は、マクロの処理の後と前に構成可能な属性を評価します 処理ルール（厳密には、 読み込みと分析のフェーズをご覧ください。 select() の評価前の処理では、 select() が選択するブランチに格納されます。マクロなど 動作し、bazel query は、 ターゲットの構成可能な依存関係について、控えめに推測するだけです。詳しくは、 こちらのよくある質問 ルールとマクロで select() を使用する方法の詳細をご覧ください。

ドキュメントで nonconfigurable とマークされている属性は使用できません 使用できます。Bazel では属性を構成できないのが一般的です。 問題解決方法を判断するには、その価値を社内で知る必要があります select()。

<ph type="x-smartling-placeholder"></ph>をご覧ください。 構成可能なビルド属性をご覧ください。

暗黙的な出力ターゲット

C++ の暗黙的な出力は非推奨になりました。使用は控えてください 可能な限り他の言語で行います非推奨のパスはまだありません 最終的にはサポート終了となります。

BUILD ファイルでビルドルールを定義する場合、 新しい名前付きのルール ターゲットをパッケージ内で宣言します。多数のビルドルール 関数は、暗黙的に 1 つ以上の出力ファイルを伴う その内容と意味はルール固有です。 たとえば、明示的に宣言する java_binary(name='foo', ...) 個のルールに加えて、 出力ファイルの暗黙的な宣言 foo_deploy.jar を同じパッケージのメンバーとしてターゲットに設定します。 （このターゲットは自己完結型の Java アーカイブであり、 します）。

暗黙的な出力ターゲットは、 ターゲット グラフ。他のターゲットと同様にオンデマンドで構築され、 トップレベルのビルド コマンドで指定されるか、 他のビルド ターゲットに必要な前提条件です。特徴 BUILD ファイルでは依存関係として参照され、 bazel query などの分析ツールの出力。

ビルドルールの種類ごとに、ルールのドキュメントに 暗黙的な依存関係の名前と内容が 出力が生成されます。

2 つのモデルの間に重要だが、微妙な違いは 2 つの Namespace があります。 labels はターゲットを識別します。 ルールまたはファイルがあります。ファイル ターゲットは、 ソース（または入力）ファイルのターゲットと派生（または出力）ファイル できます。BUILD ファイルでは コマンドラインからビルドするか、bazel query を使用して調べる これがターゲット名前空間です。各ファイルターゲットは ディスク上の 1 つの実際のファイル（「ファイルシステムの名前空間」）。各ルール ターゲットはディスク上のゼロ、1 つ、または複数の実際のファイルに対応します。 対応するターゲットがないファイルがディスク上に存在する可能性があります。 C++ コンパイル中に生成された .o オブジェクト ファイルなど BUILD ファイル内やコマンドラインから参照することはできません。 このようにして、特定の実装の詳細がビルドツールに表示されない場合があります。 確認しますこれについては BUILD コンセプト リファレンスをご覧ください。