เปิดให้ลงทะเบียนและส่งเนื้อหาสำหรับ CFP ของ BazelCon 2025 แล้ว

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

กฎ C / C++

รายงานปัญหา ดูแหล่งที่มา Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

กฎ

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

cc_binary

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

ซึ่งสร้างไบนารีที่เรียกใช้งานได้

name ของเป้าหมายควรเหมือนกับชื่อของ ไฟล์ต้นฉบับซึ่งเป็นจุดแรกเข้าหลักของแอปพลิเคชัน (ไม่รวมนามสกุล) เช่น หากจุดแรกเข้าอยู่ใน main.cc ชื่อของคุณควรเป็น main

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

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

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

Attributes
`name`	ชื่อ (ต้องระบุ) ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไลบรารีอื่นๆ ที่จะลิงก์ไปยังเป้าหมายไบนารี ซึ่งอาจเป็นเป้าหมาย `cc_library` หรือ `objc_library` ก็ได้ นอกจากนี้ คุณยังใส่สคริปต์ Linker (.lds) ลงใน deps และอ้างอิงสคริปต์เหล่านั้นใน `linkopts` ได้ด้วย แต่โปรดพิจารณา `additional_linker_inputs` สำหรับกรณีการใช้งานดังกล่าว
`srcs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ C และ C++ ที่ประมวลผลเพื่อสร้างเป้าหมายไลบรารี ซึ่งเป็นไฟล์ต้นฉบับและไฟล์ส่วนหัวของ C/C++ ไม่ว่าจะไม่ได้สร้าง (ซอร์สโค้ดปกติ) หรือสร้างขึ้น ระบบจะรวบรวมไฟล์ `.cc`, `.c` และ `.cpp` ทั้งหมด ไฟล์เหล่านี้อาจเป็นไฟล์ที่สร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน `outs` ของกฎอื่น `cc_library` นี้จะขึ้นอยู่กับกฎอื่นนั้นโดยอัตโนมัติ ไฟล์แอสเซมบลีแบบเพียว (.s, .asm) จะไม่ได้รับการประมวลผลล่วงหน้า และโดยปกติจะสร้างขึ้นโดยใช้แอสเซมเบลอร์ ไฟล์แอสเซมบลีที่ประมวลผลล่วงหน้า (.S) จะได้รับการประมวลผลล่วงหน้าและโดยทั่วไปจะสร้างขึ้น โดยใช้คอมไพเลอร์ C/C++ ระบบจะไม่คอมไพล์ไฟล์ `.h` แต่จะพร้อมให้แหล่งข้อมูลในกฎนี้รวมไว้ ทั้งไฟล์ `.cc` และ `.h` สามารถรวมส่วนหัวที่ระบุไว้ใน`srcs` เหล่านี้หรือใน`hdrs` ของกฎนี้ หรือกฎใดก็ตามที่ระบุไว้ในอาร์กิวเมนต์ `deps` ได้โดยตรง ต้องระบุไฟล์ `#include` ทั้งหมดในแอตทริบิวต์ `hdrs` ของกฎนี้หรือกฎที่อ้างอิง `cc_library` หรือควรแสดงรายการใน `srcs` หากเป็นไฟล์ส่วนตัว ของไลบรารีนี้ ดูคำอธิบายเพิ่มเติมได้ที่ "การตรวจสอบการรวมส่วนหัว" ไฟล์ `.so`, `.lo` และ `.a` คือ ไฟล์ที่คอมไพล์ล่วงหน้า ไลบรารีของคุณอาจมีรายการเหล่านี้เป็น `srcs` หากใช้โค้ดของบุคคลที่สามซึ่งเราไม่มี ซอร์สโค้ด หากแอตทริบิวต์ `srcs` มีป้ายกำกับของกฎอื่น `cc_library` จะใช้ไฟล์เอาต์พุตของกฎนั้นเป็นไฟล์ต้นฉบับเพื่อ คอมไพล์ ซึ่งมีประโยชน์สำหรับการสร้างซอร์สโค้ดแบบครั้งเดียว (หากต้องการใช้มากกว่าเป็นครั้งคราว ควรใช้คลาสกฎ Starlark และใช้ `cc_common` API) `srcs` ประเภทไฟล์ที่อนุญาตมีดังนี้ ไฟล์ต้นฉบับ C และ C++: `.c`, `.cc`, `.cpp`, `.cxx`, `.c++`, `.C` ไฟล์ส่วนหัว C และ C++: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` Assembler ที่มีตัวประมวลผล C ล่วงหน้า: `.S` เก็บ: `.a`, `.pic.a` เชื่อมต่อไลบรารี "เสมอ": `.lo`, `.pic.lo` ไลบรารีที่ใช้ร่วมกันแบบมีเวอร์ชันหรือไม่มีเวอร์ชัน: `.so`, `.so.version` ไฟล์ออบเจ็กต์: `.o`, `.pic.o` ... และกฎใดๆ ที่สร้างไฟล์เหล่านั้น (เช่น `cc_embed_data`) นามสกุลที่แตกต่างกันจะแสดงถึงภาษาโปรแกรมที่แตกต่างกันใน ตามธรรมเนียมของ gcc
`data`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ที่ไลบรารีนี้ต้องการในรันไทม์ ดูความคิดเห็นทั่วไปเกี่ยวกับ `data` ที่แอตทริบิวต์ทั่วไปที่กำหนดโดย กฎการสร้างส่วนใหญ่ หาก `data` เป็นชื่อของไฟล์ที่สร้างขึ้น กฎนี้ `cc_library` จะขึ้นอยู่กับกฎการสร้าง โดยอัตโนมัติ หาก `data` เป็นชื่อกฎ กฎ `cc_library` นี้จะขึ้นอยู่กับกฎดังกล่าวโดยอัตโนมัติ และระบบจะเพิ่ม `outs` ของกฎนั้นลงใน ไฟล์ข้อมูลของ `cc_library` นี้โดยอัตโนมัติ โค้ด C++ สามารถเข้าถึงไฟล์ข้อมูลเหล่านี้ได้ดังนี้ `const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");`
`additional_linker_inputs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` Dependency ที่มีให้เฉพาะคำสั่ง Linker ของ C++ `deps` ซึ่งสร้างขึ้นเพื่อการคอมไพล์และการลิงก์ทรัพยากร Dependency ทั้ง 2 อย่างนั้นแตกต่างจาก `additional_linker_inputs` ซึ่งสร้างขึ้นเพื่อการลิงก์เท่านั้น และส่งสัญญาณถึงทรัพยากร Dependency ที่จำเป็นสำหรับการลิงก์เท่านั้น (เช่น ไฟล์ที่อ้างอิงใน `linkopts`) เช่น คุณระบุไฟล์ .res ของ Windows ที่คอมไพล์แล้วได้ที่นี่เพื่อฝังใน เป้าหมายไบนารี
`conlyopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งการคอมไพล์ C ขึ้นอยู่กับการแทนที่ "Make variable" และ การแยกโทเค็น Bourne Shell
`copts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งการคอมไพล์ C/C++ ขึ้นอยู่กับการแทนที่ "Make variable" และ การแยกโทเค็น Bourne Shell ระบบจะเพิ่มสตริงแต่ละรายการในแอตทริบิวต์นี้ตามลำดับที่ระบุไปยัง `COPTS` ก่อน คอมไพล์เป้าหมายไบนารี โดยแฟล็กจะมีผลเฉพาะกับการคอมไพล์เป้าหมายนี้เท่านั้น ไม่รวมถึง การขึ้นต่อกัน ดังนั้นโปรดระมัดระวังเกี่ยวกับไฟล์ส่วนหัวที่รวมไว้ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้ภายนอก `third_party` หากแพ็กเกจประกาศฟีเจอร์ `no_copts_tokenization` การแยกโทเค็นของ Bourne Shell จะใช้กับสตริง ที่มีตัวแปร "Make" เพียงตัวเดียวเท่านั้น
`cxxopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งการคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "Make variable" และ การแยกโทเค็น Bourne Shell
`defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการคำจำกัดความที่จะเพิ่มลงในบรรทัดการคอมไพล์ของเป้าหมายนี้และเป้าหมายที่ขึ้นต่อกันทั้งหมด ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และ การแยกโทเค็น Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็น Bourne Shell เดียว จะนำหน้าด้วย `-D` และเพิ่มลงในบรรทัดคำสั่งคอมไพล์ไปยังเป้าหมายนี้ รวมถึงทุกกฎที่ขึ้นอยู่กับเป้าหมายนี้ โปรดระมัดระวังอย่างยิ่ง เนื่องจากอาจส่งผลกระทบในวงกว้าง โดยระบบจะเพิ่มคำจำกัดความลงในทุกเป้าหมายที่ขึ้นอยู่กับเป้าหมายนี้ หากไม่แน่ใจ ให้เพิ่มค่าที่กำหนดไว้ใน `local_defines` แทน
`dynamic_deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` การอ้างอิงเหล่านี้คือ`cc_shared_library`อื่นๆ ที่เป้าหมายปัจจุบันขึ้นอยู่กับ การติดตั้งใช้งาน `cc_shared_library` จะใช้รายการ `dynamic_deps` (แบบทรานซิทีฟ กล่าวคือ `dynamic_deps` ของ `dynamic_deps` ของเป้าหมายปัจจุบันด้วย) เพื่อตัดสินใจว่าไม่ควรลิงก์ `cc_libraries` ใดใน `deps` แบบทรานซิทีฟ เนื่องจาก `cc_shared_library` อื่นได้ระบุไว้แล้ว
`hdrs_check`	สตริง ค่าเริ่มต้นคือ `""` เลิกใช้งานแล้ว ไม่มีการดำเนินการ
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีที่รวมไว้ที่จะเพิ่มลงในบรรทัดการคอมไพล์ ขึ้นอยู่กับการแทนที่ "สร้างตัวแปร" แต่ละสตริงจะนำหน้าด้วยเส้นทางแพ็กเกจและส่งไปยังเครื่องมือ C++ สำหรับ การขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" Toolchain ที่ทำงานในระบบ POSIX พร้อมคำจำกัดความฟีเจอร์ทั่วไปจะสร้าง `-isystem path_to_package/include_entry` ควรใช้เฉพาะกับไลบรารีของบุคคลที่สามที่ ไม่ได้เป็นไปตามรูปแบบการเขียนคำสั่ง #include ของ Google ซึ่งต่างจาก COPTS โดยระบบจะเพิ่มแฟล็กเหล่านี้สำหรับกฎนี้ และทุกกฎที่ขึ้นอยู่กับกฎนี้ (หมายเหตุ: ไม่ใช่กฎที่ขึ้นอยู่กับกฎนี้) โปรด ระมัดระวังเป็นอย่างยิ่ง เนื่องจากอาจส่งผลกระทบในวงกว้าง หากไม่แน่ใจ ให้เพิ่ม Flag "-I" ไปยัง COPTS แทน เส้นทาง `include` ที่เพิ่มจะรวมไฟล์ที่สร้างขึ้นและไฟล์ในแผนผังแหล่งที่มา
`link_extra_lib`	ป้ายกำกับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:link_extra_lib"` ควบคุมการลิงก์ไลบรารีเพิ่มเติม โดยค่าเริ่มต้น ไบนารี C++ จะลิงก์กับ `//tools/cpp:link_extra_lib`, ซึ่งโดยค่าเริ่มต้นจะขึ้นอยู่กับแฟล็กป้ายกำกับ `//tools/cpp:link_extra_libs` หากไม่ได้ตั้งค่าสถานะ ไลบรารีนี้จะว่างเปล่าโดยค่าเริ่มต้น การตั้งค่าแฟล็กป้ายกำกับ จะอนุญาตให้ลิงก์การขึ้นต่อกันที่ไม่บังคับ เช่น การลบล้างสำหรับสัญลักษณ์ที่อ่อนแอ ตัวสกัดกั้น สำหรับฟังก์ชันไลบรารีที่ใช้ร่วมกัน หรือไลบรารีรันไทม์พิเศษ (สำหรับการแทนที่ malloc ให้ใช้ `malloc` หรือ `--custom_malloc`) การตั้งค่าแอตทริบิวต์นี้เป็น `None` จะปิดใช้ลักษณะการทำงานนี้
`linkopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มแฟล็กเหล่านี้ลงในคำสั่ง Linker ของ C++ ขึ้นอยู่กับการแทนที่ตัวแปร "Make" การแยกโทเค็นของ Bourne Shell และ การขยายป้ายกำกับ ระบบจะเพิ่มสตริงแต่ละรายการในแอตทริบิวต์นี้ไปยัง `LINKOPTS` ก่อน ลิงก์เป้าหมายไบนารี องค์ประกอบแต่ละรายการในรายการนี้ที่ไม่ได้ขึ้นต้นด้วย `$` หรือ `-` จะถือว่าเป็นป้ายกำกับของเป้าหมายใน `deps` ระบบจะผนวกรายการไฟล์ที่สร้างโดยเป้าหมายนั้นเข้ากับตัวเลือกของ Linker ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือไม่ได้ประกาศใน `deps`
`linkshared`	บูลีน ค่าเริ่มต้นคือ `False` สร้างไลบรารีที่ใช้ร่วมกัน หากต้องการเปิดใช้แอตทริบิวต์นี้ ให้ใส่ `linkshared=True` ในกฎ โดยค่าเริ่มต้น ตัวเลือกนี้จะปิดอยู่ การมีแฟล็กนี้หมายความว่าการลิงก์เกิดขึ้นพร้อมกับแฟล็ก `-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.link_static` โปรดดูด้านล่าง โดยค่าเริ่มต้น ตัวเลือกนี้จะเปิดอยู่สำหรับ `cc_binary` และปิดอยู่สำหรับส่วนที่เหลือ หากเปิดใช้และเป็นไบนารีหรือการทดสอบ ตัวเลือกนี้จะบอกเครื่องมือบิลด์ให้ลิงก์ใน `.a` แทน `.so` สำหรับไลบรารีของผู้ใช้ทุกครั้งที่เป็นไปได้ ไลบรารีของระบบ เช่น libc (แต่ไม่ใช่ไลบรารีรันไทม์ C/C++ ดูด้านล่าง) ยังคงลิงก์แบบไดนามิก เช่นเดียวกับไลบรารีที่ไม่มี ไลบรารีแบบคงที่ ดังนั้นไฟล์ที่เรียกใช้งานได้ที่ได้จึงยังคงลิงก์แบบไดนามิก จึงเป็นแบบคงที่ส่วนใหญ่เท่านั้น การลิงก์ไฟล์ที่เรียกใช้งานได้มี 3 วิธี ดังนี้ STATIC ที่มีฟีเจอร์ fully_static_link ซึ่งทุกอย่างจะลิงก์แบบคงที่ เช่น "`gcc -static foo.o libbar.a libbaz.a -lm`" โหมดนี้จะเปิดใช้โดยการระบุ `fully_static_link` ในแอตทริบิวต์ `features` STATIC ซึ่งจะลิงก์ไลบรารีของผู้ใช้ทั้งหมดแบบคงที่ (หากมีเวอร์ชันแบบคงที่) แต่จะลิงก์ไลบรารีของระบบ (ยกเว้นไลบรารีรันไทม์ C/C++) แบบไดนามิก เช่น "`gcc foo.o libfoo.a libbaz.a -lm`" โหมดนี้จะเปิดใช้โดยการระบุ `linkstatic=True` DYNAMIC ซึ่งจะลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันไดนามิก) เช่น "`gcc foo.o libfoo.so libbaz.so -lm`" โหมดนี้จะเปิดใช้โดยการระบุ `linkstatic=False` หากใช้แอตทริบิวต์ `linkstatic` หรือ `fully_static_link` ใน `features` นอก `//third_party` โปรดใส่ความคิดเห็นไว้ใกล้กับกฎเพื่ออธิบายเหตุผล แอตทริบิวต์ `linkstatic` จะมีความหมายต่างออกไปหากใช้ในกฎ `cc_library()` สำหรับไลบรารี C++ `linkstatic=True` จะระบุว่าอนุญาตเฉพาะ การลิงก์แบบคงที่เท่านั้น จึงจะไม่มีการสร้าง `.so` linkstatic=False ไม่ได้ ป้องกันไม่ให้สร้างไลบรารีแบบคงที่ แอตทริบิวต์นี้มีไว้เพื่อควบคุม การสร้างไลบรารีแบบไดนามิก ไม่ควรมีโค้ดที่สร้างด้วย `linkstatic=False` ในเวอร์ชันที่ใช้งานจริง หาก `linkstatic=False` เครื่องมือบิลด์จะสร้างลิงก์สัญลักษณ์ไปยัง ไลบรารีที่ใช้ร่วมกันที่ขึ้นอยู่กับในพื้นที่ `*.runfiles`
`local_defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการคำจำกัดความที่จะเพิ่มลงในบรรทัดการคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และ การแยกโทเค็น Bourne Shell สตริงแต่ละรายการซึ่งต้องประกอบด้วยโทเค็น Bourne Shell รายการเดียว จะนำหน้าด้วย `-D` และเพิ่มลงในบรรทัดคำสั่งคอมไพล์สำหรับเป้าหมายนี้ แต่จะไม่เพิ่มลงในเป้าหมายที่ขึ้นอยู่กับเป้าหมายนี้ ซึ่งแตกต่างจาก `defines` ตรงที่ระบบจะเพิ่มคำจำกัดความลงใน บรรทัดคำสั่งคอมไพล์สำหรับเป้าหมายนี้เท่านั้น
`malloc`	ป้ายกำกับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:malloc"` ลบล้างการขึ้นอยู่กับ malloc เริ่มต้น โดยค่าเริ่มต้น ไบนารี C++ จะลิงก์กับ `//tools/cpp:malloc` ซึ่งเป็นไลบรารีที่ว่างเปล่า ดังนั้นไบนารีจึงใช้ malloc ของ libc ป้ายกำกับนี้ต้องอ้างอิงถึง `cc_library` หากการคอมไพล์เป็นกฎที่ไม่ใช่ C++ ตัวเลือกนี้จะไม่มีผล ระบบจะไม่สนใจค่าของแอตทริบิวต์นี้หากระบุ `linkshared=True`
`module_interfaces`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ถือเป็นอินเทอร์เฟซโมดูล C++20 มาตรฐาน C++ ไม่ได้จำกัดนามสกุลไฟล์อินเทอร์เฟซของโมดูล Clang ใช้ cppm GCC สามารถใช้นามสกุลไฟล์ต้นฉบับใดก็ได้ MSVC use ixx การใช้งานได้รับการป้องกันโดยแฟล็ก `--experimental_cpp_modules`
`nocopts`	สตริง ค่าเริ่มต้นคือ `""` นำตัวเลือกที่ตรงกันออกจากคำสั่งการคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ตัวแปร "Make" ระบบจะตีความค่าของแอตทริบิวต์นี้เป็นนิพจน์ทั่วไป `COPTS`ที่มีอยู่ก่อนแล้วซึ่งตรงกับนิพจน์ทั่วไปนี้ (รวมถึงค่าที่ระบุอย่างชัดเจนในแอตทริบิวต์ copts ของกฎ) จะถูกนำออกจาก `COPTS` เพื่อวัตถุประสงค์ในการรวบรวมกฎนี้ ไม่ควรต้องใช้แอตทริบิวต์นี้ภายนอก `third_party` ระบบจะไม่ประมวลผลค่าล่วงหน้า ในลักษณะใดๆ นอกเหนือจากการแทนที่ตัวแปร "Make"
`reexport_deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]`
`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, exec_compatible_with, exec_group_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, package_metadata, pic_objects, pic_static_library, restricted_to, shared_library, static_library, strip_include_prefix, system_provided, tags, target_compatible_with, testonly, toolchains, 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 = True,
)

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


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

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

ใน Unix ให้ทำดังนี้


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

บน 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

ใน Unix ให้ทำดังนี้


cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  interface_library = "libmylib.ifso", # Or we can also use libmylib.so as its own interface library
  # libmylib.so is provided by system environment, for example it can be found in LD_LIBRARY_PATH.
  # This indicates that Bazel is not responsible for making libmylib.so available.
  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 = True,
)

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

ใน Unix ให้ทำดังนี้


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

บน 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",
)

ส่วนที่เหลือจะเหมือนกันใน Unix และ Windows ดังนี้


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

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

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` หากมีไบนารีที่ขึ้นอยู่กับไลบรารี C++ ที่คอมไพล์ล่วงหน้านี้ (โดยตรงหรือโดยอ้อม) ไบนารีนั้นจะลิงก์ในไฟล์ออบเจ็กต์ทั้งหมดที่เก็บไว้ในไลบรารีแบบคงที่ แม้ว่าบางไฟล์จะไม่มีสัญลักษณ์ที่ไบนารีอ้างอิงก็ตาม ซึ่งจะมีประโยชน์ในกรณีที่โค้ดไม่ได้เรียกอย่างชัดเจนโดยโค้ดใน ไบนารี เช่น หากโค้ดลงทะเบียนเพื่อรับการเรียกกลับบางอย่าง ที่ได้รับจากบริการบางอย่าง หาก alwayslink ใช้กับ VS 2017 ใน Windows ไม่ได้ นั่นเป็นเพราะปัญหาที่ทราบ โปรดอัปเกรด VS 2017 เป็นเวอร์ชันล่าสุด
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีที่รวมไว้ที่จะเพิ่มลงในบรรทัดการคอมไพล์ ขึ้นอยู่กับการแทนที่ "สร้างตัวแปร" แต่ละสตริงจะนำหน้าด้วยเส้นทางแพ็กเกจและส่งไปยังเครื่องมือ C++ สำหรับ การขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" Toolchain ที่ทำงานในระบบ POSIX พร้อมคำจำกัดความฟีเจอร์ทั่วไปจะสร้าง `-isystem path_to_package/include_entry` ควรใช้เฉพาะกับไลบรารีของบุคคลที่สามที่ ไม่ได้เป็นไปตามรูปแบบการเขียนคำสั่ง #include ของ Google ซึ่งต่างจาก COPTS โดยระบบจะเพิ่มแฟล็กเหล่านี้สำหรับกฎนี้ และทุกกฎที่ขึ้นอยู่กับกฎนี้ (หมายเหตุ: ไม่ใช่กฎที่ขึ้นอยู่กับกฎนี้) โปรด ระมัดระวังเป็นอย่างยิ่ง เนื่องจากอาจส่งผลกระทบในวงกว้าง หากไม่แน่ใจ ให้เพิ่ม Flag "-I" ไปยัง COPTS แทน เส้นทาง `include` เริ่มต้นไม่รวมไฟล์ที่สร้างขึ้น หากต้องการ `#include` ไฟล์ส่วนหัวที่สร้างขึ้น ให้แสดงไฟล์ดังกล่าวใน `srcs`
`interface_library`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ไลบรารีอินเทอร์เฟซเดียวสำหรับการลิงก์ไลบรารีที่ใช้ร่วมกัน ประเภทไฟล์ที่อนุญาต `.ifso` `.tbd` `.lib` `.so` หรือ `.dylib`
`linkopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มแฟล็กเหล่านี้ลงในคำสั่ง Linker ของ C++ ขึ้นอยู่กับการแทนที่ตัวแปร "Make" การแยกโทเค็นของ Bourne Shell และ การขยายป้ายกำกับ ระบบจะเพิ่มสตริงแต่ละรายการในแอตทริบิวต์นี้ไปยัง `LINKOPTS` ก่อน ลิงก์เป้าหมายไบนารี องค์ประกอบแต่ละรายการในรายการนี้ที่ไม่ได้ขึ้นต้นด้วย `$` หรือ `-` จะถือว่าเป็นป้ายกำกับของเป้าหมายใน `deps` ระบบจะผนวกรายการไฟล์ที่สร้างโดยเป้าหมายนั้นเข้ากับตัวเลือกของ Linker ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือไม่ได้ประกาศใน `deps`
`objects`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]`
`pic_objects`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]`
`pic_static_library`	ป้ายกำกับ ค่าเริ่มต้นคือ `None`
`shared_library`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ไลบรารีที่ใช้ร่วมกันที่คอมไพล์ล่วงหน้าเพียงรายการเดียว Bazel จะตรวจสอบว่าไบนารีที่ขึ้นอยู่กับไลบรารีนั้นพร้อมใช้งานในระหว่างรันไทม์ ประเภทไฟล์ที่อนุญาต `.so` `.dll` หรือ `.dylib`
`static_library`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ไลบรารีแบบคงที่ที่คอมไพล์ล่วงหน้าเพียงรายการเดียว ประเภทไฟล์ที่อนุญาต `.a` `.pic.a` หรือ `.lib`
`strip_include_prefix`	สตริง ค่าเริ่มต้นคือ `""` คำนำหน้าที่จะนำออกจากเส้นทางของส่วนหัวของกฎนี้ เมื่อตั้งค่าแล้ว ระบบจะเข้าถึงส่วนหัวในแอตทริบิวต์ `hdrs` ของกฎนี้ได้ ที่เส้นทางของส่วนหัวโดยตัดคำนำหน้านี้ออก หากเป็นเส้นทางแบบสัมพัทธ์ ระบบจะถือว่าเป็นเส้นทางแบบสัมพัทธ์ของแพ็กเกจ หากเป็นเส้นทางสัมบูรณ์ ระบบจะถือว่าเป็นเส้นทางสัมพัทธ์ของที่เก็บ ระบบจะเพิ่มคำนำหน้าในแอตทริบิวต์ `include_prefix` หลังจากที่นำคำนำหน้านี้ออกแล้ว แอตทริบิวต์นี้ถูกต้องตามกฎหมายภายใต้ `third_party` เท่านั้น
`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, conlyopts, copts, cxxopts, defines, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hdrs_check, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, module_interfaces, package_metadata, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

