สร้างด้วยแพลตฟอร์ม

เราจะนำ API เก่าออกทันทีที่บรรลุเป้าหมายนี้ ซึ่งจะเป็นวิธีมาตรฐานที่โปรเจ็กต์จะเลือกแพลตฟอร์มและ Toolchain

ฉันควรใช้แพลตฟอร์มไหม

หากคุณเพียงต้องการสร้างหรือคอมไพล์โปรเจ็กต์หลายๆ โปรเจ็กต์ คุณควรทำตามเอกสารอย่างเป็นทางการของโปรเจ็กต์นั้นๆ

หากคุณเป็นผู้ดูแลโปรเจ็กต์ ภาษา หรือเครื่องมือทางเทคนิค ก็จะต้องรองรับ API ใหม่ในที่สุด คุณจะรอจนกว่าการย้ายข้อมูลทั่วโลกจะเสร็จสมบูรณ์หรือเลือกใช้ตั้งแต่เนิ่นๆ นั้นขึ้นอยู่กับความต้องการด้านมูลค่า/ต้นทุนที่เฉพาะเจาะจงของคุณ

ค่า

• คุณสามารถ select() หรือเลือก Toolchain ในพร็อพเพอร์ตี้เฉพาะที่คุณสนใจแทน Flag แบบฮาร์ดโค้ด เช่น --cpu ได้ เช่น CPU หลายตัวรองรับชุดคำสั่งเดียวกันได้
• บิลด์ที่ถูกต้องมากขึ้น หาก select() ด้วย --cpu ในตัวอย่างข้างต้น ให้เพิ่ม CPU ใหม่ที่รองรับชุดคำสั่งเดียวกัน select() จะไม่รู้จัก CPU ใหม่ แต่ select() ในแพลตฟอร์มจะยังคงถูกต้อง
• ประสบการณ์ของผู้ใช้ที่ง่ายขึ้น โปรเจ็กต์ทั้งหมดจะเข้าใจรูปแบบต่อไปนี้ --platforms=//:myplatform ไม่ต้องใช้ Flag สำหรับภาษาใดภาษาหนึ่งหลายรายการในบรรทัดคำสั่ง
• ออกแบบภาษาได้ง่ายขึ้น ทุกภาษาจะใช้ API ร่วมกันสำหรับกำหนดเครื่องมือเชน การใช้ Toolchain และการเลือก Toolchain ที่เหมาะสมสำหรับแพลตฟอร์ม
• สามารถข้ามเป้าหมายในขั้นตอนการสร้างและทดสอบได้หากเป้าหมายนั้นใช้ร่วมกับแพลตฟอร์มเป้าหมายไม่ได้

ค่าใช้จ่าย

• โปรเจ็กต์ที่เกี่ยวข้องซึ่งยังไม่รองรับแพลตฟอร์มอาจทำงานได้กับโปรเจ็กต์ของคุณโดยอัตโนมัติ
• การทำให้ใช้งานได้อาจต้องมีการบำรุงรักษาชั่วคราวเพิ่มเติม
• การใช้ API ใหม่กับ API เดิมร่วมกันต้องใช้คำแนะนำผู้ใช้อย่างระมัดระวังเพื่อหลีกเลี่ยงความสับสน
• คำจำกัดความ Canonical สำหรับพร็อพเพอร์ตี้ทั่วไป เช่น OS และ CPU ยังคงพัฒนาต่อไปและอาจต้องใช้ข้อมูลเริ่มต้นเพิ่มเติม
• คําจํากัดความตามหลักสําหรับเครื่องมือทางภาษาเฉพาะยังคงพัฒนาอยู่และอาจต้องมีการมีส่วนร่วมเพิ่มเติมในขั้นต้น

การตรวจสอบ API

platform คือคอลเล็กชันเป้าหมาย constraint_value ดังนี้

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

constraint_value เป็นพร็อพเพอร์ตี้ที่สร้างขึ้นโดยคอมพิวเตอร์ ค่าต่างๆ ที่เป็น "ชนิด" เดียวกันจะจัดกลุ่มไว้ภายใต้ constraint_setting ทั่วไป ดังนี้

