การลงทะเบียน BazelCon 2024 เปิดให้ลงทะเบียนแล้วในตอนนี้

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

กฎ C / C++

รายงานปัญหา ดูแหล่งที่มา รุ่น Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

กฎ

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, distribs, dynamic_deps, env, exec_compatible_with, exec_properties, features, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, module_interfaces, nocopts, output_licenses, 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 ได้ด้วย
`srcs`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ C และ C++ ที่ประมวลผลเพื่อสร้างเป้าหมายไลบรารี ไฟล์เหล่านี้คือไฟล์ซอร์สโค้ดและไฟล์ส่วนหัว C/C++ ที่ไม่ได้สร้าง (ซอร์สโค้ดปกติ) หรือที่สร้าง ระบบจะคอมไพล์ไฟล์ `.cc`, `.c` และ `.cpp` ทั้งหมด ไฟล์เหล่านี้อาจเป็นไฟล์ที่สร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน`outs`ของกฎอื่น `cc_library`นี้จะขึ้นอยู่กับกฎอื่นนั้นโดยอัตโนมัติ ระบบจะไม่ประมวลผลไฟล์แอสเซมเบลอร์ล้วน (.s, .asm) ล่วงหน้า และมักจะสร้างโดยใช้แอสเซมเบลอร์ ไฟล์แอสเซมบลีที่ประมวลผลล่วงหน้า (.S) ได้รับการประมวลผลล่วงหน้าและมักจะสร้างขึ้นโดยใช้คอมไพเลอร์ C/C++ ระบบจะไม่คอมไพล์ไฟล์ `.h` แต่แหล่งที่มาจะรวมไฟล์ดังกล่าวได้ภายใต้กฎนี้ ทั้งไฟล์ `.cc` และ `.h` สามารถใส่ส่วนหัวที่ระบุไว้ใน `srcs` เหล่านี้หรือใน `hdrs` ของกฎนี้หรือกฎใดๆ ที่ระบุไว้ในอาร์กิวเมนต์ `deps` ได้โดยตรง ไฟล์ `#include`d ทั้งหมดต้องระบุไว้ในแอตทริบิวต์ `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 preprocessor: `.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`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]` ส่งไฟล์เหล่านี้ไปยังคําสั่ง linker ของ C++ เช่น คุณสามารถระบุไฟล์ .res ของ Windows ที่คอมไพล์แล้วที่นี่เพื่อฝังลงในเป้าหมายไบนารี
`conlyopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งคอมไพล์ C ขึ้นอยู่กับการแทนที่ "Make variable" และการแยกออกเป็นโทเค็นของ Bourne shell
`copts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งคอมไพล์ C/C++ ขึ้นอยู่กับการแทนที่ "Make variable" และการแยกออกเป็นโทเค็นของ Bourne shell ระบบจะเพิ่มสตริงแต่ละรายการในแอตทริบิวต์นี้ตามลําดับที่ระบุลงใน `COPTS` ก่อนคอมไพล์เป้าหมายไบนารี Flag จะมีผลกับการคอมไพล์เป้าหมายนี้เท่านั้น ไม่ใช่กับสิ่งที่ต้องพึ่งพา ดังนั้นโปรดระมัดระวังเกี่ยวกับไฟล์ส่วนหัวที่รวมไว้ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทํางาน ไม่ใช่กับแพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้นอก `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`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Make variable" แต่ละสตริงจะมีเส้นทางแพ็กเกจอยู่ด้านหน้าและส่งไปยังชุดเครื่องมือ C++ สำหรับการขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" เครื่องมือทางเทคนิคที่ทำงานบนระบบ POSIX ด้วยคำจำกัดความของฟีเจอร์ทั่วไปจะสร้าง `-isystem path_to_package/include_entry` ควรใช้กับไลบรารีของบุคคลที่สามที่ไม่เป็นไปตามรูปแบบการเขียนคำสั่ง #include ของ Google เท่านั้น ซึ่งแตกต่างจาก COPTS เนื่องจากระบบจะเพิ่ม Flag เหล่านี้สำหรับกฎนี้และกฎทุกข้อที่ขึ้นอยู่กับกฎนี้ (หมายเหตุ: ไม่ใช่กฎที่ใช้กับแอตทริบิวต์) โปรดใช้ความระมัดระวังอย่างยิ่ง เนื่องจากการดำเนินการนี้อาจมีผลที่ตามมาอย่างกว้างขวาง หากไม่แน่ใจ ให้เพิ่ม Flag "-I" ลงใน COPTS แทน เส้นทาง `include` ที่เพิ่มจะมีไฟล์ที่สร้างขึ้น รวมถึงไฟล์ในลําดับชั้นแหล่งที่มา
`link_extra_lib`	ป้ายกํากับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:link_extra_lib"` ควบคุมการลิงก์ไลบรารีเพิ่มเติม โดยค่าเริ่มต้น ระบบจะลิงก์ไบนารี C++ กับ `//tools/cpp:link_extra_lib` ซึ่งโดยค่าเริ่มต้นจะขึ้นอยู่กับ Flag ป้ายกำกับ `//tools/cpp:link_extra_libs` หากไม่ได้ตั้งค่า Flag ห้องสมุดนี้จะว่างเปล่าโดยค่าเริ่มต้น การตั้งค่า Flag ป้ายกำกับจะอนุญาตให้ลิงก์ไลบรารี 3rd party ที่ไม่บังคับ เช่น การลบล้างสำหรับสัญลักษณ์ที่ลบล้างได้ อินเตอร์เซปเตอร์สำหรับฟังก์ชันของไลบรารีที่ใช้ร่วมกัน หรือไลบรารีรันไทม์พิเศษ (สำหรับรายการที่แทนที่ malloc โปรดใช้ `malloc` หรือ `--custom_malloc`) การตั้งค่าแอตทริบิวต์นี้เป็น `None` จะปิดใช้ลักษณะการทำงานนี้
`linkopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่ม Flag เหล่านี้ลงในคําสั่ง linker ของ C++ ขึ้นอยู่กับการแทนที่ตัวแปร"Make", การแยกคำของ Bourne Shell และ การขยายป้ายกำกับ ระบบจะเพิ่มสตริงแต่ละรายการในแอตทริบิวต์นี้ลงใน `LINKOPTS` ก่อนลิงก์เป้าหมายไบนารี ระบบจะถือว่าองค์ประกอบแต่ละรายการในรายการนี้ที่ไม่ได้ขึ้นต้นด้วย `$` หรือ `-` เป็นป้ายกำกับของเป้าหมายใน `deps` ระบบจะเพิ่มรายการไฟล์ที่สร้างขึ้นโดยเป้าหมายนั้นต่อท้ายตัวเลือก linker ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือไม่มีการประกาศใน `deps`
`linkshared`	บูลีน ค่าเริ่มต้นคือ `False` สร้างคลังที่ใช้ร่วมกัน หากต้องการเปิดใช้แอตทริบิวต์นี้ ให้ใส่ `linkshared=True` ในกฎ ตัวเลือกนี้จะปิดอยู่โดยค่าเริ่มต้น การมี Flag นี้หมายความว่ามีการลิงก์ 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.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` ไดนามิก ซึ่งจะลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันแบบไดนามิก) เช่น "`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` อยู่ข้างหน้าและเพิ่มลงในบรรทัดคำสั่งคอมไพล์สำหรับเป้าหมายนี้ แต่จะไม่เพิ่มลงในรายการที่เกี่ยวข้อง
`malloc`	ป้ายกํากับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:malloc"` ลบล้างการพึ่งพาเริ่มต้นใน malloc โดยค่าเริ่มต้น ระบบจะลิงก์ไบนารี C++ กับ `//tools/cpp:malloc` ซึ่งเป็นไลบรารีว่างเปล่าเพื่อให้ไบนารีใช้ libc malloc ป้ายกำกับนี้ต้องอ้างอิงถึง `cc_library` หากการคอมไพล์มีไว้สำหรับกฎที่ไม่ใช่ C++ ตัวเลือกนี้จะไม่มีผล ระบบจะละเว้นค่าของแอตทริบิวต์นี้หากระบุ `linkshared=True`
`module_interfaces`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]` รายการไฟล์จะถือเป็นอินเทอร์เฟซโมดูล C++20 มาตรฐาน C++ ไม่มีข้อจำกัดเกี่ยวกับนามสกุลไฟล์อินเทอร์เฟซของโมดูล Clang ใช้ cppm GCC สามารถใช้นามสกุลไฟล์ต้นทางใดก็ได้ MSVC ใช้ ixx การใช้ได้รับการปกป้องโดย Flag `--experimental_cpp_modules`
`nocopts`	สตริง ค่าเริ่มต้นคือ `""` นำตัวเลือกที่ตรงกันออกจากคำสั่งการคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" ระบบจะตีความค่าของแอตทริบิวต์นี้เป็นนิพจน์ทั่วไป `COPTS` ที่มีอยู่ซึ่งตรงกับนิพจน์ทั่วไปนี้ (รวมถึงค่าที่ระบุไว้อย่างชัดเจนในแอตทริบิวต์ copts ของกฎ) จะถูกนําออกจาก `COPTS` เพื่อวัตถุประสงค์ในการคอมไพล์กฎนี้ คุณไม่ควรต้องใช้แอตทริบิวต์นี้นอก `third_party` ระบบจะไม่ประมวลผลค่าล่วงหน้าไม่ว่าจะด้วยวิธีใดก็ตาม นอกเหนือจากการแทนที่ตัวแปร "Make"
`reexport_deps`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]`
`stamp`	จํานวนเต็ม ค่าเริ่มต้นคือ `-1` ว่าจะเข้ารหัสข้อมูลบิลด์ลงในไบนารีหรือไม่ ค่าที่เป็นไปได้ ได้แก่ `stamp = 1`: ประทับข้อมูลบิลด์ลงในไบนารีเสมอ แม้ในบิลด์ `--nostamp` ก็ตาม คุณควรหลีกเลี่ยงการตั้งค่านี้ เนื่องจากอาจทำให้แคชระยะไกลสําหรับไบนารีและการดำเนินการดาวน์สตรีมใดๆ ที่ขึ้นอยู่กับแคชนั้นใช้งานไม่ได้ `stamp = 0`: แทนที่ข้อมูลบิลด์ด้วยค่าคงที่เสมอ ซึ่งจะช่วยแคชผลลัพธ์การสร้างที่ดี `stamp = -1`: การฝังข้อมูลบิลด์จะควบคุมโดย Flag `--[no]stamp` ระบบจะไม่สร้างไฟล์ไบนารีที่มีตราประทับอีกครั้ง เว้นแต่จะมีการเปลี่ยนแปลงทรัพยากร Dependency
`win_def_file`	ป้ายกํากับ ค่าเริ่มต้นคือ `None` ไฟล์ DEF ของ Windows ที่ส่งไปยัง linker คุณควรใช้แอตทริบิวต์นี้เมื่อ Windows เป็นแพลตฟอร์มเป้าหมายเท่านั้น ซึ่งสามารถใช้เพื่อ ส่งออกสัญลักษณ์ระหว่างการลิงก์ไลบรารีที่ใช้ร่วมกัน

