安定版リリースのドキュメントについては、[バージョニングされたドキュメント] プルダウンを使用してください。デフォルトのビューには HEAD の最新バージョンが表示されます。

このページは Cloud Translation API によって翻訳されました。

プラットフォームとツールチェーンのルール

この一連のルールにより、構築する特定のハードウェアプラットフォームをモデル化し、それらのプラットフォームのコードをコンパイルするために必要な特定のツールを指定できます。ユーザーは、こちらで説明されているコンセプトを理解している必要があります。

ルール

constraint_setting
constraint_value
プラットフォーム
ツールチェーン
toolchain_type

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

Name; required

このターゲットの一意の名前。

default_constraint_value

Name; optional; nonconfigurable

この設定のデフォルト値のラベル。値が指定されていない場合に使用されます。この属性が存在する場合、constraint_value が指す属性は、この constraint_setting と同じパッケージで定義される必要があります。

制約設定にデフォルト値がある場合、プラットフォームにその設定の制約値が含まれていない場合、プラットフォームがデフォルト値を指定している場合と同じになります。デフォルト値がない場合、制約設定はそのプラットフォームによって未指定とみなされます。その場合、その設定に対して特定の値を必要とする制約リスト（config_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

Name; required

このターゲットの一意の名前。

constraint_setting

Label; required; nonconfigurable

この constraint_value を選択できる constraint_setting。

プラットフォーム

ルールのソースを表示

platform(name, constraint_values, deprecation, distribs, exec_properties, features, licenses, parents, remote_execution_properties, tags, testonly, visibility)

このルールは、新しいプラットフォーム（CPU アーキテクチャやコンパイラバージョンなどの制約の選択肢の名前付きコレクション）を定義して、ビルドの一部を実行する環境を定義します。詳細については、プラットフォームのページをご覧ください。

例

ここでは、ARM で Linux を実行している環境を記述するプラットフォームを定義しています。

platform(
    name = "linux_arm",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:arm",
    ],
)

プラットフォームの継承

プラットフォームは、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`	`Name; required` このターゲットの一意の名前。
`constraint_values`	`List of labels; optional; nonconfigurable` このプラットフォームに含まれる制約の選択肢の組み合わせ。プラットフォームを特定の環境に適用するには、その環境に少なくともこのリストの値が必要です。このリスト内の各 `constraint_value` は、異なる `constraint_setting` に対するものでなければなりません。たとえば、CPU アーキテクチャが `@platforms//cpu:x86_64` と `@platforms//cpu:arm` の両方である必要があるプラットフォームは定義できません。
`exec_properties`	`Dictionary: String -> String; optional` リモートでのアクション方法に影響する文字列のマップBazel はこれを解釈しようとせず、不透明なデータとして扱われ、リモート実行プロトコルのプラットフォームフィールドを介して転送されます。これには、親プラットフォームの `exec_properties` 属性のデータも含まれます。子プラットフォームと親プラットフォームが同じキーを定義している場合、子の値が保持されます。空の文字列値に関連付けられているキーは辞書から削除されます。この属性は、非推奨の `remote_execution_properties` に完全に代わるものです。
`parents`	`List of labels; optional; nonconfigurable` このプラットフォームが継承する必要がある `platform` ターゲットのラベル。この属性はリストを取得しますが、複数のプラットフォームを指定することはできません。このプラットフォームに直接設定されていない constraint_settings は、親プラットフォームにあります。詳しくは、プラットフォームの継承をご覧ください。
`remote_execution_properties`	`String; optional` 非推奨。代わりに exec_properties 属性を使用してください。リモート実行プラットフォームの構成に使用する文字列。実際のビルドではこの解釈は行われず、特定の SpawnRunner で使用できる不透明なデータとして扱われます。マクロ「{PARENT_REMOTE_EXECUTION_PROPERTIES}」を使用して、親プラットフォームの「remote_execution_properties」属性のデータを含めることができます。詳しくは、プラットフォームの継承をご覧ください。

ツールチェーン

ルールのソースを表示

toolchain(name, deprecation, distribs, exec_compatible_with, features, licenses, tags, target_compatible_with, target_settings, testonly, toolchain, toolchain_type, visibility)

このルールは、特定のツールチェーンのタイプと制約を宣言し、ツールチェーンの解決中に選択できるようにします。詳細については、ツールチェーンのページをご覧ください。

引数

属性
`name`	`Name; required` このターゲットの一意の名前。
`exec_compatible_with`	`List of labels; optional; nonconfigurable` 実行プラットフォームが、そのプラットフォーム上のターゲットビルドに対してこのツールチェーンを選択するために満たす必要がある `constraint_value` のリスト。
`target_compatible_with`	`List of labels; optional; nonconfigurable` ターゲットプラットフォームがこのターゲットビルドでこのツールチェーンを選択するのに必要なターゲットの `constraint_value` のリスト。
`target_settings`	`List of labels; optional` ツールチェーンの解決中にこのツールチェーンを選択するには、ターゲット構成で満たす必要がある `config_setting` のリスト。
`toolchain`	`Name; required` このツールチェーンが選択されたときに使用可能になる実際のツールまたはツールスイートを表すターゲット。
`toolchain_type`	`Label; required; nonconfigurable` このツールチェーンが提供するロールを表す `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

Name; required

このターゲットの一意の名前。