กฎแพลตฟอร์มและเชนเครื่องมือ

ชุดกฎนี้มีไว้เพื่อให้คุณจำลองแพลตฟอร์มฮาร์ดแวร์เฉพาะที่คุณกำลังสร้าง และระบุเครื่องมือเฉพาะที่คุณอาจต้องใช้เพื่อคอมไพล์โค้ดสำหรับแพลตฟอร์มเหล่านั้น ผู้ใช้ควรคุ้นเคยกับแนวคิดที่อธิบายไว้ที่นี่

กฎ

• constraint_setting
• constraint_value
• แพลตฟอร์ม
• toolchain
• toolchain_type

constraint_setting

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

กฎนี้ใช้เพื่อแนะนำประเภทข้อจำกัดใหม่ซึ่งแพลตฟอร์มอาจระบุค่าได้ เช่น คุณอาจกำหนด constraint_setting ที่มีชื่อว่า "glibc_version" เพื่อแสดงถึงความสามารถของแพลตฟอร์มในการติดตั้งไลบรารี glibc เวอร์ชันต่างๆ ดูรายละเอียดเพิ่มเติมได้ที่หน้าแพลตฟอร์ม

constraint_setting แต่ละรายการจะมีชุด constraint_value ที่เชื่อมโยงกันซึ่งขยายได้ โดยปกติแล้ว รายการเหล่านี้จะกำหนดไว้ในแพ็กเกจเดียวกัน แต่บางครั้งแพ็กเกจอื่นอาจใช้ค่าใหม่สำหรับการตั้งค่าที่มีอยู่ เช่น การตั้งค่า @platforms//cpu:cpu ที่กําหนดไว้ล่วงหน้าสามารถขยายได้ด้วยค่าที่กําหนดเองเพื่อกําหนดแพลตฟอร์มที่กําหนดเป้าหมายสถาปัตยกรรม CPU ที่ไม่ชัดเจน

อาร์กิวเมนต์

constraint_value

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

ตัวอย่าง

บรรทัดต่อไปนี้สร้างค่าใหม่ที่เป็นไปได้สําหรับ constraint_value ที่กําหนดไว้ล่วงหน้า ซึ่งแสดงถึงสถาปัตยกรรม CPU

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

อาร์กิวเมนต์

platform

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

กฎนี้กำหนดแพลตฟอร์มใหม่ ซึ่งเป็นคอลเล็กชันที่มีชื่อของตัวเลือกข้อจำกัด (เช่น สถาปัตยกรรม CPU หรือเวอร์ชันคอมไพเลอร์) ที่อธิบายสภาพแวดล้อมที่การบิลด์บางส่วนอาจทำงาน ดูรายละเอียดเพิ่มเติมได้ที่หน้าแพลตฟอร์ม

ตัวอย่าง

การดำเนินการนี้จะกำหนดแพลตฟอร์มที่อธิบายสภาพแวดล้อมที่ใช้ Linux บน ARM

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

ธงแพลตฟอร์ม

แพลตฟอร์มอาจใช้แอตทริบิวต์ flags เพื่อระบุรายการ Flag ที่ระบบจะเพิ่มลงในการกำหนดค่าทุกครั้งที่มีการใช้แพลตฟอร์มเป็นแพลตฟอร์มเป้าหมาย (เช่น เป็นค่าของ Flag --platforms)

แฟล็กที่ตั้งค่าจากแพลตฟอร์มจะมีลําดับความสําคัญสูงสุดและเขียนทับค่าก่อนหน้าสำหรับแฟล็กนั้นจากบรรทัดคําสั่ง ไฟล์ rc หรือการเปลี่ยน

ตัวอย่าง

platform(
    name = "foo",
    flags = [
        "--dynamic_mode=fully",
        "--//bool_flag",
        "--no//package:other_bool_flag",
    ],
)

