กฎ C / C++

รายงานปัญหา ดูแหล่งที่มา Nightly{/19/} Nightly{/19/} /4} /20}

กฎ

• cc_binary
• cc_import
• cc_library
• cc_proto_library
• cc_shared_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, copts, 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) ลงใน Dep และอ้างอิงได้ใน linkopts
srcs	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] รายการไฟล์ C และ C++ ที่ประมวลผลเพื่อสร้างเป้าหมายไลบรารี ไฟล์เหล่านี้เป็นไฟล์ส่วนหัวและแหล่งที่มาของ C/C++ อาจเป็นไฟล์ที่ไม่ได้สร้าง (ซอร์สโค้ดปกติ) หรือสร้างขึ้น ระบบจะคอมไพล์ไฟล์ทั้งหมด .cc, .c และ .cpp ซึ่งอาจเป็นไฟล์ที่สร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน outs ของกฎอื่น cc_library นี้จะขึ้นอยู่กับกฎนั้นโดยอัตโนมัติ ไฟล์ As Signing ล้วน (.s, .asm) ไม่ได้รับการประมวลผลล่วงหน้าและมักสร้างขึ้นโดยใช้ Ascyclr ไฟล์แอสเซมบลีที่ประมวลผลล่วงหน้า (.S) จะได้รับการประมวลผลล่วงหน้าและโดยปกติจะสร้างโดยใช้คอมไพเลอร์ C/C++ ระบบจะไม่คอมไพล์ไฟล์ .h แต่แหล่งที่มาในกฎนี้จะรวมไฟล์ได้ ทั้งไฟล์ .cc และ .h จะมีส่วนหัวที่ระบุไว้ใน srcs เหล่านี้หรือใน hdrs ของกฎนี้หรือกฎใดก็ตามที่อยู่ในอาร์กิวเมนต์ deps ได้โดยตรง คุณต้องพูดถึงไฟล์ #included ทั้งหมดในแอตทริบิวต์ 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 เครื่องมือประกอบที่มีโปรเซสเซอร์ล่วงหน้าแบบ 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	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] ส่งต่อไฟล์เหล่านี้ไปยังคำสั่ง Linker C++ เช่น ไฟล์ .res ของ Windows ที่คอมไพล์แล้วอาจระบุที่นี่เพื่อฝังในเป้าหมายไบนารี
copts	รายการสตริง ค่าเริ่มต้นคือ [] เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "MakeVariable" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ตามลำดับที่ระบุไปยัง COPTS ก่อนคอมไพล์เป้าหมายไบนารี แฟล็กจะมีผลต่อการคอมไพล์เป้าหมายนี้เท่านั้น โดยไม่รวมทรัพยากร Dependency ต่างๆ ดังนั้นโปรดระวังเกี่ยวกับไฟล์ส่วนหัวที่อยู่ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้นอก third_party หากแพ็กเกจประกาศฟีเจอร์ no_copts_tokenization การแปลงข้อมูลเป็นโทเค็น Bourne Shell จะใช้กับสตริงที่ประกอบด้วยตัวแปร "Make" เดียวเท่านั้น
defines	รายการสตริง ค่าเริ่มต้นคือ [] รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็นเชลล์ Bourne รายการเดียว ต้องมี -D นำหน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์ไปยังเป้าหมายนี้ รวมถึงกฎทุกข้อที่อ้างอิงสตริงนี้ โปรดใช้ความระมัดระวังเป็นอย่างยิ่ง เนื่องจากอาจส่งผลกระทบในวงกว้าง หากไม่แน่ใจ ให้เพิ่มกําหนดค่าให้กับ local_defines แทน
dynamic_deps	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] นี่เป็นทรัพยากร Dependency อื่นๆ ของ cc_shared_library ที่เป้าหมายปัจจุบันใช้งานอยู่ การติดตั้งใช้งาน cc_shared_library จะใช้รายการ dynamic_deps (หรือที่เรียกว่า dynamic_deps ของ dynamic_deps ของเป้าหมายปัจจุบัน) เพื่อตัดสินใจว่าไม่ควรลิงก์ cc_libraries ใดใน deps ทางอ้อม เนื่องจากมี cc_shared_library อื่นระบุไว้อยู่แล้ว
hdrs_check	สตริง ค่าเริ่มต้นคือ "" เลิกใช้งานแล้ว ไม่มีการดำเนินการ
includes	รายการสตริง ค่าเริ่มต้นคือ [] รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" ระบบจะเพิ่มสตริงแต่ละรายการด้วยเส้นทางแพ็กเกจและส่งไปยังเครื่องมือเชน C++ สำหรับการขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" เครื่องมือเชนที่ทำงานบนระบบ POSIX ที่มีคำจำกัดความฟีเจอร์ทั่วไปจะสร้าง -isystem path_to_package/include_entry ซึ่งควรใช้กับไลบรารีของบุคคลที่สามที่ไม่สอดคล้องกับรูปแบบการเขียน #include ของ Google เท่านั้น ซึ่งต่างจาก COPTS ตรงที่จะเพิ่มแฟล็กเหล่านี้สำหรับกฎนี้และกฎทุกกฎที่อ้างอิงกฎดังกล่าว (หมายเหตุ: ไม่ใช่กฎเกณฑ์แต่อย่างใด) โปรดใช้ความระมัดระวังเป็นอย่างยิ่งเนื่องจากอาจทำให้เกิดผลกระทบอย่างมาก หากไม่แน่ใจ ให้เพิ่มแฟล็ก "-I" ลงใน COPTS แทน เส้นทาง include ที่เพิ่มเข้ามาจะรวมไฟล์ที่สร้างขึ้นและไฟล์ในโครงสร้างต้นทาง
link_extra_lib	ป้ายกำกับ ค่าเริ่มต้นคือ "@bazel_tools//tools/cpp:link_extra_lib" ควบคุมการลิงก์ไลบรารีเพิ่มเติม โดยค่าเริ่มต้น ไบนารีของ C++ จะลิงก์กับ //tools/cpp:link_extra_lib ซึ่งโดยค่าเริ่มต้นจะขึ้นอยู่กับแฟล็กป้ายกำกับ //tools/cpp:link_extra_libs หากไม่ได้ตั้งค่าสถานะ ไลบรารีนี้จะว่างเปล่าโดยค่าเริ่มต้น การตั้งค่าแฟล็กป้ายกำกับช่วยให้ลิงก์ทรัพยากร Dependency ที่ไม่บังคับได้ เช่น การลบล้างสัญลักษณ์ที่ไม่รัดกุม, ตัวดักจับสัญญาณสำหรับฟังก์ชันไลบรารีที่ใช้ร่วมกัน หรือไลบรารีรันไทม์พิเศษ (สำหรับการแทนที่ Malloc ให้ใช้ malloc หรือ --custom_malloc) การตั้งค่าแอตทริบิวต์นี้เป็น None จะปิดใช้ลักษณะการทำงานนี้
linkopts	รายการสตริง ค่าเริ่มต้นคือ [] เพิ่มแฟล็กเหล่านี้ลงในคำสั่ง Linker C++ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" การแปลงเป็นโทเค็น Shell เบิร์นและการขยายป้ายกำกับ ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ลงใน LINKOPTS ก่อนลิงก์เป้าหมายไบนารี แต่ละองค์ประกอบในรายการที่ไม่ได้ขึ้นต้นด้วย $ หรือ - จะถือว่าเป็นป้ายกำกับของเป้าหมายใน deps รายการไฟล์ที่สร้างโดยเป้าหมายดังกล่าวจะต่อท้ายตัวเลือก Linker ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือไม่มีการประกาศใน deps
linkshared	บูลีน ค่าเริ่มต้นคือ False สร้างไลบรารีที่ใช้ร่วมกัน หากต้องการเปิดใช้แอตทริบิวต์นี้ ให้ใส่ linkshared=True ในกฎ ตัวเลือกนี้จะปิดอยู่โดยค่าเริ่มต้น การมี Flag นี้แสดงว่ามีการลิงก์ด้วยแฟล็ก -shared ไปยัง gcc และไลบรารีที่ใช้ร่วมกันที่ได้เหมาะสมสำหรับการโหลดลงในโปรแกรม Java เช่น อย่างไรก็ตาม สำหรับวัตถุประสงค์ในการสร้าง จะไม่มีการลิงก์เข้ากับไบนารีแบบอ้างอิง เนื่องจากมีสมมติฐานว่าไลบรารีที่ใช้ร่วมกันที่สร้างด้วยกฎ cc_binary จะโหลดโดยโปรแกรมอื่นๆ ด้วยตนเองเท่านั้น จึงไม่ถือว่าเป็นการใช้แทนกฎ cc_library เราขอแนะนำให้หลีกเลี่ยงวิธีนี้ทั้งหมดและปล่อยให้ java_library ขึ้นอยู่กับกฎ cc_library แทน เพื่อเพิ่มความสามารถในการปรับขนาด หากระบุทั้ง linkopts=['-static'] และ linkshared=True คุณจะได้รับหน่วยโฆษณาสำเร็จรูปเพียงหน่วยเดียว หากระบุทั้ง linkstatic=True และ linkshared=True คุณจะได้รับยูนิตเดี่ยวแบบเดี่ยวส่วนใหญ่
linkstatic	บูลีน ค่าเริ่มต้นคือ True สำหรับ cc_binary และ cc_test ให้ลิงก์ไบนารีในโหมดคงที่ สำหรับ cc_library.link_static: ดูด้านล่าง โดยค่าเริ่มต้น ตัวเลือกนี้จะเปิดอยู่สำหรับ cc_binary และปิดอยู่สำหรับส่วนที่เหลือ หากเปิดใช้และนี่เป็นไบนารีหรือการทดสอบ ตัวเลือกนี้จะบอกเครื่องมือสร้างให้ลิงก์ใน .a แทน .so สำหรับไลบรารีผู้ใช้เมื่อเป็นไปได้ ไลบรารีของระบบ เช่น libc (แต่ไม่ใช่ไลบรารีรันไทม์ของ C/C++ ดูด้านล่าง) ยังคงลิงก์แบบไดนามิก เช่นเดียวกับไลบรารีที่ไม่มีไลบรารีแบบคงที่ ดังนั้นไฟล์ปฏิบัติการที่ได้จะยังคงลิงก์แบบไดนามิกอยู่ จึงส่วนใหญ่เป็นแบบคงที่ การลิงก์ไฟล์ปฏิบัติการมี 3 วิธีที่แตกต่างกันดังนี้ สถิติที่มีฟีเจอร์ลิงก์_สถิติแบบเต็ม ซึ่งลิงก์ทุกอย่างในแบบคงที่ เช่น "gcc -static foo.o libbar.a libbaz.a -lm" โหมดนี้เปิดใช้งานโดยระบุ fully_static_link ในแอตทริบิวต์ features สถิติซึ่งไลบรารีผู้ใช้ทั้งหมดลิงก์แบบคงที่ (หากมีเวอร์ชันคงที่) แต่ไลบรารีของระบบ (ยกเว้นไลบรารีรันไทม์ C/C++) มีการลิงก์แบบไดนามิก เช่น "gcc foo.o libfoo.a libbaz.a -lm" โหมดนี้เปิดใช้โดยระบุ linkstatic=True ไดนามิก (DYNAMIC) ซึ่งมีการลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันไดนามิกให้ใช้งาน) เช่น "gcc foo.o libfoo.so libbaz.so -lm" โหมดนี้เปิดใช้ด้วยการระบุ linkstatic=False หากใช้แอตทริบิวต์ linkstatic หรือ 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 รายการเดียว จะมี -D นำหน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์สำหรับเป้าหมายนี้ แต่ไม่ใช่ลงในการอ้างอิง
malloc	ป้ายกำกับ ค่าเริ่มต้นคือ "@bazel_tools//tools/cpp:malloc" ลบล้างทรัพยากร Dependency เริ่มต้นใน Malloc โดยค่าเริ่มต้น ไบนารีของ C++ จะลิงก์กับ //tools/cpp:malloc ซึ่งเป็นไลบรารีที่ว่างเปล่า ดังนั้นไบนารีนั้นจะใช้ libc Malloc ป้ายกำกับนี้ต้องอ้างอิงถึง cc_library หากการคอมไพล์เป็นกฎที่ไม่ใช่ C++ ตัวเลือกนี้จะไม่มีผล ระบบจะละเว้นค่าของแอตทริบิวต์นี้หากระบุ linkshared=True
module_interfaces	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] รายการไฟล์ถือว่าเป็นอินเทอร์เฟซโมดูล C++20 C++ มาตรฐานไม่มีข้อจำกัดเกี่ยวกับนามสกุลไฟล์ของโมดูลอินเตอร์เฟซ ใช้ cppm ในไลบรารี GCC ใช้นามสกุลไฟล์ต้นฉบับใดก็ได้ MSVC ใช้ 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, 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 = 1,
)

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 = 1,
)

