หน้านี้ได้รับการแปลโดย Cloud Translation API

กฎ C / C++

กฎ

cc_binary
cc_import
cc_library
cc_proto_library
cc_shared_library
fdo_prefetch_hints
fdo_profile
memprof_profile
propeller_optimize
cc_test
cc_toolchain
cc_toolchain_suite

cc_binary

cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, nocopts, output_licenses, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

เป้าหมายเอาต์พุตโดยนัย

name.stripped (สร้างเฉพาะในกรณีที่มีการขออย่างชัดเจน): ไบนารีเวอร์ชันที่ถูกตัดออก strip -g จะเรียกใช้ในไบนารีเพื่อนำสัญลักษณ์การแก้ไขข้อบกพร่องออก ระบุตัวเลือกแถบเพิ่มเติมในบรรทัดคำสั่งได้โดยใช้ --stripopt=-foo ระบบจะสร้างเอาต์พุตนี้ขึ้นเมื่อมีการขออย่างชัดแจ้งเท่านั้น
name.dwp (สร้างเฉพาะในกรณีที่มีคำขออย่างชัดแจ้งเท่านั้น): หากเปิดใช้ Fission: ไฟล์แพ็กเกจข้อมูลการแก้ไขข้อบกพร่องที่เหมาะสำหรับการแก้ไขข้อบกพร่องของไบนารีที่ทำให้ใช้งานได้จากระยะไกล หรือไม่ก็ไฟล์เปล่า

อาร์กิวเมนต์

Attributes
`name`	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไลบรารีอื่นๆ ที่จะลิงก์กับเป้าหมายไบนารี ซึ่งอาจเป็น `cc_library` หรือ `objc_library` เป้าหมาย
`srcs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ C และ C++ ที่ประมวลผลเพื่อสร้างเป้าหมาย ไฟล์เหล่านี้เป็นไฟล์ส่วนหัวและแหล่งที่มาของ C/C++ อาจเป็นไฟล์ที่ไม่ได้สร้าง (ซอร์สโค้ดปกติ) หรือสร้างขึ้น ระบบจะคอมไพล์ไฟล์ทั้งหมด `.cc`, `.c` และ `.cpp` ซึ่งอาจเป็นไฟล์ที่สร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน `outs` ของกฎอื่น กฎนี้จะขึ้นอยู่กับกฎนั้นโดยอัตโนมัติ ระบบจะไม่คอมไพล์ไฟล์ `.h` แต่แหล่งที่มาในกฎนี้จะรวมไฟล์ได้ ทั้งไฟล์ `.cc` และ `.h` จะมีส่วนหัวที่ระบุไว้ใน `srcs` เหล่านี้หรือใน `hdrs` ของกฎที่ระบุไว้ในอาร์กิวเมนต์ `deps` ได้โดยตรง คุณต้องพูดถึงไฟล์ `#include`d ทั้งหมดในแอตทริบิวต์ `srcs` ของกฎนี้ หรือในแอตทริบิวต์ `hdrs` ของ `cc_library()` ที่อ้างอิง รูปแบบที่แนะนำมีไว้สำหรับส่วนหัวที่เชื่อมโยงกับไลบรารีที่จะปรากฏในแอตทริบิวต์ `hdrs` ของไลบรารีดังกล่าว และแสดงส่วนหัวที่เหลืออยู่ซึ่งเชื่อมโยงกับแหล่งที่มาของกฎนี้ใน `srcs` โปรดดูรายละเอียดเพิ่มเติมใน "การตรวจสอบการรวมส่วนหัว" หากชื่อของกฎอยู่ในภาษา `srcs` กฎนี้จะขึ้นอยู่กับชื่อนั้นโดยอัตโนมัติ หาก `outs` ของกฎที่ตั้งชื่อเป็นไฟล์ต้นฉบับ C หรือ C++ ระบบจะคอมไพล์ลงในกฎนี้ หากเป็นไฟล์ไลบรารี ระบบจะลิงก์ไฟล์เหล่านั้นเข้า ไฟล์ `srcs` ประเภทที่อนุญาต: ไฟล์ต้นฉบับ C และ C++: `.c`, `.cc`, `.cpp`, `.cxx`, `.c++`, `.C` ไฟล์ส่วนหัว C และ C++: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` เครื่องมือประกอบที่มีโปรเซสเซอร์ล่วงหน้าแบบ C: `.S` ที่เก็บถาวร: `.a`, `.pic.a` ไลบรารี "ลิงก์เสมอ": `.lo`, `.pic.lo` ไลบรารีที่ใช้ร่วมกัน มีการกำหนดเวอร์ชันหรือไม่ใช่เวอร์ชัน: `.so`, `.so.version` ไฟล์ออบเจ็กต์: `.o`, `.pic.o` ...และกฎที่สร้างไฟล์เหล่านั้น ส่วนขยายที่แตกต่างกันจะแสดงภาษาโปรแกรมที่แตกต่างกันตามแบบแผน gcc
`additional_linker_inputs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` ส่งต่อไฟล์เหล่านี้ไปยังคำสั่ง Linker C++ เช่น ไฟล์ .res ของ Windows ที่คอมไพล์แล้วอาจระบุที่นี่เพื่อฝังในเป้าหมายไบนารี
`copts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" และการแปลงข้อมูลเป็นโทเค็น Bourne Shell ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ตามลำดับที่ระบุไปยัง `COPTS` ก่อนคอมไพล์เป้าหมายไบนารี แฟล็กจะมีผลต่อการคอมไพล์เป้าหมายนี้เท่านั้น โดยไม่รวมทรัพยากร Dependency ต่างๆ ดังนั้นโปรดระวังเกี่ยวกับไฟล์ส่วนหัวที่อยู่ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน หากแพ็กเกจประกาศฟีเจอร์ `no_copts_tokenization` การแปลงข้อมูลเป็นโทเค็น Bourne Shell จะใช้กับสตริงที่ประกอบด้วยตัวแปร "Make" เดียวเท่านั้น
`defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็นเชลล์ Bourne รายการเดียว จะมี `-D` นำหน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์ไปยังเป้าหมายนี้ รวมถึงกฎทั้งหมดที่อ้างอิงสตริงนี้ โปรดใช้ความระมัดระวังเป็นอย่างยิ่งเนื่องจากอาจทำให้เกิดผลกระทบอย่างมาก หากไม่แน่ใจ ให้เพิ่มกําหนดค่าให้กับ `local_defines` แทน
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" แต่ละสตริงจะเพิ่ม `-isystem` ไว้ข้างหน้า และเพิ่มลงใน `COPTS` ซึ่งต่างจาก COPTS ตรงที่จะเพิ่มแฟล็กเหล่านี้สำหรับกฎนี้และกฎทั้งหมดที่อ้างอิงกฎดังกล่าว (หมายเหตุ: ไม่ใช่กฎเกณฑ์แต่อย่างใด) โปรดระมัดระวังให้มาก เนื่องจากอาจทำให้เกิดผลกระทบอย่างมาก หากไม่แน่ใจ ให้เพิ่มแฟล็ก "-I" ลงใน COPTS แทน คุณต้องเพิ่มส่วนหัวไปยัง src หรือ hdr ไม่เช่นนั้น ส่วนหัวจะใช้ไม่ได้ในกฎที่อ้างอิงเมื่อการคอมไพล์เป็นแซนด์บ็อกซ์ (ค่าเริ่มต้น)
`link_extra_lib`	ป้ายกำกับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:link_extra_lib"` ควบคุมการลิงก์ไลบรารีเพิ่มเติม โดยค่าเริ่มต้น ไบนารีของ C++ จะลิงก์กับ `//tools/cpp:link_extra_lib` ซึ่งโดยค่าเริ่มต้นจะขึ้นอยู่กับแฟล็กป้ายกำกับ `//tools/cpp:link_extra_libs` หากไม่ได้ตั้งค่าสถานะ ไลบรารีนี้จะว่างเปล่าโดยค่าเริ่มต้น การตั้งค่าแฟล็กป้ายกำกับช่วยให้ลิงก์ทรัพยากร Dependency ที่ไม่บังคับได้ เช่น การลบล้างสัญลักษณ์ที่ไม่รัดกุม, ตัวดักจับสัญญาณสำหรับฟังก์ชันไลบรารีที่ใช้ร่วมกัน หรือไลบรารีรันไทม์พิเศษ (สำหรับการแทนที่ Malloc ให้ใช้ `malloc` หรือ `--custom_malloc`) การตั้งค่าแอตทริบิวต์นี้เป็น `None` จะปิดใช้ลักษณะการทำงานนี้
`linkopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มแฟล็กเหล่านี้ลงในคำสั่ง Linker C++ ขึ้นอยู่กับการแทนที่ "Make" ตัวแปร Bourne Shell Tokenization และ การขยายป้ายกำกับ ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ไปยัง `LINKOPTS` ก่อนลิงก์เป้าหมายไบนารี แต่ละองค์ประกอบในรายการที่ไม่ได้ขึ้นต้นด้วย `$` หรือ `-` จะถือว่าเป็นป้ายกำกับของเป้าหมายใน `deps` รายการไฟล์ที่สร้างโดยเป้าหมายดังกล่าวจะต่อท้ายตัวเลือก Linker ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือไม่มีการประกาศใน `deps`
`linkshared`	บูลีน nonconfigurable ค่าเริ่มต้นคือ `False` สร้างไลบรารีที่ใช้ร่วมกัน หากต้องการเปิดใช้แอตทริบิวต์นี้ ให้ใส่ `linkshared=True` ในกฎ ตัวเลือกนี้จะปิดอยู่โดยค่าเริ่มต้น การมี Flag นี้แสดงว่ามีการลิงก์ด้วยแฟล็ก `-shared` ไปยัง `gcc` และไลบรารีที่ใช้ร่วมกันที่ได้เหมาะสมสำหรับการโหลดลงในโปรแกรม Java เช่น อย่างไรก็ตาม สำหรับวัตถุประสงค์ในการสร้าง จะไม่มีการลิงก์เข้ากับไบนารีแบบอ้างอิง เนื่องจากมีสมมติฐานว่าไลบรารีที่ใช้ร่วมกันที่สร้างด้วยกฎ cc_binary จะโหลดโดยโปรแกรมอื่นๆ ด้วยตนเองเท่านั้น จึงไม่ถือว่าเป็นการใช้แทนกฎ cc_library เราขอแนะนำให้หลีกเลี่ยงวิธีนี้ทั้งหมดและปล่อยให้ `java_library` ขึ้นอยู่กับกฎ `cc_library` แทน เพื่อเพิ่มความสามารถในการปรับขนาด หากระบุทั้ง `linkopts=['-static']` และ `linkshared=True` คุณจะได้รับหน่วยโฆษณาสำเร็จรูปเพียงหน่วยเดียว หากระบุทั้ง `linkstatic=True` และ `linkshared=True` คุณจะได้รับยูนิตเดี่ยวแบบเดี่ยวส่วนใหญ่
`linkstatic`	บูลีน ค่าเริ่มต้นคือ `True` สำหรับ `cc_binary` และ `cc_test` ให้ลิงก์ไบนารีในโหมดคงที่ สำหรับ `cc_library.linkstatic`: ดูด้านล่าง โดยค่าเริ่มต้น ตัวเลือกนี้จะเปิดอยู่สำหรับ `cc_binary` และปิดอยู่สำหรับส่วนที่เหลือ หากเปิดใช้และนี่เป็นไบนารีหรือการทดสอบ ตัวเลือกนี้จะบอกเครื่องมือสร้างให้ลิงก์ใน `.a` แทน `.so` สำหรับไลบรารีผู้ใช้เมื่อเป็นไปได้ ไลบรารีระบบบางส่วนอาจยังลิงก์แบบไดนามิก เช่นเดียวกับไลบรารีที่ไม่มีไลบรารีแบบคงที่ ดังนั้นไฟล์ปฏิบัติการที่ได้จะยังคงลิงก์แบบไดนามิกอยู่ จึงส่วนใหญ่เป็นแบบคงที่ การลิงก์ไฟล์ปฏิบัติการมี 3 วิธีที่แตกต่างกันดังนี้ สถิติที่มีฟีเจอร์ลิงก์_สถิติแบบเต็ม ซึ่งลิงก์ทุกอย่างในแบบคงที่ เช่น "`gcc -static foo.o libbar.a libbaz.a -lm`" โหมดนี้เปิดใช้งานโดยระบุ `fully_static_link` ในแอตทริบิวต์ `features` สถิติซึ่งไลบรารีผู้ใช้ทั้งหมดลิงก์แบบคงที่ (หากมีเวอร์ชันคงที่) แต่ไลบรารีของระบบ (ยกเว้นไลบรารีรันไทม์ C/C++) มีการลิงก์แบบไดนามิก เช่น "`gcc foo.o libfoo.a libbaz.a -lm`" โหมดนี้เปิดใช้โดยระบุ `linkstatic=True` ไดนามิก (DYNAMIC) ซึ่งมีการลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันไดนามิกให้ใช้งาน) เช่น "`gcc foo.o libfoo.so libbaz.so -lm`" โหมดนี้เปิดใช้ด้วยการระบุ `linkstatic=False` แอตทริบิวต์ `linkstatic` จะมีความหมายต่างออกไปหากใช้ในกฎ `cc_library()` สำหรับไลบรารี C++ `linkstatic=True` จะระบุว่าอนุญาตให้มีการลิงก์แบบคงที่เท่านั้น จึงไม่มีการสร้าง `.so` ขึ้น linkstatic=False ไม่ได้ป้องกันการสร้างไลบรารีแบบคงที่ แอตทริบิวต์นี้มีไว้เพื่อควบคุมการสร้างไลบรารีแบบไดนามิก หากเป็น `linkstatic=False` เครื่องมือสร้างจะสร้างลิงก์สัญลักษณ์ไปยังไลบรารีที่ใช้ร่วมกันซึ่งขึ้นอยู่กับพื้นที่ `*.runfiles`
`local_defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็นเชลล์ Bourne รายการเดียว มีการเพิ่ม `-D` ไว้หน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์สำหรับเป้าหมายนี้ แต่ไม่ใช่ลงในการอ้างอิง
`malloc`	ป้ายกำกับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:malloc"` ลบล้างทรัพยากร Dependency เริ่มต้นใน Malloc โดยค่าเริ่มต้น ไบนารีของ C++ จะลิงก์กับ `//tools/cpp:malloc` ซึ่งเป็นไลบรารีที่ว่างเปล่า ดังนั้นไบนารีนั้นจะใช้ libc Malloc ป้ายกำกับนี้ต้องอ้างอิงถึง `cc_library` หากการคอมไพล์เป็นกฎที่ไม่ใช่ C++ ตัวเลือกนี้จะไม่มีผล ระบบจะละเว้นค่าของแอตทริบิวต์นี้หากระบุ `linkshared=True`
`nocopts`	สตริง ค่าเริ่มต้นคือ `""` นำรูปแบบการทำงานของคีย์เวิร์ดออกจากคำสั่งคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "Make" ระบบจะตีความค่าของแอตทริบิวต์นี้เป็นนิพจน์ทั่วไป ระบบจะนำ `COPTS` ที่มีอยู่ก่อนหน้าซึ่งตรงกับนิพจน์ทั่วไปนี้ (รวมถึงค่าที่ระบุอย่างชัดแจ้งในแอตทริบิวต์ copts ของกฎ) ออกจาก `COPTS` เพื่อวัตถุประสงค์ในการรวบรวมกฎนี้ แอตทริบิวต์นี้ไม่จำเป็นเสมอไป
`stamp`	จำนวนเต็ม ค่าเริ่มต้นคือ `-1` ระบุว่าจะเข้ารหัสข้อมูลบิลด์ลงในไบนารีหรือไม่ ค่าที่เป็นไปได้มีดังนี้ `stamp = 1`: ประทับตราข้อมูลบิลด์ลงในไบนารีเสมอ แม้ในบิลด์ `--nostamp` ก็ตาม ควรหลีกเลี่ยงการตั้งค่านี้ เนื่องจากอาจทำให้การแคชระยะไกลสำหรับไบนารีและการดำเนินการดาวน์สตรีมจะขึ้นอยู่กับการแคชจากระยะไกล `stamp = 0`: แทนที่ข้อมูลบิลด์ด้วยค่าคงที่เสมอ วิธีนี้จะทำให้มีการแคชผลลัพธ์ของบิลด์ที่ดี `stamp = -1`: การฝังข้อมูลบิลด์จะควบคุมโดยแฟล็ก `--[no]stamp` ระบบจะไม่สร้างไบนารีที่ประทับตราอีกครั้ง เว้นแต่ทรัพยากร Dependency จะมีการเปลี่ยนแปลง
`win_def_file`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ไฟล์ DEF ของ Windows ที่จะส่งไปยัง Linker แอตทริบิวต์นี้ควรใช้เมื่อ Windows เป็นแพลตฟอร์มเป้าหมายเท่านั้น โดยใช้เพื่อ ส่งออกสัญลักษณ์ระหว่างการลิงก์ไลบรารีที่ใช้ร่วมกันได้