ใช้ cc_library() สำหรับไลบรารีที่คอมไพล์ด้วย C++ ผลลัพธ์จะเป็น .so, .lo หรือ .a ขึ้นอยู่กับสิ่งที่ต้องการ

หากคุณสร้างสิ่งใดก็ตามด้วยการลิงก์แบบคงที่ซึ่งขึ้นอยู่กับ cc_library เอาต์พุตของกฎไลบรารีที่ขึ้นต่อกัน คือไฟล์ .a หากคุณระบุ alwayslink=True คุณจะได้รับไฟล์ .lo

ชื่อไฟล์เอาต์พุตจริงคือ libfoo.so สำหรับ คลังที่ใช้ร่วมกัน โดย foo คือชื่อของกฎ ส่วนไลบรารีประเภทอื่นๆ จะลงท้ายด้วย .lo และ .a ตามลำดับ หากต้องการชื่อไลบรารีที่ใช้ร่วมกันที่เฉพาะเจาะจง เช่น เพื่อกำหนดโมดูล Python ให้ใช้ genrule เพื่อคัดลอกไลบรารีไปยังชื่อที่ต้องการ

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

ต้องประกาศไฟล์ส่วนหัวทั้งหมดที่ใช้ในการสร้างใน 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.h baz.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 เพื่อบังคับใช้กฎการตรวจสอบการรวม เครื่องมือต้องรองรับlayering_checkและต้องมีการขออย่างชัดเจน เช่น ผ่าน --features=layering_check แฟล็กบรรทัดคำสั่งหรือพารามิเตอร์ features ของฟังก์ชัน package Toolchain ที่ Bazel จัดเตรียมให้รองรับฟีเจอร์นี้กับ Clang ใน Unix และ macOS เท่านั้น

