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

Bazel รองรับการจำลองแพลตฟอร์มและชุดเครื่องมืออย่างซับซ้อน การผสานรวมกับโปรเจ็กต์จริงต้องใช้ความร่วมมืออย่างรอบคอบระหว่างเจ้าของโค้ด ผู้ดูแลกฎ และนักพัฒนาซอฟต์แวร์ Bazel หลัก

หน้านี้จะสรุปวัตถุประสงค์ของแพลตฟอร์มและแสดงวิธีสร้างด้วยแพลตฟอร์ม

สรุป: API ของแพลตฟอร์มและเครื่องมือทํางานของ Bazel พร้อมใช้งานแล้ว แต่จะใช้งานไม่ได้ในทุกที่จนกว่าจะมีการอัปเดตกฎภาษา, select() และข้อมูลอ้างอิงเดิมอื่นๆ ทั้งหมด ซึ่งเป็นขั้นตอนที่ต้องดำเนินการอยู่เรื่อยๆ ในที่สุดบิลด์ทั้งหมดจะเป็นแบบแพลตฟอร์ม อ่านด้านล่างเพื่อดูว่าบิลด์ของคุณตรงกับข้อกำหนดใด

ดูเอกสารประกอบอย่างเป็นทางการเพิ่มเติมได้ที่

• แพลตฟอร์ม
• ชุดเครื่องมือ

ข้อมูลเบื้องต้น

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

นี่เป็นฟีเจอร์ที่เพิ่มเข้ามาใหม่ใน Bazel แนวคิดนี้ได้รับแรงบันดาลใจจากการสังเกตว่าผู้ดูแลภาษาดำเนินการเช่นนี้อยู่แล้วในลักษณะที่ไม่สอดคล้องกัน เช่น กฎ C++ ใช้ --cpu และ --crosstool_top เพื่อตั้งค่า CPU เป้าหมายและชุดเครื่องมือ C++ ของบิลด์ รายการเหล่านี้ไม่ได้จําลอง "แพลตฟอร์ม" อย่างถูกต้อง ที่ผ่านมาการพยายามทำเช่นนั้นทำให้ได้บิลด์ที่ไม่เป็นธรรมชาติและไม่ถูกต้อง นอกจากนี้ Flag เหล่านี้ยังไม่ควบคุมการคอมไพล์ Java ซึ่งพัฒนาอินเทอร์เฟซอิสระของตนเองด้วย --java_toolchain

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

การย้ายข้อมูล

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

เช่น แพลตฟอร์มที่รองรับกฎ C++ ของ Bazel แต่กฎของ Apple ไม่ได้ดำเนินการเช่นนั้น โปรเจ็กต์ C++ ของคุณอาจไม่เกี่ยวข้องกับ Apple แต่บางแพลตฟอร์มอาจไม่รองรับ ดังนั้นจึงยังไม่ปลอดภัยที่จะเปิดใช้แพลตฟอร์มทั่วโลกสำหรับบิลด์ C++ ทั้งหมด

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

เป้าหมาย

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

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

ซึ่งหมายความว่า

1. กฎที่โปรเจ็กต์ใช้สามารถอนุมานเครื่องมือทางเทคนิคที่ถูกต้องจาก //:myplatform
2. กฎที่ข้อกำหนดของโปรเจ็กต์ใช้สามารถอนุมานเครื่องมือทางเทคนิคที่ถูกต้องจาก //:myplatform
3. โปรเจ็กต์ที่ขึ้นอยู่กับโปรเจ็กต์ของคุณรองรับ //:myplatform หรือโปรเจ็กต์ของคุณรองรับ API รุ่นเดิม (เช่น --crosstool_top)
4. //:myplatform อ้างอิง [ประกาศทั่วไป][Common Platform Declaration]{: .external} ของ CPU, OS และแนวคิดทั่วไปอื่นๆ ที่รองรับความเข้ากันได้ข้ามโปรเจ็กต์โดยอัตโนมัติ
5. select() ของโปรเจ็กต์ที่เกี่ยวข้องทั้งหมดจะเข้าใจพร็อพเพอร์ตี้ของเครื่องจักรที่ //:myplatform บอกเป็นนัย
6. //:myplatform ได้รับการกําหนดในที่ที่ชัดเจนและนํากลับมาใช้ซ้ำได้ เช่น ในรีพอรีของโปรเจ็กต์หากแพลตฟอร์มนั้นใช้เฉพาะในโปรเจ็กต์ของคุณ หรือในที่ที่โปรเจ็กต์ทั้งหมดที่อาจใช้แพลตฟอร์มนี้ค้นหาได้

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

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

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

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

ค่า

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

ค่าใช้จ่าย

• โปรเจ็กต์ที่เกี่ยวข้องซึ่งยังไม่รองรับแพลตฟอร์มอาจไม่ทำงานร่วมกับแพลตฟอร์มของคุณโดยอัตโนมัติ
• การใช้งานอาจต้องการบำรุงรักษาชั่วคราวเพิ่มเติม
• การอยู่ร่วมกันของ API ใหม่และเดิมต้องใช้คําแนะนําผู้ใช้อย่างรอบคอบมากขึ้นเพื่อไม่ให้เกิดความสับสน
• คําจํากัดความตามหลักสําหรับพร็อพเพอร์ตี้ทั่วไป เช่น 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") ส่วนผู้ให้บริการจะส่งข้อมูลนี้ไปยังกฎที่ต้องสร้างด้วยเครื่องมือเหล่านี้

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

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

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

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

สถานะ

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

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

2. ผู้ดูแลเครื่องมือต้องกำหนดเครื่องมือและทำให้ผู้ใช้เข้าถึงได้ (ในที่เก็บ 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 ใช้แพลตฟอร์มเพื่อเลือกชุดเครื่องมือเมื่อคุณตั้งค่า --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 ใช้แพลตฟอร์ม

ซึ่งจะใช้แทน Flag เดิมอย่าง --java_toolchain, --host_java_toolchain, --javabase และ --host_javabase

ดูวิธีใช้ Flag การกําหนดค่าได้ที่คู่มือ Bazel และ Java ดูข้อมูลเพิ่มเติมได้ที่เอกสารการออกแบบ

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

Android

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

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

Apple

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

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

ภาษาอื่นๆ

• กฎ 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 หรือ Flag เดิมอื่นๆ กฎที่อ่าน --platforms จะไม่แสดงการเปลี่ยนแปลงเหล่านี้

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

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

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

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

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

2. หากโปรเจ็กต์ที่คุณสนใจยังคงใช้ Flag รุ่นเดิม เช่น --cpu และ --crosstool_top ให้ใช้ Flag เหล่านี้ร่วมกับ --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 ของแพลตฟอร์ม/เครื่องมือ โปรดติดต่อ bazel-dev@googlegroups.com

ดูเพิ่มเติม

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