cc_import

ดูแหล่งที่มาของกฎ

cc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)

กฎ cc_import อนุญาตให้ผู้ใช้นำเข้าไลบรารี C/C++ ที่คอมไพล์ไว้ล่วงหน้าได้

กรณีการใช้งานทั่วไปมีดังนี้
1. การลิงก์ไลบรารีแบบคงที่

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  # If alwayslink is turned on,
  # libmylib.a will be forcely linked into any binary that depends on it.
  # alwayslink = 1,
)

2. การลิงก์ไลบรารีที่ใช้ร่วมกัน (Unix)

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  shared_library = "libmylib.so",
)

3. การลิงก์ไลบรารีที่ใช้ร่วมกันกับไลบรารีอินเทอร์เฟซ (Windows)

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is an import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll will be available for runtime
  shared_library = "mylib.dll",
)

4. การลิงก์ไลบรารีที่ใช้ร่วมกันกับ system_provided=True (Windows)

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is an import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll is provided by system environment, for example it can be found in PATH.
  # This indicates that Bazel is not responsible for making mylib.dll available.
  system_provided = 1,
)

5. การลิงก์กับไลบรารีแบบคงที่หรือไลบรารีที่ใช้ร่วมกัน
ใน Unix ให้ทำดังนี้

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  shared_library = "libmylib.so",
)

# first will link to libmylib.a
cc_binary(
  name = "first",
  srcs = ["first.cc"],
  deps = [":mylib"],
  linkstatic = 1, # default value
)

# second will link to libmylib.so
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)

ใน Windows

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.lib", # A normal static library
  interface_library = "mylib.lib", # An import library for mylib.dll
  shared_library = "mylib.dll",
)

# first will link to libmylib.lib
cc_binary(
  name = "first",
  srcs = ["first.cc"],
  deps = [":mylib"],
  linkstatic = 1, # default value
)

# second will link to mylib.dll through mylib.lib
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)

cc_import รองรับแอตทริบิวต์ include ตัวอย่างเช่น

  cc_import(
  name = "curl_lib",
  hdrs = glob(["vendor/curl/include/curl/*.h"]),
  includes = [ "vendor/curl/include" ],
  shared_library = "vendor/curl/lib/.libs/libcurl.dylib",
)

อาร์กิวเมนต์