ตัวอย่าง

เราใช้แฟล็ก alwayslink เพื่อบังคับให้ Linker ลิงก์ใน โค้ดนี้แม้ว่าโค้ดไบนารีหลักจะไม่ได้อ้างอิงก็ตาม


cc_library(
    name = "ast_inspector_lib",
    srcs = ["ast_inspector_lib.cc"],
    hdrs = ["ast_inspector_lib.h"],
    visibility = ["//visibility:public"],
    deps = ["//third_party/llvm/llvm/tools/clang:frontend"],
    # alwayslink as we want to be able to call things in this library at
    # debug time, even if they aren't used anywhere in the code.
    alwayslink = True,
)

ตัวอย่างต่อไปนี้มาจาก third_party/python2_4_3/BUILD โค้ดบางส่วนใช้ไลบรารี dl (เพื่อโหลดไลบรารีแบบไดนามิกอื่น) ดังนั้นกฎนี้จึงระบุตัวเลือกการลิงก์ -ldl เพื่อลิงก์ไลบรารี dl


cc_library(
    name = "python2_4_3",
    linkopts = [
        "-ldl",
        "-lutil",
    ],
    deps = ["//third_party/expat"],
)

ตัวอย่างต่อไปนี้มาจาก third_party/kde/BUILD เราเก็บไฟล์ .so ที่สร้างไว้ล่วงหน้าไว้ในที่เก็บ ไฟล์ส่วนหัวจะอยู่ในไดเรกทอรีย่อยชื่อ include


cc_library(
    name = "kde",
    srcs = [
        "lib/libDCOP.so",
        "lib/libkdesu.so",
        "lib/libkhtml.so",
        "lib/libkparts.so",
        ...more .so files...,
    ],
    includes = ["include"],
    deps = ["//third_party/X11"],
)

ตัวอย่างต่อไปนี้มาจาก third_party/gles/BUILD โค้ดของบุคคลที่สามมักต้องมี defines และ linkopts


cc_library(
    name = "gles",
    srcs = [
        "GLES/egl.h",
        "GLES/gl.h",
        "ddx.c",
        "egl.c",
    ],
    defines = [
        "USE_FLOAT",
        "__GL_FLOAT",
        "__GL_COMMON",
    ],
    linkopts = ["-ldl"],  # uses dlopen(), dl library
    deps = [
        "es",
        "//third_party/X11",
    ],
)

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

