このルールセットは、ビルド対象の特定のハードウェア プラットフォームをモデル化し、それらのプラットフォームのコードをコンパイルするために必要な特定のツールを指定するために使用されます。 ユーザーは、ここで説明するコンセプトを理解している必要があります。
ルール
constraint_setting
ルールのソースを表示constraint_setting(name, default_constraint_value, deprecation, distribs, features, licenses, tags, testonly, visibility)
このルールは、プラットフォームが値を指定できる新しい制約タイプを導入するために使用されます。
たとえば、プラットフォームに異なるバージョンの glibc ライブラリをインストールする機能を表現するために、「glibc_version」という名前の constraint_setting を定義できます。
詳細については、
プラットフォームのページをご覧ください。
各 constraint_setting には、関連する
constraint_value の拡張可能なセットがあります。通常、これらは同じパッケージで定義されますが、場合によっては、別のパッケージで既存の設定に新しい値が導入されることがあります。たとえば、事前定義された
設定 @platforms//cpu:cpu は、カスタム値で拡張して、不明な CPU アーキテクチャをターゲットとするプラットフォームを定義できます。
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 |
default_constraint_value
|
値が指定されていない場合に使用される、この設定のデフォルト値のラベル。この属性が存在する場合、この属性が指す constraint_value は、この constraint_setting と同じパッケージで定義する必要があります。制約設定にデフォルト値がある場合、プラットフォームにその設定の制約値が含まれていないときは、プラットフォームがデフォルト値を指定した場合と同じになります。それ以外の場合、デフォルト値がない場合、制約設定はそのプラットフォームで指定されていないと見なされます。その場合、プラットフォームは、その設定に特定の値が必要な
制約リスト（ |
constraint_value
ルールのソースを表示constraint_value(name, constraint_setting, deprecation, distribs, features, licenses, tags, testonly, visibility)
例
次の例では、CPU アーキテクチャを表す事前定義された constraint_value
の新しい可能な値を作成します。
constraint_value(
name = "mips",
constraint_setting = "@platforms//cpu:cpu",
)
mips アーキテクチャを
x86_64、arm などの代替として使用することを宣言できます。
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 |
constraint_setting
|
この constraint_value が選択可能な constraint_setting。 |
platform
ルールのソースを表示platform(name, constraint_values, deprecation, distribs, exec_properties, features, flags, licenses, parents, remote_execution_properties, required_settings, tags, testonly, visibility)
このルールは、新しいプラットフォームを定義します。これは、ビルドの一部が実行される環境を記述する制約の選択肢 （CPU アーキテクチャやコンパイラ バージョンなど）の名前付きコレクションです。 ビルドの一部が実行される環境を記述する制約の選択肢 詳細については、プラットフォームのページをご覧ください。
例
これは、ARM で Linux を実行する環境を記述するプラットフォームを定義します。
platform(
name = "linux_arm",
constraint_values = [
"@platforms//os:linux",
"@platforms//cpu:arm",
],
)
プラットフォーム フラグ
プラットフォームは、flags 属性を使用して、プラットフォームがターゲット プラットフォームとして使用されるたびに構成に追加されるフラグのリストを指定できます（つまり、--platforms フラグの値として）。
プラットフォームから設定されたフラグは、事実上最も優先度が高く、コマンドライン、rc ファイル、または遷移から、そのフラグの以前の 値を上書きします。
例
platform(
name = "foo",
flags = [
"--dynamic_mode=fully",
"--//bool_flag",
"--no//package:other_bool_flag",
],
)
これにより、foo という名前のプラットフォームが定義されます。これがターゲット プラットフォームの場合（ユーザーが --platforms//:foo を指定した場合、遷移によって //command_line_option:platforms フラグが ["//:foo"] に設定された場合、または //:foo が実行プラットフォームとして使用された場合）、指定されたフラグが構成に設定されます。
プラットフォームと繰り返し可能なフラグ
一部のフラグは、繰り返されると値が累積されます（--features、
--copt、config.string(repeatable = True) として作成された Starlark フラグなど）。
これらのフラグは、プラットフォームからフラグを設定する場合と互換性がありません。代わりに、以前の値はすべて削除され、プラットフォームの値で上書きされます。
例として、次のプラットフォームを指定すると、build --platforms=//:repeat_demo
--features feature_a --features feature_b の呼び出しでは、
--feature フラグの値が ["feature_c", "feature_d"] になり、コマンドラインで設定された機能が削除されます。
platform(
name = "repeat_demo",
flags = [
"--features=feature_c",
"--features=feature_d",
],
)
このため、flags 属性で繰り返し可能なフラグを使用することはおすすめしません。
プラットフォームの継承
プラットフォームは、parents 属性を使用して、制約値を継承する別のプラットフォームを
指定できます。parents 属性はリストを受け取りますが、現在サポートされている値は 1 つのみです。複数の親を指定するとエラーになります。
プラットフォームで制約設定の値を確認する場合、最初に直接設定された値
（constraint_values 属性を使用）が確認され、次に親の制約値が確認されます。これは、親プラットフォームのチェーンを再帰的に続行します。このようにして、プラットフォームに直接設定された
値は、親に設定された値をオーバーライドします。
プラットフォームは、親プラットフォームから exec_properties 属性を継承します。
親プラットフォームと子プラットフォームの exec_properties のディクショナリ エントリが結合されます。
親と子の exec_properties、
の両方に同じキーが表示される場合は、子の値が使用されます。子プラットフォームで空の文字列が値として指定されている場合、対応するプロパティは設定解除されます。
プラットフォームは、親プラットフォームから（非推奨の）remote_execution_properties 属性
を継承することもできます。注: 新しいコードでは、代わりに exec_properties を使用する必要があります。以下で説明するロジックは、以前の動作との互換性を維持するために保持されますが、将来削除されます。
親プラットフォームがある場合、remote_execution_platform を設定するロジックは次のとおりです。
-
子プラットフォームで
remote_execution_propertyが設定されていない場合、親のremote_execution_propertiesが使用されます。 -
子プラットフォームで
remote_execution_propertyが設定されていて、リテラル文字列 {PARENT_REMOTE_EXECUTION_PROPERTIES} が含まれている場合、そのマクロは親のremote_execution_property属性の内容に置き換えられます。 -
子プラットフォームで
remote_execution_propertyが設定されていて、マクロが含まれていない場合、子のremote_execution_propertyは変更されずに使用されます。
remote_execution_properties は非推奨であり、段階的に廃止されるため、同じ継承チェーンで
remote_execution_properties と exec_properties を混在させることはできません。
非推奨の
remote_execution_propertiesよりもexec_propertiesを使用することをおすすめします。
例: 制約値
platform(
name = "parent",
constraint_values = [
"@platforms//os:linux",
"@platforms//cpu:arm",
],
)
platform(
name = "child_a",
parents = [":parent"],
constraint_values = [
"@platforms//cpu:x86_64",
],
)
platform(
name = "child_b",
parents = [":parent"],
)
この例では、子プラットフォームに次のプロパティがあります。
-
child_aには、制約値@platforms//os:linux（親から継承）と@platforms//cpu:x86_64（プラットフォームに直接設定）があります。 -
child_bは、親からすべての制約値を継承し、独自の制約値を設定しません。
例: 実行プロパティ
platform(
name = "parent",
exec_properties = {
"k1": "v1",
"k2": "v2",
},
)
platform(
name = "child_a",
parents = [":parent"],
)
platform(
name = "child_b",
parents = [":parent"],
exec_properties = {
"k1": "child"
}
)
platform(
name = "child_c",
parents = [":parent"],
exec_properties = {
"k1": ""
}
)
platform(
name = "child_d",
parents = [":parent"],
exec_properties = {
"k3": "v3"
}
)
この例では、子プラットフォームに次のプロパティがあります。
-
child_aは親の "exec_properties" を継承し、独自のプロパティを設定しません。 -
child_bは親のexec_propertiesを継承し、 の値をオーバーライドします。k1exec_propertiesは{ "k1": "child", "k2": "v2" }になります。 -
child_cは親のexec_propertiesを継承し、k1を設定解除します。exec_propertiesは{ "k2": "v2" }になります。 -
child_dは親のexec_propertiesを継承し、新しい プロパティを追加します。exec_propertiesは{ "k1": "v1", "k2": "v2", "k3": "v3" }になります。
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 |
constraint_values
|
このプラットフォームを構成する制約の選択肢の組み合わせ。プラットフォームが特定の環境に適用されるためには、環境にこのリストの値が少なくとも含まれている必要があります。
このリストの各 |
exec_properties
|
ディクショナリ: 文字列 -> 文字列（構成不可）。デフォルトは exec_properties 属性のデータが含まれます。
子プラットフォームと親プラットフォームで同じキーが定義されている場合、子の値が保持されます。空の文字列の値に関連付けられているキーは、ディクショナリから削除されます。
この属性は、非推奨の
remote_execution_properties の完全な代替です。
|
flags
|
文字列のリスト（構成不可）。デフォルトは |
parents
|
このプラットフォームが継承する platform ターゲットのラベル。属性はリストを受け取りますが、プラットフォームは 1 つ以下にする必要があります。このプラットフォームに直接設定されていない
constraint_settings は、親プラットフォームにあります。
詳細については、プラットフォームの継承のセクションをご覧ください。
|
remote_execution_properties
|
文字列（構成不可）。デフォルトは |
required_settings
|
ラベルのリスト。デフォルトは config_setting のリスト。必要な設定は、親プラットフォームから継承されません。
|
toolchain
ルールのソースを表示toolchain(name, deprecation, distribs, exec_compatible_with, features, licenses, tags, target_compatible_with, target_settings, testonly, toolchain, toolchain_type, visibility)
このルールは、ツールチェーンの解決中に選択できるように、特定のツールチェーンのタイプと制約を宣言します。 詳細については、 ツールチェーンのページをご覧ください。
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 |
exec_compatible_with
|
このツールチェーンがそのプラットフォームでビルドするターゲットに対して選択されるために、実行プラットフォームで満たす必要がある constraint_value のリスト。 |
target_compatible_with
|
このツールチェーンがそのプラットフォーム用にビルドするターゲットに対して選択されるために、ターゲット プラットフォームで満たす必要がある constraint_value のリスト。 |
target_settings
|
ラベルのリスト。デフォルトは config_setting のリスト。 |
toolchain
|
名前（必須） このツールチェーンが選択されたときに使用可能になる実際のツールまたはツールスイートを表すターゲット。 |
toolchain_type
|
このツールチェーンが果たす役割を表す toolchain_type ターゲットのラベル。 |
toolchain_type
ルールのソースを表示toolchain_type(name, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
このルールは、新しいタイプのツールチェーンを定義します。これは、さまざまなプラットフォームで同じ役割を果たすツールのクラスを表すシンプルなターゲットです。
詳細については、ツールチェーンのページをご覧ください。
例
これにより、カスタムルールのツールチェーン タイプが定義されます。
toolchain_type(
name = "bar_toolchain_type",
)
これは bzl ファイルで使用できます。
bar_binary = rule(
implementation = _bar_binary_impl,
attrs = {
"srcs": attr.label_list(allow_files = True),
...
# No `_compiler` attribute anymore.
},
toolchains = ["//bar_tools:toolchain_type"]
)
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 |