.bzl ファイル

_ で始まる暗黙の属性のデフォルト値は label か label_list でなければなりません。

明示的な属性の型は string 型で、values 制限を使用する必要があります。明示的な属性を使用すると、制限に従って同じ名前、タイプ、有効な値の属性を持つルールでのみ、このアスペクトを使用できます。

ネストされていないプロバイダのリストは、1 つのプロバイダのリストを含むリストに自動的に変換されます。つまり、[FooInfo, BarInfo] は自動的に [[FooInfo, BarInfo]] に変換されます。

あるルール（some_rule など）のターゲットをある側面に公開するには、some_rule が、少なくとも 1 つの必須プロバイダ リストからすべてのプロバイダをアドバタイズする必要があります。たとえば、あるアスペクトの required_providers が [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] である場合、some_rule が FooInfo、または BarInfo、あるいは BazInfo と QuxInfo の両方を提供している場合に限り、このアスペクトに some_rule ターゲットが表示されます。

ネストされていないプロバイダのリストは、1 つのプロバイダのリストを含むリストに自動的に変換されます。つまり、[FooInfo, BarInfo] は自動的に [[FooInfo, BarInfo]] に変換されます。

別のアスペクト（other_aspect など）をこのアスペクトに表示できるようにするには、other_aspect で 1 つ以上のリストからすべてのプロバイダを指定する必要があります。[[FooInfo], [BarInfo], [BazInfo, QuxInfo]] の例では、other_aspect が FooInfo、または BarInfo、または BazInfo と QuxInfo の両方を提供している場合に限り、この要素に other_aspect が表示されます。

実装関数がここに記載されているプロバイダのタイプのいずれかを戻り値から省略すると、エラーが発生します。ただし、実装関数は、ここに記載されていない追加のプロバイダを返すことがあります。

リストの各要素は provider() から返される *Info オブジェクトです。ただし、レガシー プロバイダは代わりに文字列名で表されます。このルールで必須プロバイダを宣言するターゲットの依存関係としてルールを使用する場合、そのプロバイダを指定する必要はありません。実装関数がそれを返すだけで十分です。ただし、必須ではない場合でも、指定することをおすすめします。ただし、アスペクトの required_providers フィールドでは、プロバイダを指定する必要があります。

たとえば、ある側面が「deps」属性を通じて推移的に伝播し、それがターゲット「alpha」に適用されるとします。`alpha` に `deps = [':beta_output']` がある場合、`beta_output` がターゲットの `beta` の出力を宣言していると仮定します。 `beta` に`` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` A ` ` ` ` ` A ` ` ` A ` ` ` ` A ` ` ` ` A ` ` ` A ` ` ` ` A ` ` ` ` A ` ` ` A ` ` ` ` A ` ` ` ` ` ` `、

デフォルトは False です。

• フィールドのリスト:
  

  provider(fields = ['a', 'b'])

• 辞書のフィールド名 -> ドキュメント:
  

  provider(
         fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })

直感的なディスカッションやユースケースについては、ルール（プロバイダのカスタム初期化）をご覧ください。

P を、provider() を呼び出して作成したプロバイダ シンボルにします。概念的には、P のインスタンスは、以下を行うデフォルト コンストラクタの関数 c(*args, **kwargs) を呼び出して生成されます。

• args が空でない場合、エラーが発生します。
• provider() が呼び出されたときに fields パラメータが指定されていて、kwargs に fields にリストされていないキーが含まれている場合、エラーが発生します。
• それ以外の場合は、kwargs の k: v エントリごとに、k というフィールド値 v を持つ新しいインスタンスを返します。

MyInfo = provider()
m = MyInfo(foo = 1)

ただし、init が指定されている場合、呼び出し P(*args, **kwargs) は代わりに次の手順を実行します。

1. コールバックは init(*args, **kwargs) として呼び出されます。つまり、P に渡されたものと同じ位置引数とキーワード引数が使用されます。
2. init の戻り値は辞書（d）で、キーはフィールド名の文字列であることが想定されます。そうしないと、エラーが発生します。
3. c(**d) のように、d のエントリをキーワード引数としてデフォルト コンストラクタを呼び出すことで、P の新しいインスタンスを生成します。

注意: 上記のステップは、*args または **kwargs が init のシグネチャと一致しない場合、init の本体の評価が失敗した場合（おそらく fail() の呼び出しによって失敗する場合）、または init の戻り値が期待されるスキーマの辞書でない場合に発生します。

このように、init コールバックは、前処理と検証のために位置引数と任意のロジックを許可することで、通常のプロバイダ構成を一般化します。許可されている fields のリストを回避することはできません。

init を指定すると、provider() の戻り値はタプル (P, r) になります。r は未加工のコンストラクタです。実際、r の動作は、前述のデフォルト コンストラクタ関数 c の動作とまったく同じです。通常、r は、先頭にアンダースコアが付いた変数にバインドされるため、現在の .bzl ファイルのみが直接アクセスできます。

MyInfo, _new_myinfo = provider(init = ...)