Attributes
`name`	ชื่อ (ต้องระบุ) ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไลบรารีอื่นๆ ที่เป้าหมายไลบรารีขึ้นอยู่กับ ซึ่งอาจเป็นเป้าหมาย `cc_library` หรือ `objc_library` ก็ได้ ดูความคิดเห็นทั่วไปเกี่ยวกับ `deps` ที่แอตทริบิวต์ทั่วไปที่กำหนดโดย กฎการสร้างส่วนใหญ่ ซึ่งควรเป็นชื่อของกฎไลบรารี C++ เมื่อสร้างไบนารีที่ลิงก์ไลบรารีของกฎนี้ คุณจะลิงก์ไลบรารีใน `deps` ด้วย แม้จะมีชื่อว่า "deps" แต่ไคลเอ็นต์ของไลบรารีนี้บางส่วน ไม่ได้อยู่ในที่นี้ การขึ้นต่อกันของข้อมูลรันไทม์จะอยู่ใน `data` ไฟล์ต้นฉบับที่สร้างโดยกฎอื่นๆ จะอยู่ใน `srcs` หากต้องการลิงก์ในไลบรารีของบุคคลที่สามที่คอมไพล์ไว้ล่วงหน้า ให้เพิ่มชื่อไลบรารีลงใน `srcs` แทน หากต้องการใช้สิ่งใดโดยไม่ต้องลิงก์กับไลบรารีนี้ ให้เพิ่มชื่อของสิ่งนั้นลงใน `data` แทน
`srcs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ C และ C++ ที่ประมวลผลเพื่อสร้างเป้าหมายไลบรารี ซึ่งเป็นไฟล์ต้นฉบับและไฟล์ส่วนหัวของ C/C++ ไม่ว่าจะไม่ได้สร้าง (ซอร์สโค้ดปกติ) หรือสร้างขึ้น ระบบจะรวบรวมไฟล์ `.cc`, `.c` และ `.cpp` ทั้งหมด ไฟล์เหล่านี้อาจเป็นไฟล์ที่สร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน `outs` ของกฎอื่น `cc_library` นี้จะขึ้นอยู่กับกฎอื่นนั้นโดยอัตโนมัติ ไฟล์แอสเซมบลีแบบเพียว (.s, .asm) จะไม่ได้รับการประมวลผลล่วงหน้า และโดยปกติจะสร้างขึ้นโดยใช้แอสเซมเบลอร์ ไฟล์แอสเซมบลีที่ประมวลผลล่วงหน้า (.S) จะได้รับการประมวลผลล่วงหน้าและโดยทั่วไปจะสร้างขึ้น โดยใช้คอมไพเลอร์ C/C++ ระบบจะไม่คอมไพล์ไฟล์ `.h` แต่จะพร้อมให้แหล่งข้อมูลในกฎนี้รวมไว้ ทั้งไฟล์ `.cc` และ `.h` สามารถรวมส่วนหัวที่ระบุไว้ใน`srcs` เหล่านี้หรือใน`hdrs` ของกฎนี้ หรือกฎใดก็ตามที่ระบุไว้ในอาร์กิวเมนต์ `deps` ได้โดยตรง ต้องระบุไฟล์ `#include` ทั้งหมดในแอตทริบิวต์ `hdrs` ของกฎนี้หรือกฎที่อ้างอิง `cc_library` หรือควรแสดงรายการใน `srcs` หากเป็นไฟล์ส่วนตัว ของไลบรารีนี้ ดูคำอธิบายเพิ่มเติมได้ที่ "การตรวจสอบการรวมส่วนหัว" ไฟล์ `.so`, `.lo` และ `.a` คือ ไฟล์ที่คอมไพล์ล่วงหน้า ไลบรารีของคุณอาจมีรายการเหล่านี้เป็น `srcs` หากใช้โค้ดของบุคคลที่สามซึ่งเราไม่มี ซอร์สโค้ด หากแอตทริบิวต์ `srcs` มีป้ายกำกับของกฎอื่น `cc_library` จะใช้ไฟล์เอาต์พุตของกฎนั้นเป็นไฟล์ต้นฉบับเพื่อ คอมไพล์ ซึ่งมีประโยชน์สำหรับการสร้างซอร์สโค้ดแบบครั้งเดียว (หากต้องการใช้มากกว่าเป็นครั้งคราว ควรใช้คลาสกฎ Starlark และใช้ `cc_common` API) `srcs` ประเภทไฟล์ที่อนุญาตมีดังนี้ ไฟล์ต้นฉบับ C และ C++: `.c`, `.cc`, `.cpp`, `.cxx`, `.c++`, `.C` ไฟล์ส่วนหัว C และ C++: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` Assembler ที่มีตัวประมวลผล C ล่วงหน้า: `.S` เก็บ: `.a`, `.pic.a` เชื่อมต่อไลบรารี "เสมอ": `.lo`, `.pic.lo` ไลบรารีที่ใช้ร่วมกันแบบมีเวอร์ชันหรือไม่มีเวอร์ชัน: `.so`, `.so.version` ไฟล์ออบเจ็กต์: `.o`, `.pic.o` ... และกฎใดๆ ที่สร้างไฟล์เหล่านั้น (เช่น `cc_embed_data`) นามสกุลที่แตกต่างกันจะแสดงถึงภาษาโปรแกรมที่แตกต่างกันใน ตามธรรมเนียมของ gcc
`data`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ที่ไลบรารีนี้ต้องการในรันไทม์ ดูความคิดเห็นทั่วไปเกี่ยวกับ `data` ที่แอตทริบิวต์ทั่วไปที่กำหนดโดย กฎการสร้างส่วนใหญ่ หาก `data` เป็นชื่อของไฟล์ที่สร้างขึ้น กฎนี้ `cc_library` จะขึ้นอยู่กับกฎการสร้าง โดยอัตโนมัติ หาก `data` เป็นชื่อกฎ กฎ `cc_library` นี้จะขึ้นอยู่กับกฎดังกล่าวโดยอัตโนมัติ และระบบจะเพิ่ม `outs` ของกฎนั้นลงใน ไฟล์ข้อมูลของ `cc_library` นี้โดยอัตโนมัติ โค้ด C++ สามารถเข้าถึงไฟล์ข้อมูลเหล่านี้ได้ดังนี้ `const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");`
`hdrs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ส่วนหัวที่เผยแพร่โดย ไลบรารีนี้เพื่อให้แหล่งที่มาในกฎที่ขึ้นต่อกันรวมไว้โดยตรง นี่คือตำแหน่งที่แนะนำอย่างยิ่งสำหรับการประกาศไฟล์ส่วนหัวที่ อธิบายอินเทอร์เฟซของไลบรารี ระบบจะทำให้ส่วนหัวเหล่านี้ พร้อมใช้งานเพื่อให้แหล่งที่มาในกฎนี้หรือในกฎที่ขึ้นอยู่กับกฎนี้รวมไว้ ส่วนหัวที่ไม่ได้มีไว้ให้ไคลเอ็นต์ของไลบรารีนี้รวมไว้ควรแสดงอยู่ในแอตทริบิวต์ `srcs` แทน แม้ว่าส่วนหัวที่เผยแพร่จะรวมไว้ก็ตาม ดูคำอธิบายแบบละเอียดเพิ่มเติมได้ที่ "การตรวจสอบการรวมส่วนหัว" ประเภทไฟล์ `headers` ที่อนุญาต `.h` `.hh` `.hpp` `.hxx`
`additional_compiler_inputs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` ไฟล์เพิ่มเติมที่คุณอาจต้องการส่งไปยังบรรทัดคำสั่งของคอมไพเลอร์ เช่น รายการที่ละเว้นของ Sanitizer จากนั้นจะใช้ไฟล์ที่ระบุไว้ที่นี่ใน copts กับฟังก์ชัน $(location) ได้
`additional_linker_inputs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` Dependency ที่มีให้เฉพาะคำสั่ง Linker ของ C++ `deps` ซึ่งสร้างขึ้นเพื่อการคอมไพล์และการลิงก์ทรัพยากร Dependency ทั้ง 2 อย่างนั้นแตกต่างจาก `additional_linker_inputs` ซึ่งสร้างขึ้นเพื่อการลิงก์เท่านั้น และส่งสัญญาณถึงทรัพยากร Dependency ที่จำเป็นสำหรับการลิงก์เท่านั้น (เช่น ไฟล์ที่อ้างอิงใน `linkopts`) เช่น คุณระบุไฟล์ .res ของ Windows ที่คอมไพล์แล้วได้ที่นี่เพื่อฝังใน เป้าหมายไบนารี
`alwayslink`	บูลีน ค่าเริ่มต้นคือ `False` หากเป็น 1 ไบนารีใดๆ ที่ขึ้นอยู่กับไลบรารี C++ นี้ (โดยตรงหรือโดยอ้อม) จะลิงก์ในไฟล์ออบเจ็กต์ทั้งหมดสำหรับไฟล์ที่ระบุไว้ใน `srcs` แม้ว่าบางไฟล์จะไม่มีสัญลักษณ์ที่ไบนารีอ้างอิงก็ตาม ซึ่งจะมีประโยชน์ในกรณีที่โค้ดไม่ได้เรียกอย่างชัดเจนโดยโค้ดใน ไบนารี เช่น หากโค้ดลงทะเบียนเพื่อรับการเรียกกลับบางอย่าง ที่ได้รับจากบริการบางอย่าง หาก alwayslink ใช้กับ VS 2017 ใน Windows ไม่ได้ นั่นเป็นเพราะปัญหาที่ทราบ โปรดอัปเกรด VS 2017 เป็นเวอร์ชันล่าสุด
`conlyopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งการคอมไพล์ C ขึ้นอยู่กับการแทนที่ "Make variable" และ การแยกโทเค็น Bourne Shell
`copts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งการคอมไพล์ C/C++ ขึ้นอยู่กับการแทนที่ "Make variable" และ การแยกโทเค็น Bourne Shell ระบบจะเพิ่มสตริงแต่ละรายการในแอตทริบิวต์นี้ตามลำดับที่ระบุไปยัง `COPTS` ก่อน คอมไพล์เป้าหมายไบนารี โดยแฟล็กจะมีผลเฉพาะกับการคอมไพล์เป้าหมายนี้เท่านั้น ไม่รวมถึง การขึ้นต่อกัน ดังนั้นโปรดระมัดระวังเกี่ยวกับไฟล์ส่วนหัวที่รวมไว้ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้ภายนอก `third_party` หากแพ็กเกจประกาศฟีเจอร์ `no_copts_tokenization` การแยกโทเค็นของ Bourne Shell จะใช้กับสตริง ที่มีตัวแปร "Make" เพียงตัวเดียวเท่านั้น
`cxxopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งการคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "Make variable" และ การแยกโทเค็น Bourne Shell
`defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการคำจำกัดความที่จะเพิ่มลงในบรรทัดการคอมไพล์ของเป้าหมายนี้และเป้าหมายที่ขึ้นต่อกันทั้งหมด ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และ การแยกโทเค็น Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็น Bourne Shell เดียว จะนำหน้าด้วย `-D` และเพิ่มลงในบรรทัดคำสั่งคอมไพล์ไปยังเป้าหมายนี้ รวมถึงทุกกฎที่ขึ้นอยู่กับเป้าหมายนี้ โปรดระมัดระวังอย่างยิ่ง เนื่องจากอาจส่งผลกระทบในวงกว้าง โดยระบบจะเพิ่มคำจำกัดความลงในทุกเป้าหมายที่ขึ้นอยู่กับเป้าหมายนี้ หากไม่แน่ใจ ให้เพิ่มค่าที่กำหนดไว้ใน `local_defines` แทน
`hdrs_check`	สตริง ค่าเริ่มต้นคือ `""` เลิกใช้งานแล้ว ไม่มีการดำเนินการ
`implementation_deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไลบรารีอื่นๆ ที่เป้าหมายไลบรารีขึ้นอยู่กับ ซึ่งแตกต่างจาก `deps` โดยส่วนหัวและเส้นทางรวมของไลบรารีเหล่านี้ (และ การขึ้นต่อกันแบบทรานซิทีฟทั้งหมด) จะใช้สำหรับการคอมไพล์ไลบรารีนี้เท่านั้น และไม่ใช่ไลบรารีที่ ขึ้นอยู่กับไลบรารีนี้ ไลบรารีที่ระบุด้วย `implementation_deps` จะยังคงลิงก์อยู่ใน เป้าหมายไบนารีที่ขึ้นอยู่กับไลบรารีนี้
`include_prefix`	สตริง ค่าเริ่มต้นคือ `""` คำนำหน้าที่จะเพิ่มลงในเส้นทางของส่วนหัวของกฎนี้ เมื่อตั้งค่าแล้ว ระบบจะเข้าถึงส่วนหัวในแอตทริบิวต์ `hdrs` ของกฎนี้ได้ ที่ is the value of this attribute prepended to their repository-relative path. ระบบจะนำคำนำหน้าในแอตทริบิวต์ `strip_include_prefix` ออกก่อนที่จะเพิ่มคำนำหน้านี้ แอตทริบิวต์นี้ถูกต้องตามกฎหมายภายใต้ `third_party` เท่านั้น
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีที่รวมไว้ที่จะเพิ่มลงในบรรทัดการคอมไพล์ ขึ้นอยู่กับการแทนที่ "สร้างตัวแปร" แต่ละสตริงจะนำหน้าด้วยเส้นทางแพ็กเกจและส่งไปยังเครื่องมือ C++ สำหรับ การขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" Toolchain ที่ทำงานในระบบ POSIX พร้อมคำจำกัดความฟีเจอร์ทั่วไปจะสร้าง `-isystem path_to_package/include_entry` ควรใช้เฉพาะกับไลบรารีของบุคคลที่สามที่ ไม่ได้เป็นไปตามรูปแบบการเขียนคำสั่ง #include ของ Google ซึ่งต่างจาก COPTS โดยระบบจะเพิ่มแฟล็กเหล่านี้สำหรับกฎนี้ และทุกกฎที่ขึ้นอยู่กับกฎนี้ (หมายเหตุ: ไม่ใช่กฎที่ขึ้นอยู่กับกฎนี้) โปรด ระมัดระวังเป็นอย่างยิ่ง เนื่องจากอาจส่งผลกระทบในวงกว้าง หากไม่แน่ใจ ให้เพิ่ม Flag "-I" ไปยัง COPTS แทน เส้นทาง `include` ที่เพิ่มจะรวมไฟล์ที่สร้างขึ้นและไฟล์ในแผนผังแหล่งที่มา
`linkopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` ดู `cc_binary.linkopts` ระบบจะใช้แอตทริบิวต์ `linkopts` กับเป้าหมายใดๆ ที่ขึ้นอยู่กับไลบรารีนี้โดยตรงหรือโดยอ้อมผ่านแอตทริบิวต์ `deps` (หรือผ่านแอตทริบิวต์อื่นๆ ที่ได้รับการปฏิบัติในลักษณะเดียวกัน เช่น แอตทริบิวต์ `malloc` ของ `cc_binary`) ลิงก์ตัวเลือกการขึ้นต่อกันจะมีความสำคัญเหนือกว่าลิงก์ตัวเลือกที่ขึ้นต่อกัน (เช่น ลิงก์ตัวเลือกการขึ้นต่อกันจะปรากฏในบรรทัดคำสั่งในภายหลัง) Linkopts ที่ระบุใน `--linkopt` จะมีผลเหนือกว่า Linkopts ของกฎ โปรดทราบว่าแอตทริบิวต์ `linkopts` จะมีผลเฉพาะ เมื่อสร้างไฟล์ `.so` หรือไฟล์ที่เรียกใช้งานได้เท่านั้น ไม่ใช่ เมื่อสร้างไฟล์ `.a` หรือ `.lo` ดังนั้นหากตั้งค่าแอตทริบิวต์ `linkstatic=True` แอตทริบิวต์ `linkopts` จะไม่มีผลต่อการสร้าง ไลบรารีนี้ แต่จะมีผลต่อเป้าหมายอื่นๆ ที่ขึ้นอยู่กับไลบรารีนี้ นอกจากนี้ โปรดทราบว่าระบบไม่รองรับตัวเลือก "-Wl,-soname" หรือ "-Xlinker -soname" และไม่ควรระบุในแอตทริบิวต์นี้ ไฟล์ `.so` ที่สร้างโดยกฎ `cc_library` จะไม่ลิงก์กับไลบรารีที่ไฟล์เหล่านั้นขึ้นอยู่กับ หากคุณพยายามสร้างไลบรารีที่ใช้ร่วมกันเพื่อใช้ ภายนอกที่เก็บหลัก เช่น เพื่อใช้ด้วยตนเอง กับ `dlopen()` หรือ `LD_PRELOAD` คุณอาจใช้กฎ `cc_binary` ที่มีแอตทริบิวต์ `linkshared=True` ได้ ดู `cc_binary.linkshared`
`linkstamp`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` คอมไพล์และลิงก์ไฟล์ต้นฉบับ C++ ที่ระบุลงในไบนารีสุดท้ายพร้อมกัน เราต้องใช้เทคนิคนี้เพื่อใส่ข้อมูลการประทับเวลาลงในไบนารี หากคอมไพล์ไฟล์ต้นฉบับเป็นออบเจ็กต์ไฟล์ในวิธีปกติ การประทับเวลาจะไม่ถูกต้อง การรวบรวม Linkstamp อาจไม่มีชุดแฟล็กคอมไพเลอร์ใดๆ จึงไม่ควรขึ้นอยู่กับส่วนหัว ตัวเลือกคอมไพเลอร์ หรือตัวแปรการสร้างอื่นๆ ตัวเลือกนี้ควรมีเฉพาะใน`base`แพ็กเกจ
`linkstatic`	บูลีน ค่าเริ่มต้นคือ `False` สำหรับ `cc_binary` และ `cc_test`: ลิงก์ไบนารีในโหมดคงที่ สำหรับ `cc_library.link_static` โปรดดูด้านล่าง โดยค่าเริ่มต้น ตัวเลือกนี้จะเปิดอยู่สำหรับ `cc_binary` และปิดอยู่สำหรับส่วนที่เหลือ หากเปิดใช้และเป็นไบนารีหรือการทดสอบ ตัวเลือกนี้จะบอกเครื่องมือบิลด์ให้ลิงก์ใน `.a` แทน `.so` สำหรับไลบรารีของผู้ใช้ทุกครั้งที่เป็นไปได้ ไลบรารีของระบบ เช่น libc (แต่ไม่ใช่ไลบรารีรันไทม์ C/C++ ดูด้านล่าง) ยังคงลิงก์แบบไดนามิก เช่นเดียวกับไลบรารีที่ไม่มี ไลบรารีแบบคงที่ ดังนั้นไฟล์ที่เรียกใช้งานได้ที่ได้จึงยังคงลิงก์แบบไดนามิก จึงเป็นแบบคงที่ส่วนใหญ่เท่านั้น การลิงก์ไฟล์ที่เรียกใช้งานได้มี 3 วิธี ดังนี้ STATIC ที่มีฟีเจอร์ fully_static_link ซึ่งทุกอย่างจะลิงก์แบบคงที่ เช่น "`gcc -static foo.o libbar.a libbaz.a -lm`" โหมดนี้จะเปิดใช้โดยการระบุ `fully_static_link` ในแอตทริบิวต์ `features` STATIC ซึ่งจะลิงก์ไลบรารีของผู้ใช้ทั้งหมดแบบคงที่ (หากมีเวอร์ชันแบบคงที่) แต่จะลิงก์ไลบรารีของระบบ (ยกเว้นไลบรารีรันไทม์ C/C++) แบบไดนามิก เช่น "`gcc foo.o libfoo.a libbaz.a -lm`" โหมดนี้จะเปิดใช้โดยการระบุ `linkstatic=True` DYNAMIC ซึ่งจะลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันไดนามิก) เช่น "`gcc foo.o libfoo.so libbaz.so -lm`" โหมดนี้จะเปิดใช้โดยการระบุ `linkstatic=False` หากใช้แอตทริบิวต์ `linkstatic` หรือ `fully_static_link` ใน `features` นอก `//third_party` โปรดใส่ความคิดเห็นไว้ใกล้กับกฎเพื่ออธิบายเหตุผล แอตทริบิวต์ `linkstatic` จะมีความหมายต่างออกไปหากใช้ในกฎ `cc_library()` สำหรับไลบรารี C++ `linkstatic=True` จะระบุว่าอนุญาตเฉพาะ การลิงก์แบบคงที่เท่านั้น จึงจะไม่มีการสร้าง `.so` linkstatic=False ไม่ได้ ป้องกันไม่ให้สร้างไลบรารีแบบคงที่ แอตทริบิวต์นี้มีไว้เพื่อควบคุม การสร้างไลบรารีแบบไดนามิก ไม่ควรมีโค้ดที่สร้างด้วย `linkstatic=False` ในเวอร์ชันที่ใช้งานจริง หาก `linkstatic=False` เครื่องมือบิลด์จะสร้างลิงก์สัญลักษณ์ไปยัง ไลบรารีที่ใช้ร่วมกันที่ขึ้นอยู่กับในพื้นที่ `*.runfiles`
`local_defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการคำจำกัดความที่จะเพิ่มลงในบรรทัดการคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และ การแยกโทเค็น Bourne Shell สตริงแต่ละรายการซึ่งต้องประกอบด้วยโทเค็น Bourne Shell รายการเดียว จะนำหน้าด้วย `-D` และเพิ่มลงในบรรทัดคำสั่งคอมไพล์สำหรับเป้าหมายนี้ แต่จะไม่เพิ่มลงในเป้าหมายที่ขึ้นอยู่กับเป้าหมายนี้ ซึ่งแตกต่างจาก `defines` ตรงที่ระบบจะเพิ่มคำจำกัดความลงใน บรรทัดคำสั่งคอมไพล์สำหรับเป้าหมายนี้เท่านั้น
`module_interfaces`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ถือเป็นอินเทอร์เฟซโมดูล C++20 มาตรฐาน C++ ไม่ได้จำกัดนามสกุลไฟล์อินเทอร์เฟซของโมดูล Clang ใช้ cppm GCC สามารถใช้นามสกุลไฟล์ต้นฉบับใดก็ได้ MSVC use ixx การใช้งานได้รับการป้องกันโดยแฟล็ก `--experimental_cpp_modules`
`strip_include_prefix`	สตริง ค่าเริ่มต้นคือ `""` คำนำหน้าที่จะนำออกจากเส้นทางของส่วนหัวของกฎนี้ เมื่อตั้งค่าแล้ว ระบบจะเข้าถึงส่วนหัวในแอตทริบิวต์ `hdrs` ของกฎนี้ได้ ที่เส้นทางของส่วนหัวโดยตัดคำนำหน้านี้ออก หากเป็นเส้นทางแบบสัมพัทธ์ ระบบจะถือว่าเป็นเส้นทางแบบสัมพัทธ์ของแพ็กเกจ หากเป็นเส้นทางสัมบูรณ์ ระบบจะถือว่าเป็นเส้นทางสัมพัทธ์ของที่เก็บ ระบบจะเพิ่มคำนำหน้าในแอตทริบิวต์ `include_prefix` หลังจากที่นำคำนำหน้านี้ออกแล้ว แอตทริบิวต์นี้ถูกต้องตามกฎหมายภายใต้ `third_party` เท่านั้น
`textual_hdrs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ส่วนหัวที่เผยแพร่โดย ไลบรารีนี้เพื่อให้แหล่งข้อมูลในกฎที่ขึ้นต่อกันรวมไว้ในข้อความ นี่คือตำแหน่งสำหรับการประกาศไฟล์ส่วนหัวที่คอมไพล์ด้วยตัวเองไม่ได้ กล่าวคือ ไฟล์เหล่านี้ต้องรวมอยู่ในไฟล์ต้นฉบับอื่นๆ เสมอเพื่อสร้างโค้ดที่ถูกต้อง
`win_def_file`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ไฟล์ DEF ของ Windows ที่จะส่งไปยัง Linker ควรใช้แอตทริบิวต์นี้เมื่อ Windows เป็นแพลตฟอร์มเป้าหมายเท่านั้น ใช้เพื่อ ส่งออกสัญลักษณ์ระหว่างลิงก์ไลบรารีที่แชร์ได้