Attributes
`name`	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการของไลบรารีอื่นๆ ที่เป้าหมายขึ้นอยู่กับ ดูความคิดเห็นทั่วไปเกี่ยวกับ `deps` ได้ที่แอตทริบิวต์ทั่วไปที่กำหนดโดยกฎบิลด์ส่วนใหญ่
`hdrs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ส่วนหัวที่เผยแพร่โดยไลบรารีที่คอมไพล์ไว้ล่วงหน้านี้เพื่อรวมโดยตรงโดยแหล่งที่มาในกฎที่ไม่อ้างอิง
`alwayslink`	บูลีน ค่าเริ่มต้นคือ `False` หากเป็น 1 ไบนารีใดๆ ที่ขึ้นอยู่กับ (โดยตรงหรือโดยอ้อม) ในไลบรารีที่คอมไพล์ C++ นี้ จะลิงก์ในไฟล์ออบเจ็กต์ทั้งหมดที่เก็บไว้ในไลบรารีแบบคงที่ แม้ว่าบางไฟล์จะไม่มีสัญลักษณ์ที่ไบนารีอ้างอิงอยู่ วิธีนี้มีประโยชน์หากโค้ดไม่ได้มีการเรียกอย่างชัดเจนด้วยโค้ดในไบนารี เช่น หากโค้ดของคุณลงทะเบียนเพื่อรับ Callback ที่บริการบางอย่างมีให้ หากเสมอลิงก์ไม่ได้กับ VS 2017 ใน Windows ซึ่งอาจเกิดจากปัญหาที่ทราบ โปรดอัปเกรด VS 2017 เป็นเวอร์ชันล่าสุด
`interface_library`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ไลบรารีอินเทอร์เฟซเดียวสำหรับการลิงก์ไลบรารีที่ใช้ร่วมกัน ประเภทไฟล์ที่อนุญาต: `.ifso`, `.tbd`, `.lib`, `.so` หรือ `.dylib`
`shared_library`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ไลบรารีที่ใช้ร่วมกันล่วงหน้ารายการเดียว Bazel ช่วยให้มั่นใจว่าไบนารีนั้นใช้งานได้ระหว่างรันไทม์ ประเภทไฟล์ที่อนุญาต: `.so`, `.dll` หรือ `.dylib`
`static_library`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ไลบรารีแบบคงที่ซึ่งคอมไพล์ไว้ล่วงหน้ารายการเดียว ประเภทไฟล์ที่อนุญาต: `.a`, `.pic.a` หรือ `.lib`
`system_provided`	บูลีน ค่าเริ่มต้นคือ `False` หากเป็น 1 แสดงว่าระบบจัดเตรียมไลบรารีที่ใช้ร่วมกันที่ต้องใช้ขณะรันไทม์ ในกรณีนี้ คุณควรระบุ `interface_library` และ `shared_library` ควรเว้นว่างไว้

cc_library

ดูแหล่งที่มาของกฎ

cc_library(name, deps, srcs, data, hdrs, additional_compiler_inputs, additional_linker_inputs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

การตรวจสอบการรวมส่วนหัว

ไฟล์ส่วนหัวทั้งหมดที่ใช้ในบิลด์ต้องประกาศในกฎ hdrs หรือ srcs ของ cc_* บังคับใช้ข้อกำหนดแล้ว

สำหรับกฎ cc_library ส่วนหัวใน hdrs ประกอบด้วยอินเทอร์เฟซสาธารณะของไลบรารีและรวมได้โดยตรงจากไฟล์ใน hdrs และ srcs ของไลบรารีเอง รวมถึงจากไฟล์ใน hdrs และกฎ srcs จาก cc_* ข้อที่แสดงไลบรารีใน deps ส่วนหัวใน srcs ต้องรวมโดยตรงจากไฟล์ใน hdrs และ srcs ของไลบรารีโดยตรงเท่านั้น เมื่อตัดสินใจว่าจะใส่ส่วนหัวใน hdrs หรือ srcs คุณควรถามว่าต้องการให้ผู้บริโภคของคลังนี้รวมส่วนหัวดังกล่าวได้โดยตรงหรือไม่ การตัดสินใจนี้คล้ายกับการตัดสินระหว่าง public ถึง private ในภาษาโปรแกรม

กฎ cc_binary และ cc_test ไม่มีอินเทอร์เฟซที่ส่งออก จึงไม่มีแอตทริบิวต์ hdrs ส่วนหัวทั้งหมดที่เป็นของไบนารีหรือการทดสอบโดยตรงควรระบุไว้ใน srcs

ลองดูตัวอย่างต่อไปนี้เพื่อแสดงกฎเหล่านี้

cc_binary(
    name = "foo",
    srcs = [
        "foo.cc",
        "foo.h",
    ],
    deps = [":bar"],
)

cc_library(
    name = "bar",
    srcs = [
        "bar.cc",
        "bar-impl.h",
    ],
    hdrs = ["bar.h"],
    deps = [":baz"],
)

cc_library(
    name = "baz",
    srcs = [
        "baz.cc",
        "baz-impl.h",
    ],
    hdrs = ["baz.h"],
)

การรวมโดยตรงที่อนุญาตในตัวอย่างนี้จะแสดงอยู่ในตารางด้านล่าง ตัวอย่างเช่น foo.cc ได้รับอนุญาตให้รวม foo.h และ bar.h โดยตรง แต่ไม่รวม baz.h

รวมไฟล์	การรวมที่อนุญาต
foo.h	bar.h
foo.cc	foo.h bar.h
bar.h	bar-impl.h baz.h
bar-impl.h	บาซ
bar.cc	bar.h bar-impl.h baz.h
baz.h	baz-impl.h
baz-impl.h	baz.h
baz.cc	baz.h baz-impl.h

กฎการตรวจสอบการรวมจะมีผลกับการรวมโดยตรงเท่านั้น ในตัวอย่างด้านบน foo.cc ได้รับอนุญาตให้ใส่ bar.h ซึ่งอาจรวมถึง baz.h ซึ่งส่งผลให้มี baz-impl.h รวมอยู่ด้วย ในทางเทคนิค การคอมไพล์ไฟล์ .cc อาจรวมไฟล์ส่วนหัวใดๆ ไว้ใน hdrs หรือ srcs ใน cc_library ใดๆ ในการปิด deps แบบทางอ้อม ในกรณีนี้ คอมไพเลอร์อาจอ่าน baz.h และ baz-impl.h เมื่อคอมไพเลอร์ foo.cc แต่ foo.cc ต้องไม่มี #include "baz.h" คุณต้องเพิ่ม baz ลงใน deps ของ foo จึงจะได้รับอนุญาต

Bazel อาศัยการรองรับ Toolchain เพื่อบังคับใช้กฎการตรวจสอบการรวม Toolchain ต้องรองรับฟีเจอร์ layering_check และมีการร้องขออย่างชัดแจ้ง เช่น ผ่านแฟล็กบรรทัดคำสั่ง --features=layering_check หรือพารามิเตอร์ features ของฟังก์ชัน package เครื่องมือเชนจาก Bazel รองรับเฉพาะฟีเจอร์นี้กับ Clang ใน Unix และ macOS เท่านั้น

อาร์กิวเมนต์

Attributes
`name`	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไลบรารีอื่นๆ ที่จะลิงก์กับเป้าหมายไบนารี ซึ่งอาจเป็น `cc_library` หรือ `objc_library` เป้าหมาย
`srcs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ C และ C++ ที่ประมวลผลเพื่อสร้างเป้าหมาย ไฟล์เหล่านี้เป็นไฟล์ส่วนหัวและแหล่งที่มาของ C/C++ อาจเป็นไฟล์ที่ไม่ได้สร้าง (ซอร์สโค้ดปกติ) หรือสร้างขึ้น ระบบจะคอมไพล์ไฟล์ทั้งหมด `.cc`, `.c` และ `.cpp` ซึ่งอาจเป็นไฟล์ที่สร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน `outs` ของกฎอื่น กฎนี้จะขึ้นอยู่กับกฎนั้นโดยอัตโนมัติ ระบบจะไม่คอมไพล์ไฟล์ `.h` แต่แหล่งที่มาในกฎนี้จะรวมไฟล์ได้ ทั้งไฟล์ `.cc` และ `.h` จะมีส่วนหัวที่ระบุไว้ใน `srcs` เหล่านี้หรือใน `hdrs` ของกฎที่ระบุไว้ในอาร์กิวเมนต์ `deps` ได้โดยตรง คุณต้องพูดถึงไฟล์ `#include`d ทั้งหมดในแอตทริบิวต์ `srcs` ของกฎนี้ หรือในแอตทริบิวต์ `hdrs` ของ `cc_library()` ที่อ้างอิง รูปแบบที่แนะนำมีไว้สำหรับส่วนหัวที่เชื่อมโยงกับไลบรารีที่จะปรากฏในแอตทริบิวต์ `hdrs` ของไลบรารีดังกล่าว และแสดงส่วนหัวที่เหลืออยู่ซึ่งเชื่อมโยงกับแหล่งที่มาของกฎนี้ใน `srcs` โปรดดูรายละเอียดเพิ่มเติมใน "การตรวจสอบการรวมส่วนหัว" หากชื่อของกฎอยู่ในภาษา `srcs` กฎนี้จะขึ้นอยู่กับชื่อนั้นโดยอัตโนมัติ หาก `outs` ของกฎที่ตั้งชื่อเป็นไฟล์ต้นฉบับ C หรือ C++ ระบบจะคอมไพล์ลงในกฎนี้ หากเป็นไฟล์ไลบรารี ระบบจะลิงก์ไฟล์เหล่านั้นเข้า ไฟล์ `srcs` ประเภทที่อนุญาต: ไฟล์ต้นฉบับ C และ C++: `.c`, `.cc`, `.cpp`, `.cxx`, `.c++`, `.C` ไฟล์ส่วนหัว C และ C++: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` เครื่องมือประกอบที่มีโปรเซสเซอร์ล่วงหน้าแบบ C: `.S` ที่เก็บถาวร: `.a`, `.pic.a` ไลบรารี "ลิงก์เสมอ": `.lo`, `.pic.lo` ไลบรารีที่ใช้ร่วมกัน มีการกำหนดเวอร์ชันหรือไม่ใช่เวอร์ชัน: `.so`, `.so.version` ไฟล์ออบเจ็กต์: `.o`, `.pic.o` ...และกฎที่สร้างไฟล์เหล่านั้น ส่วนขยายที่แตกต่างกันจะแสดงภาษาโปรแกรมที่แตกต่างกันตามแบบแผน gcc
`hdrs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ส่วนหัวที่เผยแพร่โดยไลบรารีนี้ที่จะรวมโดยตรงโดยแหล่งที่มาในกฎที่เกี่ยวข้อง นี่เป็นตำแหน่งที่แนะนำอย่างยิ่งสำหรับการประกาศไฟล์ส่วนหัวที่อธิบายอินเทอร์เฟซสำหรับไลบรารี ส่วนหัวเหล่านี้จะพร้อมสำหรับการรวมโดยแหล่งที่มาในกฎนี้หรือกฎที่เกี่ยวข้อง ส่วนหัวที่ไคลเอ็นต์ของไลบรารีนี้ไม่ได้รวมไว้ควรแสดงอยู่ในแอตทริบิวต์ `srcs` แทน แม้ว่าจะรวมส่วนหัวดังกล่าวโดยส่วนหัวที่เผยแพร่แล้วก็ตาม โปรดดู "การตรวจสอบการรวมส่วนหัว" สำหรับคำอธิบายโดยละเอียด
`additional_compiler_inputs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` ไฟล์เพิ่มเติมที่คุณอาจต้องการส่งไปยังบรรทัดคำสั่งของคอมไพเลอร์ เช่น รายการละเว้นของ Sanitizer เป็นต้น จากนั้นจะใช้ไฟล์ที่ระบุที่นี่ใน Copt ด้วยฟังก์ชัน $(location)
`additional_linker_inputs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` ส่งต่อไฟล์เหล่านี้ไปยังคำสั่ง Linker C++ เช่น ไฟล์ .res ของ Windows ที่คอมไพล์แล้วอาจระบุที่นี่เพื่อฝังในเป้าหมายไบนารี
`alwayslink`	บูลีน ค่าเริ่มต้นคือ `False` หากเป็น 1 ไบนารีใดๆ ที่ขึ้นอยู่กับ (โดยตรงหรือโดยอ้อม) ในไลบรารี C++ นี้จะลิงก์ในไฟล์ออบเจ็กต์ทั้งหมดของไฟล์ที่แสดงอยู่ใน `srcs` แม้ว่าบางไฟล์จะไม่มีสัญลักษณ์ที่ไบนารีอ้างอิงก็ตาม วิธีนี้มีประโยชน์หากโค้ดไม่ได้มีการเรียกอย่างชัดเจนด้วยโค้ดในไบนารี เช่น หากโค้ดของคุณลงทะเบียนเพื่อรับ Callback ที่บริการบางอย่างมีให้ หากเสมอลิงก์ไม่ได้กับ VS 2017 ใน Windows ซึ่งอาจเกิดจากปัญหาที่ทราบ โปรดอัปเกรด VS 2017 เป็นเวอร์ชันล่าสุด
`copts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" และการแปลงข้อมูลเป็นโทเค็น Bourne Shell ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ตามลำดับที่ระบุไปยัง `COPTS` ก่อนคอมไพล์เป้าหมายไบนารี แฟล็กจะมีผลต่อการคอมไพล์เป้าหมายนี้เท่านั้น โดยไม่รวมทรัพยากร Dependency ต่างๆ ดังนั้นโปรดระวังเกี่ยวกับไฟล์ส่วนหัวที่อยู่ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน หากแพ็กเกจประกาศฟีเจอร์ `no_copts_tokenization` การแปลงข้อมูลเป็นโทเค็น Bourne Shell จะใช้กับสตริงที่ประกอบด้วยตัวแปร "Make" เดียวเท่านั้น
`defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็นเชลล์ Bourne รายการเดียว จะมี `-D` นำหน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์ไปยังเป้าหมายนี้ รวมถึงกฎทั้งหมดที่อ้างอิงสตริงนี้ โปรดใช้ความระมัดระวังเป็นอย่างยิ่งเนื่องจากอาจทำให้เกิดผลกระทบอย่างมาก หากไม่แน่ใจ ให้เพิ่มกําหนดค่าให้กับ `local_defines` แทน
`implementation_deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการของไลบรารีอื่นๆ ที่เป้าหมายไลบรารีอิงตาม ส่วนหัวและการรวมเส้นทางของไลบรารีเหล่านี้ (และ Dep ทรานซิชันทั้งหมดของไลบรารี) ต่างจาก `deps` ตรงที่จะมีการใช้สำหรับการคอมไพล์ไลบรารีนี้เท่านั้น ไม่ใช่ไลบรารีที่อาศัยไลบรารีนี้ ไลบรารีที่ระบุด้วย `implementation_deps` ยังคงลิงก์ในเป้าหมายไบนารีที่ขึ้นอยู่กับไลบรารีนี้ ในตอนนี้ระบบจำกัดการใช้งานไว้ที่ cc_libraries และได้รับการป้องกันโดย Flag `--experimental_cc_implementation_deps`
`include_prefix`	สตริง ค่าเริ่มต้นคือ `""` คำนำหน้าที่จะเพิ่มลงในเส้นทางของส่วนหัวของกฎนี้ เมื่อตั้งค่าแล้ว ส่วนหัวในแอตทริบิวต์ `hdrs` ของกฎนี้จะเข้าถึงได้ที่ คือค่าของแอตทริบิวต์นี้ที่เพิ่มไว้ข้างหน้าเส้นทางที่สัมพันธ์กับที่เก็บ ระบบจะนำคำนำหน้าในแอตทริบิวต์ `strip_include_prefix` ออกก่อนที่จะเพิ่มคำนำหน้านี้
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" แต่ละสตริงจะเพิ่ม `-isystem` ไว้ข้างหน้า และเพิ่มลงใน `COPTS` ซึ่งต่างจาก COPTS ตรงที่จะเพิ่มแฟล็กเหล่านี้สำหรับกฎนี้และกฎทั้งหมดที่อ้างอิงกฎดังกล่าว (หมายเหตุ: ไม่ใช่กฎเกณฑ์แต่อย่างใด) โปรดระมัดระวังให้มาก เนื่องจากอาจทำให้เกิดผลกระทบอย่างมาก หากไม่แน่ใจ ให้เพิ่มแฟล็ก "-I" ลงใน COPTS แทน คุณต้องเพิ่มส่วนหัวไปยัง src หรือ hdr ไม่เช่นนั้น ส่วนหัวจะใช้ไม่ได้ในกฎที่อ้างอิงเมื่อการคอมไพล์เป็นแซนด์บ็อกซ์ (ค่าเริ่มต้น)
`linkopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มแฟล็กเหล่านี้ลงในคำสั่ง Linker C++ ขึ้นอยู่กับการแทนที่ "Make" ตัวแปร Bourne Shell Tokenization และ การขยายป้ายกำกับ ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ไปยัง `LINKOPTS` ก่อนลิงก์เป้าหมายไบนารี แต่ละองค์ประกอบในรายการที่ไม่ได้ขึ้นต้นด้วย `$` หรือ `-` จะถือว่าเป็นป้ายกำกับของเป้าหมายใน `deps` รายการไฟล์ที่สร้างโดยเป้าหมายดังกล่าวจะต่อท้ายตัวเลือก Linker ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือไม่มีการประกาศใน `deps`
`linkstamp`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` คอมไพล์และลิงก์ไฟล์ต้นฉบับ C++ ที่ระบุกับไบนารีสุดท้ายพร้อมกัน จำเป็นต้องใช้กลเม็ดนี้ในการนำข้อมูลการประทับเวลามาใช้ในไบนารี หากเราคอมไพล์ไฟล์แหล่งที่มาไปยังไฟล์ออบเจ็กต์ตามวิธีปกติ การประทับเวลาจะไม่ถูกต้อง การคอมไพล์ Linktamp อาจไม่มีชุดแฟล็กคอมไพเลอร์ชุดใดโดยเฉพาะ และไม่ควรขึ้นอยู่กับส่วนหัว ตัวเลือกคอมไพเลอร์ หรือตัวแปรบิลด์อื่นๆ ควรใช้ตัวเลือกนี้ในแพ็กเกจ `base` เท่านั้น
`linkstatic`	บูลีน ค่าเริ่มต้นคือ `False` สำหรับ `cc_binary` และ `cc_test` ให้ลิงก์ไบนารีในโหมดคงที่ สำหรับ `cc_library.linkstatic`: ดูด้านล่าง โดยค่าเริ่มต้น ตัวเลือกนี้จะเปิดอยู่สำหรับ `cc_binary` และปิดอยู่สำหรับส่วนที่เหลือ หากเปิดใช้และนี่เป็นไบนารีหรือการทดสอบ ตัวเลือกนี้จะบอกเครื่องมือสร้างให้ลิงก์ใน `.a` แทน `.so` สำหรับไลบรารีผู้ใช้เมื่อเป็นไปได้ ไลบรารีระบบบางส่วนอาจยังลิงก์แบบไดนามิก เช่นเดียวกับไลบรารีที่ไม่มีไลบรารีแบบคงที่ ดังนั้นไฟล์ปฏิบัติการที่ได้จะยังคงลิงก์แบบไดนามิกอยู่ จึงส่วนใหญ่เป็นแบบคงที่ การลิงก์ไฟล์ปฏิบัติการมี 3 วิธีที่แตกต่างกันดังนี้ สถิติที่มีฟีเจอร์ลิงก์_สถิติแบบเต็ม ซึ่งลิงก์ทุกอย่างในแบบคงที่ เช่น "`gcc -static foo.o libbar.a libbaz.a -lm`" โหมดนี้เปิดใช้งานโดยระบุ `fully_static_link` ในแอตทริบิวต์ `features` สถิติซึ่งไลบรารีผู้ใช้ทั้งหมดลิงก์แบบคงที่ (หากมีเวอร์ชันคงที่) แต่ไลบรารีของระบบ (ยกเว้นไลบรารีรันไทม์ C/C++) มีการลิงก์แบบไดนามิก เช่น "`gcc foo.o libfoo.a libbaz.a -lm`" โหมดนี้เปิดใช้โดยระบุ `linkstatic=True` ไดนามิก (DYNAMIC) ซึ่งมีการลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันไดนามิกให้ใช้งาน) เช่น "`gcc foo.o libfoo.so libbaz.so -lm`" โหมดนี้เปิดใช้ด้วยการระบุ `linkstatic=False` แอตทริบิวต์ `linkstatic` จะมีความหมายต่างออกไปหากใช้ในกฎ `cc_library()` สำหรับไลบรารี C++ `linkstatic=True` จะระบุว่าอนุญาตให้มีการลิงก์แบบคงที่เท่านั้น จึงไม่มีการสร้าง `.so` ขึ้น linkstatic=False ไม่ได้ป้องกันการสร้างไลบรารีแบบคงที่ แอตทริบิวต์นี้มีไว้เพื่อควบคุมการสร้างไลบรารีแบบไดนามิก หากเป็น `linkstatic=False` เครื่องมือสร้างจะสร้างลิงก์สัญลักษณ์ไปยังไลบรารีที่ใช้ร่วมกันซึ่งขึ้นอยู่กับพื้นที่ `*.runfiles`
`local_defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็นเชลล์ Bourne รายการเดียว มีการเพิ่ม `-D` ไว้หน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์สำหรับเป้าหมายนี้ แต่ไม่ใช่ลงในการอ้างอิง
`nocopts`	สตริง ค่าเริ่มต้นคือ `""` นำรูปแบบการทำงานของคีย์เวิร์ดออกจากคำสั่งคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "Make" ระบบจะตีความค่าของแอตทริบิวต์นี้เป็นนิพจน์ทั่วไป ระบบจะนำ `COPTS` ที่มีอยู่ก่อนหน้าซึ่งตรงกับนิพจน์ทั่วไปนี้ (รวมถึงค่าที่ระบุอย่างชัดแจ้งในแอตทริบิวต์ copts ของกฎ) ออกจาก `COPTS` เพื่อวัตถุประสงค์ในการรวบรวมกฎนี้ แอตทริบิวต์นี้ไม่จำเป็นเสมอไป
`strip_include_prefix`	สตริง ค่าเริ่มต้นคือ `""` คำนำหน้าที่จะตัดออกจากเส้นทางของส่วนหัวของกฎนี้ เมื่อตั้งค่าแล้ว ส่วนหัวในแอตทริบิวต์ `hdrs` ของกฎนี้จะเข้าถึงได้ที่เส้นทางโดยตัดคำนำหน้านี้ออก หากเป็นเส้นทางแบบสัมพัทธ์ ระบบจะใช้เส้นทางที่สัมพันธ์กับแพ็กเกจ หากเป็นเส้นทางสัมบูรณ์ จะเข้าใจว่าเป็นเส้นทางที่สัมพัทธ์กับที่เก็บ ระบบจะเพิ่มคำนำหน้าในแอตทริบิวต์ `include_prefix` หลังจากที่นำคำนำหน้านี้ออก
`textual_hdrs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ส่วนหัวที่เผยแพร่โดยไลบรารีนี้ที่จะรวมเป็นข้อความโดยแหล่งที่มาในกฎที่เกี่ยวข้อง นี่เป็นตำแหน่งสำหรับการประกาศไฟล์ส่วนหัวที่ไม่สามารถคอมไพล์ได้ด้วยตัวเอง กล่าวคือ ไฟล์ต้นฉบับอื่นต้องรวมเป็นข้อความเสมอเพื่อสร้างโค้ดที่ถูกต้อง
`win_def_file`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ไฟล์ DEF ของ Windows ที่จะส่งไปยัง Linker แอตทริบิวต์นี้ควรใช้เมื่อ Windows เป็นแพลตฟอร์มเป้าหมายเท่านั้น โดยใช้เพื่อ ส่งออกสัญลักษณ์ระหว่างการลิงก์ไลบรารีที่ใช้ร่วมกันได้

cc_proto_library

ดูแหล่งที่มาของกฎ

cc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

cc_proto_library สร้างโค้ด C++ จาก .proto ไฟล์

deps ต้องชี้ไปที่กฎ proto_library

เช่น

cc_library(
    name = "lib",
    deps = [":foo_cc_proto"],
)

cc_proto_library(
    name = "foo_cc_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
)

อาร์กิวเมนต์

Attributes

name

ชื่อ ต้องระบุ

ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้

deps

รายการป้ายกำกับ ค่าเริ่มต้นคือ []

รายการกฎ proto_library สำหรับสร้างโค้ด C++

cc_shared_library

ดูแหล่งที่มาของกฎ

cc_shared_library(name, deps, additional_linker_inputs, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, win_def_file)

และจะสร้างไลบรารีที่ใช้ร่วมกัน

ตัวอย่าง

cc_shared_library(
    name = "foo_shared",
    deps = [
        ":foo",
    ],
    dynamic_deps = [
        ":bar_shared",
    ],
    additional_linker_inputs = [
        ":foo.lds",
    ],
    user_link_flags = [
        "-Wl,--version-script=$(location :foo.lds)",
    ],
)
cc_library(
    name = "foo",
    srcs = ["foo.cc"],
    hdrs = ["foo.h"],
    deps = [
        ":bar",
        ":baz",
    ],
)
cc_shared_library(
    name = "bar_shared",
    shared_lib_name = "bar.so",
    deps = [":bar"],
)
cc_library(
    name = "bar",
    srcs = ["bar.cc"],
    hdrs = ["bar.h"],
)
cc_library(
    name = "baz",
    srcs = ["baz.cc"],
    hdrs = ["baz.h"],
)

ในตัวอย่าง foo_shared ลิงก์ foo กับ baz แบบคงที่ ซึ่งรายการหลังเป็นทรัพยากร Dependency แบบทรานซิทีฟ ไม่ได้ลิงก์ bar เนื่องจาก dynamic_dep bar_shared สร้างแบบไดนามิกให้อยู่แล้ว

foo_shared ใช้ไฟล์ Linker Script *.lds เพื่อควบคุมว่าควรส่งออกสัญลักษณ์ใด ตรรกะของกฎ cc_shared_library ไม่ได้ควบคุมว่าจะส่งออกสัญลักษณ์ใด แต่จะใช้เฉพาะสิ่งที่คาดว่าจะส่งออกเพื่อให้เกิดข้อผิดพลาดระหว่างช่วงการวิเคราะห์หากไลบรารีที่ใช้ร่วมกัน 2 รายการส่งออกเป้าหมายเดียวกัน

ระบบจะถือว่าการส่งออกทรัพยากร Dependency โดยตรงทั้งหมดของ cc_shared_library ดังนั้น Bazel จะถือว่าในระหว่างการวิเคราะห์ว่า foo กำลังส่งออกโดย foo_shared baz ไม่ถือว่าส่งออกโดย foo_shared ทุกเป้าหมายที่ตรงกับ exports_filter จะถือว่ามีการส่งออกด้วยเช่นกัน

ทุกๆ cc_library ในตัวอย่างควรปรากฏใน cc_shared_library ไม่เกิน 1 รายการ หากต้องการลิงก์ baz กับ bar_shared ด้วย เราจะต้องเพิ่ม tags = ["LINKABLE_MORE_THAN_ONCE"] ไปยัง baz

เนื่องจากแอตทริบิวต์ shared_lib_name ไฟล์ที่ bar_shared สร้างจะมีชื่อ bar.so ซึ่งตรงข้ามกับชื่อ libbar.so ที่เป็นค่าเริ่มต้นใน Linux

ข้อผิดพลาด

`Two shared libraries in dependencies export the same symbols.`

ซึ่งจะเกิดขึ้นเมื่อคุณสร้างเป้าหมายที่มีทรัพยากร Dependency ของ cc_shared_library 2 รายการซึ่งส่งออกเป้าหมายเดียวกัน หากต้องการแก้ไขปัญหานี้ คุณต้องหยุดการส่งออกไลบรารีในทรัพยากร Dependency ของ cc_shared_library

`Two shared libraries in dependencies link the same library statically`

ซึ่งจะเกิดขึ้นเมื่อใดก็ตามที่คุณสร้าง cc_shared_library ใหม่ด้วยทรัพยากร Dependency ของ cc_shared_library ที่แตกต่างกัน 2 รายการซึ่งลิงก์เป้าหมายเดียวกันในแบบคงที่ คล้ายกับข้อผิดพลาดที่เกิดขึ้นกับการส่งออก

วิธีหนึ่งที่จะแก้ปัญหานี้คือการหยุดลิงก์ไลบรารีเข้ากับทรัพยากร Dependency ของ cc_shared_library ในขณะเดียวกัน ลิงก์ที่ยังคงลิงก์อยู่จะต้องส่งออกไลบรารีเพื่อให้ตัวที่ไม่ได้ลิงก์ยังคงมองเห็นสัญลักษณ์ได้ อีกวิธีหนึ่งคือการดึงไลบรารีรายการที่ 3 ที่ส่งออกเป้าหมายนั้น วิธีที่ 3 คือการติดแท็กต้นเหตุของ cc_library ด้วย LINKABLE_MORE_THAN_ONCE แต่การแก้ไขนี้ไม่น่าจะเกิดขึ้นบ่อยนักและคุณควรตรวจสอบให้แน่ใจว่า cc_library จะปลอดภัยมากกว่า 1 ครั้งจริงๆ

'//foo:foo' is already linked statically in '//bar:bar' but not exported`

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