ขั้นตอนสำหรับ Windows

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

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

ใน Unix:

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

ใน 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 = 1, # default value
)

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

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

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

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

Attributes
name	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
deps	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] รายการของไลบรารีอื่นๆ ที่เป้าหมายขึ้นอยู่กับ ดูความคิดเห็นทั่วไปเกี่ยวกับ deps ได้ที่แอตทริบิวต์ทั่วไปที่กำหนดโดยกฎบิลด์ส่วนใหญ่
hdrs	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] รายการไฟล์ส่วนหัวที่เผยแพร่โดยไลบรารีที่คอมไพล์ไว้ล่วงหน้านี้ที่จะรวมโดยตรงโดยแหล่งที่มาในกฎที่เกี่ยวข้อง
alwayslink	บูลีน ค่าเริ่มต้นคือ False หากเป็น 1 ไบนารีใดๆ ที่ขึ้นอยู่กับ (โดยตรงหรือโดยอ้อม) ในไลบรารีที่คอมไพล์ C++ นี้ จะลิงก์ในไฟล์ออบเจ็กต์ทั้งหมดที่เก็บไว้ในไลบรารีแบบคงที่ แม้ว่าบางไฟล์จะไม่มีสัญลักษณ์ที่ไบนารีอ้างอิงอยู่ วิธีนี้มีประโยชน์หากโค้ดไม่ได้ถูกเรียกอย่างชัดเจนด้วยโค้ดในไบนารี เช่น หากโค้ดของคุณลงทะเบียนเพื่อรับ Callback ที่บริการบางอย่างให้ หากใช้ลิงก์ช่องตลอดเวลากับ VS 2017 ใน Windows ไม่ได้ นั่นอาจเป็นเพราะปัญหาที่ทราบแล้ว โปรดอัปเกรด VS 2017 เป็นเวอร์ชันล่าสุด
includes	รายการสตริง ค่าเริ่มต้นคือ [] รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" ระบบจะเพิ่มสตริงแต่ละรายการด้วยเส้นทางแพ็กเกจและส่งไปยังเครื่องมือเชน C++ สำหรับการขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" เครื่องมือเชนที่ทำงานบนระบบ POSIX ที่มีคำจำกัดความฟีเจอร์ทั่วไปจะสร้าง -isystem path_to_package/include_entry ซึ่งควรใช้กับไลบรารีของบุคคลที่สามที่ไม่สอดคล้องกับรูปแบบการเขียน #include ของ Google เท่านั้น ซึ่งต่างจาก COPTS ตรงที่จะเพิ่มแฟล็กเหล่านี้สำหรับกฎนี้และกฎทุกกฎที่อ้างอิงกฎดังกล่าว (หมายเหตุ: ไม่ใช่กฎเกณฑ์แต่อย่างใด) โปรดใช้ความระมัดระวังเป็นอย่างยิ่งเนื่องจากอาจทำให้เกิดผลกระทบอย่างมาก หากไม่แน่ใจ ให้เพิ่มแฟล็ก "-I" ลงใน COPTS แทน เส้นทาง include เริ่มต้นจะไม่มีไฟล์ที่สร้างขึ้น ถ้าต้องการ#includeไฟล์ส่วนหัวที่สร้างขึ้น ให้ระบุไว้ใน srcs
interface_library	ป้ายกำกับ ค่าเริ่มต้นคือ None ไลบรารีอินเทอร์เฟซเดียวสำหรับการลิงก์ไลบรารีที่ใช้ร่วมกัน ประเภทไฟล์ที่อนุญาต: .ifso, .tbd, .lib, .so หรือ .dylib
linkopts	รายการสตริง ค่าเริ่มต้นคือ [] เพิ่มแฟล็กเหล่านี้ลงในคำสั่ง Linker C++ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" การแปลงเป็นโทเค็น 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, copts, 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.cc	bar.h bar-impl.h baz.h
baz.h	baz-impl.h
baz-impl.h	baz.h
baz.cc	baz.h baz-impl.h

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

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