ซึ่งจะกําหนดแพลตฟอร์มชื่อ foo เมื่อเป็นแพลตฟอร์มเป้าหมาย (เนื่องจากผู้ใช้ระบุ --platforms//:foo เนื่องจากการเปลี่ยนการตั้งค่าตั้งค่า Flag //command_line_option:platforms เป็น ["//:foo"] หรือเนื่องจากมีการใช้ //:foo เป็นแพลตฟอร์มการเรียกใช้) ระบบจะตั้งค่า Flag ที่ระบุในการกําหนดค่า

แพลตฟอร์มและธงที่แสดงซ้ำได้

แฟล็กบางรายการจะรวบรวมค่าเมื่อใช้ซ้ำ เช่น --features, --copt, แฟล็ก Starlark ที่สร้างเป็น config.string(repeatable = True) Flag เหล่านี้ใช้ร่วมกับการตั้งค่า Flag จากแพลตฟอร์มไม่ได้ ระบบจะนำค่าก่อนหน้าทั้งหมดออกและเขียนทับด้วยค่าจากแพลตฟอร์มแทน

ตัวอย่างเช่น เมื่อใช้แพลตฟอร์มต่อไปนี้ การเรียกใช้ 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",
    ],
)

ด้วยเหตุนี้ เราจึงไม่แนะนำให้ใช้ Flag ที่ซ้ำกันในแอตทริบิวต์ flags

การรับค่าแพลตฟอร์ม

แพลตฟอร์มอาจใช้แอตทริบิวต์ parents เพื่อระบุแพลตฟอร์มอื่นที่จะรับค่าข้อจำกัดมา แม้ว่าแอตทริบิวต์ parents จะรับรายการ แต่ปัจจุบันระบบรองรับเพียงค่าเดียวเท่านั้น และการกำหนดรายการหลักหลายรายการจะเป็นข้อผิดพลาด

เมื่อตรวจสอบค่าของการตั้งค่าข้อจำกัดในแพลตฟอร์ม ระบบจะตรวจสอบค่าที่ตั้งโดยตรง (ผ่านแอตทริบิวต์ constraint_values) ก่อน จากนั้นจึงตรวจสอบค่าข้อจำกัดในรายการหลัก ซึ่งจะทําซ้ำตามลําดับชั้นของแพลตฟอร์มหลัก วิธีนี้จะทำให้ค่าที่ตั้งไว้ในแพลตฟอร์มโดยตรงลบล้างค่าที่ตั้งไว้ในแพลตฟอร์มหลัก

แพลตฟอร์มจะรับแอตทริบิวต์ exec_properties มาจากแพลตฟอร์มหลัก ระบบจะรวมรายการพจนานุกรมใน exec_properties ของแพลตฟอร์มหลักและแพลตฟอร์มย่อย หากคีย์เดียวกันปรากฏทั้งใน exec_properties ของรายการหลักและรายการย่อย ระบบจะใช้ค่าของรายการย่อย หากแพลตฟอร์มย่อยระบุสตริงว่างเป็นค่า ระบบจะไม่ตั้งค่าพร็อพเพอร์ตี้ที่เกี่ยวข้อง

นอกจากนี้ แพลตฟอร์มยังรับค่าแอตทริบิวต์ remote_execution_properties (เลิกใช้งานแล้ว) จากแพลตฟอร์มหลักได้ด้วย หมายเหตุ: รหัสใหม่ควรใช้ exec_properties แทน ตรรกะที่อธิบายไว้ด้านล่างจะยังคงอยู่เพื่อให้เข้ากันได้กับลักษณะการทำงานเดิม แต่จะถูกนําออกในอนาคต ตรรกะในการตั้งค่า remote_execution_platform มีดังนี้เมื่อมีแพลตฟอร์มหลัก

1. หากไม่ได้ตั้งค่า remote_execution_property ในแพลตฟอร์มย่อย ระบบจะใช้ remote_execution_properties ของแพลตฟอร์มหลัก
2. หากมีการตั้งค่า remote_execution_property ในแพลตฟอร์มย่อย และมีสตริงที่แท้จริง {PARENT_REMOTE_EXECUTION_PROPERTIES} ระบบจะแทนที่มาโครนั้นด้วยเนื้อหาของแอตทริบิวต์ remote_execution_property ของแพลตฟอร์มหลัก
3. หากตั้งค่า 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" }

อาร์กิวเมนต์

Toolchain

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

กฎนี้จะประกาศประเภทและข้อจำกัดของเครื่องมือทางเทคนิคที่เฉพาะเจาะจงเพื่อให้เลือกได้ในระหว่างการแก้ไขเครื่องมือทางเทคนิค ดูรายละเอียดเพิ่มเติมได้ในหน้าชุดเครื่องมือ

อาร์กิวเมนต์

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"]
)

อาร์กิวเมนต์