cc_import

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

cc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, pic_objects, pic_static_library, restricted_to, shared_library, static_library, 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` หากเป็น 1 ไฟล์ไบนารีที่ขึ้นอยู่กับ (โดยตรงหรือโดยอ้อม) ไลบรารี C++ ที่คอมไพล์ล่วงหน้านี้จะลิงก์ไฟล์ออบเจ็กต์ทั้งหมดที่เก็บถาวรไว้ในไลบรารีแบบคงที่ แม้ว่าบางไฟล์จะไม่มีสัญลักษณ์ที่ไบนารีอ้างอิงก็ตาม ซึ่งมีประโยชน์ในกรณีที่โค้ดในไบนารีไม่ได้เรียกใช้โค้ดของคุณอย่างชัดเจน เช่น ในกรณีที่โค้ดลงทะเบียนเพื่อรับการเรียกกลับบางอย่างที่บริการบางอย่างให้ไว้ หาก alwayslink ไม่ทำงานกับ VS 2017 ใน Windows แสดงว่าเป็นปัญหาที่ทราบ โปรดอัปเกรด VS 2017 เป็นเวอร์ชันล่าสุด
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Make variable" แต่ละสตริงจะมีเส้นทางแพ็กเกจอยู่ด้านหน้าและส่งไปยังชุดเครื่องมือ C++ สำหรับการขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" เครื่องมือทางเทคนิคที่ทำงานบนระบบ POSIX ด้วยคำจำกัดความของฟีเจอร์ทั่วไปจะสร้าง `-isystem path_to_package/include_entry` ควรใช้กับไลบรารีของบุคคลที่สามที่ไม่เป็นไปตามรูปแบบการเขียนคำสั่ง #include ของ Google เท่านั้น ซึ่งแตกต่างจาก COPTS เนื่องจากระบบจะเพิ่ม Flag เหล่านี้สำหรับกฎนี้และกฎทุกข้อที่ขึ้นอยู่กับกฎนี้ (หมายเหตุ: ไม่ใช่กฎที่ใช้กับแอตทริบิวต์) โปรดใช้ความระมัดระวังอย่างยิ่ง เนื่องจากการดำเนินการนี้อาจมีผลที่ตามมาอย่างกว้างขวาง หากไม่แน่ใจ ให้เพิ่ม Flag "-I" ลงใน COPTS แทน เส้นทาง `include` เริ่มต้นจะไม่รวมไฟล์ที่สร้างขึ้น หากต้องการ`#include`ไฟล์ส่วนหัวที่สร้างขึ้น ให้ระบุไฟล์นั้นใน`srcs`
`interface_library`	ป้ายกํากับ ค่าเริ่มต้นคือ `None` ไลบรารีอินเทอร์เฟซเดียวสำหรับลิงก์ไลบรารีที่ใช้ร่วมกัน ประเภทไฟล์ที่อนุญาต ได้แก่ `.ifso`, `.tbd`, `.lib`, `.so` หรือ `.dylib`
`linkopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่ม Flag เหล่านี้ลงในคําสั่ง 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`
`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, distribs, exec_compatible_with, exec_properties, features, hdrs_check, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, module_interfaces, 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 อาศัยการรองรับเครื่องมือทางเทคนิคเพื่อบังคับใช้กฎการตรวจสอบการรวม เครื่องมือควรรองรับฟีเจอร์ layering_check และมีการขออย่างชัดแจ้ง เช่น ผ่าน Flag บรรทัดคำสั่ง --features=layering_check หรือพารามิเตอร์ features ของฟังก์ชัน package เครื่องมือทางเทคนิคที่ Bazel มีให้รองรับฟีเจอร์นี้กับ clang ใน Unix และ macOS เท่านั้น

ตัวอย่าง

เราใช้ Flag 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 = 1,
)

ตัวอย่างต่อไปนี้มาจาก 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`d ทั้งหมดต้องระบุไว้ในแอตทริบิวต์ `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 preprocessor: `.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`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]` ส่งไฟล์เหล่านี้ไปยังคําสั่ง linker ของ C++ เช่น คุณสามารถระบุไฟล์ .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` ก่อนคอมไพล์เป้าหมายไบนารี Flag จะมีผลกับการคอมไพล์เป้าหมายนี้เท่านั้น ไม่ใช่กับสิ่งที่ต้องพึ่งพา ดังนั้นโปรดระมัดระวังเกี่ยวกับไฟล์ส่วนหัวที่รวมไว้ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทํางาน ไม่ใช่กับแพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้นอก `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` ของกฎนี้ได้ ซึ่งก็คือค่าของแอตทริบิวต์นี้ที่ขึ้นต้นเส้นทางแบบสัมพัทธ์กับที่เก็บ ระบบจะนำคำนำหน้าในแอตทริบิวต์ `strip_include_prefix` ออกก่อนเพิ่มคำนำหน้านี้ แอตทริบิวต์นี้ถูกกฎหมายภายใต้ `third_party` เท่านั้น
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Make variable" แต่ละสตริงจะมีเส้นทางแพ็กเกจอยู่ด้านหน้าและส่งไปยังชุดเครื่องมือ C++ สำหรับการขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" เครื่องมือทางเทคนิคที่ทำงานบนระบบ POSIX ด้วยคำจำกัดความของฟีเจอร์ทั่วไปจะสร้าง `-isystem path_to_package/include_entry` ควรใช้กับไลบรารีของบุคคลที่สามที่ไม่เป็นไปตามรูปแบบการเขียนคำสั่ง #include ของ Google เท่านั้น ซึ่งแตกต่างจาก COPTS เนื่องจากระบบจะเพิ่ม Flag เหล่านี้สำหรับกฎนี้และกฎทุกข้อที่ขึ้นอยู่กับกฎนี้ (หมายเหตุ: ไม่ใช่กฎที่ใช้กับแอตทริบิวต์) โปรดใช้ความระมัดระวังอย่างยิ่ง เนื่องจากการดำเนินการนี้อาจมีผลที่ตามมาอย่างกว้างขวาง หากไม่แน่ใจ ให้เพิ่ม 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++ ที่ระบุเป็นไบนารีขั้นสุดท้ายพร้อมกัน ต้องใช้กลโกงนี้เพื่อใส่ข้อมูลการประทับเวลาลงในไบนารี หากเราคอมไพล์ไฟล์ต้นฉบับเป็นไฟล์ออบเจ็กต์ด้วยวิธีปกติ การประทับเวลาจะไม่ถูกต้อง การคอมไพล์ลิงก์แสตมป์อาจไม่รวมชุด Flag คอมไพเลอร์ใดๆ โดยเฉพาะ จึงไม่ควรขึ้นอยู่กับส่วนหัว ตัวเลือกคอมไพเลอร์ หรือตัวแปรการสร้างอื่นๆ โดยเฉพาะ ตัวเลือกนี้ควรใช้ในแพ็กเกจ `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` ไดนามิก ซึ่งจะลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันแบบไดนามิก) เช่น "`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` อยู่ข้างหน้าและเพิ่มลงในบรรทัดคำสั่งคอมไพล์สำหรับเป้าหมายนี้ แต่จะไม่เพิ่มลงในรายการที่เกี่ยวข้อง
`module_interfaces`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]` รายการไฟล์จะถือเป็นอินเทอร์เฟซโมดูล C++20 มาตรฐาน C++ ไม่มีข้อจำกัดเกี่ยวกับนามสกุลไฟล์อินเทอร์เฟซของโมดูล Clang ใช้ cppm GCC สามารถใช้นามสกุลไฟล์ต้นทางใดก็ได้ MSVC ใช้ ixx การใช้ได้รับการปกป้องโดย Flag `--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, distribs, dynamic_deps, exec_compatible_with, exec_properties, exports_filter, features, 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 ลิงก์กับ foo แบบทรานซิทีฟ แต่ไม่ลิงก์ bar เนื่องจาก dynamic_dep bar_shared ระบุค่านี้แบบไดนามิกอยู่แล้ว

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

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

cc_library แต่ละรายการในตัวอย่างควรปรากฏไม่เกิน 1 ครั้งใน cc_shared_library หากต้องการลิงก์ 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.`

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

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

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

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

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

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