ตัวอย่าง

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

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 ที่สร้างไว้ล่วงหน้าใน Depot ไฟล์ส่วนหัวอยู่ในไดเรกทอรีย่อยชื่อ 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" แต่ไคลเอ็นต์ของไลบรารีนี้บางส่วนอาจไม่อยู่ที่นี่ ทรัพยากร Dependency ของข้อมูลรันไทม์อยู่ใน data ไฟล์ต้นฉบับที่สร้างโดยกฎอื่นจะอยู่ใน srcs หากต้องการลิงก์ในไลบรารีของบุคคลที่สามที่คอมไพล์ไว้ล่วงหน้า ให้เพิ่มชื่อในไลบรารีดังกล่าวลงใน srcs แทน หากต้องการอ้างอิงเนื้อหาโดยไม่ลิงก์กับไลบรารีนี้ ให้เพิ่มชื่อใน data แทน
srcs	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] รายการไฟล์ C และ C++ ที่ประมวลผลเพื่อสร้างเป้าหมายไลบรารี ไฟล์เหล่านี้เป็นไฟล์ส่วนหัวและแหล่งที่มาของ C/C++ อาจเป็นไฟล์ที่ไม่ได้สร้าง (ซอร์สโค้ดปกติ) หรือสร้างขึ้น ระบบจะคอมไพล์ไฟล์ทั้งหมด .cc, .c และ .cpp ซึ่งอาจเป็นไฟล์ที่สร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน outs ของกฎอื่น cc_library นี้จะขึ้นอยู่กับกฎนั้นโดยอัตโนมัติ ไฟล์ As Signing ล้วน (.s, .asm) ไม่ได้รับการประมวลผลล่วงหน้าและมักสร้างขึ้นโดยใช้ Ascyclr ไฟล์แอสเซมบลีที่ประมวลผลล่วงหน้า (.S) จะได้รับการประมวลผลล่วงหน้าและโดยปกติจะสร้างโดยใช้คอมไพเลอร์ C/C++ ระบบจะไม่คอมไพล์ไฟล์ .h แต่แหล่งที่มาในกฎนี้จะรวมไฟล์ได้ ทั้งไฟล์ .cc และ .h จะมีส่วนหัวที่ระบุไว้ใน srcs เหล่านี้หรือใน hdrs ของกฎนี้หรือกฎใดก็ตามที่อยู่ในอาร์กิวเมนต์ deps ได้โดยตรง คุณต้องพูดถึงไฟล์ #included ทั้งหมดในแอตทริบิวต์ 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 เครื่องมือประกอบที่มีโปรเซสเซอร์ล่วงหน้าแบบ 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 เป็นต้น ไฟล์ที่ระบุไว้ที่นี่จะใช้ใน Copt ด้วยฟังก์ชัน $(location) ได้
additional_linker_inputs	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] ส่งต่อไฟล์เหล่านี้ไปยังคำสั่ง Linker C++ เช่น ไฟล์ .res ของ Windows ที่คอมไพล์แล้วอาจระบุที่นี่เพื่อฝังในเป้าหมายไบนารี
alwayslink	บูลีน ค่าเริ่มต้นคือ False หากเป็น 1 ไบนารีใดๆ ที่ขึ้นอยู่กับ (ทั้งโดยตรงหรือโดยอ้อม) ในไลบรารี C++ นี้จะลิงก์ในไฟล์ออบเจ็กต์ทั้งหมดของไฟล์ที่แสดงอยู่ใน srcs แม้ว่าบางไฟล์จะไม่มีสัญลักษณ์ที่ไบนารีอ้างอิงก็ตาม วิธีนี้มีประโยชน์หากโค้ดไม่ได้ถูกเรียกอย่างชัดเจนด้วยโค้ดในไบนารี เช่น หากโค้ดของคุณลงทะเบียนเพื่อรับ Callback ที่บริการบางอย่างให้ หากใช้ลิงก์ช่องตลอดเวลากับ VS 2017 ใน Windows ไม่ได้ นั่นอาจเป็นเพราะปัญหาที่ทราบแล้ว โปรดอัปเกรด VS 2017 เป็นเวอร์ชันล่าสุด
copts	รายการสตริง ค่าเริ่มต้นคือ [] เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "MakeVariable" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ตามลำดับที่ระบุไปยัง COPTS ก่อนคอมไพล์เป้าหมายไบนารี แฟล็กจะมีผลต่อการคอมไพล์เป้าหมายนี้เท่านั้น โดยไม่รวมทรัพยากร Dependency ต่างๆ ดังนั้นโปรดระวังเกี่ยวกับไฟล์ส่วนหัวที่อยู่ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้นอก third_party หากแพ็กเกจประกาศฟีเจอร์ no_copts_tokenization การแปลงข้อมูลเป็นโทเค็น Bourne Shell จะใช้กับสตริงที่ประกอบด้วยตัวแปร "Make" เดียวเท่านั้น
defines	รายการสตริง ค่าเริ่มต้นคือ [] รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็นเชลล์ Bourne รายการเดียว ต้องมี -D นำหน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์ไปยังเป้าหมายนี้ รวมถึงกฎทุกข้อที่อ้างอิงสตริงนี้ โปรดใช้ความระมัดระวังเป็นอย่างยิ่ง เนื่องจากอาจส่งผลกระทบในวงกว้าง หากไม่แน่ใจ ให้เพิ่มกําหนดค่าให้กับ local_defines แทน
hdrs_check	สตริง ค่าเริ่มต้นคือ "" เลิกใช้งานแล้ว ไม่มีการดำเนินการ
implementation_deps	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] รายการของไลบรารีอื่นๆ ที่เป้าหมายไลบรารีอิงตาม ส่วนหัวและพาธของไลบรารีเหล่านี้ (และ Dep สับเปลี่ยนทั้งหมด) ต่างจาก deps ตรงที่จะมีการใช้สำหรับการคอมไพล์ไลบรารีนี้เท่านั้น ไม่ใช่ไลบรารีที่ขึ้นอยู่กับไลบรารีนี้ ไลบรารีที่ระบุด้วย implementation_deps ยังคงลิงก์ในเป้าหมายแบบไบนารีที่ขึ้นอยู่กับไลบรารีนี้ สำหรับตอนนี้ การใช้งานจะถูกจำกัดไว้ที่ cc_libraries และได้รับการป้องกันโดย Flag --experimental_cc_implementation_deps
include_prefix	สตริง ค่าเริ่มต้นคือ "" คำนำหน้าที่จะเพิ่มลงในเส้นทางของส่วนหัวของกฎนี้ เมื่อตั้งค่าแล้ว ส่วนหัวในแอตทริบิวต์ hdrs ของกฎนี้จะเข้าถึงได้จากค่าของแอตทริบิวต์นี้ที่เพิ่มไว้ข้างหน้าเส้นทางที่สัมพันธ์กับที่เก็บ ระบบจะนำคำนำหน้าในแอตทริบิวต์ strip_include_prefix ออกก่อนที่จะเพิ่มคำนำหน้านี้ แอตทริบิวต์นี้ใช้ได้ตามกฎหมายภายใต้ third_party เท่านั้น
includes	รายการสตริง ค่าเริ่มต้นคือ [] รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" ระบบจะเพิ่มสตริงแต่ละรายการด้วยเส้นทางแพ็กเกจและส่งไปยังเครื่องมือเชน C++ สำหรับการขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" เครื่องมือเชนที่ทำงานบนระบบ POSIX ที่มีคำจำกัดความฟีเจอร์ทั่วไปจะสร้าง -isystem path_to_package/include_entry ซึ่งควรใช้กับไลบรารีของบุคคลที่สามที่ไม่สอดคล้องกับรูปแบบการเขียน #include ของ Google เท่านั้น ซึ่งต่างจาก COPTS ตรงที่จะเพิ่มแฟล็กเหล่านี้สำหรับกฎนี้และกฎทุกกฎที่อ้างอิงกฎดังกล่าว (หมายเหตุ: ไม่ใช่กฎเกณฑ์แต่อย่างใด) โปรดใช้ความระมัดระวังเป็นอย่างยิ่งเนื่องจากอาจทำให้เกิดผลกระทบอย่างมาก หากไม่แน่ใจ ให้เพิ่มแฟล็ก "-I" ลงใน COPTS แทน เส้นทาง include ที่เพิ่มเข้ามาจะรวมไฟล์ที่สร้างขึ้นและไฟล์ในโครงสร้างต้นทาง
linkopts	รายการสตริง ค่าเริ่มต้นคือ [] โปรดดู cc_binary.linkopts นอกจากนี้ แอตทริบิวต์ linkopts ยังใช้กับเป้าหมายใดๆ ที่ขึ้นต่อกันโดยตรงหรือโดยอ้อมในไลบรารีนี้ผ่านแอตทริบิวต์ deps (หรือผ่านแอตทริบิวต์อื่นๆ ที่ได้รับการปฏิบัติในลักษณะเดียวกันคือแอตทริบิวต์ malloc ของ cc_binary) การขึ้นต่อกันลิงก์จะมีความสำคัญเหนือกว่า linkopts ที่ไม่เป็นอิสระ (นั่นคือ Dependency linkopts จะปรากฏภายหลังในบรรทัดคำสั่ง) Linkopt ที่ระบุไว้ใน --linkopt มีลำดับความสำคัญเหนือ Linkopt ของกฎ โปรดทราบว่าแอตทริบิวต์ 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++ ที่ระบุลงในไบนารีสุดท้ายพร้อมกัน จำเป็นต้องใช้เคล็ดลับนี้ในการนำข้อมูลการประทับเวลามาใช้ในไบนารี หากเราคอมไพล์ไฟล์แหล่งที่มาไปยังไฟล์ออบเจ็กต์ตามวิธีปกติ การประทับเวลาจะไม่ถูกต้อง การคอมไพล์ Linktamp อาจไม่มีชุดแฟล็กคอมไพเลอร์ชุดใดโดยเฉพาะ และไม่ควรขึ้นอยู่กับส่วนหัว ตัวเลือกของคอมไพเลอร์ หรือตัวแปรบิลด์อื่นๆ ควรใช้ตัวเลือกนี้ในแพ็กเกจ base เท่านั้น
linkstatic	บูลีน ค่าเริ่มต้นคือ False สำหรับ cc_binary และ cc_test ให้ลิงก์ไบนารีในโหมดคงที่ สำหรับ cc_library.link_static: ดูด้านล่าง โดยค่าเริ่มต้น ตัวเลือกนี้จะเปิดอยู่สำหรับ cc_binary และปิดอยู่สำหรับส่วนที่เหลือ หากเปิดใช้และนี่เป็นไบนารีหรือการทดสอบ ตัวเลือกนี้จะบอกเครื่องมือสร้างให้ลิงก์ใน .a แทน .so สำหรับไลบรารีผู้ใช้เมื่อเป็นไปได้ ไลบรารีของระบบ เช่น libc (แต่ไม่ใช่ไลบรารีรันไทม์ของ C/C++ ดูด้านล่าง) ยังคงลิงก์แบบไดนามิก เช่นเดียวกับไลบรารีที่ไม่มีไลบรารีแบบคงที่ ดังนั้นไฟล์ปฏิบัติการที่ได้จะยังคงลิงก์แบบไดนามิกอยู่ จึงส่วนใหญ่เป็นแบบคงที่ การลิงก์ไฟล์ปฏิบัติการมี 3 วิธีที่แตกต่างกันดังนี้ สถิติที่มีฟีเจอร์ลิงก์_สถิติแบบเต็ม ซึ่งลิงก์ทุกอย่างในแบบคงที่ เช่น "gcc -static foo.o libbar.a libbaz.a -lm" โหมดนี้เปิดใช้งานโดยระบุ fully_static_link ในแอตทริบิวต์ features สถิติซึ่งไลบรารีผู้ใช้ทั้งหมดลิงก์แบบคงที่ (หากมีเวอร์ชันคงที่) แต่ไลบรารีของระบบ (ยกเว้นไลบรารีรันไทม์ C/C++) มีการลิงก์แบบไดนามิก เช่น "gcc foo.o libfoo.a libbaz.a -lm" โหมดนี้เปิดใช้โดยระบุ linkstatic=True ไดนามิก (DYNAMIC) ซึ่งมีการลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันไดนามิกให้ใช้งาน) เช่น "gcc foo.o libfoo.so libbaz.so -lm" โหมดนี้เปิดใช้ด้วยการระบุ linkstatic=False หากใช้แอตทริบิวต์ linkstatic หรือ 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 รายการเดียว จะมี -D นำหน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์สำหรับเป้าหมายนี้ แต่ไม่ใช่ลงในการอ้างอิง
module_interfaces	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] รายการไฟล์ถือว่าเป็นอินเทอร์เฟซโมดูล C++20 C++ มาตรฐานไม่มีข้อจำกัดเกี่ยวกับนามสกุลไฟล์ของโมดูลอินเตอร์เฟซ ใช้ cppm ในไลบรารี GCC ใช้นามสกุลไฟล์ต้นฉบับใดก็ได้ MSVC ใช้ ixx การใช้งานได้รับการปกป้องโดยแฟล็ก --experimental_cpp_modules
strip_include_prefix	สตริง ค่าเริ่มต้นคือ "" คำนำหน้าที่จะตัดออกจากเส้นทางของส่วนหัวของกฎนี้ เมื่อตั้งค่าแล้ว ส่วนหัวในแอตทริบิวต์ hdrs ของกฎนี้จะสามารถเข้าถึงได้ในเส้นทางโดยการตัดคำนำหน้านี้ออก หากเป็นเส้นทางแบบสัมพัทธ์ ระบบจะใช้เส้นทางที่สัมพันธ์กับแพ็กเกจ หากเป็นเส้นทางสัมบูรณ์ ก็เข้าใจว่าเป็นเส้นทางที่สัมพันธ์กับที่เก็บ ระบบจะเพิ่มคำนำหน้าในแอตทริบิวต์ include_prefix หลังจากที่เลิกใช้คำนำหน้านี้ แอตทริบิวต์นี้ใช้ได้ตามกฎหมายภายใต้ third_party เท่านั้น
textual_hdrs	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] รายการไฟล์ส่วนหัวที่เผยแพร่โดยไลบรารีนี้ที่จะรวมเป็นข้อความโดยแหล่งที่มาในกฎที่เกี่ยวข้อง นี่เป็นตำแหน่งสำหรับการประกาศไฟล์ส่วนหัวที่ไม่สามารถคอมไพล์ได้ด้วยตัวเอง กล่าวคือ ไฟล์ต้นฉบับอื่นต้องรวมเป็นข้อความเสมอเพื่อสร้างโค้ดที่ถูกต้อง
win_def_file	ป้ายกำกับ ค่าเริ่มต้นคือ None ไฟล์ DEF ของ Windows ที่จะส่งไปยัง Linker แอตทริบิวต์นี้ควรใช้เมื่อ Windows เป็นแพลตฟอร์มเป้าหมายเท่านั้น ซึ่งใช้เพื่อ ส่งออกสัญลักษณ์ระหว่างการลิงก์ไลบรารีที่ใช้ร่วมกันได้

