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

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

กฎ C / C

วันที่ รายงานปัญหา ดูแหล่งที่มา ตอนกลางคืน · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

กฎ

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) ลงใน Dependency แล้วอ้างอิงด้วย linkopts
`srcs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ C และ C ที่ประมวลผลเพื่อสร้างเป้าหมายไลบรารี ไฟล์เหล่านี้คือไฟล์ต้นทางและส่วนหัว C/C อย่างใดอย่างหนึ่ง (แหล่งที่มาปกติ) รหัส) หรือสร้าง ไฟล์ `.cc`, `.c` และ `.cpp` ทั้งหมดจะ ได้ ไฟล์เหล่านี้อาจสร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน `outs` ของกฎอื่นๆ `cc_library`นี้ จะขึ้นอยู่กับกฎนั้นโดยอัตโนมัติ ไฟล์ As Signing ทั้งหมด (.s, .asm) ไม่ได้ถูกประมวลผลล่วงหน้าและมักจะสร้างขึ้นโดยใช้ โปรแกรมประกอบ ไฟล์แอสเซมบลีที่ประมวลผลล่วงหน้า (.S) ได้รับการประมวลผลล่วงหน้าและมักสร้างขึ้น โดยใช้คอมไพเลอร์ C/C ไฟล์ `.h` จะไม่ได้รับการคอมไพล์ แต่จะพร้อมใช้งานสำหรับ การรวมตามแหล่งที่มาในกฎนี้ ทั้ง `.cc` และ ไฟล์ `.h` รายการสามารถมีส่วนหัวที่แสดงใน `srcs`เหล่านี้หรือใน`hdrs`ของกฎนี้หรือ กฎที่ระบุไว้ในอาร์กิวเมนต์ `deps` ไฟล์ `#include`d ทั้งหมดต้องมีการกล่าวถึงใน แอตทริบิวต์ `hdrs` ของรายการหรือที่อ้างอิง `cc_library` หรือควรแสดงอยู่ใน `srcs` หากเป็นแบบส่วนตัว ลงในไลบรารีนี้ โปรดดูที่ "การตรวจสอบการรวมส่วนหัว" สำหรับ คำอธิบายที่ละเอียดขึ้น ไฟล์ `.so`, `.lo` และ `.a` ไฟล์ที่คอมไพล์ไว้ล่วงหน้าแล้ว คลังของคุณอาจมีรายการเหล่านี้ `srcs` หาก URL ดังกล่าวใช้โค้ดของบุคคลที่สามซึ่งเราไม่ได้ใช้ มีซอร์สโค้ด หากแอตทริบิวต์ `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 ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" และ การแปลงข้อมูลเป็นโทเค็นของ Bourne Shell ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ตามลำดับที่ระบุให้กับ `COPTS` ก่อน กำลังคอมไพล์เป้าหมายไบนารี แฟล็กจะมีผลต่อการคอมไพล์เป้าหมายนี้เท่านั้น ไม่ใช่ ทรัพยากร Dependency ของไฟล์ดังกล่าว ดังนั้น โปรดระวังไฟล์ส่วนหัวที่อยู่ที่อื่นด้วย เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้นอก `third_party` หากแพ็กเกจแจ้งฟีเจอร์ `no_copts_tokenization` การแปลงข้อมูลเป็นโทเค็น Bourne Shell มีผลกับสตริงเท่านั้น ที่ประกอบด้วย "Make" เดียว ตัวแปร
`defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับ "ผู้ผลิต" การแทนที่ตัวแปรและ การแปลงข้อมูลเป็นโทเค็นของ 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`	String; ค่าเริ่มต้นคือ `""` เลิกใช้งานแล้ว ไม่มีการดำเนินการ
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" สตริงแต่ละรายการจะมีการเติมเส้นทางแพ็กเกจไว้ข้างหน้าและส่งไปยังเครื่องมือเชน C สำหรับ การขยายผ่าน "include_paths" CROSSTOOL เครื่องมือเชนที่ทำงานบนระบบ 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 ขึ้นอยู่กับ "ผู้ผลิต" การแทนที่ตัวแปร การแปลงข้อมูลเป็นโทเค็น Bourne Shell และ การขยายป้ายกำกับ ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ไปยัง `LINKOPTS` ก่อน การลิงก์เป้าหมายไบนารี องค์ประกอบของรายการนี้ที่ไม่ได้ขึ้นต้นด้วย `$` หรือ `-` จะเป็น เป็นป้ายกำกับของเป้าหมายใน `deps` รายการไฟล์ที่สร้างโดยเป้าหมายดังกล่าวจะต่อท้าย Linker ตัวเลือก ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือ ไม่มีการประกาศใน `deps`
`linkshared`	บูลีน ค่าเริ่มต้นคือ `False` สร้างไลบรารีที่ใช้ร่วมกัน หากต้องการเปิดใช้แอตทริบิวต์นี้ ให้ใส่ `linkshared=True` ในกฎ โดยค่าเริ่มต้น ตัวเลือกนี้ปิดอยู่ การมี Flag นี้แสดงว่ามีการลิงก์ด้วยแฟล็ก `-shared` ไปยัง `gcc` และไลบรารีที่ใช้ร่วมกันที่ได้เหมาะสมสำหรับการโหลดเข้าไปใน ตัวอย่างโปรแกรม Java อย่างไรก็ตาม สำหรับวัตถุประสงค์ของการสร้าง URL นี้จะไม่มีการเชื่อมโยงเข้ากับ ไบนารีแบบอิสระ เนื่องจากมีการสันนิษฐานว่าไลบรารีที่ใช้ร่วมกันที่สร้างด้วย โปรแกรมอื่นจะโหลดกฎ cc_binary ด้วยตัวเองเท่านั้น ดังนั้น ไม่ควรจะใช้แทน cc_library กฎ เราขอแนะนำให้หลีกเลี่ยงวิธีนี้ทั้งหมดเพื่อให้ปรับขนาดได้ และ เพียงแค่ให้ `java_library` อ้างอิงกฎ `cc_library` รายการ แทน หากคุณระบุทั้ง `linkopts=['-static']` และ `linkshared=True` คุณก็จะได้ชุดเครื่องมือสำเร็จรูปเพียงหน่วยเดียว หากคุณระบุทั้ง 2 อย่าง `linkstatic=True` และ `linkshared=True` คุณได้รับสิทธิ์ใช้บริการเดียว แบบครบวงจร
`linkstatic`	บูลีน ค่าเริ่มต้นคือ `True` สำหรับ `cc_binary` และ `cc_test`: ลิงก์ไบนารีในแบบคงที่ สำหรับ `cc_library.link_static`: ดูด้านล่าง โดยค่าเริ่มต้น ตัวเลือกนี้จะเปิดอยู่สำหรับ `cc_binary` และปิดอยู่สำหรับส่วนที่เหลือ หากเปิดใช้และนี่เป็นไบนารีหรือการทดสอบ ตัวเลือกนี้จะบอกให้เครื่องมือบิลด์ลิงก์ `.a` แทน `.so` สำหรับไลบรารีของผู้ใช้เมื่อเป็นไปได้ ไลบรารีระบบ เช่น libc (แต่ไม่ใช่ไลบรารีรันไทม์ C/C ดูด้านล่าง) ยังคงลิงก์แบบไดนามิก เช่นเดียวกับไลบรารีที่ จะไม่มีไลบรารีแบบคงที่ ดังนั้นไฟล์ปฏิบัติการที่ได้จะยังคง ดังนั้น จึงเป็นสิ่งส่วนใหญ่ การลิงก์ไฟล์ปฏิบัติการมี 3 วิธีที่แตกต่างกันดังนี้ STATIC ที่มีคุณลักษณะต่างๆ แบบเต็ม_static_link ซึ่งทุกอย่างมีการเชื่อมโยงแบบคงที่ เช่น "`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` ไดนามิก (ไลบรารีทั้งหมดจะมีการเชื่อมโยงแบบไดนามิก) (หากเวอร์ชันแบบไดนามิกคือ ใช้งานได้) เช่น "`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`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับ "ผู้ผลิต" การแทนที่ตัวแปรและ การแปลงข้อมูลเป็นโทเค็นของ 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`	String; ค่าเริ่มต้นคือ `""` นำรูปแบบการทำงานของคีย์เวิร์ดออกจากคำสั่งคอมไพล์ C ขึ้นอยู่กับ "ผู้ผลิต" แทน ระบบจะตีความค่าของแอตทริบิวต์นี้เป็นนิพจน์ทั่วไป `COPTS` ที่มีอยู่ก่อนหน้าซึ่งตรงกับนิพจน์ทั่วไปนี้ (รวมถึงค่าที่ระบุอย่างชัดแจ้งในแอตทริบิวต์ copts ของกฎ) จะถูกลบออกจาก `COPTS` เพื่อวัตถุประสงค์ในการรวบรวมกฎนี้ ไม่ควรต้องใช้หรือใช้แอตทริบิวต์นี้ ภายนอก `third_party` ค่าไม่ได้ประมวลผลล่วงหน้า ในลักษณะอื่นใดนอกเหนือจาก "ผู้ผลิต" การแทนที่ตัวแปร
`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 = 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 นี้ ไลบรารีที่คอมไพล์ไว้ล่วงหน้าแล้ว จะลิงก์ในไฟล์ออบเจ็กต์ทั้งหมดที่เก็บไว้ในไลบรารีแบบคงที่ แม้ว่าบางอันจะไม่มีสัญลักษณ์ที่ไบนารีอ้างอิงก็ตาม วิธีนี้มีประโยชน์หากโค้ดของคุณไม่ได้ถูกเรียกอย่างชัดแจ้งด้วยโค้ดใน ไบนารี เช่น หากโค้ดของคุณลงทะเบียนเพื่อให้รับการเรียกกลับ ที่ให้บริการโดยบางบริการ หาก Alwayslink ใช้ไม่ได้กับ VS 2017 ใน Windows นั่นเป็นเพราะ ปัญหาที่ทราบแล้ว โปรดอัปเกรด VS 2017 เป็นเวอร์ชันล่าสุด
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" สตริงแต่ละรายการจะมีการเติมเส้นทางแพ็กเกจไว้ข้างหน้าและส่งไปยังเครื่องมือเชน C สำหรับ การขยายผ่าน "include_paths" CROSSTOOL เครื่องมือเชนที่ทำงานบนระบบ 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 ขึ้นอยู่กับ "ผู้ผลิต" การแทนที่ตัวแปร การแปลงข้อมูลเป็นโทเค็น 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, 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 โดยขึ้นอยู่กับสิ่งที่ต้องการ