วิธีแก้ปัญหาคือส่งออกจากcc_shared_library Dependency หรือดึง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 และใช้จากไดนามิก Dependency เท่านั้น หรือตรวจสอบว่า exports_filter ไม่ได้จับเป้าหมายนี้

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

Attributes
`name`	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`deps`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]` ไลบรารีระดับบนสุดที่จะลิงก์แบบคงที่กับไลบรารีที่ใช้ร่วมกันโดยไม่มีเงื่อนไขหลังจากเก็บถาวรทั้งไลบรารีแล้ว ระบบจะลิงก์ไลบรารีที่ขึ้นต่อกันแบบทรานซิทีฟของไลบรารีที่ขึ้นต่อกันโดยตรงเหล่านี้ไปยังไลบรารีที่แชร์นี้ ตราบใดที่ยังไม่ได้ลิงก์โดย `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`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]` รายการเหล่านี้คือ `cc_shared_library` อื่นๆ ที่เป้าหมายปัจจุบันพึ่งพา การติดตั้งใช้งาน `cc_shared_library` จะใช้รายการ `dynamic_deps` (แบบสื่อกลาง กล่าวคือ `dynamic_deps` ของ `dynamic_deps` เป้าหมายปัจจุบัน) เพื่อตัดสินใจว่า `cc_libraries` รายการใดใน `deps` แบบสื่อกลางไม่ควรลิงก์เนื่องจากมี `cc_shared_library` รายการอื่นให้อยู่แล้ว
`exports_filter`	รายการสตริง ค่าเริ่มต้นคือ `[]` แอตทริบิวต์นี้มีรายการเป้าหมายที่อ้างว่าส่งออกโดยไลบรารีที่แชร์ในปัจจุบัน ระบบเข้าใจว่าไลบรารีที่ใช้ร่วมกันส่งออกเป้าหมาย `deps` อยู่แล้ว คุณควรใช้แอตทริบิวต์นี้เพื่อแสดงรายการเป้าหมายที่ส่งออกโดยไลบรารีที่ใช้ร่วมกันแต่มีความเกี่ยวข้องแบบเปลี่ยนผ่านของ `deps` โปรดทราบว่าแอตทริบิวต์นี้ไม่ได้เพิ่มขอบความเกี่ยวข้องไปยังเป้าหมายเหล่านั้น `deps` ควรสร้างขอบความเกี่ยวข้องแทน รายการในแอตทริบิวต์นี้เป็นเพียงสตริง โปรดทราบว่าการวางเป้าหมายในแอตทริบิวต์นี้ถือเป็นการอ้างสิทธิ์ว่าไลบรารีที่แชร์จะส่งออกสัญลักษณ์จากเป้าหมายนั้น ตรรกะ `cc_shared_library` ไม่ได้จัดการกับการบอก linker ว่าควรส่งออกสัญลักษณ์ใด ไวยากรณ์ที่อนุญาตมีดังนี้ `//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`	รายการสตริง ค่าเริ่มต้นคือ `[]` แฟล็กเพิ่มเติมที่คุณต้องการส่งไปยังโปรแกรมลิงก์ ตัวอย่างเช่น หากต้องการให้ตัวลิงก์ทราบเกี่ยวกับสคริปต์ลิงก์ที่ส่งผ่าน 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, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

