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

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

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

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

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

• แพลตฟอร์ม
• Toolchains

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

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

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

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

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

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

ตัวอย่างเช่น Bazel แพลตฟอร์มสนับสนุนกฎ C++ แต่กฎของ 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 เก่าออกทันทีที่บรรลุเป้าหมายนี้ จากนั้นการดำเนินการนี้จะ เป็นวิธีมาตรฐานในการเลือกแพลตฟอร์มและ Toolchain ของโปรเจ็กต์

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

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

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

ค่า

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

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

Java

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

การดำเนินการนี้จะแทนที่ Flag เดิม --java_toolchain, --host_java_toolchain, --javabase และ --host_javabase

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

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

Android

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

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

Apple

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

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

ภาษาอื่นๆ

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

หากกำลังออกแบบกฎสำหรับภาษาใหม่ ให้ใช้แพลตฟอร์ม เพื่อเลือก Toolchain ของภาษาได้ โปรดดู เอกสารคู่มือ 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หรือใช้การแมปแพลตฟอร์มเพื่อรองรับ ผ่านกรอบเวลาการย้ายข้อมูล

ทรานซิชัน

การเปลี่ยนแปลงการเปลี่ยนของ Starlark แจ้งส่วนต่างๆ ของกราฟบิลด์ หากโปรเจ็กต์ของคุณใช้การเปลี่ยนผ่านที่ ตั้งค่า --cpu, --crossstool_top หรือแฟล็กเดิมอื่นๆ ซึ่งก็คือกฎที่อ่าน --platforms จะไม่เห็นการเปลี่ยนแปลงเหล่านี้

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

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

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

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

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

2. หากโปรเจ็กต์ที่คุณสนใจยังคงต้องใช้ Flag เดิม เช่น --cpu และ --crosstool_top ใช้ร่วมกับ --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 ในไฟล์ Workspace Root นอกจากนี้ คุณยังสามารถตั้งค่า --platform_mappings=//:my_custom_mapping

โปรดดู ที่นี่ เพื่อดูรายละเอียดทั้งหมด

คำถาม

หากต้องการรับการสนับสนุนทั่วไปและมีคำถามเกี่ยวกับไทม์ไลน์การย้ายข้อมูล โปรดติดต่อ bazel-discuss@googlegroups.com หรือเจ้าของกฎที่เหมาะสม

สำหรับการพูดคุยถึงการออกแบบและพัฒนา API ของแพลตฟอร์ม/เครื่องมือเชน รายชื่อติดต่อ bazel-dev@googlegroups.com.

ดูเพิ่มเติม

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