cc_proto_library

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

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

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

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

เช่น

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

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

proto_library(
    name = "foo_proto",
)

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

Attributes
name	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
deps	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] รายการกฎ proto_library สำหรับสร้างโค้ด C++

cc_shared_library

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

cc_shared_library(name, deps, additional_linker_inputs, compatible_with, deprecation, distribs, dynamic_deps, exec_compatible_with, exec_properties, experimental_disable_topo_sort_do_not_use_remove_before_7_0, 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 แบบคงที่ ซึ่งรายการหลังเป็นทรัพยากร Dependency แบบทรานซิทีฟ ไม่ได้ลิงก์ bar เนื่องจาก dynamic_dep bar_shared สร้างแบบไดนามิกให้อยู่แล้ว

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

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

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

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

ข้อผิดพลาด

Two shared libraries in dependencies export the same symbols.

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

Two shared libraries in dependencies link the same library statically

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

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

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

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

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

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

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

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

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

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

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

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

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

cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, 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() จะรวมการทดสอบ การทดสอบจะเป็น Wrapper แบบไบนารีรอบๆ โค้ดการทดสอบ

โดยค่าเริ่มต้น การทดสอบ C++ จะลิงก์แบบไดนามิก
หากต้องการลิงก์การทดสอบ 1 หน่วยแบบคงที่ ให้ระบุ 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) ลงใน Dep และอ้างอิงได้ใน linkopts
srcs	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] รายการไฟล์ C และ C++ ที่ประมวลผลเพื่อสร้างเป้าหมายไลบรารี ไฟล์เหล่านี้เป็นไฟล์ส่วนหัวและแหล่งที่มาของ C/C++ อาจเป็นไฟล์ที่ไม่ได้สร้าง (ซอร์สโค้ดปกติ) หรือสร้างขึ้น ระบบจะคอมไพล์ไฟล์ทั้งหมด .cc, .c และ .cpp ซึ่งอาจเป็นไฟล์ที่สร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน outs ของกฎอื่น cc_library นี้จะขึ้นอยู่กับกฎนั้นโดยอัตโนมัติ ไฟล์ As Signing ล้วน (.s, .asm) ไม่ได้รับการประมวลผลล่วงหน้าและมักสร้างขึ้นโดยใช้ Ascyclr ไฟล์แอสเซมบลีที่ประมวลผลล่วงหน้า (.S) จะได้รับการประมวลผลล่วงหน้าและโดยปกติจะสร้างโดยใช้คอมไพเลอร์ C/C++ ระบบจะไม่คอมไพล์ไฟล์ .h แต่แหล่งที่มาในกฎนี้จะรวมไฟล์ได้ ทั้งไฟล์ .cc และ .h จะมีส่วนหัวที่ระบุไว้ใน srcs เหล่านี้หรือใน hdrs ของกฎนี้หรือกฎใดก็ตามที่อยู่ในอาร์กิวเมนต์ deps ได้โดยตรง คุณต้องพูดถึงไฟล์ #included ทั้งหมดในแอตทริบิวต์ 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 เครื่องมือประกอบที่มีโปรเซสเซอร์ล่วงหน้าแบบ 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	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] ส่งต่อไฟล์เหล่านี้ไปยังคำสั่ง Linker C++ เช่น ไฟล์ .res ของ Windows ที่คอมไพล์แล้วอาจระบุที่นี่เพื่อฝังในเป้าหมายไบนารี
copts	รายการสตริง ค่าเริ่มต้นคือ [] เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งคอมไพล์ C++ ขึ้นอยู่กับการแทนที่ "MakeVariable" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ตามลำดับที่ระบุไปยัง COPTS ก่อนคอมไพล์เป้าหมายไบนารี แฟล็กจะมีผลต่อการคอมไพล์เป้าหมายนี้เท่านั้น โดยไม่รวมทรัพยากร Dependency ต่างๆ ดังนั้นโปรดระวังเกี่ยวกับไฟล์ส่วนหัวที่อยู่ที่อื่น เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้นอก third_party หากแพ็กเกจประกาศฟีเจอร์ no_copts_tokenization การแปลงข้อมูลเป็นโทเค็น Bourne Shell จะใช้กับสตริงที่ประกอบด้วยตัวแปร "Make" เดียวเท่านั้น
defines	รายการสตริง ค่าเริ่มต้นคือ [] รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" และการแปลงข้อมูลเป็นโทเค็นของ Bourne Shell แต่ละสตริงซึ่งต้องประกอบด้วยโทเค็นเชลล์ Bourne รายการเดียว ต้องมี -D นำหน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์ไปยังเป้าหมายนี้ รวมถึงกฎทุกข้อที่อ้างอิงสตริงนี้ โปรดใช้ความระมัดระวังเป็นอย่างยิ่ง เนื่องจากอาจส่งผลกระทบในวงกว้าง หากไม่แน่ใจ ให้เพิ่มกําหนดค่าให้กับ local_defines แทน
dynamic_deps	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] นี่เป็นทรัพยากร Dependency อื่นๆ ของ cc_shared_library ที่เป้าหมายปัจจุบันใช้งานอยู่ การติดตั้งใช้งาน cc_shared_library จะใช้รายการ dynamic_deps (หรือที่เรียกว่า dynamic_deps ของ dynamic_deps ของเป้าหมายปัจจุบัน) เพื่อตัดสินใจว่าไม่ควรลิงก์ cc_libraries ใดใน deps ทางอ้อม เนื่องจากมี cc_shared_library อื่นระบุไว้อยู่แล้ว
hdrs_check	สตริง ค่าเริ่มต้นคือ "" เลิกใช้งานแล้ว ไม่มีการดำเนินการ
includes	รายการสตริง ค่าเริ่มต้นคือ [] รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" ระบบจะเพิ่มสตริงแต่ละรายการด้วยเส้นทางแพ็กเกจและส่งไปยังเครื่องมือเชน C++ สำหรับการขยายผ่านฟีเจอร์ CROSSTOOL "include_paths" เครื่องมือเชนที่ทำงานบนระบบ POSIX ที่มีคำจำกัดความฟีเจอร์ทั่วไปจะสร้าง -isystem path_to_package/include_entry ซึ่งควรใช้กับไลบรารีของบุคคลที่สามที่ไม่สอดคล้องกับรูปแบบการเขียน #include ของ Google เท่านั้น ซึ่งต่างจาก COPTS ตรงที่จะเพิ่มแฟล็กเหล่านี้สำหรับกฎนี้และกฎทุกกฎที่อ้างอิงกฎดังกล่าว (หมายเหตุ: ไม่ใช่กฎเกณฑ์แต่อย่างใด) โปรดใช้ความระมัดระวังเป็นอย่างยิ่งเนื่องจากอาจทำให้เกิดผลกระทบอย่างมาก หากไม่แน่ใจ ให้เพิ่มแฟล็ก "-I" ลงใน COPTS แทน เส้นทาง include ที่เพิ่มเข้ามาจะรวมไฟล์ที่สร้างขึ้นและไฟล์ในโครงสร้างต้นทาง
link_extra_lib	ป้ายกำกับ ค่าเริ่มต้นคือ "@bazel_tools//tools/cpp:link_extra_lib" ควบคุมการลิงก์ไลบรารีเพิ่มเติม โดยค่าเริ่มต้น ไบนารีของ C++ จะลิงก์กับ //tools/cpp:link_extra_lib ซึ่งโดยค่าเริ่มต้นจะขึ้นอยู่กับแฟล็กป้ายกำกับ //tools/cpp:link_extra_libs หากไม่ได้ตั้งค่าสถานะ ไลบรารีนี้จะว่างเปล่าโดยค่าเริ่มต้น การตั้งค่าแฟล็กป้ายกำกับช่วยให้ลิงก์ทรัพยากร Dependency ที่ไม่บังคับได้ เช่น การลบล้างสัญลักษณ์ที่ไม่รัดกุม, ตัวดักจับสัญญาณสำหรับฟังก์ชันไลบรารีที่ใช้ร่วมกัน หรือไลบรารีรันไทม์พิเศษ (สำหรับการแทนที่ Malloc ให้ใช้ malloc หรือ --custom_malloc) การตั้งค่าแอตทริบิวต์นี้เป็น None จะปิดใช้ลักษณะการทำงานนี้
linkopts	รายการสตริง ค่าเริ่มต้นคือ [] เพิ่มแฟล็กเหล่านี้ลงในคำสั่ง Linker C++ ขึ้นอยู่กับการแทนที่ตัวแปร"Make" การแปลงเป็นโทเค็น Shell เบิร์นและการขยายป้ายกำกับ ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ลงใน LINKOPTS ก่อนลิงก์เป้าหมายไบนารี แต่ละองค์ประกอบในรายการที่ไม่ได้ขึ้นต้นด้วย $ หรือ - จะถือว่าเป็นป้ายกำกับของเป้าหมายใน deps รายการไฟล์ที่สร้างโดยเป้าหมายดังกล่าวจะต่อท้ายตัวเลือก Linker ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือไม่มีการประกาศใน deps
linkshared	บูลีน ค่าเริ่มต้นคือ False สร้างไลบรารีที่ใช้ร่วมกัน หากต้องการเปิดใช้แอตทริบิวต์นี้ ให้ใส่ linkshared=True ในกฎ ตัวเลือกนี้จะปิดอยู่โดยค่าเริ่มต้น การมี 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 วิธีที่แตกต่างกันดังนี้ สถิติที่มีฟีเจอร์ลิงก์_สถิติแบบเต็ม ซึ่งลิงก์ทุกอย่างในแบบคงที่ เช่น "gcc -static foo.o libbar.a libbaz.a -lm" โหมดนี้เปิดใช้งานโดยระบุ fully_static_link ในแอตทริบิวต์ features สถิติซึ่งไลบรารีผู้ใช้ทั้งหมดลิงก์แบบคงที่ (หากมีเวอร์ชันคงที่) แต่ไลบรารีของระบบ (ยกเว้นไลบรารีรันไทม์ C/C++) มีการลิงก์แบบไดนามิก เช่น "gcc foo.o libfoo.a libbaz.a -lm" โหมดนี้เปิดใช้โดยระบุ linkstatic=True ไดนามิก (DYNAMIC) ซึ่งมีการลิงก์ไลบรารีทั้งหมดแบบไดนามิก (หากมีเวอร์ชันไดนามิกให้ใช้งาน) เช่น "gcc foo.o libfoo.so libbaz.so -lm" โหมดนี้เปิดใช้ด้วยการระบุ linkstatic=False หากใช้แอตทริบิวต์ linkstatic หรือ 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 รายการเดียว จะมี -D นำหน้าและเพิ่มลงในบรรทัดคำสั่งของคอมไพล์สำหรับเป้าหมายนี้ แต่ไม่ใช่ลงในการอ้างอิง
malloc	ป้ายกำกับ ค่าเริ่มต้นคือ "@bazel_tools//tools/cpp:malloc" ลบล้างทรัพยากร Dependency เริ่มต้นใน Malloc โดยค่าเริ่มต้น ไบนารีของ C++ จะลิงก์กับ //tools/cpp:malloc ซึ่งเป็นไลบรารีที่ว่างเปล่า ดังนั้นไบนารีนั้นจะใช้ libc Malloc ป้ายกำกับนี้ต้องอ้างอิงถึง cc_library หากการคอมไพล์เป็นกฎที่ไม่ใช่ C++ ตัวเลือกนี้จะไม่มีผล ระบบจะละเว้นค่าของแอตทริบิวต์นี้หากระบุ linkshared=True
module_interfaces	รายการป้ายกำกับ ค่าเริ่มต้นคือ [] รายการไฟล์ถือว่าเป็นอินเทอร์เฟซโมดูล C++20 C++ มาตรฐานไม่มีข้อจำกัดเกี่ยวกับนามสกุลไฟล์ของโมดูลอินเตอร์เฟซ ใช้ cppm ในไลบรารี GCC ใช้นามสกุลไฟล์ต้นฉบับใดก็ได้ MSVC ใช้ 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, 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++ และโปรดดู หน้า นี้เพื่อดูการกำหนดค่า Toolchain ของ C++ อย่างละเอียดและเอกสารการเลือก Toolchain

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

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

