一般的な定義

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

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

目次

Bourne シェルのトークン化

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

このトークン化の対象となる属性は、このドキュメントの定義で明示的に示されています。

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

ラベルの展開

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

属性の例には、genrule.cmdcc_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 属性。定義を表示 dependencies をご覧ください。

licenses

文字列のリスト。構成不可。デフォルトは ["none"] です。

この特定のターゲットに使用されるライセンス タイプの文字列のリスト。 これは、Bazel で使用されなくなった非推奨のライセンス API の一部です。すべきでないこと 使用します。

srcs

ラベルのリスト。デフォルトは [] です

このルールによって処理または追加されたファイル。通常はファイルを直接リストしますが、デフォルト出力を含めるようにルール ターゲット(filegroupgenrule など)をリストすることもできます。

言語固有のルールでは、リスト内のファイルに特定のファイル拡張子が必要になることがよくあります。

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

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

属性 説明
compatible_with

ラベルのリスト。 構成不可デフォルトは []

以下に加えて、このターゲットを構築できる環境のリスト 環境に依存しています。

これは Bazel の制約システムの一部です。これにより、ユーザーはどの Pod が ターゲット同士の相互依存が可能です。たとえば、外部にデプロイ可能な バイナリは、企業秘密のコードを含むライブラリに依存すべきではありません。詳しくは、 ConstraintSemantics をご覧ください。

deprecation

文字列。構成不可。デフォルトは 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 は次の場合にサンドボックス コードの動作を変更します。 任意のテストまたは genruletags 属性内のキーワード ターゲット、または任意の 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-cacheno-remote-exec
  • no-remote-cache-upload キーワードは、spawn のリモート キャッシュの一部のアップロードを無効にします。 リモート実行が無効になることはありません。
  • local キーワードにより、アクションまたはテストがリモート キャッシュから排除される。 サンドボックス内で実行することもできます。 genrule とテストの場合、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 キーワードを使用すると、buildtestcoverage コマンドに対してビルドまたは実行するトップレベル ターゲットのセットを計算するときに、ターゲット パターンのワイルドカード(...:*:all など)と、テストを明示的にリストしない test_suite ルールの展開からターゲットが除外されます。残念ながら、 他のコンテキストでは、ターゲット ワイルドカードやテストスイートの拡張に query コマンドを使用します。なお、manual は、ターゲットを 継続的なビルド/テストシステムで自動的にビルド/実行されない。たとえば、 特定のターゲットが必要なため、bazel test ... からターゲットを除外することが推奨されます。 Bazel フラグだが、適切に構成された presubmit または継続的テストに含まれている 実行されます
  • external キーワードを指定すると、強制的にテストが無条件に行われます 実行(--cache_test_results に関係なく) あります。
テスト対象に適用されるタグの規則については、テスト エンサイクロペディアのタグの規則をご覧ください。
target_compatible_with

ラベルのリスト。デフォルトは [] です

リスト constraint_values 必須フィールドです。 互換性。これは、 選択します。ターゲット プラットフォームがリストされている制約をすべて満たしていない場合、 ターゲットは互換性がないと見なされます。互換性のないターゲットは ターゲット パターンが拡張されたときにビルドとテストではスキップされます (例: //...: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 属性は、ターゲットを他のパッケージで使用できるかどうかを制御します。公開設定のドキュメントをご覧ください。

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

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

属性 説明
args

文字列のリスト。条件 $(location) と [変数を作成] で置換する Bourne Shell のトークン化:デフォルトは [] です

Bazel がターゲットに渡すコマンドライン引数 bazel test で実行されます。

これらの引数は、bazel test コマンドラインで指定された --test_arg 値の前に渡されます。

env

文字列の辞書適用される $(location) と 「変数を作成」デフォルトは []

テストの実行時に設定する追加の環境変数を指定します。 bazel test

この属性は、cc_test などのネイティブ ルールにのみ適用されます。 py_testsh_test。適用対象外 Starlark が定義したテストルール。独自の Starlark ルールの場合は、環境変数に「env」と その属性を使用して TestEnvironment

env_inherit

文字列のリスト。デフォルトは [] です。

プロジェクトから継承する追加の環境変数を bazel test がテストを実行したときの外部環境。

この属性は、cc_testpy_testsh_test などのネイティブ ルールにのみ適用されます。Starlark で定義されたテストルールには適用されません。

size

文字列 "enormous""large""medium"、または "small";構成不可、 デフォルトは "medium" です

テスト ターゲットの「重さ」、つまり実行に必要な時間/リソースを指定します。

単体テストは「小規模」、統合テストは「中」、エンドツーエンド テストは「大規模」と見なされますまたは 「enormous」です。Bazel はこのサイズを使用してデフォルトのタイムアウトを決定します。デフォルトのタイムアウトは timeout 属性。タイムアウトは、個々のテストではなく、BUILD ターゲットのすべてのテストに適用されます。テストをローカルで実行する場合、さらに 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 シェルのトークン化の対象。構成不可。デフォルトは []

Bazel の実行時にターゲットに渡すコマンドライン引数 run コマンドで指定するか、テストとして指定します。これらの引数は、 bazel run で指定されたものよりも前に渡されます。 bazel test コマンドライン。

注: ターゲットの実行時に引数は渡されません。 Bazel 以外(たとえば、Terraform でバイナリを手動で実行する、 bazel-bin/)。

env

文字列の辞書適用される $(location) と 「変数を作成」デフォルトは {}

ターゲットの作成時に設定する追加の環境変数を指定します。 bazel run が実行します。

この属性はネイティブ ルール(cc_binarypy_binary、 および sh_binary。Starlark で定義されている実行可能ファイルには適用されません。

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