วิธีแก้ไขคือให้ส่งออกข้อมูลจากทรัพยากร Dependency cc_shared_library หรือดึง cc_shared_library ที่ 3 ที่ส่งออกออกไป

`Do not place libraries which only contain a precompiled dynamic library in deps.`

หากคุณมีไลบรารีแบบไดนามิกที่คอมไพล์ไว้ล่วงหน้าแล้ว ก็ไม่จำเป็นที่จะต้องลิงก์ในเชิงสถิติกับเป้าหมาย cc_shared_library ปัจจุบันที่คุณกำลังสร้างอยู่ ดังนั้นจึงไม่ได้อยู่ใน deps ของ cc_shared_library หากไลบรารีแบบไดนามิกที่คอมไพล์ไว้ล่วงหน้านี้เป็นทรัพยากร Dependency ของ cc_libraries ของคุณ cc_library จะต้องพึ่งพาไลบรารีดังกล่าวโดยตรง

`Trying to export a library already exported by a different shared library`

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

หากต้องการแก้ไขปัญหานี้ ให้นำเป้าหมายออกจาก deps แล้วอิงตามการขึ้นต่อกันแบบไดนามิกหรือตรวจสอบว่า exports_filter ตรวจไม่พบเป้าหมายนี้

อาร์กิวเมนต์