cc_shared_library

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

cc_shared_library(name, deps, additional_linker_inputs, compatible_with, deprecation, dynamic_deps, exec_compatible_with, exec_group_compatible_with, exec_properties, exports_filter, features, package_metadata, restricted_to, roots, shared_lib_name, static_deps, tags, target_compatible_with, testonly, toolchains, user_link_flags, visibility, 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 โดย baz เป็นการขึ้นต่อกันแบบทรานซิทีฟ ไม่ลิงก์ bar เนื่องจาก dynamic_dep bar_shared มีการระบุแบบไดนามิกอยู่แล้ว

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

ระบบจะถือว่าการขึ้นต่อโดยตรงทั้งหมดของ cc_shared_library มีการส่งออก ดังนั้น Bazel จึงถือว่า foo ได้รับการส่งออกโดย foo_shared ในระหว่างการวิเคราะห์ foo_shared ไม่ได้ส่งออก baz ระบบจะถือว่าเป้าหมายทุกรายการที่ 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.`

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

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

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

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

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

ซึ่งหมายความว่าไลบรารีใน Transitive Closure ของ deps สามารถเข้าถึงได้ โดยไม่ต้องผ่านการอ้างอิง cc_shared_library รายการใดรายการหนึ่ง แต่มีการลิงก์ ไปยัง cc_shared_library อื่นใน dynamic_deps อยู่แล้วและไม่ได้ ส่งออก

วิธีแก้คือส่งออกจากcc_shared_libraryการขึ้นต่อกันหรือดึงcc_shared_libraryบุคคลที่สามที่ส่งออก

`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`

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

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

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

Attributes
`name`	ชื่อ (ต้องระบุ) ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` ไลบรารีระดับบนสุดที่จะลิงก์แบบคงที่ลงในไลบรารีที่ใช้ร่วมกันโดยไม่มีเงื่อนไข หลังจากที่เก็บถาวรทั้งสถาปัตยกรรม การขึ้นต่อกันของไลบรารีแบบทรานซิทีฟของ Deps โดยตรงเหล่านี้จะลิงก์ไปยังไลบรารีที่แชร์นี้ ตราบใดที่ `cc_shared_library` ใน `dynamic_deps` ยังไม่ได้ลิงก์ ในระหว่างการวิเคราะห์ การติดตั้งใช้งานกฎจะพิจารณาเป้าหมายที่ระบุใน `deps` ว่าส่งออกจากไลบรารีที่ใช้ร่วมกันเพื่อแสดงข้อผิดพลาดเมื่อ `cc_shared_libraries` หลายรายการส่งออกเป้าหมายเดียวกัน การใช้งานกฎ ไม่ได้ดูแลการแจ้งให้ Linker ทราบว่าควรถ่ายโอนสัญลักษณ์ใดโดย ออบเจ็กต์ที่ใช้ร่วมกัน ผู้ใช้ควรจัดการเรื่องนี้ผ่านสคริปต์ลิงก์เกอร์หรือการประกาศระดับการมองเห็น ในซอร์สโค้ด การใช้งานจะทริกเกอร์ข้อผิดพลาดทุกครั้งที่มีการลิงก์ไลบรารีเดียวกันแบบคงที่ ใน `cc_shared_library` มากกว่า 1 รายการ คุณหลีกเลี่ยงปัญหานี้ได้โดยการเพิ่ม `"LINKABLE_MORE_THAN_ONCE"` ไปยัง `cc_library.tags` หรือโดยการระบุ `cc_library` เป็นการส่งออกของไลบรารีที่ใช้ร่วมกันรายการใดรายการหนึ่ง เพื่อให้ไลบรารีหนึ่งเป็น`dynamic_dep` ของอีกไลบรารีหนึ่งได้
`additional_linker_inputs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` ไฟล์เพิ่มเติมที่คุณอาจต้องการส่งไปยัง Linker เช่น สคริปต์ Linker คุณต้องส่งแฟล็ก Linker ที่ Linker ต้องการแยกต่างหากเพื่อให้ทราบ เกี่ยวกับไฟล์นี้ โดยทำได้ผ่านแอตทริบิวต์ `user_link_flags`
`dynamic_deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` การอ้างอิงเหล่านี้คือ`cc_shared_library`อื่นๆ ที่เป้าหมายปัจจุบันขึ้นอยู่กับ การติดตั้งใช้งาน `cc_shared_library` จะใช้รายการ `dynamic_deps` (แบบทรานซิทีฟ กล่าวคือ `dynamic_deps` ของ `dynamic_deps` ของเป้าหมายปัจจุบันด้วย) เพื่อตัดสินใจว่าไม่ควรลิงก์ `cc_libraries` ใดใน `deps` แบบทรานซิทีฟ เนื่องจาก `cc_shared_library` อื่นได้ระบุไว้แล้ว
`exports_filter`	รายการสตริง ค่าเริ่มต้นคือ `[]` แอตทริบิวต์นี้มีรายการเป้าหมายที่อ้างว่าไลบรารีที่ใช้ร่วมกันปัจจุบัน ส่งออก ระบบจะถือว่าไลบรารีที่ใช้ร่วมกันส่งออกเป้าหมาย `deps` อยู่แล้ว คุณควรใช้แอตทริบิวต์นี้เพื่อแสดงรายการเป้าหมายใดๆ ที่ไลบรารีที่ใช้ร่วมกันส่งออก แต่เป็นทรัพยากร Dependency แบบทรานซิทีฟของ `deps` โปรดทราบว่าแอตทริบิวต์นี้ไม่ได้เพิ่มขอบการอ้างอิงไปยังเป้าหมายเหล่านั้นจริงๆ แต่`deps` ควรเป็นผู้สร้างขอบการอ้างอิงแทน รายการในแอตทริบิวต์นี้เป็นเพียงสตริง โปรดทราบว่าเมื่อวางเป้าหมายในแอตทริบิวต์นี้ ระบบจะถือว่าเป็นการอ้างสิทธิ์ว่าไลบรารีที่แชร์จะส่งออกสัญลักษณ์จากเป้าหมายนั้น `cc_shared_library` ตรรกะ ไม่ได้จัดการการบอกลิงก์เกอร์ว่าควรส่งออกสัญลักษณ์ใด ไวยากรณ์ต่อไปนี้ได้รับอนุญาต `//foo:__pkg__` เพื่อพิจารณาเป้าหมายใน foo/BUILD `//foo:__subpackages__` เพื่อพิจารณาเป้าหมายใน foo/BUILD หรือแพ็กเกจอื่นๆ ที่อยู่ใต้ foo/ เช่น foo/bar/BUILD
`roots`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]`
`shared_lib_name`	สตริง ค่าเริ่มต้นคือ `""` โดยค่าเริ่มต้น cc_shared_library จะใช้ชื่อสำหรับไฟล์เอาต์พุตของไลบรารีที่ใช้ร่วมกันตามชื่อของเป้าหมายและแพลตฟอร์ม ซึ่งรวมถึงส่วนขยายและบางครั้งอาจมีคำนำหน้าด้วย บางครั้งคุณอาจไม่ต้องการใช้ชื่อเริ่มต้น เช่น เมื่อโหลดไลบรารีที่ใช้ร่วมกันของ C++ สำหรับ Python คุณมักไม่ต้องการใช้คำนำหน้า lib* เริ่มต้น ในกรณีนี้ คุณสามารถใช้แอตทริบิวต์นี้เพื่อเลือกชื่อที่กำหนดเองได้
`static_deps`	รายการสตริง ค่าเริ่มต้นคือ `[]`
`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 เป็นแพลตฟอร์มเป้าหมายเท่านั้น ใช้เพื่อ ส่งออกสัญลักษณ์ระหว่างลิงก์ไลบรารีที่แชร์ได้

