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

รายงานปัญหา ดูแหล่งที่มา

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

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

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

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

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

ฉากหลัง

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

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

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

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

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

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

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

เป้าหมาย

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

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

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

1. กฎที่โปรเจ็กต์ใช้สามารถอนุมาน Toolchain ที่ถูกต้องจาก //:myplatform
2. กฎที่การขึ้นต่อกันของโปรเจ็กต์ใช้จะอนุมาน Toolchain ที่ถูกต้องได้ จาก //:myplatform
3. ไม่ว่าโปรเจ็กต์ที่ขึ้นอยู่กับโปรเจ็กต์ของคุณจะรองรับ //:myplatform หรือโปรเจ็กต์ของคุณจะรองรับ API เดิม (เช่น --crosstool_top)
4. //:myplatform references [common declarations][Common Platform Declaration]{: .external} of CPU, OS, and other generic concepts that support automatic cross-project compatibility.
5. โปรเจ็กต์ที่เกี่ยวข้องทั้งหมดselect() เข้าใจพร็อพเพอร์ตี้ของเครื่องที่ //:myplatform ระบุ
6. //:myplatform มีการกำหนดไว้ในที่ที่ชัดเจนและนำกลับมาใช้ใหม่ได้ นั่นคือ ใน ที่เก็บของโปรเจ็กต์หากแพลตฟอร์มนั้นเป็นของโปรเจ็กต์ของคุณโดยเฉพาะ หรือในที่ที่โปรเจ็กต์ทั้งหมด ที่อาจใช้แพลตฟอร์มนี้ค้นหาได้

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

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

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

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

ค่า

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

ค่าใช้จ่าย

• โปรเจ็กต์ที่ขึ้นต่อกันซึ่งยังไม่รองรับแพลตฟอร์มอาจไม่ทำงานร่วมกับโปรเจ็กต์ของคุณโดยอัตโนมัติ
• การทำให้ฟีเจอร์เหล่านี้ทำงานอาจต้องการบำรุงรักษาชั่วคราวเพิ่มเติม
• การใช้ API ใหม่และ 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"]) และเครื่องที่เครื่องมือสามารถ เรียกใช้ (exec_compatible_with = ["@platforms//os:mac"])

เมื่อสร้าง $ bazel build //:myproject --platforms=//:myplatform, Bazel จะเลือก Toolchain ที่สามารถเรียกใช้ในเครื่องบิลด์และ สร้างไบนารีสำหรับ //:myplatform โดยอัตโนมัติ การดำเนินการนี้เรียกว่าการแก้ปัญหา 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 ทริกเกอร์เหล่านี้จะเปิดโหมด "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

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

หากยังใช้ฟีเจอร์ที่เลิกใช้งานแล้ว ให้ทำตามกระบวนการย้ายข้อมูลในปัญหา #7849

Android

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

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

Apple

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

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

ภาษาอื่นๆ

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

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

select()

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

หากต้องการเลือกใน constraint_values อย่างน้อย 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 แพลตฟอร์ม/เครื่องมือ โปรดติดต่อ [e-mail]

ดูเพิ่มเติม

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