Attributes
name	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
all_files	ป้ายกำกับ ต้องระบุ คอลเล็กชันของอาร์ติแฟกต์ cc_toolchain ทั้งหมด ระบบจะเพิ่มอาร์ติแฟกต์เหล่านี้เป็นอินพุตของการดำเนินการที่เกี่ยวข้องกับrules_cc ทั้งหมด (ยกเว้นการดำเนินการที่ใช้ชุดอาร์ติแฟกต์จากแอตทริบิวต์ด้านล่างที่แม่นยำยิ่งขึ้น) Bazel ถือว่า all_files เป็นชุดพิเศษของแอตทริบิวต์ที่มีอาร์ติแฟกต์อื่นๆ ทั้งหมด (เช่น การคอมไพล์ Linktamp ต้องใช้ทั้งไฟล์คอมไพล์และลิงก์ ดังนั้นจึงต้องใช้ all_files) นี่คือสิ่งที่ cc_toolchain.files มี และจะใช้โดยกฎ Starlark ทั้งหมดที่ใช้เครื่องมือเชน C++
ar_files	ป้ายกำกับ ค่าเริ่มต้นคือ None คอลเล็กชันของอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการเก็บถาวร
as_files	ป้ายกำกับ ค่าเริ่มต้นคือ None คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการประกอบ
compiler_files	ป้ายกำกับ ต้องระบุ คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการคอมไพล์
compiler_files_without_includes	ป้ายกำกับ ค่าเริ่มต้นคือ None การรวบรวมอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการคอมไพล์ในกรณีที่รองรับการค้นพบอินพุต (ปัจจุบันใช้ได้กับ Google เท่านั้น)
coverage_files	ป้ายกำกับ ค่าเริ่มต้นคือ None คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการเกี่ยวกับความครอบคลุม หากไม่ได้ระบุไว้ จะมีการใช้ไฟล์ all_files
dwp_files	ป้ายกำกับ ต้องระบุ คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการ dwp
dynamic_runtime_lib	ป้ายกำกับ ค่าเริ่มต้นคือ None อาร์ติแฟกต์ไลบรารีแบบไดนามิกสำหรับไลบรารีรันไทม์ C++ (เช่น libstdc++.so) ซึ่งจะใช้เมื่อเปิดใช้ฟีเจอร์ "static_link_cpp_runtimes" และเรากำลังลิงก์การขึ้นต่อกันแบบไดนามิก
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 ทั้งหมดที่จำเป็นสำหรับการดำเนินการนำออก
supports_header_parsing	บูลีน ค่าเริ่มต้นคือ False ตั้งค่าเป็น "จริง" เมื่อ cc_toolchain รองรับการดำเนินการแยกวิเคราะห์ส่วนหัว
supports_param_files	บูลีน ค่าเริ่มต้นคือ True ตั้งค่าเป็น "จริง" เมื่อ cc_toolchain รองรับการใช้ไฟล์พารามิเตอร์สำหรับการลิงก์การดำเนินการ
toolchain_config	ป้ายกำกับ ต้องระบุ ป้ายกำกับของกฎที่ระบุ cc_toolchain_config_info
toolchain_identifier	สตริง ค่าเริ่มต้นคือ "" ตัวระบุที่ใช้เพื่อจับคู่ cc_toolchain กับcrosstool_config.toolchain ที่เกี่ยวข้อง นี่เป็นวิธีที่แนะนำในการเชื่อมโยง cc_toolchain กับ CROSSTOOL.toolchain จนกว่าปัญหา #5380 จะได้รับการแก้ไข ซึ่งจะแทนที่ด้วยแอตทริบิวต์ toolchain_config (#5380)

cc_toolchain_suite

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

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

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

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

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 ที่มีโปรไฟล์ Profraw LLVM, .afdo สำหรับโปรไฟล์ AutoFDO, .xfdo สำหรับโปรไฟล์ XBinary ป้ายกำกับยังสามารถชี้ไปยังกฎ fdo_absolute_path_profile ได้ด้วย
proto_profile	ป้ายกำกับ ค่าเริ่มต้นคือ None ป้ายกำกับของโปรไฟล์ Protocolbuf

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