Attributes
`name`	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` ไลบรารีระดับบนสุดที่จะลิงก์แบบคงที่กับไลบรารีที่ใช้ร่วมกันอย่างไม่มีเงื่อนไขหลังจากเก็บถาวรทั้งหมด ทรัพยากร Dependency ของไลบรารีแบบทรานซิทีฟของ Dep โดยตรงเหล่านี้จะลิงก์เข้ากับไลบรารีที่แชร์นี้ ตราบใดที่คุณยังไม่ได้ลิงก์โดย `cc_shared_library` ใน `dynamic_deps` ในระหว่างการวิเคราะห์ การใช้งานกฎจะถือว่าเป้าหมายที่ระบุใน `deps` ได้รับการส่งออกโดยไลบรารีที่ใช้ร่วมกัน เพื่อแสดงข้อผิดพลาดเมื่อ `cc_shared_libraries` หลายรายการส่งออกเป้าหมายเดียวกัน การใช้กฎไม่ได้มีหน้าที่แจ้ง Linker ว่าออบเจ็กต์ที่แชร์ควรส่งออกสัญลักษณ์ใด ผู้ใช้ควรแก้ไขปัญหานี้ผ่านสคริปต์ Linker หรือการประกาศระดับการเข้าถึงในซอร์สโค้ด การติดตั้งใช้งานยังจะทริกเกอร์ข้อผิดพลาดเมื่อใดก็ตามที่ลิงก์ไลบรารีเดียวกันใน `cc_shared_library` มากกว่า 1 รายการแบบคงที่ด้วย คุณหลีกเลี่ยงปัญหานี้ได้โดยการเพิ่ม `"LINKABLE_MORE_THAN_ONCE"` ใน `cc_library.tags` หรือแสดงรายการ "cc_library" เป็นการส่งออกไลบรารีที่ใช้ร่วมกันรายการใดรายการหนึ่ง เพื่อให้สามารถสร้าง `dynamic_dep` ในคลังอื่นได้
`additional_linker_inputs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` ไฟล์อื่นๆ ที่คุณอาจต้องการส่งต่อไปยัง Linker เช่น สคริปต์ Linker คุณต้องส่ง Flag ของ Linker ที่ Linker ต้องใช้แยกกันเพื่อให้ทราบไฟล์นี้ โดยใช้แอตทริบิวต์ `user_link_flags`
`dynamic_deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` นี่เป็นทรัพยากร Dependency อื่นๆ ของ `cc_shared_library` ที่เป้าหมายปัจจุบันใช้งานอยู่ การติดตั้งใช้งาน `cc_shared_library` จะใช้รายการ `dynamic_deps` (หรือที่เรียกว่า `dynamic_deps` ของ `dynamic_deps` ของเป้าหมายปัจจุบัน) เพื่อตัดสินใจว่าไม่ควรลิงก์ `cc_libraries` ใดใน `deps` ทางอ้อม เนื่องจากมี `cc_shared_library` อื่นระบุไว้อยู่แล้ว
`exports_filter`	รายการสตริง ค่าเริ่มต้นคือ `[]` แอตทริบิวต์นี้มีรายการเป้าหมายที่อ้างว่าส่งออกโดยไลบรารีที่ใช้ร่วมกันปัจจุบัน ระบบเข้าใจว่า `deps` เป้าหมายใดๆ จะส่งออกโดยไลบรารีที่ใช้ร่วมกันอยู่แล้ว แอตทริบิวต์นี้ควรใช้เพื่อแสดงรายการเป้าหมายที่ส่งออกโดยไลบรารีที่ใช้ร่วมกัน แต่เป็นทรัพยากร Dependency แบบทรานซิทีฟของ `deps` โปรดทราบว่าจริงๆ แล้วแอตทริบิวต์นี้ไม่ได้เพิ่ม Edge ทรัพยากร Dependency ไปยังเป้าหมายเหล่านั้น คุณควรสร้าง Dependency ผ่าน `deps` แทน รายการในแอตทริบิวต์นี้เป็นเพียงสตริง โปรดทราบว่าเมื่อวางเป้าหมายในแอตทริบิวต์นี้ จะถือว่าเป็นการกล่าวอ้างว่าไลบรารีที่ใช้ร่วมกันจะส่งออกสัญลักษณ์จากเป้าหมายนั้น ตรรกะ `cc_shared_library` ไม่ได้มีหน้าที่บอก Linker ว่าควรส่งออกสัญลักษณ์ใด ระบบอนุญาตให้ใช้ไวยากรณ์ต่อไปนี้ `//foo:__package__` เพื่อรวมเป้าหมายใน foo/BUILD `//foo:__subpackages__` เพื่อรวมเป้าหมายใน foo/BUILD หรือแพ็กเกจอื่นๆ ที่มี foo/ เช่น foo/bar/BUILD
`shared_lib_name`	สตริง ค่าเริ่มต้นคือ `""` โดยค่าเริ่มต้น cc_shared_library จะใช้ชื่อสำหรับไฟล์เอาต์พุตของไลบรารีที่ใช้ร่วมกันโดยอิงจากชื่อเป้าหมายและแพลตฟอร์ม ซึ่งรวมถึงส่วนขยายและบางครั้งเป็นคำนำหน้า บางครั้งคุณอาจไม่ต้องการชื่อเริ่มต้น เช่น เมื่อโหลดไลบรารีที่ใช้ร่วมกันของ C++ สำหรับ Python มักไม่ใช่คำที่ต้องการสำหรับคำนำหน้า lib* เริ่มต้น ซึ่งในกรณีนี้คุณอาจใช้แอตทริบิวต์นี้เพื่อเลือกชื่อที่กำหนดเองได้
`user_link_flags`	รายการสตริง ค่าเริ่มต้นคือ `[]` แฟล็กเพิ่มเติมที่คุณอาจต้องการส่งไปยัง Linker เช่น หากต้องการทำให้ Linker ทราบว่าสคริปต์ Linker ที่ส่งผ่านadditional_linker_inputs ได้ คุณจะใช้รายการต่อไปนี้ได้ cc_shared_library( name = "foo_shared", additional_linker_inputs = select({ "//src/conditions:linux": [ ":foo.lds", ":additional_script.txt", ], "//conditions:default": []}), user_link_flags = select({ "//src/conditions:linux": [ "-Wl,-rpath,kittens", "-Wl,--version-script=$(location :foo.lds)", "-Wl,--script=$(location :additional_script.txt)", ], "//conditions:default": []}), ... )
`win_def_file`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ไฟล์ DEF ของ Windows ที่จะส่งไปยัง Linker แอตทริบิวต์นี้ควรใช้เมื่อ Windows เป็นแพลตฟอร์มเป้าหมายเท่านั้น โดยใช้เพื่อ ส่งออกสัญลักษณ์ระหว่างการลิงก์ไลบรารีที่ใช้ร่วมกันได้