ขณะนี้กฎนี้อยู่ในขั้นทดลองและใช้ได้กับ Flag --experimental_cc_static_library เท่านั้น สร้างไลบรารีแบบคงที่จากรายการเป้าหมายและทรัพยากร Dependency แบบเปลี่ยนผ่าน

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

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

`linkdeps`

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

`linkopts`

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

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

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

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

การรองรับชุดเครื่องมือสำหรับ `symbol_check`

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

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

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

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, distribs, dynamic_deps, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local, local_defines, malloc, module_interfaces, nocopts, reexport_deps, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

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

โดยค่าเริ่มต้น การทดสอบ C++ จะลิงก์แบบไดนามิก
หากต้องการลิงก์การทดสอบหน่วยแบบคงที่ ให้ระบุ 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 ได้ด้วย
`srcs`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ C และ C++ ที่ประมวลผลเพื่อสร้างเป้าหมายไลบรารี ไฟล์เหล่านี้คือไฟล์ซอร์สโค้ดและไฟล์ส่วนหัว C/C++ ที่ไม่ได้สร้าง (ซอร์สโค้ดปกติ) หรือที่สร้าง ระบบจะคอมไพล์ไฟล์ `.cc`, `.c` และ `.cpp` ทั้งหมด ไฟล์เหล่านี้อาจเป็นไฟล์ที่สร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน`outs`ของกฎอื่น `cc_library`นี้จะขึ้นอยู่กับกฎอื่นนั้นโดยอัตโนมัติ ระบบจะไม่ประมวลผลไฟล์แอสเซมเบลอร์ล้วน (.s, .asm) ล่วงหน้า และมักจะสร้างโดยใช้แอสเซมเบลอร์ ไฟล์แอสเซมบลีที่ประมวลผลล่วงหน้า (.S) ได้รับการประมวลผลล่วงหน้าและมักจะสร้างขึ้นโดยใช้คอมไพเลอร์ C/C++ ระบบจะไม่คอมไพล์ไฟล์ `.h` แต่แหล่งที่มาจะรวมไฟล์ดังกล่าวได้ภายใต้กฎนี้ ทั้งไฟล์ `.cc` และ `.h` สามารถใส่ส่วนหัวที่ระบุไว้ใน `srcs` เหล่านี้หรือใน `hdrs` ของกฎนี้หรือกฎใดๆ ที่ระบุไว้ในอาร์กิวเมนต์ `deps` ได้โดยตรง ไฟล์ `#include`d ทั้งหมดต้องระบุไว้ในแอตทริบิวต์ `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 preprocessor: `.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`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]` ส่งไฟล์เหล่านี้ไปยังคําสั่ง linker ของ C++ เช่น คุณสามารถระบุไฟล์ .res ของ Windows ที่คอมไพล์แล้วที่นี่เพื่อฝังลงในเป้าหมายไบนารี
`conlyopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งคอมไพล์ C ขึ้นอยู่กับการแทนที่ "Make variable" และการแยกออกเป็นโทเค็นของ Bourne shell
`copts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งคอมไพล์ C/C++ ขึ้นอยู่กับการแทนที่ "Make variable" และการแยกออกเป็นโทเค็นของ Bourne shell ระบบจะเพิ่มสตริงแต่ละรายการในแอตทริบิวต์นี้ตามลําดับที่ระบุลงใน `COPTS` ก่อนคอมไพล์เป้าหมายไบนารี Flag จะมีผลกับการคอมไพล์เป้าหมายนี้เท่านั้น ไม่ใช่กับสิ่งที่ต้องพึ่งพา ดังนั้นโปรดระมัดระวังเกี่ยวกับไฟล์ส่วนหัวที่รวมไว้ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทํางาน ไม่ใช่กับแพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้นอก `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`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Make variable" แต่ละสตริงจะมีเส้นทางแพ็กเกจอยู่ด้านหน้าและส่งไปยังชุดเครื่องมือ C++ สำหรับการขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" เครื่องมือทางเทคนิคที่ทำงานบนระบบ POSIX ด้วยคำจำกัดความของฟีเจอร์ทั่วไปจะสร้าง `-isystem path_to_package/include_entry` ควรใช้กับไลบรารีของบุคคลที่สามที่ไม่เป็นไปตามรูปแบบการเขียนคำสั่ง #include ของ Google เท่านั้น ซึ่งแตกต่างจาก COPTS เนื่องจากระบบจะเพิ่ม Flag เหล่านี้สำหรับกฎนี้และกฎทุกข้อที่ขึ้นอยู่กับกฎนี้ (หมายเหตุ: ไม่ใช่กฎที่ใช้กับแอตทริบิวต์) โปรดใช้ความระมัดระวังอย่างยิ่ง เนื่องจากการดำเนินการนี้อาจมีผลที่ตามมาอย่างกว้างขวาง หากไม่แน่ใจ ให้เพิ่ม Flag "-I" ลงใน COPTS แทน เส้นทาง `include` ที่เพิ่มจะมีไฟล์ที่สร้างขึ้น รวมถึงไฟล์ในลําดับชั้นแหล่งที่มา
`link_extra_lib`	ป้ายกํากับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:link_extra_lib"` ควบคุมการลิงก์ไลบรารีเพิ่มเติม โดยค่าเริ่มต้น ระบบจะลิงก์ไบนารี C++ กับ `//tools/cpp:link_extra_lib` ซึ่งโดยค่าเริ่มต้นจะขึ้นอยู่กับ Flag ป้ายกำกับ `//tools/cpp:link_extra_libs` หากไม่ได้ตั้งค่า Flag ห้องสมุดนี้จะว่างเปล่าโดยค่าเริ่มต้น การตั้งค่า Flag ป้ายกำกับจะอนุญาตให้ลิงก์ไลบรารี 3rd party ที่ไม่บังคับ เช่น การลบล้างสำหรับสัญลักษณ์ที่ลบล้างได้ อินเตอร์เซปเตอร์สำหรับฟังก์ชันของไลบรารีที่ใช้ร่วมกัน หรือไลบรารีรันไทม์พิเศษ (สำหรับรายการที่แทนที่ malloc โปรดใช้ `malloc` หรือ `--custom_malloc`) การตั้งค่าแอตทริบิวต์นี้เป็น `None` จะปิดใช้ลักษณะการทำงานนี้
`linkopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่ม Flag เหล่านี้ลงในคําสั่ง linker ของ C++ ขึ้นอยู่กับการแทนที่ตัวแปร"Make", การแยกคำของ Bourne Shell และ การขยายป้ายกำกับ ระบบจะเพิ่มสตริงแต่ละรายการในแอตทริบิวต์นี้ลงใน `LINKOPTS` ก่อนลิงก์เป้าหมายไบนารี ระบบจะถือว่าองค์ประกอบแต่ละรายการในรายการนี้ที่ไม่ได้ขึ้นต้นด้วย `$` หรือ `-` เป็นป้ายกำกับของเป้าหมายใน `deps` ระบบจะเพิ่มรายการไฟล์ที่สร้างขึ้นโดยเป้าหมายนั้นต่อท้ายตัวเลือก linker ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือไม่มีการประกาศใน `deps`
`linkshared`	บูลีน ค่าเริ่มต้นคือ `False` สร้างคลังที่ใช้ร่วมกัน หากต้องการเปิดใช้แอตทริบิวต์นี้ ให้ใส่ `linkshared=True` ในกฎ ตัวเลือกนี้จะปิดอยู่โดยค่าเริ่มต้น การมี Flag นี้หมายความว่ามีการลิงก์ Flag `-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` ไดนามิก ซึ่งจะลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันแบบไดนามิก) เช่น "`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` อยู่ข้างหน้าและเพิ่มลงในบรรทัดคำสั่งคอมไพล์สำหรับเป้าหมายนี้ แต่จะไม่เพิ่มลงในรายการที่เกี่ยวข้อง
`malloc`	ป้ายกํากับ ค่าเริ่มต้นคือ `"@bazel_tools//tools/cpp:malloc"` ลบล้างการพึ่งพาเริ่มต้นใน malloc โดยค่าเริ่มต้น ระบบจะลิงก์ไบนารี C++ กับ `//tools/cpp:malloc` ซึ่งเป็นไลบรารีว่างเปล่าเพื่อให้ไบนารีใช้ libc malloc ป้ายกำกับนี้ต้องอ้างอิงถึง `cc_library` หากการคอมไพล์มีไว้สำหรับกฎที่ไม่ใช่ C++ ตัวเลือกนี้จะไม่มีผล ระบบจะละเว้นค่าของแอตทริบิวต์นี้หากระบุ `linkshared=True`
`module_interfaces`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]` รายการไฟล์จะถือเป็นอินเทอร์เฟซโมดูล C++20 มาตรฐาน C++ ไม่มีข้อจำกัดเกี่ยวกับนามสกุลไฟล์อินเทอร์เฟซของโมดูล Clang ใช้ cppm GCC สามารถใช้นามสกุลไฟล์ต้นทางใดก็ได้ MSVC ใช้ ixx การใช้ได้รับการปกป้องโดย Flag `--experimental_cpp_modules`
`nocopts`	สตริง ค่าเริ่มต้นคือ `""` นำตัวเลือกที่ตรงกันออกจากคำสั่งการคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" ระบบจะตีความค่าของแอตทริบิวต์นี้เป็นนิพจน์ทั่วไป `COPTS` ที่มีอยู่ซึ่งตรงกับนิพจน์ทั่วไปนี้ (รวมถึงค่าที่ระบุไว้อย่างชัดเจนในแอตทริบิวต์ copts ของกฎ) จะถูกนําออกจาก `COPTS` เพื่อวัตถุประสงค์ในการคอมไพล์กฎนี้ คุณไม่ควรต้องใช้แอตทริบิวต์นี้นอก `third_party` ระบบจะไม่ประมวลผลค่าล่วงหน้าไม่ว่าจะด้วยวิธีใดก็ตาม นอกเหนือจากการแทนที่ตัวแปร "Make"
`reexport_deps`	รายการป้ายกํากับ ค่าเริ่มต้นคือ `[]`
`stamp`	จํานวนเต็ม ค่าเริ่มต้นคือ `0` ว่าจะเข้ารหัสข้อมูลบิลด์ลงในไบนารีหรือไม่ ค่าที่เป็นไปได้ ได้แก่ `stamp = 1`: ประทับข้อมูลบิลด์ลงในไบนารีเสมอ แม้ในบิลด์ `--nostamp` ก็ตาม คุณควรหลีกเลี่ยงการตั้งค่านี้ เนื่องจากอาจทำให้แคชระยะไกลสําหรับไบนารีและการดำเนินการดาวน์สตรีมใดๆ ที่ขึ้นอยู่กับแคชนั้นใช้งานไม่ได้ `stamp = 0`: แทนที่ข้อมูลบิลด์ด้วยค่าคงที่เสมอ ซึ่งจะช่วยแคชผลลัพธ์การสร้างที่ดี `stamp = -1`: การฝังข้อมูลบิลด์จะควบคุมโดย Flag `--[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_compatible_with, exec_properties, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, output_licenses, 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) ซึ่งโดยปกติแล้วจะเป็นกลุ่มไฟล์ที่รวมไฟล์ที่จำเป็นทั้งหมด
การสร้างบรรทัดคำสั่งที่ถูกต้องสําหรับการดำเนินการ C++ ซึ่งทำได้โดยใช้ผู้ให้บริการ CcToolchainConfigInfo (ดูรายละเอียดด้านล่าง)

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

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

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