cc_static_library

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

cc_static_library(name, deps, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

สร้างไลบรารีแบบคงที่จากรายการเป้าหมายและทรัพยากร Dependency แบบทรานซิทีฟ

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

กลุ่มเอาต์พุต

`linkdeps`

ไฟล์ข้อความที่มีป้ายกำกับของทรัพยากร Dependency แบบทรานซิทีฟของเป้าหมายที่แสดงใน deps ซึ่งไม่ได้มีส่วนร่วมในไฟล์ออบเจ็กต์ใดๆ กับไลบรารีแบบคงที่ แต่มี ไลบรารีแบบคงที่ แบบไดนามิก หรืออินเทอร์เฟซอย่างน้อย 1 รายการ ไลบรารีแบบคงที่ที่ได้ อาจกำหนดให้ไลบรารีเหล่านี้พร้อมใช้งานในเวลาลิงก์

`linkopts`

ไฟล์ข้อความที่มี linkopts ที่ผู้ใช้ระบุของ การอ้างอิงแบบทรานซิทีฟทั้งหมดของเป้าหมายที่ระบุไว้ใน deps

สัญลักษณ์ซ้ำ

โดยค่าเริ่มต้น กฎ cc_static_library จะตรวจสอบว่าไลบรารีแบบคงที่ที่ได้ไม่มีสัญลักษณ์ที่ซ้ำกัน หากมี ระบบจะสร้างไม่สำเร็จพร้อมข้อความแสดงข้อผิดพลาด ที่แสดงรายการสัญลักษณ์ที่ซ้ำกันและไฟล์ออบเจ็กต์ที่มีสัญลักษณ์เหล่านั้น

คุณปิดใช้การตรวจสอบนี้ต่อเป้าหมายหรือต่อแพ็กเกจได้โดยตั้งค่า features = ["-symbol_check"] หรือปิดใช้ทั่วโลกผ่าน --features=-symbol_check

การรองรับ Toolchain สำหรับ `symbol_check`

ชุดเครื่องมือ C++ ที่กำหนดค่าอัตโนมัติซึ่งมาพร้อมกับ Bazel รองรับฟีเจอร์ symbol_checkในทุกแพลตฟอร์ม Toolchain ที่กำหนดเองสามารถเพิ่มการรองรับ ได้ 2 วิธีดังนี้

การใช้การดำเนินการ ACTION_NAMES.validate_static_library และ การเปิดใช้ด้วยฟีเจอร์ symbol_check ชุดเครื่องมือที่ตั้งค่าไว้ในการดำเนินการจะ เรียกใช้ด้วยอาร์กิวเมนต์ 2 รายการ ได้แก่ ไลบรารีแบบคงที่ที่จะตรวจสอบสัญลักษณ์ที่ซ้ำกัน และ เส้นทางของไฟล์ที่ต้องสร้างหากการตรวจสอบผ่าน
มีsymbol_checkฟีเจอร์ที่เพิ่มแฟล็กการเก็บถาวรซึ่งทำให้การดำเนินการสร้างไลบรารีแบบคงที่ล้มเหลวเนื่องจากมีสัญลักษณ์ที่ซ้ำกัน

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

Attributes

name

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

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

deps

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

รายการเป้าหมายที่จะรวมไว้ในไลบรารีแบบคงที่ รวมถึงการอ้างอิงแบบทรานซิทีฟทั้งหมด

Dependency ที่ไม่ได้ระบุไฟล์ออบเจ็กต์จะไม่รวมอยู่ในไลบรารีแบบคงที่ แต่ระบบจะรวบรวมป้ายกำกับของ Dependency เหล่านั้นไว้ในไฟล์ที่จัดทำโดยกลุ่มเอาต์พุต linkdeps

cc_test

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

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

cc_test() กฎจะคอมไพล์การทดสอบ ในที่นี้ เทสต์ คือ Wrapper แบบไบนารีที่ครอบโค้ดการทดสอบบางส่วน

โดยค่าเริ่มต้น การทดสอบ C++ จะลิงก์แบบไดนามิก
หากต้องการลิงก์แบบคงที่กับ Unit Test ให้ระบุ linkstatic=True คุณควรแสดงความคิดเห็นว่าทำไมการทดสอบจึงต้องมี linkstatic เนื่องจากอาจไม่ชัดเจน

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

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

ดูอาร์กิวเมนต์ cc_binary() ยกเว้นว่า อาร์กิวเมนต์ stamp จะตั้งค่าเป็น 0 โดยค่าเริ่มต้นสำหรับการทดสอบ และ cc_test มี แอตทริบิวต์เพิ่มเติมที่ใช้ร่วมกันในกฎการทดสอบทั้งหมด (*_test)

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

Attributes
`name`	ชื่อ (ต้องระบุ) ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไลบรารีอื่นๆ ที่จะลิงก์ไปยังเป้าหมายไบนารี ซึ่งอาจเป็นเป้าหมาย `cc_library` หรือ `objc_library` ก็ได้ นอกจากนี้ คุณยังใส่สคริปต์ Linker (.lds) ลงใน deps และอ้างอิงสคริปต์เหล่านั้นใน `linkopts` ได้ด้วย แต่โปรดพิจารณา `additional_linker_inputs` สำหรับกรณีการใช้งานดังกล่าว
`srcs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ C และ C++ ที่ประมวลผลเพื่อสร้างเป้าหมายไลบรารี ซึ่งเป็นไฟล์ต้นฉบับและไฟล์ส่วนหัวของ C/C++ ไม่ว่าจะไม่ได้สร้าง (ซอร์สโค้ดปกติ) หรือสร้างขึ้น ระบบจะรวบรวมไฟล์ `.cc`, `.c` และ `.cpp` ทั้งหมด ไฟล์เหล่านี้อาจเป็นไฟล์ที่สร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน `outs` ของกฎอื่น `cc_library` นี้จะขึ้นอยู่กับกฎอื่นนั้นโดยอัตโนมัติ ไฟล์แอสเซมบลีแบบเพียว (.s, .asm) จะไม่ได้รับการประมวลผลล่วงหน้า และโดยปกติจะสร้างขึ้นโดยใช้แอสเซมเบลอร์ ไฟล์แอสเซมบลีที่ประมวลผลล่วงหน้า (.S) จะได้รับการประมวลผลล่วงหน้าและโดยทั่วไปจะสร้างขึ้น โดยใช้คอมไพเลอร์ C/C++ ระบบจะไม่คอมไพล์ไฟล์ `.h` แต่จะพร้อมให้แหล่งข้อมูลในกฎนี้รวมไว้ ทั้งไฟล์ `.cc` และ `.h` สามารถรวมส่วนหัวที่ระบุไว้ใน`srcs` เหล่านี้หรือใน`hdrs` ของกฎนี้ หรือกฎใดก็ตามที่ระบุไว้ในอาร์กิวเมนต์ `deps` ได้โดยตรง ต้องระบุไฟล์ `#include` ทั้งหมดในแอตทริบิวต์ `hdrs` ของกฎนี้หรือกฎที่อ้างอิง `cc_library` หรือควรแสดงรายการใน `srcs` หากเป็นไฟล์ส่วนตัว ของไลบรารีนี้ ดูคำอธิบายเพิ่มเติมได้ที่ "การตรวจสอบการรวมส่วนหัว" ไฟล์ `.so`, `.lo` และ `.a` คือ ไฟล์ที่คอมไพล์ล่วงหน้า ไลบรารีของคุณอาจมีรายการเหล่านี้เป็น `srcs` หากใช้โค้ดของบุคคลที่สามซึ่งเราไม่มี ซอร์สโค้ด หากแอตทริบิวต์ `srcs` มีป้ายกำกับของกฎอื่น `cc_library` จะใช้ไฟล์เอาต์พุตของกฎนั้นเป็นไฟล์ต้นฉบับเพื่อ คอมไพล์ ซึ่งมีประโยชน์สำหรับการสร้างซอร์สโค้ดแบบครั้งเดียว (หากต้องการใช้มากกว่าเป็นครั้งคราว ควรใช้คลาสกฎ Starlark และใช้ `cc_common` API) `srcs` ประเภทไฟล์ที่อนุญาตมีดังนี้ ไฟล์ต้นฉบับ C และ C++: `.c`, `.cc`, `.cpp`, `.cxx`, `.c++`, `.C` ไฟล์ส่วนหัว C และ C++: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` Assembler ที่มีตัวประมวลผล C ล่วงหน้า: `.S` เก็บ: `.a`, `.pic.a` เชื่อมต่อไลบรารี "เสมอ": `.lo`, `.pic.lo` ไลบรารีที่ใช้ร่วมกันแบบมีเวอร์ชันหรือไม่มีเวอร์ชัน: `.so`, `.so.version` ไฟล์ออบเจ็กต์: `.o`, `.pic.o` ... และกฎใดๆ ที่สร้างไฟล์เหล่านั้น (เช่น `cc_embed_data`) นามสกุลที่แตกต่างกันจะแสดงถึงภาษาโปรแกรมที่แตกต่างกันใน ตามธรรมเนียมของ gcc
`data`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ที่ไลบรารีนี้ต้องการในรันไทม์ ดูความคิดเห็นทั่วไปเกี่ยวกับ `data` ที่แอตทริบิวต์ทั่วไปที่กำหนดโดย กฎการสร้างส่วนใหญ่ หาก `data` เป็นชื่อของไฟล์ที่สร้างขึ้น กฎนี้ `cc_library` จะขึ้นอยู่กับกฎการสร้าง โดยอัตโนมัติ หาก `data` เป็นชื่อกฎ กฎ `cc_library` นี้จะขึ้นอยู่กับกฎดังกล่าวโดยอัตโนมัติ และระบบจะเพิ่ม `outs` ของกฎนั้นลงใน ไฟล์ข้อมูลของ `cc_library` นี้โดยอัตโนมัติ โค้ด C++ สามารถเข้าถึงไฟล์ข้อมูลเหล่านี้ได้ดังนี้ `const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");`
`additional_linker_inputs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` Dependency ที่มีให้เฉพาะคำสั่ง Linker ของ C++ `deps` ซึ่งสร้างขึ้นเพื่อการคอมไพล์และการลิงก์ทรัพยากร Dependency ทั้ง 2 อย่างนั้นแตกต่างจาก `additional_linker_inputs` ซึ่งสร้างขึ้นเพื่อการลิงก์เท่านั้น และส่งสัญญาณถึงทรัพยากร Dependency ที่จำเป็นสำหรับการลิงก์เท่านั้น (เช่น ไฟล์ที่อ้างอิงใน `linkopts`) เช่น คุณระบุไฟล์ .res ของ Windows ที่คอมไพล์แล้วได้ที่นี่เพื่อฝังใน เป้าหมายไบนารี
`conlyopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งการคอมไพล์ C ขึ้นอยู่กับการแทนที่ "Make variable" และ การแยกโทเค็น Bourne Shell
`copts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งการคอมไพล์ C/C++ ขึ้นอยู่กับการแทนที่ "Make variable" และ การแยกโทเค็น Bourne Shell ระบบจะเพิ่มสตริงแต่ละรายการในแอตทริบิวต์นี้ตามลำดับที่ระบุไปยัง `COPTS` ก่อน คอมไพล์เป้าหมายไบนารี โดยแฟล็กจะมีผลเฉพาะกับการคอมไพล์เป้าหมายนี้เท่านั้น ไม่รวมถึง การขึ้นต่อกัน ดังนั้นโปรดระมัดระวังเกี่ยวกับไฟล์ส่วนหัวที่รวมไว้ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้ภายนอก `third_party` หากแพ็กเกจประกาศฟีเจอร์ `no_copts_tokenization` การแยกโทเค็นของ Bourne Shell จะใช้กับสตริง ที่มีตัวแปร "Make" เพียงตัวเดียวเท่านั้น
`cxxopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งการคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "Make variable" และ การแยกโทเค็น Bourne Shell
`defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการคำจำกัดความที่จะเพิ่มลงในบรรทัดการคอมไพล์ของเป้าหมายนี้และเป้าหมายที่ขึ้นต่อกันทั้งหมด ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และ การแยกโทเค็น Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็น Bourne Shell เดียว จะนำหน้าด้วย `-D` และเพิ่มลงในบรรทัดคำสั่งคอมไพล์ไปยังเป้าหมายนี้ รวมถึงทุกกฎที่ขึ้นอยู่กับเป้าหมายนี้ โปรดระมัดระวังอย่างยิ่ง เนื่องจากอาจส่งผลกระทบในวงกว้าง โดยระบบจะเพิ่มคำจำกัดความลงในทุกเป้าหมายที่ขึ้นอยู่กับเป้าหมายนี้ หากไม่แน่ใจ ให้เพิ่มค่าที่กำหนดไว้ใน `local_defines` แทน
`dynamic_deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` การอ้างอิงเหล่านี้คือ`cc_shared_library`อื่นๆ ที่เป้าหมายปัจจุบันขึ้นอยู่กับ การติดตั้งใช้งาน `cc_shared_library` จะใช้รายการ `dynamic_deps` (แบบทรานซิทีฟ กล่าวคือ `dynamic_deps` ของ `dynamic_deps` ของเป้าหมายปัจจุบันด้วย) เพื่อตัดสินใจว่าไม่ควรลิงก์ `cc_libraries` ใดใน `deps` แบบทรานซิทีฟ เนื่องจาก `cc_shared_library` อื่นได้ระบุไว้แล้ว
`hdrs_check`	สตริง ค่าเริ่มต้นคือ `""` เลิกใช้งานแล้ว ไม่มีการดำเนินการ
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีที่รวมไว้ที่จะเพิ่มลงในบรรทัดการคอมไพล์ ขึ้นอยู่กับการแทนที่ "สร้างตัวแปร" แต่ละสตริงจะนำหน้าด้วยเส้นทางแพ็กเกจและส่งไปยังเครื่องมือ C++ สำหรับ การขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" Toolchain ที่ทำงานในระบบ POSIX พร้อมคำจำกัดความฟีเจอร์ทั่วไปจะสร้าง `-isystem path_to_package/include_entry` ควรใช้เฉพาะกับไลบรารีของบุคคลที่สามที่ ไม่ได้เป็นไปตามรูปแบบการเขียนคำสั่ง #include ของ Google ซึ่งต่างจาก COPTS โดยระบบจะเพิ่มแฟล็กเหล่านี้สำหรับกฎนี้ และทุกกฎที่ขึ้นอยู่กับกฎนี้ (หมายเหตุ: ไม่ใช่กฎที่ขึ้นอยู่กับกฎนี้) โปรด ระมัดระวังเป็นอย่างยิ่ง เนื่องจากอาจส่งผลกระทบในวงกว้าง หากไม่แน่ใจ ให้เพิ่ม Flag "-I" ไปยัง COPTS แทน เส้นทาง `include` ที่เพิ่มจะรวมไฟล์ที่สร้างขึ้นและไฟล์ในแผนผังแหล่งที่มา
`link_extra_lib`	ป้ายกำกับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:link_extra_lib"` ควบคุมการลิงก์ไลบรารีเพิ่มเติม โดยค่าเริ่มต้น ไบนารี C++ จะลิงก์กับ `//tools/cpp:link_extra_lib`, ซึ่งโดยค่าเริ่มต้นจะขึ้นอยู่กับแฟล็กป้ายกำกับ `//tools/cpp:link_extra_libs` หากไม่ได้ตั้งค่าสถานะ ไลบรารีนี้จะว่างเปล่าโดยค่าเริ่มต้น การตั้งค่าแฟล็กป้ายกำกับ จะอนุญาตให้ลิงก์การขึ้นต่อกันที่ไม่บังคับ เช่น การลบล้างสำหรับสัญลักษณ์ที่อ่อนแอ ตัวสกัดกั้น สำหรับฟังก์ชันไลบรารีที่ใช้ร่วมกัน หรือไลบรารีรันไทม์พิเศษ (สำหรับการแทนที่ malloc ให้ใช้ `malloc` หรือ `--custom_malloc`) การตั้งค่าแอตทริบิวต์นี้เป็น `None` จะปิดใช้ลักษณะการทำงานนี้
`linkopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มแฟล็กเหล่านี้ลงในคำสั่ง Linker ของ C++ ขึ้นอยู่กับการแทนที่ตัวแปร "Make" การแยกโทเค็นของ Bourne Shell และ การขยายป้ายกำกับ ระบบจะเพิ่มสตริงแต่ละรายการในแอตทริบิวต์นี้ไปยัง `LINKOPTS` ก่อน ลิงก์เป้าหมายไบนารี องค์ประกอบแต่ละรายการในรายการนี้ที่ไม่ได้ขึ้นต้นด้วย `$` หรือ `-` จะถือว่าเป็นป้ายกำกับของเป้าหมายใน `deps` ระบบจะผนวกรายการไฟล์ที่สร้างโดยเป้าหมายนั้นเข้ากับตัวเลือกของ Linker ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือไม่ได้ประกาศใน `deps`
`linkshared`	บูลีน ค่าเริ่มต้นคือ `False` สร้างไลบรารีที่ใช้ร่วมกัน หากต้องการเปิดใช้แอตทริบิวต์นี้ ให้ใส่ `linkshared=True` ในกฎ โดยค่าเริ่มต้น ตัวเลือกนี้จะปิดอยู่ การมีแฟล็กนี้หมายความว่าการลิงก์เกิดขึ้นพร้อมกับแฟล็ก `-shared` ถึง `gcc` และไลบรารีที่แชร์ซึ่งเป็นผลลัพธ์เหมาะสำหรับการโหลดลงในโปรแกรม Java เป็นต้น อย่างไรก็ตาม เพื่อวัตถุประสงค์ในการสร้าง จะไม่มีการลิงก์เข้ากับไบนารีที่ขึ้นต่อกัน เนื่องจากถือว่าไลบรารีที่ใช้ร่วมกันซึ่งสร้างด้วยกฎ cc_binary จะโหลดด้วยตนเองโดยโปรแกรมอื่นๆ เท่านั้น ดังนั้นจึงไม่ควรพิจารณาว่ากฎนี้ใช้แทนกฎ cc_library ได้ เพื่อความสามารถในการปรับขนาด เราขอแนะนำให้หลีกเลี่ยงแนวทางนี้โดยสิ้นเชิงและ เพียงแค่ปล่อยให้`java_library`ขึ้นอยู่กับกฎ`cc_library` แทน หากคุณระบุทั้ง `linkopts=['-static']` และ `linkshared=True` คุณจะได้รับหน่วยเดียวที่ทำงานได้ด้วยตัวเองอย่างสมบูรณ์ หากคุณระบุทั้ง `linkstatic=True` และ `linkshared=True` คุณจะได้รับหน่วยเดียวที่ส่วนใหญ่ มีอยู่ในตัว
`linkstatic`	บูลีน ค่าเริ่มต้นคือ `False` สำหรับ `cc_binary` และ `cc_test`: ลิงก์ไบนารีในโหมดคงที่ สำหรับ `cc_library.link_static` โปรดดูด้านล่าง โดยค่าเริ่มต้น ตัวเลือกนี้จะเปิดอยู่สำหรับ `cc_binary` และปิดอยู่สำหรับส่วนที่เหลือ หากเปิดใช้และเป็นไบนารีหรือการทดสอบ ตัวเลือกนี้จะบอกเครื่องมือบิลด์ให้ลิงก์ใน `.a` แทน `.so` สำหรับไลบรารีของผู้ใช้ทุกครั้งที่เป็นไปได้ ไลบรารีของระบบ เช่น libc (แต่ไม่ใช่ไลบรารีรันไทม์ C/C++ ดูด้านล่าง) ยังคงลิงก์แบบไดนามิก เช่นเดียวกับไลบรารีที่ไม่มี ไลบรารีแบบคงที่ ดังนั้นไฟล์ที่เรียกใช้งานได้ที่ได้จึงยังคงลิงก์แบบไดนามิก จึงเป็นแบบคงที่ส่วนใหญ่เท่านั้น การลิงก์ไฟล์ที่เรียกใช้งานได้มี 3 วิธี ดังนี้ STATIC ที่มีฟีเจอร์ fully_static_link ซึ่งทุกอย่างจะลิงก์แบบคงที่ เช่น "`gcc -static foo.o libbar.a libbaz.a -lm`" โหมดนี้จะเปิดใช้โดยการระบุ `fully_static_link` ในแอตทริบิวต์ `features` STATIC ซึ่งจะลิงก์ไลบรารีของผู้ใช้ทั้งหมดแบบคงที่ (หากมีเวอร์ชันแบบคงที่) แต่จะลิงก์ไลบรารีของระบบ (ยกเว้นไลบรารีรันไทม์ C/C++) แบบไดนามิก เช่น "`gcc foo.o libfoo.a libbaz.a -lm`" โหมดนี้จะเปิดใช้โดยการระบุ `linkstatic=True` DYNAMIC ซึ่งจะลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันไดนามิก) เช่น "`gcc foo.o libfoo.so libbaz.so -lm`" โหมดนี้จะเปิดใช้โดยการระบุ `linkstatic=False` หากใช้แอตทริบิวต์ `linkstatic` หรือ `fully_static_link` ใน `features` นอก `//third_party` โปรดใส่ความคิดเห็นไว้ใกล้กับกฎเพื่ออธิบายเหตุผล แอตทริบิวต์ `linkstatic` จะมีความหมายต่างออกไปหากใช้ในกฎ `cc_library()` สำหรับไลบรารี C++ `linkstatic=True` จะระบุว่าอนุญาตเฉพาะ การลิงก์แบบคงที่เท่านั้น จึงจะไม่มีการสร้าง `.so` linkstatic=False ไม่ได้ ป้องกันไม่ให้สร้างไลบรารีแบบคงที่ แอตทริบิวต์นี้มีไว้เพื่อควบคุม การสร้างไลบรารีแบบไดนามิก ไม่ควรมีโค้ดที่สร้างด้วย `linkstatic=False` ในเวอร์ชันที่ใช้งานจริง หาก `linkstatic=False` เครื่องมือบิลด์จะสร้างลิงก์สัญลักษณ์ไปยัง ไลบรารีที่ใช้ร่วมกันที่ขึ้นอยู่กับในพื้นที่ `*.runfiles`
`local_defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการคำจำกัดความที่จะเพิ่มลงในบรรทัดการคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และ การแยกโทเค็น Bourne Shell สตริงแต่ละรายการซึ่งต้องประกอบด้วยโทเค็น Bourne Shell รายการเดียว จะนำหน้าด้วย `-D` และเพิ่มลงในบรรทัดคำสั่งคอมไพล์สำหรับเป้าหมายนี้ แต่จะไม่เพิ่มลงในเป้าหมายที่ขึ้นอยู่กับเป้าหมายนี้ ซึ่งแตกต่างจาก `defines` ตรงที่ระบบจะเพิ่มคำจำกัดความลงใน บรรทัดคำสั่งคอมไพล์สำหรับเป้าหมายนี้เท่านั้น
`malloc`	ป้ายกำกับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:malloc"` ลบล้างการขึ้นอยู่กับ malloc เริ่มต้น โดยค่าเริ่มต้น ไบนารี C++ จะลิงก์กับ `//tools/cpp:malloc` ซึ่งเป็นไลบรารีที่ว่างเปล่า ดังนั้นไบนารีจึงใช้ malloc ของ libc ป้ายกำกับนี้ต้องอ้างอิงถึง `cc_library` หากการคอมไพล์เป็นกฎที่ไม่ใช่ C++ ตัวเลือกนี้จะไม่มีผล ระบบจะไม่สนใจค่าของแอตทริบิวต์นี้หากระบุ `linkshared=True`
`module_interfaces`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ถือเป็นอินเทอร์เฟซโมดูล C++20 มาตรฐาน C++ ไม่ได้จำกัดนามสกุลไฟล์อินเทอร์เฟซของโมดูล Clang ใช้ cppm GCC สามารถใช้นามสกุลไฟล์ต้นฉบับใดก็ได้ MSVC use ixx การใช้งานได้รับการป้องกันโดยแฟล็ก `--experimental_cpp_modules`
`nocopts`	สตริง ค่าเริ่มต้นคือ `""` นำตัวเลือกที่ตรงกันออกจากคำสั่งการคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ตัวแปร "Make" ระบบจะตีความค่าของแอตทริบิวต์นี้เป็นนิพจน์ทั่วไป `COPTS`ที่มีอยู่ก่อนแล้วซึ่งตรงกับนิพจน์ทั่วไปนี้ (รวมถึงค่าที่ระบุอย่างชัดเจนในแอตทริบิวต์ copts ของกฎ) จะถูกนำออกจาก `COPTS` เพื่อวัตถุประสงค์ในการรวบรวมกฎนี้ ไม่ควรต้องใช้แอตทริบิวต์นี้ภายนอก `third_party` ระบบจะไม่ประมวลผลค่าล่วงหน้า ในลักษณะใดๆ นอกเหนือจากการแทนที่ตัวแปร "Make"
`reexport_deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]`
`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, dwp_files, dynamic_runtime_lib, exec_compatible_with, exec_group_compatible_with, exec_properties, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, output_licenses, package_metadata, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, toolchains, visibility)

แสดงถึงเครื่องมือ C++

กฎนี้มีหน้าที่ดังนี้

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

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

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

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

Attributes
`name`	ชื่อ (ต้องระบุ) ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`all_files`	ป้ายกำกับ (ต้องระบุ) คอลเล็กชันของอาร์ติแฟกต์ cc_toolchain ทั้งหมด ระบบจะเพิ่มอาร์ติแฟกต์เหล่านี้เป็นอินพุตในการดำเนินการทั้งหมดที่เกี่ยวข้องกับ rules_cc (ยกเว้นการดำเนินการที่ใช้ชุดอาร์ติแฟกต์ที่แม่นยำกว่าจากแอตทริบิวต์ด้านล่าง) Bazel ถือว่า `all_files` เป็นซูเปอร์เซ็ต ของแอตทริบิวต์อื่นๆ ทั้งหมดที่ให้สิ่งประดิษฐ์ (เช่น การคอมไพล์ linkstamp ต้องใช้ทั้งไฟล์คอมไพล์ และไฟล์ลิงก์ จึงใช้ `all_files`) ซึ่งเป็นสิ่งที่ `cc_toolchain.files` มี และกฎ Starlark ทั้งหมดที่ใช้ Toolchain 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" และเราลิงก์ การอ้างอิงแบบไดนามิก
`exec_transition_for_inputs`	บูลีน ค่าเริ่มต้นคือ `False` เลิกใช้งานแล้ว ไม่มีการดำเนินการ
`libc_top`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ชุดอาร์ติแฟกต์สำหรับ libc ที่ส่งเป็นอินพุตไปยังการดำเนินการคอมไพล์/ลิงก์
`linker_files`	ป้ายกำกับ (ต้องระบุ) รวบรวมอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการลิงก์
`module_map`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` อาร์ติแฟกต์แผนที่โมดูลที่จะใช้สำหรับการสร้างแบบแยกส่วน
`objcopy_files`	ป้ายกำกับ (ต้องระบุ) รวบรวมอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการ objcopy
`output_licenses`	รายการสตริง ค่าเริ่มต้นคือ `[]`
`static_runtime_lib`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` อาร์ติแฟกต์ไลบรารีแบบคงที่สำหรับไลบรารีรันไทม์ C++ (เช่น libstdc++.a) โดยจะใช้เมื่อเปิดใช้ฟีเจอร์ "static_link_cpp_runtimes" และเราลิงก์ การอ้างอิงแบบคงที่
`strip_files`	ป้ายกำกับ (ต้องระบุ) รวบรวมอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการ strip
`supports_header_parsing`	บูลีน ค่าเริ่มต้นคือ `False` ตั้งค่าเป็น True เมื่อ cc_toolchain รองรับการดำเนินการแยกวิเคราะห์ส่วนหัว
`supports_param_files`	บูลีน ค่าเริ่มต้นคือ `True` ตั้งค่าเป็น "จริง" เมื่อ cc_toolchain รองรับการใช้ไฟล์พารามิเตอร์สำหรับการดำเนินการลิงก์
`toolchain_config`	ป้ายกำกับ (ต้องระบุ) ป้ายกำกับของกฎที่ระบุ `cc_toolchain_config_info`
`toolchain_identifier`	สตริง ค่าเริ่มต้นคือ `""` ตัวระบุที่ใช้เพื่อจับคู่ cc_toolchain นี้กับ crosstool_config.toolchain ที่เกี่ยวข้อง จนกว่าปัญหา #5380 จะได้รับการแก้ไข วิธีที่แนะนำในการเชื่อมโยง `cc_toolchain` กับ `CROSSTOOL.toolchain` คือ โดยจะแทนที่ด้วยแอตทริบิวต์ `toolchain_config` (#5380)

cc_toolchain_suite

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

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

เลิกใช้งานแล้ว: กฎนี้ไม่มีผลและจะถูกนำออก

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

Attributes

name

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

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

fdo_prefetch_hints

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

fdo_prefetch_hints(name, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

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


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

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

Attributes

name

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

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

profile

ป้ายกำกับ (ต้องระบุ)

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

fdo_profile

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

fdo_profile(name, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, memprof_profile, package_metadata, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

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


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

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

Attributes
`name`	ชื่อ (ต้องระบุ) ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`memprof_profile`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ป้ายกำกับของโปรไฟล์ MemProf โปรไฟล์ควรมีนามสกุล .profdata (สำหรับโปรไฟล์ memprof ที่จัดทำดัชนี/มีสัญลักษณ์) หรือนามสกุล .zip สำหรับไฟล์ ZIP ที่มีไฟล์ memprof.profdata
`profile`	ป้ายกำกับ (ต้องระบุ) ป้ายกำกับของโปรไฟล์ FDO หรือกฎที่สร้างโปรไฟล์ ไฟล์ FDO อาจมีนามสกุลต่อไปนี้ .profraw สำหรับโปรไฟล์ LLVM ที่ไม่ได้จัดทำดัชนี, .profdata สำหรับโปรไฟล์ LLVM ที่จัดทำดัชนี, .zip ที่มีโปรไฟล์ LLVM profraw, .afdo สำหรับโปรไฟล์ AutoFDO, .xfdo สำหรับ โปรไฟล์ XBinary ป้ายกำกับยังชี้ไปยังกฎ fdo_absolute_path_profile ได้ด้วย
`proto_profile`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` ป้ายกำกับของโปรไฟล์ Protobuf

memprof_profile

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

memprof_profile(name, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

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


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

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

Attributes

name

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

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

profile

ป้ายกำกับ (ต้องระบุ)

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

propeller_optimize

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

propeller_optimize(name, cc_profile, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, ld_profile, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

แสดงโปรไฟล์การเพิ่มประสิทธิภาพของ Propeller ในพื้นที่ทํางาน ตัวอย่าง


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

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

Attributes

name

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

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

cc_profile

ป้ายกำกับ (ต้องระบุ)

ป้ายกำกับของโปรไฟล์ที่ส่งไปยังการดำเนินการคอมไพล์ต่างๆ ไฟล์นี้มีนามสกุลเป็น .txt

ld_profile

ป้ายกำกับ (ต้องระบุ)

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

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

กฎ

cc_binary

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

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

cc_import

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

cc_library

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

ตัวอย่าง

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

cc_shared_library

ตัวอย่าง

ข้อผิดพลาด

Two shared libraries in dependencies export the same symbols.

Two shared libraries in dependencies link the same library statically

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

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

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

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

cc_static_library

กลุ่มเอาต์พุต

linkdeps

linkopts

สัญลักษณ์ซ้ำ

การรองรับ Toolchain สำหรับ symbol_check

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

cc_test

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

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

cc_toolchain

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

cc_toolchain_suite

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

fdo_prefetch_hints

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

fdo_profile

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

memprof_profile

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

propeller_optimize

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

กฎ C / C++

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

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

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

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

`linkdeps`

`linkopts`

การรองรับ Toolchain สำหรับ `symbol_check`