Bazel มีการสนับสนุนที่ซับซ้อนสำหรับการสร้างแบบจำลอง แพลตฟอร์มและเครื่องมือเชนสำหรับสถาปัตยกรรมและ บิลด์ที่คอมไพล์แบบข้ามระบบ
หน้านี้สรุปสถานะของการสนับสนุนนี้
และดู:
สถานะ
C++
กฎ C++ จะใช้แพลตฟอร์มเพื่อเลือก Toolchain
ตั้งค่า --incompatible_enable_cc_toolchain_resolution
แล้ว
ซึ่งหมายความว่าคุณจะกำหนดค่าโปรเจ็กต์ C++ ได้ด้วยสิ่งต่อไปนี้
bazel build //:my_cpp_project --platforms=//:myplatform
แทนที่จะเป็นแบบเดิม
bazel build //:my_cpp_project` --cpu=... --crosstool_top=... --compiler=...
การดำเนินการนี้จะเปิดใช้โดยค่าเริ่มต้นใน Bazel 7.0 (#7260)
หากต้องการทดสอบโปรเจ็กต์ C++ กับแพลตฟอร์ม โปรดดู การย้ายข้อมูลโปรเจ็กต์และ การกำหนดค่าเครื่องมือเชน C++
Java
กฎ Java จะใช้แพลตฟอร์มเพื่อเลือก Toolchain
การดำเนินการนี้จะแทนที่ Flag เดิม --java_toolchain
, --host_java_toolchain
,
--javabase
และ --host_javabase
ดูรายละเอียดได้ที่ Java และ Bazel
Android
กฎ Android จะใช้แพลตฟอร์มเพื่อเลือก Toolchain
ตั้งค่า --incompatible_enable_android_toolchain_resolution
แล้ว
ซึ่งหมายความว่าคุณจะกำหนดค่าโปรเจ็กต์ Android ได้ด้วยสิ่งต่อไปนี้
bazel build //:my_android_project --android_platforms=//:my_android_platform
แทน Flag เดิมอย่าง --android_crosstool_top
, --android_cpu
และ --fat_apk_cpu
การดำเนินการนี้จะเปิดใช้โดยค่าเริ่มต้นใน Bazel 7.0 (#16285)
หากต้องการทดสอบโปรเจ็กต์ Android กับแพลตฟอร์ม โปรดดู การย้ายข้อมูลโปรเจ็กต์
Apple
กฎของ Apple ไม่รองรับแพลตฟอร์มและยังไม่มีการกำหนดเวลา เพื่อรับการสนับสนุน
คุณจะยังใช้ API ของแพลตฟอร์มกับบิลด์ของ Apple ได้ (เช่น เมื่อสร้าง โดยใช้ทั้งกฎของ Apple และ C++ ที่แท้จริง) กับแพลตฟอร์ม การแมป
ภาษาอื่นๆ
- กฎ Go รองรับแพลตฟอร์มอย่างเต็มรูปแบบ
- กฎความน่าเชื่อถือรองรับแพลตฟอร์มอย่างเต็มรูปแบบ
หากคุณเป็นเจ้าของชุดกฎภาษา โปรดดูการย้ายข้อมูลชุดกฎสำหรับการเพิ่ม การสนับสนุน
ข้อมูลเบื้องต้น
มีการนำแพลตฟอร์มและเครื่องมือเชนมาใช้เพื่อกำหนดมาตรฐานของซอฟต์แวร์ กำหนดกลุ่มเป้าหมายของสถาปัตยกรรมที่ต่างกันและคอมไพล์แบบข้ามระบบ
นี่คือ
แรงบันดาลใจ
จากการสังเกตที่ผู้ดูแลภาษาทำสิ่งนี้ในโฆษณาอยู่แล้ว
เฉพาะกิจ, แบบที่ใช้ร่วมกันไม่ได้ ตัวอย่างเช่น กฎ C++ ใช้ --cpu
และ
--crosstool_top
เพื่อประกาศ CPU และ Toolchain เป้าหมาย ไม่ใช่ทั้ง 2 อย่างนี้
สร้างแบบจำลอง "แพลตฟอร์ม" อย่างถูกต้อง สิ่งนี้ทำให้เกิดงานสร้างที่ไม่ถูกต้องและแปลกประหลาด
Java, Android และภาษาอื่นๆ พัฒนาค่าสถานะของตัวเองเพื่อวัตถุประสงค์ที่คล้ายกัน ที่ทำงานร่วมกันเองไม่ได้ การสร้างบิลด์ข้ามภาษา ยุ่งยากและซับซ้อน
Bazel ออกแบบมาสำหรับโปรเจ็กต์ขนาดใหญ่ที่ใช้หลายภาษาและหลายแพลตฟอร์ม ช่วงเวลานี้ ต้องการการสนับสนุนโดยมีหลักการมากกว่าสำหรับแนวคิดเหล่านี้ รวมถึง API มาตรฐาน
ความต้องการในการย้ายข้อมูล
การอัปเกรดเป็น API ใหม่ต้องใช้ความพยายาม 2 ประการ ได้แก่ การเผยแพร่ API และการอัปเกรด ใช้ตรรกะของกฎ
รายการแรกเสร็จแล้ว แต่ครั้งที่ 2 ยังทำอยู่ ซึ่งประกอบด้วย
มีการกำหนดแพลตฟอร์มและ Toolchain เฉพาะภาษา การอ่านตรรกะทางภาษา
Toolchain ผ่าน API ใหม่แทน Flag เก่าอย่าง --crosstool_top
และ
config_setting
เลือกใช้ API ใหม่แทน Flag เก่า
วิธีนี้ไม่ซับซ้อน แต่ต้องใช้ความพยายามที่แตกต่างกันสำหรับแต่ละภาษา พร้อมทั้งการเตือนที่ยุติธรรมเพื่อให้เจ้าของโปรเจ็กต์ได้ทดสอบกับการเปลี่ยนแปลงที่กำลังจะเกิดขึ้น
นี่จึงเป็นสาเหตุที่ต้องทำการย้ายข้อมูลอย่างต่อเนื่อง
เป้าหมาย
การย้ายข้อมูลนี้จะเสร็จสมบูรณ์เมื่อโปรเจ็กต์ทั้งหมดสร้างด้วยฟอร์ม:
bazel build //:myproject --platforms=//:myplatform
ซึ่งหมายความว่า
- กฎของโปรเจ็กต์เลือกเครื่องมือเชนที่ถูกต้องสำหรับ
//:myplatform
- ทรัพยากร Dependency ของโปรเจ็กต์เลือก Toolchain ที่เหมาะสมสำหรับ
//:myplatform
- ข้อมูลอ้างอิง
//:myplatform
รายการ การประกาศทั่วไป ของCPU
,OS
และพร็อพเพอร์ตี้ทั่วไปอื่นๆ ที่ไม่ขึ้นอยู่กับภาษา select()
ที่เกี่ยวข้องทั้งหมดตรงกับ//:myplatform
อย่างถูกต้อง//:myplatform
ได้กำหนดไว้ในตำแหน่งที่ชัดเจนและเข้าถึงได้ง่าย: ใน เก็บในกรณีที่แพลตฟอร์มนี้เป็นแพลตฟอร์มเฉพาะสำหรับโครงการของคุณ หรือสถานที่ทั่วไป โปรเจ็กต์ที่ทำอยู่จะสามารถค้นหาสิ่งนั้นได้
แฟล็กเก่า เช่น --cpu
, --crosstool_top
และ --fat_apk_cpu
จะ
จะเลิกใช้งานและนำออกทันทีที่ทำได้
ท้ายที่สุดแล้ว การกำหนดค่าสถาปัตยกรรมจึงเป็นวิธีเดียว
กำลังย้ายข้อมูลโปรเจ็กต์
หากคุณสร้างโดยใช้ภาษาที่สนับสนุนแพลตฟอร์ม บิลด์ของคุณควร ทำงานร่วมกับคำขอ เช่น
bazel build //:myproject --platforms=//:myplatform
ดูรายละเอียดอย่างละเอียดได้ที่สถานะและเอกสารประกอบของภาษา
หากภาษาต้องมีการตั้งค่าสถานะเพื่อเปิดใช้การรองรับแพลตฟอร์ม คุณยังต้องตั้งค่า แฟล็กนั้น ดูรายละเอียดได้ที่สถานะ
คุณต้องตรวจสอบรายการต่อไปนี้เพื่อให้โปรเจ็กต์สร้าง
ต้องมี
//:myplatform
อยู่ โดยทั่วไปแล้วเป็นความรับผิดชอบของเจ้าของโปรเจ็กต์ กำหนดแพลตฟอร์มเพราะโครงการที่ต่างกันกำหนดเป้าหมายเครื่องที่ต่างกัน โปรดดูแพลตฟอร์มเริ่มต้นต้องมี Toolchain ที่ต้องการใช้ หากใช้ Partner Toolchain เจ้าของภาษาควรระบุคำแนะนำในการลงทะเบียน ถ้า การเขียน Toolchain ของคุณเอง คุณจะต้องลงทะเบียนใน
WORKSPACE
หรือด้วย--extra_toolchains
select()
และการเปลี่ยนการกำหนดค่าต้อง แก้ไขได้อย่างถูกต้อง โปรดดูselect() และการเปลี่ยนหากบิลด์ของคุณรวมภาษาที่รองรับและไม่รองรับแพลตฟอร์มต่างๆ คุณอาจ ซึ่งจำเป็นต้องใช้การแมปแพลตฟอร์มเพื่อช่วยให้ภาษาเดิมใช้งานกับ API ใหม่ได้ ดูรายละเอียดได้ที่การแมปแพลตฟอร์ม
หากยังพบปัญหาอยู่ โปรดติดต่อเพื่อขอความช่วยเหลือ
แพลตฟอร์มเริ่มต้น
เจ้าของโปรเจ็กต์ควรระบุอย่างชัดแจ้งว่า
แพลตฟอร์มในการอธิบายสถาปัตยกรรม
ที่ตนต้องการสร้าง ซึ่งจะทริกเกอร์ด้วย --platforms
เมื่อไม่ได้ตั้งค่า --platforms
ค่าเริ่มต้นของ Bazel จะเป็น platform
ที่แสดงถึง
เครื่องสร้างในเครื่อง ส่วนนี้สร้างขึ้นโดยอัตโนมัติที่ @local_config_platform//:host
จึงไม่จำเป็นต้องกำหนด
สิ่งนี้ไว้อย่างชัดเจน ซึ่งจะแมป OS
ของคอมพิวเตอร์ในเครื่อง
และ CPU
ที่ประกาศconstraint_value
ใน
@platforms
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" }
หรือใช้ platform
เพื่อให้รองรับทั้ง 2 สไตล์ระหว่างการย้ายข้อมูล
กำลังย้ายข้อมูลชุดกฎ
หากคุณเป็นเจ้าของชุดกฎและต้องการรองรับแพลตฟอร์ม คุณต้องทำดังนี้
มีการแปลง Toolchain ของกฎด้วย Toolchain API โปรดดู toolchain API (
ctx.toolchains
)ไม่บังคับ: กำหนดแฟล็ก
--incompatible_enable_platforms_for_my_language
เพื่อให้ ตรรกะของกฎจะแปลง Toolchain ผ่าน API ใหม่หรือแฟล็กเก่า เช่น--crosstool_top
ระหว่างการทดสอบการย้ายข้อมูลกำหนดพร็อพเพอร์ตี้ที่เกี่ยวข้องซึ่งเป็นส่วนประกอบของแพลตฟอร์ม โปรดดู พร็อพเพอร์ตี้ทั่วไปของแพลตฟอร์ม
กำหนด Toolchain มาตรฐานและทำให้ผู้ใช้เข้าถึงได้ผ่าน วิธีการลงทะเบียนของกฎ (รายละเอียด)
ตรวจสอบว่า
select()
และ แพลตฟอร์มสนับสนุนการเปลี่ยนการกำหนดค่า นี่คือ ที่ท้าทายที่สุด เป็นเรื่องที่ท้าทายอย่างยิ่งสำหรับโปรเจ็กต์หลายภาษา (ซึ่งอาจล้มเหลวหากทุกภาษาอ่าน--platforms
ไม่ได้)
หากต้องการใช้กฎที่ไม่รองรับแพลตฟอร์มต่างๆ ร่วมกัน คุณอาจต้อง การแมปแพลตฟอร์มเพื่อเชื่อมช่องว่าง
พร็อพเพอร์ตี้ของแพลตฟอร์มทั่วไป
พร็อพเพอร์ตี้ทั่วไปของแพลตฟอร์มข้ามภาษา เช่น OS
และ CPU
ควรมีลักษณะดังนี้
ที่ประกาศใน @platforms
ซึ่งจะช่วยส่งเสริมการแชร์ การกำหนดมาตรฐาน และความเข้ากันได้ข้ามภาษา
คุณควรประกาศพร็อพเพอร์ตี้ที่ไม่ซ้ำกันสำหรับกฎของคุณในที่เก็บของกฎ ช่วงเวลานี้ ช่วยให้คุณรักษาความเป็นเจ้าของแนวคิดที่ชัดเจนเกี่ยวกับกฎ เป็นผู้รับผิดชอบ
หากกฎของคุณใช้ระบบปฏิบัติการหรือ CPU ตามวัตถุประสงค์ที่กำหนดเอง ควรประกาศรายการเหล่านี้ไว้ใน
ที่เก็บของกฎเทียบกับ
@platforms
การแมปแพลตฟอร์ม
การแมปแพลตฟอร์มเป็น 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_x86_64 --apple_platform_type=macos" to "//platform:macos".
--cpu=darwin_x86_64
--apple_platform_type=macos
//platforms:macos
Bazel ใช้วิธีนี้รับประกันการตั้งค่าทั้งหมด ทั้งที่อิงตามแพลตฟอร์มและ กลุ่มเดิมมีการใช้งานอย่างสอดคล้องกันตลอดการสร้าง รวมถึง การเปลี่ยนผ่าน
โดยค่าเริ่มต้น Bazel จะอ่านการแมปจากไฟล์ platform_mappings
ในไฟล์
Workspace Root นอกจากนี้ คุณยังสามารถตั้งค่า
--platform_mappings=//:my_custom_mapping
โปรดดูรายละเอียดในการออกแบบการแมปแพลตฟอร์ม
การตรวจสอบ 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"
) บัตรของ providers
ข้อมูลนี้มาใช้กับกฎที่จะต้องสร้างด้วยเครื่องมือเหล่านี้
Toolchain เป็นการประกาศconstraint_value
ของเครื่องที่ทำได้
เป้าหมาย
(target_compatible_with = ["@platforms//os:linux"]
) และแมชชีน เครื่องมือที่เครื่องมือเหล่านี้สามารถทำได้
ทำงานบน
(exec_compatible_with = ["@platforms//os:mac"]
)
เมื่อสร้าง $ bazel build //:myproject --platforms=//:myplatform
, Bazel
จะเลือกเครื่องมือเชนที่เรียกใช้บนเครื่องบิลด์ได้โดยอัตโนมัติและ
สร้างไบนารีสำหรับ //:myplatform
วิธีนี้เรียกว่าความละเอียดของ Toolchain
ชุด Toolchain ที่มีให้ใช้งานสามารถลงทะเบียนใน WORKSPACE
ได้ด้วย
register_toolchains
หรือที่
บรรทัดคำสั่งด้วย --extra_toolchains
ดูข้อมูลเพิ่มเติมที่นี่
คำถาม
หากต้องการรับการสนับสนุนทั่วไปและมีคำถามเกี่ยวกับไทม์ไลน์การย้ายข้อมูล โปรดติดต่อ bazel-discuss หรือเจ้าของกฎที่เหมาะสม
สำหรับการสนทนาเกี่ยวกับการออกแบบและพัฒนา API ของแพลตฟอร์ม/เครื่องมือเชน โปรดติดต่อ bazel-dev