Attributes
`name`	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`all_files`	ป้ายกำกับ (ต้องระบุ) การเก็บรวบรวมอาร์ติแฟกต์ cc_toolchain ทั้งหมด ระบบจะเพิ่มอาร์ติแฟกต์เหล่านี้เป็นอินพุตสําหรับการดําเนินการทั้งหมดที่เกี่ยวข้องกับ rules_cc (ยกเว้นการดําเนินการที่ใช้ชุดอาร์ติแฟกต์ที่แม่นยํากว่าจากแอตทริบิวต์ด้านล่าง) Bazel จะถือว่า `all_files` เป็นเซตที่ใหญ่กว่าของแอตทริบิวต์อื่นๆ ทั้งหมดที่ให้อาร์ติแฟกต์ (เช่น การคอมไพล์ลิงก์แสตมป์ต้องใช้ทั้งการคอมไพล์และลิงก์ไฟล์ จึงต้องใช้ `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" และเรากำลังลิงก์ข้อกําหนดอย่างไดนามิก
`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` ตั้งค่าเป็น "จริง" เมื่อ cc_toolchain รองรับการดำเนินการแยกวิเคราะห์ส่วนหัว
`supports_param_files`	บูลีน ค่าเริ่มต้นคือ `True` ตั้งค่าเป็น "จริง" เมื่อ cc_toolchain รองรับการใช้ไฟล์ param สำหรับการลิงก์การดำเนินการ
`toolchain_config`	ป้ายกำกับ (ต้องระบุ) ป้ายกำกับของกฎที่ให้ `cc_toolchain_config_info`
`toolchain_identifier`	สตริง ค่าเริ่มต้นคือ `""` ตัวระบุที่ใช้จับคู่ cc_toolchain นี้กับ toolchain ของ crosstool_config ที่เกี่ยวข้อง ในระหว่างที่รอแก้ไขปัญหา #5380 เราขอแนะนําให้ใช้วิธีนี้ในการเชื่อมโยง `cc_toolchain` กับ `CROSSTOOL.toolchain` ระบบจะแทนที่ด้วยแอตทริบิวต์ `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)

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

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

Attributes

name

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

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

fdo_prefetch_hints

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

fdo_prefetch_hints(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, 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, distribs, exec_compatible_with, exec_properties, features, memprof_profile, 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, distribs, exec_compatible_with, exec_properties, features, 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, distribs, exec_compatible_with, exec_properties, features, ld_profile, 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

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

การรองรับชุดเครื่องมือสำหรับ symbol_check

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

cc_test

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

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

cc_toolchain

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

cc_toolchain_suite

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

fdo_prefetch_hints

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

fdo_profile

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

memprof_profile

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

propeller_optimize

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

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

การรองรับชุดเครื่องมือสำหรับ `symbol_check`