หากคุณสร้างบางอย่างโดยใช้การลิงก์แบบคงที่ซึ่งขึ้นอยู่กับ 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 Toolchain Bazel รองรับเฉพาะฟีเจอร์นี้กับคําแปลใน Unix และ macOS เท่านั้น

ตัวอย่าง

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


cc_library(
    name = "ast_inspector_lib",
    srcs = ["ast_inspector_lib.cc"],
    hdrs = ["ast_inspector_lib.h"],
    visibility = ["//visibility:public"],
    deps = ["//third_party/llvm/llvm/tools/clang:frontend"],
    # alwayslink as we want to be able to call things in this library at
    # debug time, even if they aren't used anywhere in the code.
    alwayslink = 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) ไม่ได้ถูกประมวลผลล่วงหน้าและมักจะสร้างขึ้นโดยใช้ โปรแกรมประกอบ ไฟล์แอสเซมบลีที่ประมวลผลล่วงหน้า (.S) ได้รับการประมวลผลล่วงหน้าและมักสร้างขึ้น โดยใช้คอมไพเลอร์ C/C ไฟล์ `.h` จะไม่ได้รับการคอมไพล์ แต่จะพร้อมใช้งานสำหรับ การรวมตามแหล่งที่มาในกฎนี้ ทั้ง `.cc` และ ไฟล์ `.h` รายการสามารถมีส่วนหัวที่แสดงใน `srcs`เหล่านี้หรือใน`hdrs`ของกฎนี้หรือ กฎที่ระบุไว้ในอาร์กิวเมนต์ `deps` ไฟล์ `#include`d ทั้งหมดต้องมีการกล่าวถึงใน แอตทริบิวต์ `hdrs` ของรายการหรือที่อ้างอิง `cc_library` หรือควรแสดงอยู่ใน `srcs` หากเป็นแบบส่วนตัว ลงในไลบรารีนี้ โปรดดูที่ "การตรวจสอบการรวมส่วนหัว" สำหรับ คำอธิบายที่ละเอียดขึ้น ไฟล์ `.so`, `.lo` และ `.a` ไฟล์ที่คอมไพล์ไว้ล่วงหน้าแล้ว คลังของคุณอาจมีรายการเหล่านี้ `srcs` หาก URL ดังกล่าวใช้โค้ดของบุคคลที่สามซึ่งเราไม่ได้ใช้ มีซอร์สโค้ด หากแอตทริบิวต์ `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 รายการละเว้น เป็นต้น ไฟล์ที่ระบุไว้ที่นี่จะสามารถใช้ในสำเนาที่มี $(location)
`additional_linker_inputs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` ส่งต่อไฟล์เหล่านี้ไปยังคำสั่ง Linker C ตัวอย่างเช่น ไฟล์ .res ของ Windows ที่คอมไพล์แล้วสามารถใส่ที่นี่เพื่อฝังใน เป้าหมายไบนารี
`alwayslink`	บูลีน ค่าเริ่มต้นคือ `False` หากเป็น 1 ไบนารีใดๆ ที่ขึ้นอยู่กับ (โดยตรงหรือโดยอ้อม) ใน C นี้ Library จะเชื่อมโยงในไฟล์ออบเจ็กต์ทั้งหมดของไฟล์ที่แสดงอยู่ใน `srcs` แม้ว่าบางแอตทริบิวต์จะไม่มีสัญลักษณ์ที่ไบนารีอ้างอิงอยู่ วิธีนี้มีประโยชน์หากโค้ดของคุณไม่ได้ถูกเรียกอย่างชัดแจ้งด้วยโค้ดใน ไบนารี เช่น หากโค้ดของคุณลงทะเบียนเพื่อให้รับการเรียกกลับ ที่ให้บริการโดยบางบริการ หาก Alwayslink ใช้ไม่ได้กับ VS 2017 ใน Windows นั่นเป็นเพราะ ปัญหาที่ทราบแล้ว โปรดอัปเกรด VS 2017 เป็นเวอร์ชันล่าสุด
`copts`	รายการสตริง ค่าเริ่มต้นคือ `[]` เพิ่มตัวเลือกเหล่านี้ลงในคำสั่งคอมไพล์ C ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" และ การแปลงข้อมูลเป็นโทเค็นของ Bourne Shell ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ตามลำดับที่ระบุให้กับ `COPTS` ก่อน กำลังคอมไพล์เป้าหมายไบนารี แฟล็กจะมีผลต่อการคอมไพล์เป้าหมายนี้เท่านั้น ไม่ใช่ ทรัพยากร Dependency ของไฟล์ดังกล่าว ดังนั้น โปรดระวังไฟล์ส่วนหัวที่อยู่ที่อื่นด้วย เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้นอก `third_party` หากแพ็กเกจแจ้งฟีเจอร์ `no_copts_tokenization` การแปลงข้อมูลเป็นโทเค็น Bourne Shell มีผลกับสตริงเท่านั้น ที่ประกอบด้วย "Make" เดียว ตัวแปร
`defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับ "ผู้ผลิต" การแทนที่ตัวแปรและ การแปลงข้อมูลเป็นโทเค็นของ Bourne Shell แต่ละสตริง ซึ่งต้องประกอบด้วยโทเค็นเชลล์ Bourne เดี่ยว มีการเพิ่ม `-D` ไว้ข้างหน้า และเพิ่มลงในบรรทัดคำสั่งคอมไพล์ไปยังเป้าหมายนี้ รวมทั้งกฎทุกกฎที่ขึ้นอยู่กับกฎนั้น โปรดระมัดระวังให้มาก เนื่องจาก ที่ส่งผลกระทบในวงกว้าง หากไม่แน่ใจ ให้เพิ่มกําหนดค่าให้กับ `local_defines` แทน
`hdrs_check`	String; ค่าเริ่มต้นคือ `""` เลิกใช้งานแล้ว ไม่มีการดำเนินการ
`implementation_deps`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการของไลบรารีอื่นๆ ที่เป้าหมายไลบรารีอิงตาม ต่างจาก `deps` ส่วนหัว และระบุเส้นทางของไลบรารีเหล่านี้ (รวมถึงเส้นทางทั้งหมดของไลบรารี deps สับเปลี่ยน) จะใช้สำหรับการรวบรวมไลบรารีนี้เท่านั้น ไม่รวมถึงไลบรารีที่ ต้องพึ่งพาสิ่งนั้น ไลบรารีที่ระบุด้วย `implementation_deps` ยังคงลิงก์อยู่ใน เป้าหมายไบนารีที่ขึ้นอยู่กับไลบรารีนี้ สำหรับตอนนี้ การใช้งานจะถูกจำกัดไว้ที่ cc_libraries และได้รับการปกป้องโดย Flag `--experimental_cc_implementation_deps`
`include_prefix`	String; ค่าเริ่มต้นคือ `""` คำนำหน้าที่จะเพิ่มลงในเส้นทางของส่วนหัวของกฎนี้ เมื่อตั้งค่าแล้ว ส่วนหัวในแอตทริบิวต์ `hdrs` ของกฎนี้จะเข้าถึงได้ at คือค่าของแอตทริบิวต์นี้ที่เพิ่มไว้ข้างหน้าเส้นทางที่สัมพันธ์กับที่เก็บ ระบบนำคำนำหน้าในแอตทริบิวต์ `strip_include_prefix` ออกก่อนหน้านั้น เพิ่มคำนำหน้าแล้ว แอตทริบิวต์นี้ใช้ได้ตามกฎหมายภายใต้ `third_party` เท่านั้น
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" สตริงแต่ละรายการจะมีการเติมเส้นทางแพ็กเกจไว้ข้างหน้าและส่งไปยังเครื่องมือเชน C สำหรับ การขยายผ่าน "include_paths" CROSSTOOL เครื่องมือเชนที่ทำงานบนระบบ POSIX ที่มีคำจำกัดความคุณลักษณะทั่วไปจะ `-isystem path_to_package/include_entry` ควรใช้การตั้งค่านี้สำหรับไลบรารีของบุคคลที่สามที่ ไม่เป็นไปตามรูปแบบการเขียน #include ของ Google กฎนี้ต่างจาก COPTS ตรงที่เพิ่มแฟล็กเหล่านี้ และทุกกฎที่เกี่ยวข้อง (หมายเหตุ: ไม่ใช่กฎเกณฑ์แต่อย่างใด) เป็น ระมัดระวังให้มาก เนื่องจากอาจส่งผลกระทบเป็นวงกว้าง หากไม่แน่ใจ ให้เพิ่ม "-I" แจ้งว่าเป็น COPTS แทน เส้นทาง `include` ที่เพิ่มเข้ามาจะรวมไฟล์ที่สร้างขึ้นและ ในโครงสร้างซอร์ส
`linkopts`	รายการสตริง ค่าเริ่มต้นคือ `[]` โปรดดู `cc_binary.linkopts` แอตทริบิวต์ `linkopts` ยังมีผลกับเป้าหมายที่ ขึ้นอยู่กับไลบรารีนี้โดยตรงหรือโดยอ้อมผ่านทาง `deps` (หรือผ่านแอตทริบิวต์อื่นๆ ที่ได้รับการปฏิบัติในลักษณะเดียวกัน: `malloc` ของ `cc_binary`) การขึ้นต่อกัน linkopts จะมีความสำคัญเหนือกว่า linkopts ที่อ้างอิง (นั่นคือ linkopt ของทรัพยากร Dependency อีกด้วย ปรากฏภายหลังในบรรทัดคำสั่ง) 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 ที่ระบุลงในไฟล์สุดท้ายพร้อมกัน 2. ต้องใช้กลเม็ดนี้เพื่อใช้การประทับเวลา ข้อมูลลงในไบนารี หากเราคอมไพล์ไฟล์ต้นฉบับไปยัง ตามปกติ การประทับเวลาอาจไม่ถูกต้อง การคอมไพล์ Linktamp อาจไม่มีชุดของ แฟล็กคอมไพเลอร์ ดังนั้นจึงไม่ควรขึ้นอยู่กับสถานะใดเป็นพิเศษ ส่วนหัว ตัวเลือกคอมไพเลอร์ หรือตัวแปรบิลด์อื่นๆ ควรใช้ตัวเลือกนี้ใน แพ็กเกจ `base`
`linkstatic`	บูลีน ค่าเริ่มต้นคือ `False` สำหรับ `cc_binary` และ `cc_test`: ลิงก์ไบนารีในแบบคงที่ สำหรับ `cc_library.link_static`: ดูด้านล่าง โดยค่าเริ่มต้น ตัวเลือกนี้จะเปิดอยู่สำหรับ `cc_binary` และปิดอยู่สำหรับส่วนที่เหลือ หากเปิดใช้และนี่เป็นไบนารีหรือการทดสอบ ตัวเลือกนี้จะบอกให้เครื่องมือบิลด์ลิงก์ `.a` แทน `.so` สำหรับไลบรารีของผู้ใช้เมื่อเป็นไปได้ ไลบรารีระบบ เช่น libc (แต่ไม่ใช่ไลบรารีรันไทม์ C/C ดูด้านล่าง) ยังคงลิงก์แบบไดนามิก เช่นเดียวกับไลบรารีที่ จะไม่มีไลบรารีแบบคงที่ ดังนั้นไฟล์ปฏิบัติการที่ได้จะยังคง ดังนั้น จึงเป็นสิ่งส่วนใหญ่ การลิงก์ไฟล์ปฏิบัติการมี 3 วิธีที่แตกต่างกันดังนี้ STATIC ที่มีคุณลักษณะต่างๆ แบบเต็ม_static_link ซึ่งทุกอย่างมีการเชื่อมโยงแบบคงที่ เช่น "`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` ไดนามิก (ไลบรารีทั้งหมดจะมีการเชื่อมโยงแบบไดนามิก) (หากเวอร์ชันแบบไดนามิกคือ ใช้งานได้) เช่น "`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`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับ "ผู้ผลิต" การแทนที่ตัวแปรและ การแปลงข้อมูลเป็นโทเค็นของ Bourne Shell แต่ละสตริง ซึ่งต้องประกอบด้วยโทเค็นเชลล์ Bourne เดี่ยว มีการเพิ่ม `-D` ไว้ข้างหน้า และเพิ่มลงในบรรทัดคำสั่งคอมไพล์สำหรับเป้าหมายนี้ แต่ไม่ใช่เครือข่ายที่เกี่ยวข้อง
`module_interfaces`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ถือว่าเป็นอินเทอร์เฟซโมดูล C 20 C มาตรฐานไม่มีข้อจำกัดเกี่ยวกับนามสกุลไฟล์ของโมดูลอินเตอร์เฟซ ใช้ cppm ในไลบรารี GCC ใช้นามสกุลไฟล์ต้นฉบับใดก็ได้ MSVC ใช้ ixx การใช้งานได้รับการปกป้องโดยธง `--experimental_cpp_modules`
`strip_include_prefix`	String; ค่าเริ่มต้นคือ `""` คำนำหน้าที่จะตัดออกจากเส้นทางของส่วนหัวของกฎนี้ เมื่อตั้งค่าแล้ว ส่วนหัวในแอตทริบิวต์ `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 ซึ่งเป็นการขึ้นต่อกันแบบสับเปลี่ยน ไม่ได้ผล ลิงก์ 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.`

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

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

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

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

