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

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

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

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

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

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

ที่มา

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

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

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

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

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

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

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

เป้าหมาย

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

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

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

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

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

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

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

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

ค่า

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

ค่าใช้จ่าย

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

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

เชนเครื่องมือจะประกาศ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

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

สถานะ

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

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

2. ผู้ดูแลเชนเครื่องมือต้องกำหนด 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 จะใช้แพลตฟอร์มเพื่อเลือกเชนเครื่องมือเมื่อตั้งค่า --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 ยังคงกำหนดค่าทรัพยากร Dependency ของ C++ ด้วย --cpu และ --crosstool_top (ตัวอย่าง) ซึ่งขึ้นอยู่กับกฎของ Apple ที่ย้ายข้อมูลไปยังแพลตฟอร์ม

Java

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

แฟล็กนี้มาแทนที่แฟล็กเดิม --java_toolchain, --host_java_toolchain, --javabase และ --host_javabase

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

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

Android

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

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

แอปเปิ้ล

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

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

ภาษาอื่นๆ

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

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

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. หากโปรเจ็กต์ที่คุณสนใจยังคงต้องใช้แฟล็กเดิม เช่น --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 ก็ได้

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

คำถาม

หากต้องการการสนับสนุนทั่วไปและมีข้อสงสัยเกี่ยวกับไทม์ไลน์การย้ายข้อมูล โปรดติดต่อ [e-mail] หรือเจ้าของกฎที่เหมาะสม

หากต้องการพูดคุยเกี่ยวกับการออกแบบและพัฒนา API ของแพลตฟอร์ม/toolchain โปรดติดต่อ [e-mail]

ดูเพิ่มเติม

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