fdo_prefetch_hints

ดูแหล่งที่มาของกฎ

fdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

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

fdo_prefetch_hints(
    name = "hints",
    profile = "//path/to/hints:profile.afdo",
)

fdo_profile(
  name = "hints_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

อาร์กิวเมนต์

Attributes

name

ชื่อ ต้องระบุ

ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้

profile

ป้ายกำกับ ค่าเริ่มต้นคือ None

ป้ายกำกับของโปรไฟล์คำแนะนำ ไฟล์คำแนะนำมีนามสกุล .afdo และป้ายกำกับอาจนำไปยังกฎ fdo_absolute_path_profile ด้วย

fdo_profile

ดูแหล่งที่มาของกฎ

fdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)

แสดงโปรไฟล์ FDO ที่อยู่ในพื้นที่ทำงานหรือในเส้นทางสัมบูรณ์ที่ระบุ ตัวอย่าง

fdo_profile(
    name = "fdo",
    profile = "//path/to/fdo:profile.zip",
)

fdo_profile(
  name = "fdo_abs",
  absolute_path_profile = "/absolute/path/profile.zip",
)

อาร์กิวเมนต์

Attributes
`name`	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`absolute_path_profile`	สตริง ค่าเริ่มต้นคือ `""` เส้นทางสัมบูรณ์ไปยังโปรไฟล์ FDO ไฟล์ FDO อาจมีส่วนขยายอย่างใดอย่างหนึ่งต่อไปนี้ .profraw สำหรับโปรไฟล์ LLVM ที่ไม่ได้จัดทำดัชนี, .profdata สำหรับโปรไฟล์ LLVM ที่จัดทำดัชนี, .zip ที่มีโปรไฟล์ Profraw LLVM หรือ .afdo สำหรับโปรไฟล์ AutoFDO
`profile`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ป้ายกำกับของโปรไฟล์ FDO หรือกฎที่สร้างโปรไฟล์ดังกล่าว ไฟล์ FDO อาจมีนามสกุลใดไฟล์หนึ่งต่อไปนี้ .profraw สำหรับโปรไฟล์ LLVM ที่ไม่ได้จัดทำดัชนี, .profdata สำหรับโปรไฟล์ LLVM ที่จัดทำดัชนี, .zip ที่มีโปรไฟล์ Profraw LLVM, .afdo สำหรับโปรไฟล์ AutoFDO, .xfdo สำหรับโปรไฟล์ XBinary ป้ายกำกับยังสามารถชี้ไปยังกฎ fdo_absolute_path_profile ได้ด้วย
`proto_profile`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ป้ายกำกับของโปรไฟล์ Protocolbuf

memprof_profile

ดูแหล่งที่มาของกฎ

memprof_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

แสดงโปรไฟล์ MEMPROF ที่อยู่ในพื้นที่ทำงานหรือในเส้นทางสัมบูรณ์ที่ระบุ ตัวอย่าง

memprof_profile(
    name = "memprof",
    profile = "//path/to/memprof:profile.afdo",
)