constraint_setting(name = "os")
constraint_value(
    name = "linux",
    constraint_setting = ":os",
)
constraint_value(
    name = "mac",
    constraint_setting = ":os",
)

toolchain คือกฎ Starlark แอตทริบิวต์ของแอตทริบิวต์ประกาศเครื่องมือของภาษา (เช่น compiler = "//mytoolchain:custom_gcc") ผู้ให้บริการจะส่งข้อมูลนี้ไปยังกฎที่จำเป็นต้องสร้างด้วยเครื่องมือเหล่านี้

Toolchains ประกาศ constraint_value ของเครื่องที่ กำหนดเป้าหมาย (target_compatible_with = ["@platforms//os:linux"]) และเครื่องที่เครื่องมือของตน ทำงานบนได้ (exec_compatible_with = ["@platforms//os:mac"])

เมื่อสร้าง $ bazel build //:myproject --platforms=//:myplatform Bazel จะเลือก Toolchain ที่เรียกใช้บนเครื่องบิลด์โดยอัตโนมัติและสร้างไบนารีสำหรับ //:myplatform ได้ วิธีนี้เรียกว่าความละเอียดของ Toolchain

คุณสามารถลงทะเบียนชุดเครื่องมือที่ใช้ได้ใน WORKSPACE ด้วย register_toolchains หรือที่บรรทัดคำสั่งด้วย --extra_toolchains

ดูข้อมูลแบบเจาะลึกที่นี่

สถานะ

การรองรับแพลตฟอร์มในปัจจุบันจะแตกต่างกันไปในแต่ละภาษา กฎหลักทั้งหมดของ Bazel นั้น จะใช้กับแพลตฟอร์มต่างๆ แต่กระบวนการนี้จะใช้เวลาสักระยะ สาเหตุหลักๆ มี 3 ข้อดังนี้

1. ตรรกะกฎต้องได้รับการอัปเดตเพื่อรับข้อมูลเครื่องมือจาก toolchain API ใหม่ (ctx.toolchains) และหยุดอ่านการตั้งค่าเดิม เช่น --cpu และ --crosstool_top ซึ่งค่อนข้างตรงไปตรงมา

2. ผู้บำรุงรักษา Toolchain ต้องกำหนด Toolchain และทำให้ผู้ใช้เข้าถึงได้ (ในที่เก็บ GitHub และ WORKSPACE) วิธีการนี้ตรงไปตรงมาในทางเทคนิค แต่ต้องจัดระเบียบอย่างชาญฉลาดเพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ง่ายดาย

   และยังจำเป็นต้องมีการกำหนดแพลตฟอร์มอีกด้วย (ยกเว้นในกรณีที่คุณสร้างสำหรับเครื่องเดียวกันซึ่ง Bazel ทำงานอยู่) โดยทั่วไปแล้ว โปรเจ็กต์ควรกำหนดแพลตฟอร์มของตนเอง

3. ต้องย้ายข้อมูลโปรเจ็กต์ที่มีอยู่ รวมถึงต้องย้ายข้อมูล select() และการเปลี่ยนด้วย นี่เป็นปัญหาที่ใหญ่ที่สุด ซึ่งจะทําได้ยากมากสําหรับโปรเจ็กต์หลายภาษา (อาจไม่สําเร็จหากอ่านทุกภาษาไม่ได้--platforms)

หากออกแบบชุดกฎใหม่ คุณต้องรองรับแพลตฟอร์มตั้งแต่เริ่มต้น ซึ่งทำให้กฎของคุณเข้ากันได้กับกฎและโปรเจ็กต์อื่นๆ โดยอัตโนมัติ และมีมูลค่าเพิ่มขึ้นเมื่อ API ของแพลตฟอร์มใช้งานกันอย่างแพร่หลายมากขึ้น

พร็อพเพอร์ตี้ของแพลตฟอร์มทั่วไป

พร็อพเพอร์ตี้แพลตฟอร์ม เช่น OS และ CPU ที่พบได้ทั่วไปในโปรเจ็กต์ต่างๆ ควรประกาศไว้ในที่ส่วนกลางที่เป็นมาตรฐาน การทำเช่นนี้ช่วยส่งเสริมให้มี ความเข้ากันได้แบบข้ามโปรเจ็กต์และข้ามภาษา

