このルールセットは、ビルド対象の特定のハードウェア プラットフォームをモデル化し、それらのプラットフォームのコードをコンパイルするために必要な特定のツールを指定できるようにするために存在します。ユーザーは、こちらで説明されているコンセプトを理解している必要があります。
ルール
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_setting と同じパッケージで、この属性が指す constraint_value を定義する必要があります。制約設定にデフォルト値がある場合、プラットフォームがその設定の制約値を指定していないときは、プラットフォームがデフォルト値を指定した場合と同じになります。それ以外の場合で、デフォルト値がない場合、制約設定はプラットフォームによって指定されていないと見なされます。その場合、プラットフォームは、その設定に特定の値が必要な制約リスト( |
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(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 属性はリストを受け取りますが、現在サポートされているのは単一の値のみです。複数の親を指定するとエラーになります。
プラットフォームで制約設定の値を確認する場合、最初に直接設定された値(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
|
このプラットフォームが構成する制約の選択の組み合わせ。プラットフォームを特定の環境に適用するには、環境にこのリストの少なくとも 1 つの値が必要です。 このリストの各 |
exec_properties
|
ディクショナリ: 文字列 -> 文字列。構成不可。デフォルトは exec_properties 属性のデータも含まれます。子プラットフォームと親プラットフォームで同じキーが定義されている場合、子の値が保持されます。空の文字列である値に関連付けられているキーは、辞書から削除されます。この属性は、非推奨の remote_execution_properties に完全に代わるものです。 |
flags
|
文字列のリスト。設定不可。デフォルトは |
parents
|
このプラットフォームが継承する platform ターゲットのラベル。この属性はリストを受け取りますが、プラットフォームは 1 つのみ存在する必要があります。このプラットフォームで直接設定されていない constraint_settings は、親プラットフォームで確認できます。詳しくは、プラットフォームの継承のセクションをご覧ください。 |
remote_execution_properties
|
文字列。構成不可。デフォルトは |
required_settings
|
ラベルのリスト。デフォルトは config_setting のリスト。必須の設定が親プラットフォームから継承されていません。 |
ツールチェーン
ルールソースを表示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 |
名前(必須) このターゲットの一意の名前。 |