Bazel รองรับการจำลองแพลตฟอร์มและชุดเครื่องมืออย่างซับซ้อน การผสานรวมสิ่งนี้กับโปรเจ็กต์จริงต้องอาศัยความร่วมมืออย่างระมัดระวังระหว่างเจ้าของโค้ด ผู้ดูแลกฎ และนักพัฒนาซอฟต์แวร์หลักของ Bazel
หน้านี้จะสรุปวัตถุประสงค์ของแพลตฟอร์มและแสดงวิธีการสร้างแพลตฟอร์ม
tl;dr: API แพลตฟอร์มและ Toolchain ของ Bazel ใช้งานได้แต่จะไม่ทำงานในทุกที่จนกว่าจะมีการอัปเดตกฎภาษา, select()
และการอ้างอิงเดิมอื่นๆ ซึ่งเป็นขั้นตอนที่ต้องดำเนินการอยู่เรื่อยๆ ในที่สุดบิลด์ทั้งหมดจะเป็นแบบแพลตฟอร์ม
โปรดอ่านข้อมูลด้านล่างเพื่อดูว่าสิ่งปลูกสร้างของคุณเหมาะสมกับตำแหน่งใด
ดูเอกสารประกอบอย่างเป็นทางการเพิ่มเติมได้ที่
ข้อมูลเบื้องต้น
แพลตฟอร์มและชุดเครื่องมือได้เริ่มนำมาใช้เพื่อกำหนดมาตรฐานวิธีกำหนดเป้าหมายเครื่องต่างๆ และสร้างโปรเจ็กต์ซอฟต์แวร์ด้วยเครื่องมือภาษาที่เหมาะสม
นี่เป็นผลิตภัณฑ์ที่เพิ่งเพิ่มเข้ามาของ Bazel ซึ่งได้ได้รับแรงบันดาลใจจากการสังเกตการณ์ว่าผู้ดูแลภาษาเคยทำสิ่งนี้แบบเฉพาะกิจซึ่งไม่ใช่วิธีที่เข้ากันไม่ได้ เช่น กฎ C++ ใช้ --cpu
และ --crosstool_top
เพื่อตั้งค่า CPU เป้าหมายของบิลด์และเครื่องมือเชน C++ รายการเหล่านี้ไม่ได้จําลอง "แพลตฟอร์ม" อย่างถูกต้อง ความพยายามในอดีตทำให้เกิดงานสร้างที่ไม่ถูกต้องและอึดอัด
นอกจากนี้ Flag เหล่านี้ไม่ได้ควบคุมการคอมไพล์ Java ซึ่งพัฒนาอินเทอร์เฟซอิสระของตนเองด้วย --java_toolchain
Bazel มีไว้สำหรับโปรเจ็กต์ขนาดใหญ่ที่มีหลายภาษาและหลายแพลตฟอร์ม ด้วยเหตุนี้ เราจึงต้องการการสนับสนุนที่ยึดตามหลักการมากขึ้นสําหรับแนวคิดเหล่านี้ รวมถึง API ที่ชัดเจนซึ่งส่งเสริมการทำงานร่วมกันของภาษาและโปรเจ็กต์ นี่แหละคือวัตถุประสงค์ของ API ใหม่
การย้ายข้อมูล
API ของแพลตฟอร์มและเครื่องมือจะทำงานก็ต่อเมื่อโปรเจ็กต์ใช้ API เหล่านั้นจริงๆ นี่ไม่ใช่ปัญหาใหญ่เนื่องจากตรรกะของกฎ, Toolchains, ทรัพยากร Dependency และ select()
ของโปรเจ็กต์ต้องรองรับ ซึ่งต้องใช้ลำดับการย้ายข้อมูลอย่างรอบคอบเพื่อให้โปรเจ็กต์ทั้งหมดและรายการที่เกี่ยวข้องทำงานได้อย่างถูกต้อง
เช่น แพลตฟอร์มรองรับ กฎ C++ ของ Bazel แต่กฎของ Apple ไม่ได้ทำเช่นนั้น โครงการ C++ ของคุณ อาจไม่สนใจ Apple แต่บางแพลตฟอร์มอาจไม่รองรับ ดังนั้นจึงยังไม่ปลอดภัยที่จะเปิดใช้แพลตฟอร์มทั่วโลกสำหรับบิลด์ C++ ทั้งหมด
ส่วนที่เหลือของหน้านี้จะอธิบายลำดับการย้ายข้อมูลนี้ รวมถึงวิธีการและเวลาที่โปรเจ็กต์จะเข้าที่
เป้าหมาย
การย้ายข้อมูลแพลตฟอร์มของ Bazel จะเสร็จสมบูรณ์เมื่อโปรเจ็กต์ทั้งหมดสร้างด้วยรูปแบบต่อไปนี้
bazel build //:myproject --platforms=//:myplatform
ซึ่งหมายความว่า
- กฎที่โปรเจ็กต์ใช้สามารถอนุมานเครื่องมือทางเทคนิคที่ถูกต้องจาก
//:myplatform
- กฎที่ทรัพยากร Dependency ใช้ของโปรเจ็กต์อาจอนุมานเครื่องมือเชนที่ถูกต้องจาก
//:myplatform
ได้ - โปรเจ็กต์ที่ขึ้นอยู่กับโปรเจ็กต์ของคุณรองรับ
//:myplatform
หรือโปรเจ็กต์ของคุณรองรับ API รุ่นเดิม (เช่น--crosstool_top
) //:myplatform
อ้างอิง [ประกาศทั่วไป][Common Platform Declaration]{: .external} ของCPU
,OS
และแนวคิดทั่วไปอื่นๆ ที่รองรับความเข้ากันได้ข้ามโปรเจ็กต์โดยอัตโนมัติ- โปรเจ็กต์ที่เกี่ยวข้องทั้งหมด
select()
จะเข้าใจพร็อพเพอร์ตี้เครื่องที่บอกเป็นนัยด้วย//:myplatform
//:myplatform
ได้รับการกำหนดไว้ในตำแหน่งที่ชัดเจนและนำมาใช้ใหม่ได้ นั่นคือในที่เก็บของโปรเจ็กต์หากแพลตฟอร์มนั้นเป็นของโปรเจ็กต์ของคุณโดยเฉพาะ หรือหากไม่มีแพลตฟอร์มนี้จะพบโปรเจ็กต์ทั้งหมดที่ใช้แพลตฟอร์มนี้ได้
เราจะนำ 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 ข้อดังนี้
ตรรกะกฎต้องได้รับการอัปเดตเพื่อรับข้อมูลเครื่องมือจาก toolchain API ใหม่ (
ctx.toolchains
) และหยุดอ่านการตั้งค่าเดิม เช่น--cpu
และ--crosstool_top
ซึ่งค่อนข้างตรงไปตรงมาผู้บำรุงรักษา Toolchain ต้องกำหนด Toolchain และทำให้ผู้ใช้เข้าถึงได้ (ในที่เก็บ GitHub และ
WORKSPACE
) วิธีการนี้ตรงไปตรงมาในทางเทคนิค แต่ต้องจัดระเบียบอย่างชาญฉลาดเพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ง่ายดายและยังจำเป็นต้องมีการกำหนดแพลตฟอร์มอีกด้วย (ยกเว้นในกรณีที่คุณสร้างสำหรับเครื่องเดียวกันซึ่ง Bazel ทำงานอยู่) โดยทั่วไปแล้ว โปรเจ็กต์ควรกำหนดแพลตฟอร์มของตนเอง
ต้องย้ายข้อมูลโปรเจ็กต์ที่มีอยู่ รวมถึงต้องย้ายข้อมูล
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 ตัวเลือก (นอกเหนือจากการรอการย้ายข้อมูลทั่วโลก) ดังนี้
พลิกแฟล็ก "ใช้แพลตฟอร์ม" สำหรับภาษาของโปรเจ็กต์ (หากมี) แล้วทำการทดสอบอะไรก็ได้ที่ต้องการเพื่อดูว่าโปรเจ็กต์ที่คุณสนใจใช้งานได้หรือไม่
หากโปรเจ็กต์ที่คุณสนใจยังคงต้องใช้ Flag เดิม เช่น
--cpu
และ--crosstool_top
ให้ใช้โปรเจ็กต์เหล่านี้ร่วมกับ--platforms
bazel build //:my_mixed_project --platforms==//:myplatform --cpu=... --crosstool_top=...
ซึ่งจะมีค่าใช้จ่ายในการบำรุงรักษา (คุณต้องตรวจสอบการตั้งค่าให้ตรงกันด้วยตนเอง) แต่วิธีนี้ควรใช้งานได้เมื่อไม่มีการเปลี่ยนการเปลี่ยนแปลง
เขียนการแมปแพลตฟอร์มเพื่อรองรับทั้ง 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