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

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

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

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

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

• แพลตฟอร์ม
• เครื่องมือทางเทคนิค

ฉากหลัง

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

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

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

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

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

ตัวอย่างเช่น กฎ 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()` ของโปรเจ็กต์ที่เกี่ยวข้องทั้งหมด select()s เข้าใจพร็อพเพอร์ตี้ของเครื่องที่ //:myplatform บอกเป็นนัย
6. //:myplatform กำหนดไว้ในตำแหน่งที่ชัดเจนและนำกลับมาใช้ซ้ำได้ นั่นคือในที่เก็บของโปรเจ็กต์หากแพลตฟอร์มนั้นไม่ซ้ำกับโปรเจ็กต์ของคุณ หรือไม่เช่นนั้นก็อยู่ในตำแหน่งที่โปรเจ็กต์ทั้งหมดที่อาจใช้แพลตฟอร์มนี้สามารถค้นหาได้

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

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

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

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

คุณค่า

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

ค่าใช้จ่าย

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

การตรวจสอบ API

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

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

A 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") และ ผู้ให้บริการจะส่งข้อมูลนี้ไปยังกฎที่ต้องสร้างด้วยเครื่องมือเหล่านี้

เครื่องมือทางเทคนิคจะประกาศ 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. ต้องอัปเดตตรรกะกฎเพื่อรับข้อมูลเครื่องมือจาก API Toolchain ใหม่ (ctx.toolchains) และหยุดอ่านการตั้งค่าเดิม เช่น --cpu และ --crosstool_top ซึ่งเป็นกระบวนการที่ค่อนข้างตรงไปตรงมา

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

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

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

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

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

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

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

พร็อพเพอร์ตี้ที่ใช้ร่วมกันทั่วโลกจะประกาศในที่เก็บ @platforms (ดังนั้นป้ายกำกับมาตรฐานสำหรับตัวอย่างข้างต้นคือ @platforms//cpu:arm) ส่วนพร็อพเพอร์ตี้ที่ใช้ร่วมกันในภาษาควรประกาศในที่เก็บของภาษาที่เกี่ยวข้อง

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

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

เมื่อไม่ได้ตั้งค่า --platforms Bazel จะใช้ platform ที่แสดงถึงเครื่องสร้างในเครื่องเป็นค่าเริ่มต้น ซึ่งจะสร้างขึ้นโดยอัตโนมัติที่ @local_config_platform//:host คุณจึงไม่จำเป็นต้องกำหนดอย่างชัดเจน โดยจะจับคู่ OS และ CPU ของเครื่องในเครื่องกับ constraint_values ที่ประกาศใน @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++ ไม่ได้ขึ้นต่อกันกับโปรเจ็กต์ของคุณ คุณสามารถใช้ แพลตฟอร์มได้อย่างปลอดภัยตราบใดที่ selects และ การเปลี่ยนผ่านเข้ากันได้ ดูคำแนะนำเพิ่มเติมได้ที่ #7260 และ การกำหนดค่าเครื่องมือทางเทคนิค C++

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

Java

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

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

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

หากยังคงใช้แฟล็กเดิมอยู่ ให้ทำตามกระบวนการย้ายข้อมูลใน Issue #7849

Android

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

ซึ่งไม่ได้เปิดใช้โดยค่าเริ่มต้น แต่การย้ายข้อมูลก็ดำเนินการไปได้ด้วยดี

Apple

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

นอกจากนี้ กฎดังกล่าวยังไม่รองรับทรัพยากร Dependency C++ ที่เปิดใช้แพลตฟอร์มเนื่องจากใช้ --crosstool_top เดิมเพื่อตั้งค่า Toolchain 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 หรือแฟล็กเดิมอื่นๆ กฎที่อ่าน --platforms จะไม่เห็นการเปลี่ยนแปลงเหล่านี้

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

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

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

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

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

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

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

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

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

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

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

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

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
• แพลตฟอร์ม
• เครื่องมือทางเทคนิค
• สูตรการแก้ปัญหาแพลตฟอร์ม Bazel
• hlopko/bazel_platforms_examples
• ตัวอย่าง Toolchain C++ ที่กำหนดเอง