事前に宣言された出力を定義するスキーマ。output 属性や output_list 属性とは異なり、ユーザーはこれらのファイルのラベルを指定しません。事前に宣言された出力について詳しくは、ルールのページをご覧ください。

この引数の値は、辞書、または辞書を生成するコールバック関数です。コールバックは、計算済みの依存関係属性と同様に動作します。たとえば、関数のパラメータ名とルールの属性が照合されるため、たとえば、定義 def _my_func(srcs, deps): ... を指定して outputs = _my_func を渡すと、関数では属性 srcs と deps にアクセスできます。辞書が直接指定されているか、関数を介して指定されているかに関係なく、次のように解釈されます。

辞書の各エントリで、事前に宣言された出力が作成されます。ここで、キーは識別子、値は出力のラベルを決定する文字列テンプレートです。ルールの実装関数では、この識別子が、ctx.outputs の出力 File へのアクセスに使用されるフィールド名になります。出力のラベルはルールと同じパッケージであり、"%{ATTR}" という形式の各プレースホルダを属性 ATTR の値から形成される文字列に置き換えることで、パッケージの後の部分が生成されます。

• 文字列型の属性は、逐語的に置き換えます。
• ラベル型の属性は、パッケージの拡張子を省いてファイル拡張子を除いた部分になります。たとえば、ラベル "//pkg:a/b.c" は "a/b" になります。
• 出力型の属性は、ファイル拡張子を含むラベルの後の部分になります（上記の例では "a/b.c"）。
• プレースホルダで使用されるすべてのリスト型属性（attr.label_list など）には、要素が 1 つだけ必要です。コンバージョンが非リスト バージョン（attr.label）と同じである。
• その他の属性タイプは、プレースホルダに表示されない場合があります。
• 特別な非属性プレースホルダ %{dirname} と %{basename} は、ルールの該当部分（パッケージを除く）に展開されます。たとえば、"//pkg:a/b.c" で、dirname は a、basename は b.c です。

実際には、最も一般的な置換プレースホルダは "%{name}" です。たとえば、「foo」という名前のターゲットの場合、出力ディクショナリ {"bin": "%{name}.exe"} は、実装関数内で ctx.outputs.bin としてアクセス可能な foo.exe という出力をあらかじめ宣言します。

実装関数がここに記載されているプロバイダのタイプのいずれかを戻り値から省略すると、エラーが発生します。ただし、実装関数は、ここに記載されていない追加のプロバイダを返すことがあります。

リストの各要素は provider() から返される *Info オブジェクトです。ただし、レガシー プロバイダは代わりに文字列名で表されます。このルールで必須プロバイダを宣言するターゲットの依存関係としてルールを使用する場合、そのプロバイダを指定する必要はありません。実装関数がそれを返すだけで十分です。ただし、必須ではない場合でも、指定することをおすすめします。ただし、アスペクトの required_providers フィールドでは、プロバイダを指定する必要があります。

注: 分析テストルールは主に、Starlark のコアライブラリで提供されるインフラストラクチャを使用して定義されます。詳しくは、テストをご覧ください。

分析テストルールとしてルールを定義すると、その属性に対して analysis_test_transition を使用して定義された構成遷移を使用できますが、いくつかの制限が適用されます。

• このルールのターゲットは、推移的依存関係の数が制限されています。
• このルールは、test=True が設定されているかのように、テストルールとみなされます。これは test の値よりも優先されます
• ルールの実装関数ではアクションを登録できません。代わりに、AnalysisTestResultInfo を指定して、合否の結果を登録する必要があります。

このルールの名前。Bazel によって認識され、ロギング、native.existing_rule(...)[kind]、bazel query などのコンテキストで報告されます。これは通常、このルールにバインドされる Starlark 識別子と同じです。たとえば、foo_library というルールは通常 foo_library = rule(...) として宣言され、BUILD ファイルで foo_library(...) としてインスタンス化されます。

このパラメータを省略すると、宣言する .bzl モジュール内で、このルールに最初にバインドされる Starlark グローバル変数の名前がルールの名前に設定されます。したがって、名前が foo_library の場合は foo_library = rule(...) でこのパラメータを指定する必要はありません。

ルールの明示的な名前を指定しても、ルールをインスタンス化できる場所は変更されません。

パッケージの仕様は package_group の形式を使用しますが、負のパッケージ仕様は使用できません。つまり、仕様は次の形式になります。

• "//foo": パッケージ //foo
• "//foo/...": パッケージ //foo とそのすべてのサブパッケージ。
• "public" または "private": それぞれすべてのパッケージまたはなし

「@」構文は使用できません。すべての指定は、現在のモジュールのリポジトリを基準として解釈されます。

value が文字列のリストの場合、このモジュールへの表示が許可されているパッケージのセットが、各仕様で表されるパッケージを組み合わせたものです。（空のリストは、private と同じ結果になります）。value が単一の文字列の場合、これはシングルトン リスト [value] と同じように扱われます。

--incompatible_package_group_has_public_syntax フラグと --incompatible_fix_package_group_reporoot_syntax フラグはこの引数には影響しません。"public" と "private" の値は常に使用可能で、"//..." は常に「現在のリポジトリ内のすべてのパッケージ」として解釈されます。