memprof_profile(
  name = "memprof_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

อาร์กิวเมนต์

Attributes

name

ชื่อ ต้องระบุ

ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้

absolute_path_profile

สตริง ค่าเริ่มต้นคือ ""

เส้นทางสัมบูรณ์ไปยังโปรไฟล์ MEMPROF ไฟล์จะมีนามสกุล .profdata หรือ .zip เท่านั้น (โดยที่ไฟล์ ZIP ต้องมีไฟล์ memprof.profdata)

profile

ป้ายกำกับ ค่าเริ่มต้นคือ None

ป้ายกำกับของโปรไฟล์ MEMPROF โปรไฟล์ควรมีนามสกุล .profdata (สำหรับโปรไฟล์ Memprof ที่มีการจัดทำดัชนี/เป็นสัญลักษณ์) หรือส่วนขยาย .zip สำหรับไฟล์ ZIP ที่มีไฟล์ memprof.profdata ป้ายกำกับยังสามารถชี้ไปยังกฎ fdo_absolute_path_profile ได้ด้วย

propeller_optimize

ดูแหล่งที่มาของกฎ

propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

แสดงโปรไฟล์การเพิ่มประสิทธิภาพ Propeller ในพื้นที่ทำงาน เช่น

propeller_optimize(
    name = "layout",
    cc_profile = "//path:cc_profile.txt",
    ld_profile = "//path:ld_profile.txt"
)

propeller_optimize(
    name = "layout_absolute",
    absolute_cc_profile = "/absolute/cc_profile.txt",
    absolute_ld_profile = "/absolute/ld_profile.txt"
)

อาร์กิวเมนต์

Attributes

name

ชื่อ ต้องระบุ

ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้

ld_profile

ป้ายกำกับ ค่าเริ่มต้นคือ None

ป้ายกำกับของโปรไฟล์ที่ส่งไปยังการทำงานของลิงก์ ไฟล์นี้มีนามสกุล .txt

cc_test

ดูแหล่งที่มาของกฎ

cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, includes, licenses, link_extra_lib, linkopts, linkstatic, local, local_defines, malloc, nocopts, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

อาร์กิวเมนต์

Attributes
`name`	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไลบรารีอื่นๆ ที่จะลิงก์กับเป้าหมายไบนารี ซึ่งอาจเป็น `cc_library` หรือ `objc_library` เป้าหมาย
`srcs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ C และ C++ ที่ประมวลผลเพื่อสร้างเป้าหมาย ไฟล์เหล่านี้เป็นไฟล์ส่วนหัวและแหล่งที่มาของ C/C++ อาจเป็นไฟล์ที่ไม่ได้สร้าง (ซอร์สโค้ดปกติ) หรือสร้างขึ้น ระบบจะคอมไพล์ไฟล์ทั้งหมด `.cc`, `.c` และ `.cpp` ซึ่งอาจเป็นไฟล์ที่สร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน `outs` ของกฎอื่น กฎนี้จะขึ้นอยู่กับกฎนั้นโดยอัตโนมัติ ระบบจะไม่คอมไพล์ไฟล์ `.h` แต่แหล่งที่มาในกฎนี้จะรวมไฟล์ได้ ทั้งไฟล์ `.cc` และ `.h` จะมีส่วนหัวที่ระบุไว้ใน `srcs` เหล่านี้หรือใน `hdrs` ของกฎที่ระบุไว้ในอาร์กิวเมนต์ `deps` ได้โดยตรง คุณต้องพูดถึงไฟล์ `#include`d ทั้งหมดในแอตทริบิวต์ `srcs` ของกฎนี้ หรือในแอตทริบิวต์ `hdrs` ของ `cc_library()` ที่อ้างอิง รูปแบบที่แนะนำมีไว้สำหรับส่วนหัวที่เชื่อมโยงกับไลบรารีที่จะปรากฏในแอตทริบิวต์ `hdrs` ของไลบรารีดังกล่าว และแสดงส่วนหัวที่เหลืออยู่ซึ่งเชื่อมโยงกับแหล่งที่มาของกฎนี้ใน `srcs` โปรดดูรายละเอียดเพิ่มเติมใน "การตรวจสอบการรวมส่วนหัว" หากชื่อของกฎอยู่ในภาษา `srcs` กฎนี้จะขึ้นอยู่กับชื่อนั้นโดยอัตโนมัติ หาก `outs` ของกฎที่ตั้งชื่อเป็นไฟล์ต้นฉบับ C หรือ C++ ระบบจะคอมไพล์ลงในกฎนี้ หากเป็นไฟล์ไลบรารี ระบบจะลิงก์ไฟล์เหล่านั้นเข้า ไฟล์ `srcs` ประเภทที่อนุญาต: ไฟล์ต้นฉบับ C และ C++: `.c`, `.cc`, `.cpp`, `.cxx`, `.c++`, `.C` ไฟล์ส่วนหัว C และ C++: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` เครื่องมือประกอบที่มีโปรเซสเซอร์ล่วงหน้าแบบ C: `.S` ที่เก็บถาวร: `.a`, `.pic.a` ไลบรารี "ลิงก์เสมอ": `.lo`, `.pic.lo` ไลบรารีที่ใช้ร่วมกัน มีการกำหนดเวอร์ชันหรือไม่ใช่เวอร์ชัน: `.so`, `.so.version` ไฟล์ออบเจ็กต์: `.o`, `.pic.o` ...และกฎที่สร้างไฟล์เหล่านั้น ส่วนขยายที่แตกต่างกันจะแสดงภาษาโปรแกรมที่แตกต่างกันตามแบบแผน gcc
`additional_linker_inputs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` ส่งต่อไฟล์เหล่านี้ไปยังคำสั่ง Linker C++ เช่น ไฟล์ .res ของ Windows ที่คอมไพล์แล้วอาจระบุที่นี่เพื่อฝังในเป้าหมายไบนารี
`copts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" และการแปลงข้อมูลเป็นโทเค็น Bourne Shell ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ตามลำดับที่ระบุไปยัง `COPTS` ก่อนคอมไพล์เป้าหมายไบนารี แฟล็กจะมีผลต่อการคอมไพล์เป้าหมายนี้เท่านั้น โดยไม่รวมทรัพยากร Dependency ต่างๆ ดังนั้นโปรดระวังเกี่ยวกับไฟล์ส่วนหัวที่อยู่ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน หากแพ็กเกจประกาศฟีเจอร์ `no_copts_tokenization` การแปลงข้อมูลเป็นโทเค็น Bourne Shell จะใช้กับสตริงที่ประกอบด้วยตัวแปร "Make" เดียวเท่านั้น
`defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็นเชลล์ Bourne รายการเดียว จะมี `-D` นำหน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์ไปยังเป้าหมายนี้ รวมถึงกฎทั้งหมดที่อ้างอิงสตริงนี้ โปรดใช้ความระมัดระวังเป็นอย่างยิ่งเนื่องจากอาจทำให้เกิดผลกระทบอย่างมาก หากไม่แน่ใจ ให้เพิ่มกําหนดค่าให้กับ `local_defines` แทน
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" แต่ละสตริงจะเพิ่ม `-isystem` ไว้ข้างหน้า และเพิ่มลงใน `COPTS` ซึ่งต่างจาก COPTS ตรงที่จะเพิ่มแฟล็กเหล่านี้สำหรับกฎนี้และกฎทั้งหมดที่อ้างอิงกฎดังกล่าว (หมายเหตุ: ไม่ใช่กฎเกณฑ์แต่อย่างใด) โปรดระมัดระวังให้มาก เนื่องจากอาจทำให้เกิดผลกระทบอย่างมาก หากไม่แน่ใจ ให้เพิ่มแฟล็ก "-I" ลงใน COPTS แทน คุณต้องเพิ่มส่วนหัวไปยัง src หรือ hdr ไม่เช่นนั้น ส่วนหัวจะใช้ไม่ได้ในกฎที่อ้างอิงเมื่อการคอมไพล์เป็นแซนด์บ็อกซ์ (ค่าเริ่มต้น)
`link_extra_lib`	ป้ายกำกับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:link_extra_lib"` ควบคุมการลิงก์ไลบรารีเพิ่มเติม โดยค่าเริ่มต้น ไบนารีของ C++ จะลิงก์กับ `//tools/cpp:link_extra_lib` ซึ่งโดยค่าเริ่มต้นจะขึ้นอยู่กับแฟล็กป้ายกำกับ `//tools/cpp:link_extra_libs` หากไม่ได้ตั้งค่าสถานะ ไลบรารีนี้จะว่างเปล่าโดยค่าเริ่มต้น การตั้งค่าแฟล็กป้ายกำกับช่วยให้ลิงก์ทรัพยากร Dependency ที่ไม่บังคับได้ เช่น การลบล้างสัญลักษณ์ที่ไม่รัดกุม, ตัวดักจับสัญญาณสำหรับฟังก์ชันไลบรารีที่ใช้ร่วมกัน หรือไลบรารีรันไทม์พิเศษ (สำหรับการแทนที่ Malloc ให้ใช้ `malloc` หรือ `--custom_malloc`) การตั้งค่าแอตทริบิวต์นี้เป็น `None` จะปิดใช้ลักษณะการทำงานนี้
`linkopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มแฟล็กเหล่านี้ลงในคำสั่ง Linker C++ ขึ้นอยู่กับการแทนที่ "Make" ตัวแปร Bourne Shell Tokenization และ การขยายป้ายกำกับ ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ไปยัง `LINKOPTS` ก่อนลิงก์เป้าหมายไบนารี แต่ละองค์ประกอบในรายการที่ไม่ได้ขึ้นต้นด้วย `$` หรือ `-` จะถือว่าเป็นป้ายกำกับของเป้าหมายใน `deps` รายการไฟล์ที่สร้างโดยเป้าหมายดังกล่าวจะต่อท้ายตัวเลือก Linker ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือไม่มีการประกาศใน `deps`
`linkstatic`	บูลีน ค่าเริ่มต้นคือ `False` สำหรับ `cc_binary` และ `cc_test` ให้ลิงก์ไบนารีในโหมดคงที่ สำหรับ `cc_library.linkstatic`: ดูด้านล่าง โดยค่าเริ่มต้น ตัวเลือกนี้จะเปิดอยู่สำหรับ `cc_binary` และปิดอยู่สำหรับส่วนที่เหลือ หากเปิดใช้และนี่เป็นไบนารีหรือการทดสอบ ตัวเลือกนี้จะบอกเครื่องมือสร้างให้ลิงก์ใน `.a` แทน `.so` สำหรับไลบรารีผู้ใช้เมื่อเป็นไปได้ ไลบรารีระบบบางส่วนอาจยังลิงก์แบบไดนามิก เช่นเดียวกับไลบรารีที่ไม่มีไลบรารีแบบคงที่ ดังนั้นไฟล์ปฏิบัติการที่ได้จะยังคงลิงก์แบบไดนามิกอยู่ จึงส่วนใหญ่เป็นแบบคงที่ การลิงก์ไฟล์ปฏิบัติการมี 3 วิธีที่แตกต่างกันดังนี้ สถิติที่มีฟีเจอร์ลิงก์_สถิติแบบเต็ม ซึ่งลิงก์ทุกอย่างในแบบคงที่ เช่น "`gcc -static foo.o libbar.a libbaz.a -lm`" โหมดนี้เปิดใช้งานโดยระบุ `fully_static_link` ในแอตทริบิวต์ `features` สถิติซึ่งไลบรารีผู้ใช้ทั้งหมดลิงก์แบบคงที่ (หากมีเวอร์ชันคงที่) แต่ไลบรารีของระบบ (ยกเว้นไลบรารีรันไทม์ C/C++) มีการลิงก์แบบไดนามิก เช่น "`gcc foo.o libfoo.a libbaz.a -lm`" โหมดนี้เปิดใช้โดยระบุ `linkstatic=True` ไดนามิก (DYNAMIC) ซึ่งมีการลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันไดนามิกให้ใช้งาน) เช่น "`gcc foo.o libfoo.so libbaz.so -lm`" โหมดนี้เปิดใช้ด้วยการระบุ `linkstatic=False` แอตทริบิวต์ `linkstatic` จะมีความหมายต่างออกไปหากใช้ในกฎ `cc_library()` สำหรับไลบรารี C++ `linkstatic=True` จะระบุว่าอนุญาตให้มีการลิงก์แบบคงที่เท่านั้น จึงไม่มีการสร้าง `.so` ขึ้น linkstatic=False ไม่ได้ป้องกันการสร้างไลบรารีแบบคงที่ แอตทริบิวต์นี้มีไว้เพื่อควบคุมการสร้างไลบรารีแบบไดนามิก หากเป็น `linkstatic=False` เครื่องมือสร้างจะสร้างลิงก์สัญลักษณ์ไปยังไลบรารีที่ใช้ร่วมกันซึ่งขึ้นอยู่กับพื้นที่ `*.runfiles`
`local_defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็นเชลล์ Bourne รายการเดียว มีการเพิ่ม `-D` ไว้หน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์สำหรับเป้าหมายนี้ แต่ไม่ใช่ลงในการอ้างอิง
`malloc`	ป้ายกำกับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:malloc"` ลบล้างทรัพยากร Dependency เริ่มต้นใน Malloc โดยค่าเริ่มต้น ไบนารีของ C++ จะลิงก์กับ `//tools/cpp:malloc` ซึ่งเป็นไลบรารีที่ว่างเปล่า ดังนั้นไบนารีนั้นจะใช้ libc Malloc ป้ายกำกับนี้ต้องอ้างอิงถึง `cc_library` หากการคอมไพล์เป็นกฎที่ไม่ใช่ C++ ตัวเลือกนี้จะไม่มีผล ระบบจะละเว้นค่าของแอตทริบิวต์นี้หากระบุ `linkshared=True`
`nocopts`	สตริง ค่าเริ่มต้นคือ `""` นำรูปแบบการทำงานของคีย์เวิร์ดออกจากคำสั่งคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "Make" ระบบจะตีความค่าของแอตทริบิวต์นี้เป็นนิพจน์ทั่วไป ระบบจะนำ `COPTS` ที่มีอยู่ก่อนหน้าซึ่งตรงกับนิพจน์ทั่วไปนี้ (รวมถึงค่าที่ระบุอย่างชัดแจ้งในแอตทริบิวต์ copts ของกฎ) ออกจาก `COPTS` เพื่อวัตถุประสงค์ในการรวบรวมกฎนี้ แอตทริบิวต์นี้ไม่จำเป็นเสมอไป
`stamp`	จำนวนเต็ม ค่าเริ่มต้นคือ `0` ระบุว่าจะเข้ารหัสข้อมูลบิลด์ลงในไบนารีหรือไม่ ค่าที่เป็นไปได้มีดังนี้ `stamp = 1`: ประทับตราข้อมูลบิลด์ลงในไบนารีเสมอ แม้ในบิลด์ `--nostamp` ก็ตาม ควรหลีกเลี่ยงการตั้งค่านี้ เนื่องจากอาจทำให้การแคชระยะไกลสำหรับไบนารีและการดำเนินการดาวน์สตรีมจะขึ้นอยู่กับการแคชจากระยะไกล `stamp = 0`: แทนที่ข้อมูลบิลด์ด้วยค่าคงที่เสมอ วิธีนี้จะทำให้มีการแคชผลลัพธ์ของบิลด์ที่ดี `stamp = -1`: การฝังข้อมูลบิลด์จะควบคุมโดยแฟล็ก `--[no]stamp` ระบบจะไม่สร้างไบนารีที่ประทับตราอีกครั้ง เว้นแต่ทรัพยากร Dependency จะมีการเปลี่ยนแปลง
`win_def_file`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ไฟล์ DEF ของ Windows ที่จะส่งไปยัง Linker แอตทริบิวต์นี้ควรใช้เมื่อ Windows เป็นแพลตฟอร์มเป้าหมายเท่านั้น โดยใช้เพื่อ ส่งออกสัญลักษณ์ระหว่างการลิงก์ไลบรารีที่ใช้ร่วมกันได้

cc_toolchain

ดูแหล่งที่มาของกฎ

cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, visibility)