`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 และอาศัยเป้าหมายจากไดนามิก ทรัพยากร Dependency หรือตรวจสอบว่า 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 คุณต้องส่ง Flager ของ 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 ไปยังเป้าหมายเหล่านั้น Dependency Edge ควรสร้างโดย `deps` แทน รายการใน เป็นสตริงเท่านั้น โปรดทราบว่าเมื่อวางเป้าหมายในแอตทริบิวต์นี้ นี่ถือเป็นการกล่าวอ้างว่าไลบรารีที่ใช้ร่วมกันส่งออกสัญลักษณ์จากเป้าหมายนั้น ตรรกะ `cc_shared_library` ไม่ได้มีหน้าที่บอก Linker ว่า ควรส่งออกสัญลักษณ์ ระบบอนุญาตให้ใช้ไวยากรณ์ต่อไปนี้ `//foo:__package__` เพื่อรวมเป้าหมายใน foo/BUILD `//foo:__subpackages__` เพื่อรวมเป้าหมายใน foo/BUILD หรือเป้าหมายอื่นๆ แพ็กเกจด้านล่าง foo/ เช่น foo/bar/BUILD
`roots`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]`
`shared_lib_name`	String; ค่าเริ่มต้นคือ `""` โดยค่าเริ่มต้น cc_shared_library จะใช้ชื่อสำหรับไฟล์เอาต์พุตไลบรารีที่ใช้ร่วมกันตาม ชื่อเป้าหมายและแพลตฟอร์ม ซึ่งรวมถึงส่วนขยายและบางครั้งเป็นคำนำหน้า บางครั้งคุณอาจไม่ต้องการชื่อเริ่มต้น เช่น เมื่อโหลดไลบรารีที่ใช้ร่วมกันของ C สำหรับ Python นั้น คำนำหน้า lib* เริ่มต้นมักจะไม่เป็นที่ต้องการ ซึ่งในกรณีนี้คุณสามารถใช้ เพื่อเลือกชื่อที่กำหนดเอง
`static_deps`	รายการสตริง ค่าเริ่มต้นคือ `[]`
`user_link_flags`	รายการสตริง ค่าเริ่มต้นคือ `[]` แฟล็กเพิ่มเติมที่คุณอาจต้องการส่งไปยัง Linker ตัวอย่างเช่น เพื่อทำให้ Linker รับรู้ถึงสคริปต์ Linker ที่ส่งผ่าน more_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)

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

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

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

`linkdeps`

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

`linkopts`

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

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

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

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

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

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

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

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

Attributes

name

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

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

deps

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

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

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

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) ลงใน Dependency แล้วอ้างอิงด้วย linkopts
`srcs`	รายการป้ายกำกับ ค่าเริ่มต้นคือ `[]` รายการไฟล์ C และ C ที่ประมวลผลเพื่อสร้างเป้าหมายไลบรารี ไฟล์เหล่านี้คือไฟล์ต้นทางและส่วนหัว C/C อย่างใดอย่างหนึ่ง (แหล่งที่มาปกติ) รหัส) หรือสร้าง ไฟล์ `.cc`, `.c` และ `.cpp` ทั้งหมดจะ ได้ ไฟล์เหล่านี้อาจสร้างขึ้น หากไฟล์ที่มีชื่ออยู่ใน `outs` ของกฎอื่นๆ `cc_library`นี้ จะขึ้นอยู่กับกฎนั้นโดยอัตโนมัติ ไฟล์ As Signing ทั้งหมด (.s, .asm) ไม่ได้ถูกประมวลผลล่วงหน้าและมักจะสร้างขึ้นโดยใช้ โปรแกรมประกอบ ไฟล์แอสเซมบลีที่ประมวลผลล่วงหน้า (.S) ได้รับการประมวลผลล่วงหน้าและมักสร้างขึ้น โดยใช้คอมไพเลอร์ C/C ไฟล์ `.h` จะไม่ได้รับการคอมไพล์ แต่จะพร้อมใช้งานสำหรับ การรวมตามแหล่งที่มาในกฎนี้ ทั้ง `.cc` และ ไฟล์ `.h` รายการสามารถมีส่วนหัวที่แสดงใน `srcs`เหล่านี้หรือใน`hdrs`ของกฎนี้หรือ กฎที่ระบุไว้ในอาร์กิวเมนต์ `deps` ไฟล์ `#include`d ทั้งหมดต้องมีการกล่าวถึงใน แอตทริบิวต์ `hdrs` ของรายการหรือที่อ้างอิง `cc_library` หรือควรแสดงอยู่ใน `srcs` หากเป็นแบบส่วนตัว ลงในไลบรารีนี้ โปรดดูที่ "การตรวจสอบการรวมส่วนหัว" สำหรับ คำอธิบายที่ละเอียดขึ้น ไฟล์ `.so`, `.lo` และ `.a` ไฟล์ที่คอมไพล์ไว้ล่วงหน้าแล้ว คลังของคุณอาจมีรายการเหล่านี้ `srcs` หาก URL ดังกล่าวใช้โค้ดของบุคคลที่สามซึ่งเราไม่ได้ใช้ มีซอร์สโค้ด หากแอตทริบิวต์ `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 ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" และ การแปลงข้อมูลเป็นโทเค็นของ Bourne Shell ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ตามลำดับที่ระบุให้กับ `COPTS` ก่อน กำลังคอมไพล์เป้าหมายไบนารี แฟล็กจะมีผลต่อการคอมไพล์เป้าหมายนี้เท่านั้น ไม่ใช่ ทรัพยากร Dependency ของไฟล์ดังกล่าว ดังนั้น โปรดระวังไฟล์ส่วนหัวที่อยู่ที่อื่นด้วย เส้นทางทั้งหมดควรสัมพันธ์กับพื้นที่ทำงาน ไม่ใช่แพ็กเกจปัจจุบัน ไม่ควรต้องใช้แอตทริบิวต์นี้นอก `third_party` หากแพ็กเกจแจ้งฟีเจอร์ `no_copts_tokenization` การแปลงข้อมูลเป็นโทเค็น Bourne Shell มีผลกับสตริงเท่านั้น ที่ประกอบด้วย "Make" เดียว ตัวแปร
`defines`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับ "ผู้ผลิต" การแทนที่ตัวแปรและ การแปลงข้อมูลเป็นโทเค็นของ 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`	String; ค่าเริ่มต้นคือ `""` เลิกใช้งานแล้ว ไม่มีการดำเนินการ
`includes`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการไดเรกทอรีรวมที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับการแทนที่ "Makeตัวแปร" สตริงแต่ละรายการจะมีการเติมเส้นทางแพ็กเกจไว้ข้างหน้าและส่งไปยังเครื่องมือเชน C สำหรับ การขยายผ่าน "include_paths" CROSSTOOL เครื่องมือเชนที่ทำงานบนระบบ 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 ขึ้นอยู่กับ "ผู้ผลิต" การแทนที่ตัวแปร การแปลงข้อมูลเป็นโทเค็น Bourne Shell และ การขยายป้ายกำกับ ระบบจะเพิ่มแต่ละสตริงในแอตทริบิวต์นี้ไปยัง `LINKOPTS` ก่อน การลิงก์เป้าหมายไบนารี องค์ประกอบของรายการนี้ที่ไม่ได้ขึ้นต้นด้วย `$` หรือ `-` จะเป็น เป็นป้ายกำกับของเป้าหมายใน `deps` รายการไฟล์ที่สร้างโดยเป้าหมายดังกล่าวจะต่อท้าย Linker ตัวเลือก ระบบจะรายงานข้อผิดพลาดหากป้ายกำกับไม่ถูกต้องหรือ ไม่มีการประกาศใน `deps`
`linkshared`	บูลีน ค่าเริ่มต้นคือ `False` สร้างไลบรารีที่ใช้ร่วมกัน หากต้องการเปิดใช้แอตทริบิวต์นี้ ให้ใส่ `linkshared=True` ในกฎ โดยค่าเริ่มต้น ตัวเลือกนี้ปิดอยู่ การมี Flag นี้แสดงว่ามีการลิงก์ด้วยแฟล็ก `-shared` ไปยัง `gcc` และไลบรารีที่ใช้ร่วมกันที่ได้เหมาะสมสำหรับการโหลดเข้าไปใน ตัวอย่างโปรแกรม Java อย่างไรก็ตาม สำหรับวัตถุประสงค์ของการสร้าง URL นี้จะไม่มีการเชื่อมโยงเข้ากับ ไบนารีแบบอิสระ เนื่องจากมีการสันนิษฐานว่าไลบรารีที่ใช้ร่วมกันที่สร้างด้วย โปรแกรมอื่นจะโหลดกฎ cc_binary ด้วยตัวเองเท่านั้น ดังนั้น ไม่ควรจะใช้แทน cc_library กฎ เราขอแนะนำให้หลีกเลี่ยงวิธีนี้ทั้งหมดเพื่อให้ปรับขนาดได้ และ เพียงแค่ให้ `java_library` อ้างอิงกฎ `cc_library` รายการ แทน หากคุณระบุทั้ง `linkopts=['-static']` และ `linkshared=True` คุณก็จะได้ชุดเครื่องมือสำเร็จรูปเพียงหน่วยเดียว หากคุณระบุทั้ง 2 อย่าง `linkstatic=True` และ `linkshared=True` คุณได้รับสิทธิ์ใช้บริการเดียว แบบครบวงจร
`linkstatic`	บูลีน ค่าเริ่มต้นคือ `False` สำหรับ `cc_binary` และ `cc_test`: ลิงก์ไบนารีในแบบคงที่ สำหรับ `cc_library.link_static`: ดูด้านล่าง โดยค่าเริ่มต้น ตัวเลือกนี้จะเปิดอยู่สำหรับ `cc_binary` และปิดอยู่สำหรับส่วนที่เหลือ หากเปิดใช้และนี่เป็นไบนารีหรือการทดสอบ ตัวเลือกนี้จะบอกให้เครื่องมือบิลด์ลิงก์ `.a` แทน `.so` สำหรับไลบรารีของผู้ใช้เมื่อเป็นไปได้ ไลบรารีระบบ เช่น libc (แต่ไม่ใช่ไลบรารีรันไทม์ C/C ดูด้านล่าง) ยังคงลิงก์แบบไดนามิก เช่นเดียวกับไลบรารีที่ จะไม่มีไลบรารีแบบคงที่ ดังนั้นไฟล์ปฏิบัติการที่ได้จะยังคง ดังนั้น จึงเป็นสิ่งส่วนใหญ่ การลิงก์ไฟล์ปฏิบัติการมี 3 วิธีที่แตกต่างกันดังนี้ STATIC ที่มีคุณลักษณะต่างๆ แบบเต็ม_static_link ซึ่งทุกอย่างมีการเชื่อมโยงแบบคงที่ เช่น "`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` ไดนามิก (ไลบรารีทั้งหมดจะมีการเชื่อมโยงแบบไดนามิก) (หากเวอร์ชันแบบไดนามิกคือ ใช้งานได้) เช่น "`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`	รายการสตริง ค่าเริ่มต้นคือ `[]` รายการกำหนดที่จะเพิ่มลงในบรรทัดคอมไพล์ ขึ้นอยู่กับ "ผู้ผลิต" การแทนที่ตัวแปรและ การแปลงข้อมูลเป็นโทเค็นของ 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`	String; ค่าเริ่มต้นคือ `""` นำรูปแบบการทำงานของคีย์เวิร์ดออกจากคำสั่งคอมไพล์ C ขึ้นอยู่กับ "ผู้ผลิต" แทน ระบบจะตีความค่าของแอตทริบิวต์นี้เป็นนิพจน์ทั่วไป `COPTS` ที่มีอยู่ก่อนหน้าซึ่งตรงกับนิพจน์ทั่วไปนี้ (รวมถึงค่าที่ระบุอย่างชัดแจ้งในแอตทริบิวต์ copts ของกฎ) จะถูกลบออกจาก `COPTS` เพื่อวัตถุประสงค์ในการรวบรวมกฎนี้ ไม่ควรต้องใช้หรือใช้แอตทริบิวต์นี้ ภายนอก `third_party` ค่าไม่ได้ประมวลผลล่วงหน้า ในลักษณะอื่นใดนอกเหนือจาก "ผู้ผลิต" การแทนที่ตัวแปร
`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 ดูเพิ่มเติม เพจ สำหรับการกำหนดค่า Toolchain ของ C อย่างละเอียดและเอกสารการเลือก Toolchain

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

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

Attributes
`name`	ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้
`all_files`	ป้ายกำกับ ต้องระบุ คอลเล็กชันของอาร์ติแฟกต์ cc_toolchain ทั้งหมด ระบบจะเพิ่มอาร์ติแฟกต์เหล่านี้เป็นอินพุตสำหรับ การดำเนินการที่เกี่ยวข้องกับ Rules_cc (ยกเว้นการดำเนินการที่ใช้ชุดของ อาร์ติแฟกต์จากแอตทริบิวต์ด้านล่าง) Bazel ถือว่า `all_files` เป็นซูเปอร์เซ็ต ของแอตทริบิวต์ที่ให้อาร์ติแฟกต์อื่นๆ ทั้งหมด (เช่น การคอมไพล์ Linktamp จำเป็นต้องมีทั้งการคอมไพล์ และลิงก์ไฟล์ ดังนั้นจึงใช้เวลา `all_files`) นี่คือข้อมูลที่ `cc_toolchain.files` มี และ Starlark ทุกคนใช้ โดยใช้ Toolchain ของ C
`ar_files`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` คอลเล็กชันของอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการเก็บถาวร
`as_files`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการประกอบ
`compiler_files`	ป้ายกำกับ ต้องระบุ คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการคอมไพล์
`compiler_files_without_includes`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการคอมไพล์ในกรณีที่มี รองรับการค้นพบอินพุต (ปัจจุบันใช้ได้กับ Google เท่านั้น)
`coverage_files`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการเกี่ยวกับความครอบคลุม หากไม่ได้ระบุ "all_files"
`dwp_files`	ป้ายกำกับ ต้องระบุ คอลเล็กชันอาร์ติแฟกต์ cc_toolchain ทั้งหมดที่จำเป็นสำหรับการดำเนินการ dwp
`dynamic_runtime_lib`	ป้ายกำกับ ค่าเริ่มต้นคือ `None` อาร์ติแฟกต์ไลบรารีแบบไดนามิกสำหรับไลบรารีรันไทม์ C (เช่น libstdc .so) จะมีการใช้ข้อมูลนี้เมื่อ "static_link_cpp_runtimes" เปิดใช้งานฟีเจอร์แล้ว และเรากำลังเชื่อมโยง ทรัพยากร Dependency แบบไดนามิก
`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`	String; ค่าเริ่มต้นคือ `""` ตัวระบุที่ใช้เพื่อจับคู่ cc_toolchain กับตัวระบุ crosstool_config.toolchain. จนกว่าปัญหา #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 ที่มีโปรไฟล์ Profraw LLVM, .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_proto_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`