この一連のルールは、ビルド対象の特定のハードウェア プラットフォームをモデル化し、それらのプラットフォームのコードをコンパイルするために必要な特定のツールを指定できるようにするために存在します。ユーザーは、こちらで説明されているコンセプトに精通している必要があります。
ルール
constraint_setting
ルールソースを表示constraint_setting(name, default_constraint_value, deprecation, distribs, features, licenses, tags, testonly, visibility)
このルールは、プラットフォームが値を指定できる新しい制約タイプを導入するために使用されます。たとえば、「glibc_version」という名前の constraint_setting を定義して、プラットフォームに異なるバージョンの glibc ライブラリがインストールされている機能を表すことができます。詳細については、プラットフォームのページをご覧ください。
各 constraint_setting には、関連付けられた拡張可能な constraint_value のセットが用意されています。通常、これらは同じパッケージで定義されますが、既存の設定に新しい値が別のパッケージで導入されることもあります。たとえば、不明な CPU アーキテクチャをターゲットとするプラットフォームを定義するために、事前定義された設定 @platforms//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",
)
プラットフォームは、x86_64、arm などの代わりに mips アーキテクチャがあることを宣言できます。
引数
| 属性 | |
|---|---|
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を継承し、k1の値をオーバーライドします。exec_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 が提供するロールを表す 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 |
名前: 必須 このターゲットの名前。 |