ตัวอย่างเช่น หาก MyApp มี select() ใน constraint_value @myapp//cpus:arm และ SomeCommonLib มี select() ใน @commonlib//constraints:arm โหมดเหล่านี้จะทริกเกอร์โหมด "Arm" ด้วยเกณฑ์ที่เข้ากันไม่ได้

พร็อพเพอร์ตี้ที่พบได้ทั่วโลกจะประกาศในรีพอส @platforms (ดังนั้นป้ายกํากับ Canonical สําหรับตัวอย่างข้างต้นจึงเป็น @platforms//cpu:arm) ควรประกาศพร็อพเพอร์ตี้ที่พบได้ในแต่ละภาษาในรีพอสของภาษานั้นๆ

แพลตฟอร์มเริ่มต้น

โดยทั่วไปแล้ว เจ้าของโปรเจ็กต์ควรกำหนดแพลตฟอร์มอย่างชัดเจนเพื่ออธิบายประเภทเครื่องที่ต้องการสร้าง จากนั้นระบบจะทริกเกอร์เหตุการณ์เหล่านี้ด้วย --platforms

เมื่อไม่ได้ตั้งค่า --platforms ค่าเริ่มต้นของ Bazel จะเป็น platform ที่แสดงถึงเครื่องสำหรับสร้างในเครื่อง สิ่งนี้จะสร้างขึ้นโดยอัตโนมัติที่ @local_config_platform//:host ดังนั้นจึงไม่จำเป็นต้องระบุให้ชัดเจน โดยจะแมป OS ในเครื่องและ CPU กับ constraint_value ที่ประกาศใน @platforms

C++

กฎ C++ ของ Bazel จะใช้แพลตฟอร์มเพื่อเลือก Toolchain เมื่อตั้งค่าไว้ --incompatible_enable_cc_toolchain_resolution (#7260)

ซึ่งหมายความว่าคุณสามารถกำหนดค่าโปรเจ็กต์ C++ โดยใช้สิ่งต่อไปนี้

bazel build //:my_cpp_project --platforms=//:myplatform

แทนที่จะเป็นแบบเดิม

bazel build //:my_cpp_project` --cpu=... --crosstool_top=...  --compiler=...

หากโปรเจ็กต์ของคุณเป็น C++ ล้วนๆ และโปรเจ็กต์ที่ไม่ใช่ C++ ไม่ได้ใช้โปรเจ็กต์ของคุณ คุณจะใช้แพลตฟอร์มได้อย่างปลอดภัย ตราบใดที่ select และทรานซิชันของคุณเข้ากันได้ ดูคำแนะนำเพิ่มเติมได้ในส่วน #7260 และการกำหนดค่าชุดเครื่องมือ C++

โหมดนี้จะไม่เปิดใช้โดยค่าเริ่มต้น เนื่องจากโปรเจ็กต์ Apple ยังคงกำหนดค่าการอ้างอิง C++ ด้วย --cpu และ --crosstool_top (ตัวอย่าง) ทั้งนี้ขึ้นอยู่กับกฎของ Apple ที่ย้ายข้อมูลไปยังแพลตฟอร์ม

Java

กฎ Java ของ Bazel ใช้แพลตฟอร์ม

ซึ่งจะแทนที่แฟล็กเดิม --java_toolchain, --host_java_toolchain, --javabase และ --host_javabase

หากต้องการดูวิธีใช้แฟล็กการกำหนดค่า โปรดดูคู่มือ Bazel และ Java โปรดดูข้อมูลเพิ่มเติมที่หัวข้อเอกสารการออกแบบ

หากคุณยังคงใช้ Flag แบบเดิมอยู่ ให้ทำตามขั้นตอนการย้ายข้อมูลในปัญหา #7849

Android

กฎ Android ของ Bazel จะใช้แพลตฟอร์มเพื่อเลือกเครื่องมือเชนเมื่อคุณตั้งค่า --incompatible_enable_android_toolchain_resolution

ซึ่งจะเปิดใช้โดยค่าเริ่มต้น แต่เรากําลังดำเนินการย้ายข้อมูล

Apple

กฎ Apple ของ Bazel ยังไม่รองรับแพลตฟอร์มสำหรับเลือกเครื่องมือของ Apple

นอกจากนี้ เครื่องมือเหล่านี้ยังไม่รองรับไลบรารี C++ ที่เปิดใช้แพลตฟอร์ม เนื่องจากใช้ --crosstool_top รุ่นเดิมเพื่อตั้งค่าชุดเครื่องมือ C++ คุณสามารถรวมโปรเจ็กต์ Apple กับ C++ ที่เปิดใช้ Platorm เข้ากับการแมปแพลตฟอร์มได้จนกว่าจะมีการย้ายข้อมูลดังกล่าว (ตัวอย่าง)

ภาษาอื่นๆ

• กฎ Rust ของ Bazel รองรับแพลตฟอร์มเหล่านี้อย่างเต็มรูปแบบ
• กฎ Go ของ Bazel รองรับแพลตฟอร์มต่างๆ อย่างเต็มที่ (รายละเอียด)

หากคุณออกแบบกฎสําหรับภาษาใหม่ ให้ใช้แพลตฟอร์มเพื่อเลือกชุดเครื่องมือของภาษา ดูคำแนะนำแบบทีละขั้นตอนที่มีประโยชน์ได้ในเอกสารประกอบเกี่ยวกับเครื่องมือทํางาน

select()

โปรเจ็กต์จะ select() ได้ใน constraint_value เป้าหมาย แต่จะดำเนินการในแพลตฟอร์มไม่ได้ โดยเป็นความตั้งใจเพื่อให้ select() รองรับคอมพิวเตอร์ที่หลากหลายมากที่สุดเท่าที่จะเป็นไปได้ ไลบรารีที่มีแหล่งที่มาสำหรับ ARM โดยเฉพาะควรรองรับเครื่องทั้งหมดที่ใช้ ARM เว้นแต่จะมีเหตุผลที่เจาะจงมากขึ้น

หากต้องการเลือก constraint_value อย่างน้อย 1 รายการ ให้ใช้

config_setting(
    name = "is_arm",
    constraint_values = [
        "@platforms//cpu:arm",
    ],
)

ซึ่งเทียบเท่ากับการเลือกใน --cpu แบบดั้งเดิม

config_setting(
    name = "is_arm",
    values = {
        "cpu": "arm",
    },
)

ดูรายละเอียดเพิ่มเติมได้ที่นี่

select ใน --cpu, --crosstool_top ฯลฯ ไม่เข้าใจ --platforms เมื่อย้ายข้อมูลโปรเจ็กต์ไปยังแพลตฟอร์ม คุณต้องแปลงโปรเจ็กต์เป็น constraint_values หรือใช้การแมปแพลตฟอร์มเพื่อรองรับทั้ง 2 สไตล์ผ่านกรอบเวลาการย้ายข้อมูล

ทรานซิชัน

การเปลี่ยนแบบ Starlark เปลี่ยน การทำเครื่องหมายส่วนต่างๆ ของกราฟบิลด์ หากโปรเจ็กต์ใช้การเปลี่ยนที่ตั้งค่า --cpu, --crossstool_top หรือแฟล็กเดิมอื่นๆ กฎที่อ่านว่า --platforms จะไม่เห็นการเปลี่ยนแปลงเหล่านี้

เมื่อย้ายข้อมูลโปรเจ็กต์ไปยังแพลตฟอร์ม คุณต้องแปลงการเปลี่ยนแปลง เช่น return { "//command_line_option:cpu": "arm" } เป็น return { "//command_line_option:platforms": "//:my_arm_platform" } หรือใช้การแมปแพลตฟอร์มเพื่อรองรับทั้ง 2 รูปแบบผ่านกรอบเวลาการย้ายข้อมูล

วิธีใช้แพลตฟอร์มในปัจจุบัน

หากต้องการสร้างหรือคอมไพล์ข้ามโปรเจ็กต์ คุณควรทำตามเอกสารประกอบอย่างเป็นทางการของโปรเจ็กต์ ผู้ดูแลภาษาและโปรเจ็กต์จะเป็นผู้กำหนดวิธีและเวลาที่จะผสานรวมกับแพลตฟอร์ม รวมถึงคุณค่าที่การผสานรวมนั้นมอบให้

หากคุณเป็นผู้ดูแลโปรเจ็กต์ ภาษา หรือเครื่องมือทางเทคนิค และบิลด์ของคุณไม่ได้ใช้แพลตฟอร์มโดยค่าเริ่มต้น คุณจะมี 3 ตัวเลือก (นอกเหนือจากการรอการย้ายข้อมูลทั่วโลก) ดังนี้

1. พลิกแฟล็ก "ใช้แพลตฟอร์ม" สำหรับภาษาของโปรเจ็กต์ (หากมี) แล้วทำการทดสอบอะไรก็ได้ที่ต้องการเพื่อดูว่าโปรเจ็กต์ที่คุณสนใจใช้งานได้หรือไม่

2. หากโปรเจ็กต์ที่คุณสนใจยังคงต้องใช้ Flag เดิม เช่น --cpu และ --crosstool_top ให้ใช้โปรเจ็กต์เหล่านี้ร่วมกับ --platforms

   bazel build //:my_mixed_project --platforms==//:myplatform --cpu=... --crosstool_top=...

   ซึ่งจะมีค่าใช้จ่ายในการบำรุงรักษา (คุณต้องตรวจสอบการตั้งค่าให้ตรงกันด้วยตนเอง) แต่วิธีนี้ควรใช้งานได้เมื่อไม่มีการเปลี่ยนการเปลี่ยนแปลง

3. เขียนการแมปแพลตฟอร์มเพื่อรองรับทั้ง 2 รูปแบบ โดยแมปการตั้งค่าสไตล์ --cpu กับแพลตฟอร์มที่เกี่ยวข้อง และในทางกลับกัน

การแมปแพลตฟอร์ม

การแมปแพลตฟอร์มเป็น API ชั่วคราวที่ช่วยให้ตรรกะที่ขับเคลื่อนด้วยแพลตฟอร์มและตรรกะเดิมสามารถอยู่ร่วมกันในบิลด์เดียวกันได้ผ่านกรอบเวลาการเลิกใช้งานในภายหลัง

การแมปแพลตฟอร์มคือการแมป platform() กับชุด Flag เดิมที่สอดคล้องกันหรือแบบย้อนกลับ เช่น

platforms:
  # Maps "--platforms=//platforms:ios" to "--cpu=ios_x86_64 --apple_platform_type=ios".
  //platforms:ios
    --cpu=ios_x86_64
    --apple_platform_type=ios

flags:
  # Maps "--cpu=ios_x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
  --cpu=ios_x86_64
  --apple_platform_type=ios
    //platforms:ios

  # Maps "--cpu=darwin --apple_platform_type=macos" to "//platform:macos".
  --cpu=darwin
  --apple_platform_type=macos
    //platforms:macos

Bazel ใช้วิธีนี้เพื่อรับประกันการตั้งค่าทั้งหมดทั้งตามแพลตฟอร์มและแบบเดิมจะมีผลอย่างสอดคล้องกันตลอดบิลด์ รวมถึงการเปลี่ยน

โดยค่าเริ่มต้น Bazel จะอ่านการแมปจากไฟล์ platform_mappings ในรูทพื้นที่ทำงานของคุณ นอกจากนี้ คุณยังตั้งค่า --platform_mappings=//:my_custom_mapping ได้อีกด้วย

ดูรายละเอียดทั้งหมดที่นี่

คำถาม

หากต้องการรับการสนับสนุนทั่วไปเกี่ยวกับไทม์ไลน์การย้ายข้อมูล โปรดติดต่อ bazel-discuss@googlegroups.com หรือเจ้าของกฎที่เหมาะสม

หากต้องการพูดคุยเกี่ยวกับการออกแบบและพัฒนา API ของแพลตฟอร์ม/toolchain โปรดติดต่อ bazel-dev@googlegroups.com

ดูเพิ่มเติม

• บิลด์ที่กำหนดค่าได้ - ส่วนที่ 1
• แพลตฟอร์ม
• ชุดเครื่องมือ
• ตำราอาหารสำหรับแพลตฟอร์มบาเซล
• hlopko/bazel_platforms_examples
• ตัวอย่างเครื่องมือทางเทคนิคที่กำหนดเองของ C++