BazelCon 2024 登録の受け付けを開始しました。

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

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

問題を報告ソースを表示夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

ルール

<ph type="x-smartling-placeholder"></ph> constraint_setting
<ph type="x-smartling-placeholder"></ph> constraint_value
<ph type="x-smartling-placeholder"></ph> プラットフォーム
<ph type="x-smartling-placeholder"></ph> ツールチェーン
<ph type="x-smartling-placeholder"></ph> toolchain_type

constraint_setting

<ph type="x-smartling-placeholder"></ph> ルールのソースを表示

constraint_setting(name, default_constraint_value, deprecation, distribs, features, licenses, tags, testonly, visibility)

このルールは、プラットフォームで値を指定できる新しい制約タイプを導入するために使用されます。たとえば、「glibc_version」という名前の constraint_setting を定義できます。表すプラットフォームに異なるバージョンの glibc ライブラリをインストールする機能。詳しくは、プラットフォームページ。

各 constraint_setting には、拡張可能な一連の関連する constraint_value 秒。通常、これらは同じパッケージで定義されますが、別のパッケージでは、既存の設定に新しい値が導入されます。たとえば、事前定義された @platforms//cpu:cpu の設定をカスタム値で拡張することで、不明な CPU アーキテクチャをターゲットとするプラットフォームを定義しています。

引数

属性

name

名前:必須

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

default_constraint_value

名前:構成不可デフォルトは None

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

制約設定にデフォルト値がある場合、プラットフォームに制約の値を指定している場合は、プラットフォームがデフォルト値です。デフォルト値がない場合、制約の設定が考慮されます。指定することはできません。この場合、そのプラットフォームはどのポリシーにも一致しません。特定の値を必要とする制約リスト（config_setting 用など）その設定を選択します。

constraint_value

<ph type="x-smartling-placeholder"></ph> ルールのソースを表示

constraint_value(name, constraint_setting, deprecation, distribs, features, licenses, tags, testonly, visibility)

このルールにより、特定の制約タイプに新しい値が導入されます。詳しくは、プラットフォームページ。

例

以下では、事前定義の constraint_value に使用できる新しい値を作成します。 CPU アーキテクチャを表します

constraint_value(
    name = "mips",
    constraint_setting = "@platforms//cpu:cpu",
)

プラットフォームは、代わりに mips アーキテクチャがあることを宣言できます。 x86_64、arm など。

引数

属性

name

名前:必須

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

constraint_setting

ラベル:構成不可必須

この constraint_value に該当する constraint_setting 選択肢になります。

プラットフォーム

<ph type="x-smartling-placeholder"></ph> ルールのソースを表示

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 属性はリストを受け取りますが、現在、複数の値がサポートされており、複数の親を指定するとエラーになります。

プラットフォームの制約設定の値をチェックするときは、まず、（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 を同じ継承チェーンは使用できません。非推奨ではなく exec_properties を優先する remote_execution_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`	ラベルのリスト。構成不可デフォルトは `[]` このプラットフォームに含まれる制約の選択肢の組み合わせ。プラットフォームは環境に適用するには、少なくともこのリストの値が必要です。このリストの各 `constraint_value` は、それぞれ異なる `constraint_setting`。たとえば、Terraform で記述されたコードを必要とするプラットフォームを CPU アーキテクチャを `@platforms//cpu:x86_64` と `@platforms//cpu:arm`。
`exec_properties`	辞書: 文字列 ->String;設定不可デフォルトは `{}` ですアクションをリモートで実行する方法に影響を与える文字列のマップ。Bazel が試行しないこれは不透明なデータとして扱われリモート実行プロトコルを使用します。これには、親プラットフォームの `exec_properties` 属性のデータが含まれます。子と親プラットフォームで同じキーを定義している場合、子の値は保持されます。制限なし空の文字列の値に関連付けられているキーは辞書から削除されます。この属性は、サポートが終了した `remote_execution_properties`。
`parents`	ラベルのリスト。構成不可デフォルトは `[]` このプラットフォームが継承する `platform` ターゲットのラベル。ただし、この属性にはリストを指定します。複数のプラットフォームを指定することはできません。制限なしこのプラットフォームで直接設定されていない constraint_settings は、親プラットフォームで確認できます。詳しくは、プラットフォームの継承をご覧ください。
`remote_execution_properties`	String;設定不可デフォルトは `""` です非推奨。代わりに exec_properties 属性を使用してください。リモート実行プラットフォームを構成するために使用される文字列。実際のビルドでは、これを解釈すると、特定の SpawnRunner が使用できる不透明なデータとして扱われます。これには、親プラットフォームの「remote_execution_properties」のデータが含まれます。属性、マクロ「{PARENT_REMOTE_EXECUTION_PROPERTIES}」を使用します。詳しくは、プラットフォームの継承をご覧ください。

ツールチェーン

<ph type="x-smartling-placeholder"></ph> ルールのソースを表示

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

<ph type="x-smartling-placeholder"></ph> ルールのソースを表示

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

名前:必須

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