แสดงเครื่องมือเชน C++

กฎนี้มีหน้าที่รับผิดชอบในเรื่องต่อไปนี้

กำลังรวบรวมอาร์ติแฟกต์ทั้งหมดที่จำเป็นสำหรับการเรียกใช้การดำเนินการ C++ ซึ่งทำโดยแอตทริบิวต์ เช่น all_files, compiler_files, linker_files หรือแอตทริบิวต์อื่นๆ ที่ลงท้ายด้วย _files) กลุ่มไฟล์ต่อไปนี้มักมีชื่อไฟล์ที่จำเป็นทั้งหมด
กำลังสร้างบรรทัดคำสั่งที่ถูกต้องสำหรับการดำเนินการ C++ ซึ่งทำโดยใช้ผู้ให้บริการ CcToolchainConfigInfo (ตามรายละเอียดด้านล่าง)

ใช้แอตทริบิวต์ toolchain_config เพื่อกำหนดค่าเครื่องมือเชน C++ และโปรดดู หน้า นี้เพื่อดูการกำหนดค่า Toolchain ของ C++ อย่างละเอียดและเอกสารการเลือก Toolchain

ใช้ tags = ["manual"] เพื่อป้องกันไม่ให้มีการสร้างและกำหนดค่า Toolchain โดยไม่จำเป็นเมื่อเรียกใช้ bazel build //...

อาร์กิวเมนต์

Attributes
`name`	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`all_files`	ป้ายกำกับ ต้องระบุ คอลเล็กชันของอาร์ติแฟกต์ cc_toolchain ทั้งหมด ระบบจะเพิ่มอาร์ติแฟกต์เหล่านี้เป็นอินพุตของการดำเนินการที่เกี่ยวข้องกับ rules_cc ทั้งหมด (ยกเว้นการดำเนินการที่ใช้ชุดอาร์ติแฟกต์จากแอตทริบิวต์ด้านล่างที่แม่นยำยิ่งขึ้น) Bazel สมมติว่า `all_files` เป็นชุดพิเศษของแอตทริบิวต์ที่มีอาร์ติแฟกต์อื่นๆ ทั้งหมด (เช่น การคอมไพล์ Linktamp ต้องใช้ทั้งไฟล์คอมไพล์และลิงก์ ดังนั้นจึงต้องใช้ `all_files`) นี่คือสิ่งที่ `cc_toolchain.files` มี และจะใช้โดยกฎ Starlark ทั้งหมดที่ใช้เครื่องมือเชน C++
`ar_files`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` คอลเล็กชันของอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการเก็บถาวร
`as_files`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการประกอบ
`compiler_files`	ป้ายกำกับ ต้องระบุ คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการคอมไพล์
`compiler_files_without_includes`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` คอลเล็กชันของอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการคอมไพล์ในกรณีที่มีการรองรับการค้นพบอินพุต (ปัจจุบันใช้ได้กับ Google เท่านั้น)
`coverage_files`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการเกี่ยวกับความครอบคลุม หากไม่ได้ระบุไว้ ระบบจะใช้ all_files
`dwp_files`	ป้ายกำกับ ต้องระบุ คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการ dwp
`dynamic_runtime_lib`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` อาร์ติแฟกต์ไลบรารีแบบไดนามิกสำหรับไลบรารีรันไทม์ C++ (เช่น libstdc++.so) ระบบจะใช้ข้อมูลนี้เมื่อเปิดใช้ฟีเจอร์ "static_link_cpp_runtimes" และเรากำลังลิงก์ทรัพยากร Dependency แบบไดนามิก
`exec_transition_for_inputs`	บูลีน ค่าเริ่มต้นคือ `True` ตั้งค่าเป็น "จริง" เพื่อสร้างอินพุตไฟล์ทั้งหมดไปยัง cc_toolchain สำหรับแพลตฟอร์มผู้บริหาร แทนที่จะไม่ต้องเปลี่ยน (เช่น แพลตฟอร์มเป้าหมายโดยค่าเริ่มต้น)
`libc_top`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` คอลเล็กชันอาร์ติแฟกต์สำหรับ libc ที่ส่งผ่านเป็นอินพุตสำหรับการดำเนินการคอมไพล์/ลิงก์
`linker_files`	ป้ายกำกับ ต้องระบุ คอลเล็กชันของอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการลิงก์
`module_map`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` อาร์ติแฟกต์แมปโมดูลที่จะใช้สําหรับบิลด์แบบแยกส่วน
`objcopy_files`	ป้ายกำกับ ต้องระบุ คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการ objcopy
`static_runtime_lib`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` อาร์ติแฟกต์ไลบรารีแบบคงที่สำหรับไลบรารีรันไทม์ C++ (เช่น libstdc++.a) ระบบจะใช้ข้อมูลนี้เมื่อเปิดใช้ฟีเจอร์ "static_link_cpp_runtimes" และเรากำลังลิงก์ทรัพยากร Dependency แบบคงที่
`strip_files`	ป้ายกำกับ ต้องระบุ คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการนำออก
`supports_header_parsing`	บูลีน ค่าเริ่มต้นคือ `False` ตั้งค่าเป็น "จริง" เมื่อ cc_toolchain รองรับการดำเนินการแยกวิเคราะห์ส่วนหัว
`supports_param_files`	บูลีน ค่าเริ่มต้นคือ `True` ตั้งค่าเป็น "จริง" เมื่อ cc_toolchain รองรับการใช้ไฟล์พารามิเตอร์สำหรับการลิงก์การดำเนินการ
`toolchain_config`	ป้ายกำกับ ต้องระบุ ป้ายกำกับของกฎที่ระบุ `cc_toolchain_config_info`
`toolchain_identifier`	สตริง nonconfigurable ค่าเริ่มต้นคือ `""` ตัวระบุที่ใช้จับคู่ cc_toolchain นี้กับ Crosstool_config.toolchain ที่เกี่ยวข้อง นี่เป็นวิธีที่แนะนำในการเชื่อมโยง `cc_toolchain` กับ `CROSSTOOL.toolchain` จนกว่าปัญหา #5380 จะได้รับการแก้ไข ซึ่งจะแทนที่ด้วยแอตทริบิวต์ `toolchain_config` (#5380)

cc_toolchain_suite

ดูแหล่งที่มาของกฎ

cc_toolchain_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

แสดงคอลเล็กชันของ Toolchain ของ C++

กฎนี้มีหน้าที่รับผิดชอบในเรื่องต่อไปนี้

การรวบรวมเครื่องมือ C++ ที่เกี่ยวข้องทั้งหมด
เลือกเครื่องมือเชน 1 รายการโดยขึ้นอยู่กับ --cpu และ --compiler ตัวเลือกที่ส่งไปยัง Bazel

และโปรดดู หน้า นี้เพื่อดูการกำหนดค่า Toolchain ของ C++ อย่างละเอียดและเอกสารการเลือก Toolchain

อาร์กิวเมนต์

Attributes

name

ชื่อ ต้องระบุ

ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้

toolchains

สตริงการจับคู่พจนานุกรมกับป้ายกำกับ nonconfigurable จำเป็น

แผนที่จากสตริง "<cpu>" หรือ "<cpu>|<compiler>" ไปยังป้ายกำกับ cc_toolchain ระบบจะใช้ "<cpu>" เมื่อมีการส่ง --cpu ไปยัง Bazel เท่านั้น และใช้ "<cpu>|<compiler>" เมื่อมีการส่งทั้ง --cpu และ --compiler ไปยัง Bazel เช่น

          cc_toolchain_suite(
            name = "toolchain",
            toolchains = {
              "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",
              "piii": ":my_cc_toolchain_for_piii_using_default_compiler",
            },
          )