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

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

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

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

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

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

ที่มา

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

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

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

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

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

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

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

เป้าหมาย

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

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

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

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

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

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

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

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

ค่า

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

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

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

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

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

สถานะ

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

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

  2. ผู้บำรุงรักษา Toolchain ต้องกำหนด 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 และ การกำหนดค่า Toolchains ของ 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 ยังไม่รองรับแพลตฟอร์มให้เลือก Toolchain ของ Apple

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

ภาษาอื่นๆ

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

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

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

  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 ในรูทพื้นที่ทำงานของคุณ คุณยังตั้งค่า --platform_mappings=//:my_custom_mapping ได้ด้วย

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

คำถาม

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

หากต้องการพูดคุยเกี่ยวกับการออกแบบและพัฒนา API ของแพลตฟอร์ม/toolchain โปรดติดต่อ bazel-dev@googlegroups.com

ดูเพิ่มเติม