C / C++ नियम

नाइटली रिलीज़ · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

नियम

cc_binary
cc_import
cc_library
cc_shared_library
cc_static_library
cc_test
cc_toolchain
fdo_prefetch_hints
fdo_profile
memprof_profile
propeller_optimize

cc_binary

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

इससे एक एक्ज़ीक्यूटेबल बाइनरी बनती है.

टारगेट का name, सोर्स फ़ाइल के नाम के जैसा होना चाहिए. यह सोर्स फ़ाइल, ऐप्लिकेशन का मुख्य एंट्री पॉइंट होती है. इसमें एक्सटेंशन शामिल नहीं होना चाहिए. उदाहरण के लिए, अगर आपका एंट्री पॉइंट main.cc में है, तो आपका नाम main होना चाहिए.

इंप्लिसिट आउटपुट टारगेट

name.stripped (सिर्फ़ अनुरोध करने पर बनाया जाता है): बाइनरी का स्ट्रिप्ड वर्शन. डीबग सिंबल हटाने के लिए, बाइनरी पर strip -g चलाया जाता है. कमांड लाइन पर --stripopt=-foo का इस्तेमाल करके, स्ट्रिप के अतिरिक्त विकल्प दिए जा सकते हैं.
name.dwp (सिर्फ़ अनुरोध करने पर बनाया जाता है): अगर Fission चालू है, तो यह एक डीबग जानकारी वाला पैकेज होता है. यह दूर से डिप्लॉय किए गए बाइनरी को डीबग करने के लिए सही होता है. अन्यथा: एक खाली फ़ाइल.

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये `cc_library` या `objc_library` टारगेट हो सकते हैं. लिंकर स्क्रिप्ट (.lds) को deps में रखने और उन्हें `linkopts` में रेफ़रंस करने की अनुमति भी है. हालांकि, कृपया इस मामले में `additional_linker_inputs` का इस्तेमाल करें.
`srcs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है C और C++ फ़ाइलों की सूची, जिन्हें लाइब्रेरी टारगेट बनाने के लिए प्रोसेस किया जाता है. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये जनरेट नहीं की गई हैं (सामान्य सोर्स कोड) या जनरेट की गई हैं. सभी `.cc`, `.c`, और `.cpp` फ़ाइलों को कंपाइल किया जाएगा. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर किसी नाम वाली फ़ाइल, किसी दूसरे नियम के `outs` में है, तो यह `cc_library` अपने-आप उस दूसरे नियम पर निर्भर करेगा. असेंबलर फ़ाइलों (.s, .asm) को पहले से प्रोसेस नहीं किया जाता है. इन्हें आम तौर पर असेंबलर का इस्तेमाल करके बनाया जाता है. प्रीप्रोसेस की गई असेंबली फ़ाइलों (.S) को प्रीप्रोसेस किया जाता है. इन्हें आम तौर पर C/C++ कंपाइलर का इस्तेमाल करके बनाया जाता है. `.h` फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, यह इस नियम के तहत आने वाले स्रोतों के लिए उपलब्ध रहेगी. `.cc` और `.h`, दोनों तरह की फ़ाइलों में, इन `srcs` में या इस नियम के `hdrs` में या `deps` आर्ग्युमेंट में दिए गए किसी भी नियम में शामिल हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी `#include`d फ़ाइलों का ज़िक्र, इस या रेफ़र की गई `cc_library` नियमों के `hdrs` एट्रिब्यूट में किया जाना चाहिए. अगर ये फ़ाइलें इस लाइब्रेरी के लिए निजी हैं, तो इन्हें `srcs` में शामिल किया जाना चाहिए. ज़्यादा जानकारी के लिए, "हेडर शामिल करने की जांच" देखें. `.so`, `.lo`, और `.a` फ़ाइलें, पहले से कंपाइल की गई फ़ाइलें हैं. अगर आपकी लाइब्रेरी में तीसरे पक्ष का ऐसा कोड इस्तेमाल किया गया है जिसका सोर्स कोड हमारे पास नहीं है, तो हो सकता है कि आपकी लाइब्रेरी में ये `srcs` के तौर पर मौजूद हों. अगर `srcs` एट्रिब्यूट में किसी दूसरे नियम का लेबल शामिल है, तो `cc_library`, कंपाइल करने के लिए उस नियम की आउटपुट फ़ाइलों को सोर्स फ़ाइलों के तौर पर इस्तेमाल करेगा. यह सोर्स कोड को एक बार जनरेट करने के लिए काम आता है. अगर आपको इसका इस्तेमाल कभी-कभी से ज़्यादा बार करना है, तो Starlark नियम क्लास लागू करना और `cc_common` एपीआई का इस्तेमाल करना बेहतर होता है `srcs` के लिए इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: C और C++ सोर्स फ़ाइलें: `.c`, `.cc`, `.cpp`, `.cxx`, `.c++`, `.C` C और C++ हेडर फ़ाइलें: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` सी प्रीप्रोसेसर के साथ असेंबलर: `.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`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है ऐसी डिपेंडेंसी जो सिर्फ़ C++ लिंकर कमांड के लिए उपलब्ध कराई जाती हैं. `deps` को कंपाइल करने और लिंक करने की डिपेंडेंसी, दोनों के लिए बनाया गया है. वहीं, `additional_linker_inputs` को सिर्फ़ लिंक करने की डिपेंडेंसी के लिए बनाया गया है. यह ऐसी डिपेंडेंसी का सिग्नल देता है जो सिर्फ़ लिंक करने के लिए ज़रूरी है. उदाहरण के लिए, `linkopts` में रेफ़र की गई फ़ाइलें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.
`conlyopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इन विकल्पों को C कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.
`copts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है C/C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, दिए गए क्रम में `COPTS` में जोड़ा जाता है. इसके बाद, बाइनरी टारगेट को कंपाइल किया जाता है. ये फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, इसकी डिपेंडेंसी के लिए नहीं. इसलिए, किसी दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस के हिसाब से होने चाहिए. इस एट्रिब्यूट की ज़रूरत `third_party` के बाहर नहीं होनी चाहिए. अगर पैकेज में सुविधा `no_copts_tokenization` के बारे में बताया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.
`cxxopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.
`defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस और इससे जुड़े सभी टारगेट की कंपाइल लाइन में जोड़ने के लिए, डिफ़ाइन की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शेल टोकन होना चाहिए. इसे `-D` से पहले जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. इसके अलावा, इसे इस पर निर्भर हर नियम में भी जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. इस टारगेट पर निर्भर रहने वाले हर टारगेट में, परिभाषाएं जोड़ी जाती हैं. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय `local_defines` में वैल्यू तय करें.
`dynamic_deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है ये अन्य `cc_shared_library` डिपेंडेंसी हैं, जिन पर मौजूदा टारगेट निर्भर करता है. `cc_shared_library` को लागू करने के लिए, `dynamic_deps` की सूची का इस्तेमाल किया जाएगा.इसमें `dynamic_deps` (ट्रांज़िटिव तौर पर, यानी कि मौजूदा टारगेट के `dynamic_deps` का `dynamic_deps` भी) शामिल है. इससे यह तय किया जा सकेगा कि ट्रांज़िटिव `deps` में मौजूद कौनसे `cc_libraries` को लिंक नहीं किया जाना चाहिए, क्योंकि उन्हें पहले ही किसी दूसरे `cc_shared_library` ने उपलब्ध करा दिया है.
`hdrs_check`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है अब सेवा में नहीं है, कोई कार्रवाई नहीं की जाती.
`includes`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है शामिल किए जाने वाले डायरेक्ट्री की सूची, जिसे कंपाइल लाइन में जोड़ा जाना है. "बदलाव के हिसाब से" विकल्प के तहत बदलाव किया जा सकता है. हर स्ट्रिंग के पहले पैकेज का पाथ जोड़ा जाता है. इसके बाद, इसे C++ टूलचेन को पास किया जाता है. ऐसा "include_paths" CROSSTOOL सुविधा के ज़रिए किया जाता है. POSIX सिस्टम पर चलने वाला टूलचेन, सामान्य सुविधाओं की परिभाषाओं के साथ `-isystem path_to_package/include_entry` जनरेट करेगा. इसका इस्तेमाल सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के लिए किया जाना चाहिए जो #include स्टेटमेंट लिखने के Google के तरीके का पालन नहीं करती हैं. COPTS के उलट, इन फ़्लैग को इस नियम और इस पर निर्भर हर नियम के लिए जोड़ा जाता है. (ध्यान दें: यह उन नियमों के बारे में नहीं है जिन पर यह निर्भर करता है!) बहुत ज़्यादा सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. अगर आपको किसी तरह का संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. जोड़े गए `include` पाथ में, जनरेट की गई फ़ाइलों के साथ-साथ सोर्स ट्री में मौजूद फ़ाइलें भी शामिल होंगी.
`link_extra_lib`	लेबल; डिफ़ॉल्ट वैल्यू `"@bazel_tools//tools/cpp:link_extra_lib"` है इस कुकी से, अन्य लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल किया जाता है. C++ बाइनरी, डिफ़ॉल्ट रूप से `@bazel_tools//tools/cpp:link_extra_lib` से लिंक होती हैं. यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग `@bazel_tools//tools/cpp:link_extra_libs` पर निर्भर करता है. फ़्लैग सेट न करने पर, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग सेट करने से, वैकल्पिक डिपेंडेंसी लिंक की जा सकती हैं. जैसे, कमज़ोर सिंबल के लिए ओवरराइड, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के विकल्पों के लिए, `malloc` या `--custom_malloc` का इस्तेमाल करें). इस एट्रिब्यूट को `None` पर सेट करने से, यह सुविधा बंद हो जाती है.
`linkopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "Make" वैरिएबल के हिसाब से बदलाव किया जा सकता है. Bourne shell टोकनाइज़ेशन और लेबल एक्सपैंशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट से लिंक करने से पहले `LINKOPTS` में जोड़ा जाता है. इस सूची का हर ऐसा एलिमेंट जो `$` या `-` से शुरू नहीं होता है उसे `deps` में टारगेट का लेबल माना जाता है. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या `deps` में इसका एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
`linkshared`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है शेयर की गई लाइब्रेरी बनाएं. इस एट्रिब्यूट को चालू करने के लिए, अपने नियम में `linkshared=True` शामिल करें. डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है. इस फ़्लैग की मौजूदगी का मतलब है कि `-shared` फ़्लैग के साथ `gcc` से लिंक किया गया है. साथ ही, इससे बनी शेयर की गई लाइब्रेरी को लोड किया जा सकता है. उदाहरण के लिए, Java प्रोग्राम में. हालांकि, बिल्ड करने के लिए इसे कभी भी निर्भर बाइनरी में लिंक नहीं किया जाएगा. ऐसा इसलिए, क्योंकि यह माना जाता है कि cc_binary नियम के साथ बनाई गई शेयर की गई लाइब्रेरी को सिर्फ़ अन्य प्रोग्राम मैन्युअल तरीके से लोड करते हैं. इसलिए, इसे cc_library नियम के विकल्प के तौर पर नहीं माना जाना चाहिए. हमारा सुझाव है कि स्केलेबिलिटी के लिए, इस तरीके का इस्तेमाल न करें. इसके बजाय, `java_library` को `cc_library` नियमों पर निर्भर रहने दें. `linkopts=['-static']` और `linkshared=True`, दोनों को तय करने पर, आपको एक ऐसी यूनिट मिलती है जिसमें सभी ज़रूरी जानकारी शामिल होती है. `linkstatic=True` और `linkshared=True`, दोनों को शामिल करने पर आपको एक यूनिट मिलती है. इसमें ज़्यादातर जानकारी शामिल होती है.
`linkstatic`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है `cc_binary` और `cc_test` के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. `cc_library.link_static` के लिए: यहां देखें. डिफ़ॉल्ट रूप से, यह विकल्प `cc_binary` के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी संभव हो, उपयोगकर्ता लाइब्रेरी के लिए `.so`'s के बजाय `.a`'s को लिंक करें. libc जैसी सिस्टम लाइब्रेरी अब भी डाइनैमिक तरीके से लिंक की जाती हैं. हालांकि, C/C++ रनटाइम लाइब्रेरी नहीं (नीचे देखें). साथ ही, जिन लाइब्रेरी के लिए कोई स्टैटिक लाइब्रेरी नहीं है उन्हें भी डाइनैमिक तरीके से लिंक किया जाता है. इसलिए, एक्ज़ीक्यूटेबल फ़ाइल अब भी डाइनैमिक रूप से लिंक होगी. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगी. किसी एक्ज़ीक्यूटेबल को लिंक करने के तीन अलग-अलग तरीके हैं: STATIC, जिसमें पूरी तरह से स्टैटिक लिंक की सुविधा होती है. इसमें सब कुछ स्टैटिक तौर पर लिंक किया जाता है; उदाहरण के लिए, "`gcc -static foo.o libbar.a libbaz.a -lm`". इस मोड को चालू करने के लिए, `features` एट्रिब्यूट में `fully_static_link` की वैल्यू डालें. STATIC, इसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, इसमें सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है. उदाहरण के लिए, "`gcc foo.o libfoo.a libbaz.a -lm`". इस मोड को `linkstatic=True` तय करके चालू किया जाता है. डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाती हैं.ऐसा तब होता है, जब डाइनैमिक वर्शन उपलब्ध हो. उदाहरण के लिए, "`gcc foo.o libfoo.so libbaz.so -lm`". इस मोड को `linkstatic=False` को तय करके चालू किया जाता है. अगर `linkstatic` एट्रिब्यूट या `fully_static_link` in `features` का इस्तेमाल `//third_party` के बाहर किया गया है, तो कृपया नियम के पास एक टिप्पणी शामिल करें. इसमें बताएं कि ऐसा क्यों किया गया है. `cc_library()` नियम में इस्तेमाल करने पर, `linkstatic` एट्रिब्यूट का मतलब अलग होता है. C++ लाइब्रेरी के लिए, `linkstatic=True` से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई `.so` नहीं बनाया जाएगा. linkstatic=False से स्टैटिक लाइब्रेरी बनाने पर कोई असर नहीं पड़ता. इस एट्रिब्यूट का इस्तेमाल, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करने के लिए किया जाता है. प्रोडक्शन में `linkstatic=False` का इस्तेमाल करके बहुत कम कोड बनाया जाना चाहिए. अगर `linkstatic=False` है, तो बिल्ड टूल, `*.runfiles` फ़ोल्डर में मौजूद, इस्तेमाल की गई शेयर की गई लाइब्रेरी के लिए सिमलंक बनाएगा.
`local_defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है कंपाइल लाइन में जोड़ने के लिए, तय की गई वैल्यू की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शैल टोकन होना चाहिए. इसके पहले `-D` जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे इसके डिपेंडेंट में नहीं जोड़ा जाता. `defines` के उलट, इस टारगेट के लिए सिर्फ़ कंपाइल कमांड लाइन में, 'डिफ़ाइन' जोड़े जाते हैं.
`malloc`	लेबल; डिफ़ॉल्ट वैल्यू `"@bazel_tools//tools/cpp:malloc"` है malloc पर डिफ़ॉल्ट डिपेंडेंसी को बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी को `//tools/cpp:malloc` के साथ लिंक किया जाता है. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी libc malloc का इस्तेमाल करती है. इस लेबल में, `cc_library` का रेफ़रंस होना चाहिए. अगर कंपाइल करने का नियम C++ का नहीं है, तो इस विकल्प का कोई असर नहीं होता. अगर `linkshared=True` एट्रिब्यूट की वैल्यू दी गई है, तो इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है.
`module_interfaces`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है फ़ाइलों की सूची को C++20 मॉड्यूल इंटरफ़ेस माना जाता है. C++ स्टैंडर्ड में, मॉड्यूल इंटरफ़ेस फ़ाइल एक्सटेंशन के बारे में कोई पाबंदी नहीं है Clang का इस्तेमाल करने वाले cppm GCC, किसी भी सोर्स फ़ाइल एक्सटेंशन का इस्तेमाल कर सकता है MSVC ixx का इस्तेमाल करता है इस सुविधा का इस्तेमाल, `--experimental_cpp_modules` फ़्लैग के ज़रिए किया जाता है.
`nocopts`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है C++ कंपाइलेशन कमांड से, मिलते-जुलते विकल्पों को हटाएं. "Make" वैरिएबल को बदला जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले किसी भी मौजूदा `COPTS` (इसमें नियम के copts एट्रिब्यूट में साफ़ तौर पर बताई गई वैल्यू भी शामिल हैं) को इस नियम को कंपाइल करने के लिए, `COPTS` से हटा दिया जाएगा. इस एट्रिब्यूट की ज़रूरत `third_party` के बाहर नहीं होनी चाहिए. साथ ही, इसका इस्तेमाल भी `third_party` के बाहर नहीं किया जाना चाहिए. "Make" वैरिएबल के बदले जाने के अलावा, वैल्यू को किसी भी तरह से पहले से प्रोसेस नहीं किया जाता है.
`reexport_deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है
`stamp`	पूर्णांक; डिफ़ॉल्ट वैल्यू `-1` है बाइनरी में बिल्ड की जानकारी को कोड में बदलना है या नहीं. इन वैल्यू का इस्तेमाल किया जा सकता है: `stamp = 1`: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. भले ही, वह `--nostamp` बिल्ड हो. इस सेटिंग का इस्तेमाल नहीं करना चाहिए, क्योंकि इससे बाइनरी और उस पर निर्भर डाउनस्ट्रीम कार्रवाइयों के लिए रिमोट कैश मेमोरी बंद हो जाती है. `stamp = 0`: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे बिल्ड के नतीजों को बेहतर तरीके से कैश मेमोरी में सेव किया जा सकता है. `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने की प्रोसेस को `--[no]stamp` फ़्लैग कंट्रोल करता है. स्टैंप किए गए बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो.
`win_def_file`	लेबल; डिफ़ॉल्ट वैल्यू `None` है Windows की DEF फ़ाइल, जिसे लिंकर को पास किया जाना है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब टारगेट प्लैटफ़ॉर्म Windows हो. इसका इस्तेमाल, शेयर की गई लाइब्रेरी को लिंक करते समय सिंबल एक्सपोर्ट करने के लिए किया जा सकता है.

cc_import

नियम का सोर्स देखें

cc_import(name, deps, data, hdrs, alwayslink, aspect_hints, compatible_with, defines, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, package_metadata, pic_objects, pic_static_library, restricted_to, shared_library, static_library, strip_include_prefix, system_provided, tags, target_compatible_with, testonly, toolchains, visibility)

cc_import के नियमों की मदद से, उपयोगकर्ता पहले से कंपाइल की गई C/C++ लाइब्रेरी इंपोर्ट कर सकते हैं.

यहां इस्तेमाल के कुछ सामान्य उदाहरण दिए गए हैं:
1. स्टैटिक लाइब्रेरी को लिंक करना


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

2. शेयर की गई लाइब्रेरी को लिंक करना (Unix)


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

3. शेयर की गई लाइब्रेरी को इंटरफ़ेस लाइब्रेरी से लिंक करना

Unix पर:


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

Windows पर:


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

4. शेयर की गई लाइब्रेरी को system_provided=True से लिंक करना

Unix पर:


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

Windows पर:


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

5. स्टैटिक या शेयर की गई लाइब्रेरी से लिंक करना

Unix पर:


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

Windows पर:


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

Unix और Windows पर बाकी जानकारी एक जैसी होती है:


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

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

cc_import में include एट्रिब्यूट काम करता है. उदाहरण के लिए:


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

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है उन अन्य लाइब्रेरी की सूची जिन पर टारगेट निर्भर करता है. `deps` पर ज़्यादातर बिल्ड नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट के बारे में सामान्य टिप्पणियां देखें.
`hdrs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस प्रीकंपाइल की गई लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची. इन्हें सीधे तौर पर, निर्भरता वाले नियमों में शामिल किया जा सकता है.
`alwayslink`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है अगर यह नीति चालू है, तो इस C++ प्रीकंपाइल की गई लाइब्रेरी पर सीधे या परोक्ष रूप से निर्भर रहने वाला कोई भी बाइनरी, स्टैटिक लाइब्रेरी में संग्रहित की गई सभी ऑब्जेक्ट फ़ाइलों में लिंक हो जाएगा. भले ही, कुछ में बाइनरी से रेफ़रंस किए गए कोई भी सिंबल मौजूद न हों. यह तब काम आता है, जब आपके कोड को बाइनरी में कोड के ज़रिए साफ़ तौर पर कॉल नहीं किया जाता. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिले कॉलबैक को पाने के लिए रजिस्टर करता है. अगर `alwayslink`, Windows पर VS 2017 के साथ काम नहीं करता है, तो इसकी वजह एक जानी-पहचानी समस्या है. कृपया VS 2017 को नए वर्शन में अपग्रेड करें.
`defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस और इससे जुड़े सभी टारगेट की कंपाइल लाइन में जोड़ने के लिए, डिफ़ाइन की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शेल टोकन होना चाहिए. इसे `-D` से पहले जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. इसके अलावा, इसे इस पर निर्भर हर नियम में भी जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. इस टारगेट पर निर्भर रहने वाले हर टारगेट में, परिभाषाएं जोड़ी जाती हैं.
`includes`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है शामिल किए जाने वाले डायरेक्ट्री की सूची, जिसे कंपाइल लाइन में जोड़ा जाना है. "बदलाव के हिसाब से" विकल्प के तहत बदलाव किया जा सकता है. हर स्ट्रिंग के पहले पैकेज का पाथ जोड़ा जाता है. इसके बाद, इसे C++ टूलचेन को पास किया जाता है. ऐसा "include_paths" CROSSTOOL सुविधा के ज़रिए किया जाता है. POSIX सिस्टम पर चलने वाला टूलचेन, सामान्य सुविधाओं की परिभाषाओं के साथ `-isystem path_to_package/include_entry` जनरेट करेगा. इसका इस्तेमाल सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के लिए किया जाना चाहिए जो #include स्टेटमेंट लिखने के Google के तरीके का पालन नहीं करती हैं. COPTS के उलट, इन फ़्लैग को इस नियम और इस पर निर्भर हर नियम के लिए जोड़ा जाता है. (ध्यान दें: यह उन नियमों के बारे में नहीं है जिन पर यह निर्भर करता है!) बहुत ज़्यादा सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. अगर आपको किसी तरह का संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. डिफ़ॉल्ट `include` पाथ में जनरेट की गई फ़ाइलें शामिल नहीं हैं. अगर आपको जनरेट की गई हेडर फ़ाइल को `#include` करना है, तो उसे `srcs` में शामिल करें.
`interface_library`	लेबल; डिफ़ॉल्ट वैल्यू `None` है शेयर की गई लाइब्रेरी को लिंक करने के लिए, एक इंटरफ़ेस लाइब्रेरी. इन फ़ाइल टाइप का इस्तेमाल किया जा सकता है: `.ifso`, `.tbd`, `.lib`, `.so` या `.dylib`
`linkopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "Make" वैरिएबल के हिसाब से बदलाव किया जा सकता है. Bourne shell टोकनाइज़ेशन और लेबल एक्सपैंशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट से लिंक करने से पहले `LINKOPTS` में जोड़ा जाता है. इस सूची का हर ऐसा एलिमेंट जो `$` या `-` से शुरू नहीं होता है उसे `deps` में मौजूद टारगेट का लेबल माना जाता है. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या `deps` में इसका एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
`objects`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है
`pic_objects`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है
`pic_static_library`	लेबल; डिफ़ॉल्ट वैल्यू `None` है
`shared_library`	लेबल; डिफ़ॉल्ट वैल्यू `None` है पहले से कंपाइल की गई एक शेयर की गई लाइब्रेरी. Bazel यह पक्का करता है कि रनटाइम के दौरान, यह उस बाइनरी के लिए उपलब्ध हो जो इस पर निर्भर करती है. इन फ़ाइल टाइप का इस्तेमाल किया जा सकता है: `.so`, `.dll` `.dylib`, या `.pyd`
`static_library`	लेबल; डिफ़ॉल्ट वैल्यू `None` है पहले से कंपाइल की गई एक स्टैटिक लाइब्रेरी. इन फ़ाइल टाइप का इस्तेमाल किया जा सकता है: `.a`, `.pic.a` या `.lib`
`strip_include_prefix`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है इस नियम के हेडर के पाथ से हटाने के लिए प्रीफ़िक्स. इस विकल्प को सेट करने पर, इस नियम के `hdrs` एट्रिब्यूट में मौजूद हेडर, इस प्रीफ़िक्स को हटाकर उनके पाथ पर ऐक्सेस किए जा सकते हैं. अगर यह रिलेटिव पाथ है, तो इसे पैकेज के हिसाब से रिलेटिव पाथ माना जाता है. अगर यह ऐब्सलूट पाथ है, तो इसे रिपॉज़िटरी के हिसाब से रिलेटिव पाथ माना जाता है. इस प्रीफ़िक्स को हटाने के बाद, `include_prefix` एट्रिब्यूट में प्रीफ़िक्स जोड़ा जाता है. यह एट्रिब्यूट सिर्फ़ `third_party` के तहत मान्य है.
`system_provided`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है अगर यह सुविधा चालू है, तो इससे पता चलता है कि रनटाइम के दौरान ज़रूरी शेयर की गई लाइब्रेरी, सिस्टम से मिली है. इस मामले में, `interface_library` की वैल्यू दी जानी चाहिए और `shared_library` खाली होना चाहिए.

cc_library

नियम का सोर्स देखें

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

C++ में कंपाइल की गई लाइब्रेरी के लिए, cc_library() का इस्तेमाल करें. नतीजा, ज़रूरत के हिसाब से .so, .lo या .a होता है.

अगर आपने स्टैटिक लिंकिंग का इस्तेमाल करके कोई ऐसी चीज़ बनाई है जो किसी cc_library पर निर्भर करती है, तो निर्भरता वाली लाइब्रेरी के नियम का आउटपुट cc_library फ़ाइल होती है..a alwayslink=True की वैल्यू देने पर, आपको .lo फ़ाइल मिलती है.

शेयर की गई लाइब्रेरी के लिए, आउटपुट फ़ाइल का असली नाम libfoo.so है. इसमें foo, नियम का नाम है. अन्य तरह की लाइब्रेरी के नाम के आखिर में, .lo और .a होते हैं. अगर आपको शेयर की गई लाइब्रेरी के किसी खास नाम की ज़रूरत है, तो उदाहरण के लिए, Python मॉड्यूल को तय करने के लिए, लाइब्रेरी को अपने हिसाब से नाम देने के लिए genrule का इस्तेमाल करें.

हेडर शामिल करने की जांच की जा रही है

बिल्ड में इस्तेमाल की गई सभी हेडर फ़ाइलों को cc_* नियमों के hdrs या srcs में एलान किया जाना चाहिए. यह लागू है.

cc_library नियमों के लिए, hdrs में मौजूद हेडर, लाइब्रेरी का सार्वजनिक इंटरफ़ेस बनाते हैं. इन्हें सीधे तौर पर, लाइब्रेरी के hdrs और srcs में मौजूद फ़ाइलों से शामिल किया जा सकता है. साथ ही, cc_* नियमों के hdrs और srcs में मौजूद फ़ाइलों से भी शामिल किया जा सकता है. ये नियम, लाइब्रेरी को अपने deps में शामिल करते हैं. srcs में मौजूद हेडर को सिर्फ़ लाइब्रेरी के hdrs और srcs में मौजूद फ़ाइलों से सीधे तौर पर शामिल किया जाना चाहिए. यह तय करते समय कि किसी हेडर को hdrs या srcs में रखना है या नहीं, आपको यह पूछना चाहिए कि क्या आपको इस लाइब्रेरी के उपभोक्ताओं को इसे सीधे तौर पर शामिल करने की अनुमति देनी है. यह फ़ैसला, प्रोग्रामिंग भाषाओं में public और private की विज़िबिलिटी के बीच लिए गए फ़ैसले के जैसा ही होता है.

cc_binary और cc_test नियमों में एक्सपोर्ट किया गया इंटरफ़ेस नहीं होता. इसलिए, इनमें hdrs एट्रिब्यूट भी नहीं होता. बाइनरी या टेस्ट से जुड़े सभी हेडर, srcs में शामिल होने चाहिए.

इन नियमों को समझने के लिए, यहां दिया गया उदाहरण देखें.


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

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

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

इस उदाहरण में, सीधे तौर पर शामिल किए जा सकने वाले आइटम की सूची यहां दी गई है. उदाहरण के लिए, foo.cc में सीधे तौर पर foo.h और bar.h को शामिल किया जा सकता है, लेकिन baz.h को नहीं.

फ़ाइल शामिल करें	शामिल करने की अनुमति है
foo.h	bar.h
foo.cc	foo.h bar.h
bar.h	bar-impl.h baz.h
bar-impl.h	bar.h baz.h
bar.cc	bar.h bar-impl.h baz.h
baz.h	baz-impl.h
baz-impl.h	baz.h
baz.cc	baz.h baz-impl.h

शामिल करने की जांच से जुड़े नियम, सिर्फ़ सीधे तौर पर शामिल किए गए यूआरएल पर लागू होते हैं. ऊपर दिए गए उदाहरण में, foo.cc को bar.h शामिल करने की अनुमति है. bar.h में baz.h शामिल हो सकता है और baz.h में baz-impl.h शामिल हो सकता है. तकनीकी तौर पर, .cc फ़ाइल के कंपाइलेशन में, hdrs या srcs में मौजूद कोई भी हेडर फ़ाइल शामिल हो सकती है. साथ ही, यह ट्रांज़िटिव deps क्लोज़र में मौजूद किसी भी cc_library में शामिल हो सकती है. इस मामले में, कंपाइलर foo.cc को कंपाइल करते समय baz.h और baz-impl.h को पढ़ सकता है. हालांकि, foo.cc में #include "baz.h" नहीं होना चाहिए. इसके लिए, baz को foo के deps में जोड़ना होगा.

Bazel, टूलचेन के साथ काम करता है, ताकि फ़ाइल शामिल करने से जुड़े नियमों को लागू किया जा सके. layering_check सुविधा के लिए, टूलचेन का इस्तेमाल किया जाना चाहिए. साथ ही, इसके लिए साफ़ तौर पर अनुरोध किया जाना चाहिए. उदाहरण के लिए, --features=layering_check कमांड-लाइन फ़्लैग या package फ़ंक्शन के features पैरामीटर के ज़रिए अनुरोध किया जा सकता है. Bazel की ओर से उपलब्ध कराई गई टूलचेन, इस सुविधा के साथ सिर्फ़ Unix और macOS पर clang के साथ काम करती हैं.

उदाहरण

हम alwayslink फ़्लैग का इस्तेमाल करते हैं, ताकि लिंकर को इस कोड को लिंक करने के लिए मजबूर किया जा सके. भले ही, मुख्य बाइनरी कोड इसे रेफ़र न करे.


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

यहां दिया गया उदाहरण, third_party/python2_4_3/BUILD से लिया गया है. कुछ कोड, dl लाइब्रेरी का इस्तेमाल करते हैं (दूसरी डाइनैमिक लाइब्रेरी लोड करने के लिए). इसलिए, यह नियम dl लाइब्रेरी को लिंक करने के लिए, -ldl लिंक विकल्प के बारे में बताता है.


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

यहां दिया गया उदाहरण third_party/kde/BUILD से लिया गया है. हम डिपो में पहले से बनी .so फ़ाइलें रखते हैं. हेडर फ़ाइलें, include नाम की सबडायरेक्ट्री में होती हैं.


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

यहां दिया गया उदाहरण third_party/gles/BUILD से लिया गया है. तीसरे पक्ष के कोड को अक्सर कुछ defines और linkopts की ज़रूरत होती है.


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

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है उन अन्य लाइब्रेरी की सूची जिन पर लाइब्रेरी टारगेट निर्भर करता है. ये `cc_library` या `objc_library` टारगेट हो सकते हैं. बिल्ड करने के ज़्यादातर नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट में, `deps` के बारे में सामान्य टिप्पणियां देखें. ये C++ लाइब्रेरी के नियमों के नाम होने चाहिए. इस नियम की लाइब्रेरी को लिंक करने वाला बाइनरी बनाने पर, `deps` में मौजूद लाइब्रेरी भी लिंक हो जाएंगी. "deps" नाम होने के बावजूद, इस लाइब्रेरी के सभी क्लाइंट यहां नहीं आते. रन-टाइम डेटा डिपेंडेंसी, `data` में शामिल होती हैं. अन्य नियमों से जनरेट की गई सोर्स फ़ाइलें, `srcs` में होनी चाहिए. पहले से कंपाइल की गई तीसरे पक्ष की लाइब्रेरी को लिंक करने के लिए, उसका नाम `srcs` में जोड़ें. अगर आपको किसी चीज़ को इस लाइब्रेरी से लिंक किए बिना उस पर निर्भर रहना है, तो उसका नाम `data` में जोड़ें.
`srcs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है C और C++ फ़ाइलों की सूची, जिन्हें लाइब्रेरी टारगेट बनाने के लिए प्रोसेस किया जाता है. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये जनरेट नहीं की गई हैं (सामान्य सोर्स कोड) या जनरेट की गई हैं. सभी `.cc`, `.c`, और `.cpp` फ़ाइलों को कंपाइल किया जाएगा. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर किसी नाम वाली फ़ाइल, किसी दूसरे नियम के `outs` में है, तो यह `cc_library` अपने-आप उस दूसरे नियम पर निर्भर करेगा. असेंबलर फ़ाइलों (.s, .asm) को पहले से प्रोसेस नहीं किया जाता है. इन्हें आम तौर पर असेंबलर का इस्तेमाल करके बनाया जाता है. प्रीप्रोसेस की गई असेंबली फ़ाइलों (.S) को प्रीप्रोसेस किया जाता है. इन्हें आम तौर पर C/C++ कंपाइलर का इस्तेमाल करके बनाया जाता है. `.h` फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, यह इस नियम के तहत आने वाले स्रोतों के लिए उपलब्ध रहेगी. `.cc` और `.h`, दोनों तरह की फ़ाइलों में, इन `srcs` में या इस नियम के `hdrs` में या `deps` आर्ग्युमेंट में दिए गए किसी भी नियम में शामिल हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी `#include`d फ़ाइलों का ज़िक्र, इस या रेफ़र की गई `cc_library` नियमों के `hdrs` एट्रिब्यूट में किया जाना चाहिए. अगर ये फ़ाइलें इस लाइब्रेरी के लिए निजी हैं, तो इन्हें `srcs` में शामिल किया जाना चाहिए. ज़्यादा जानकारी के लिए, "हेडर शामिल करने की जांच" देखें. `.so`, `.lo`, और `.a` फ़ाइलें, पहले से कंपाइल की गई फ़ाइलें हैं. अगर आपकी लाइब्रेरी में तीसरे पक्ष का ऐसा कोड इस्तेमाल किया गया है जिसका सोर्स कोड हमारे पास नहीं है, तो हो सकता है कि आपकी लाइब्रेरी में ये `srcs` के तौर पर मौजूद हों. अगर `srcs` एट्रिब्यूट में किसी दूसरे नियम का लेबल शामिल है, तो `cc_library`, कंपाइल करने के लिए उस नियम की आउटपुट फ़ाइलों को सोर्स फ़ाइलों के तौर पर इस्तेमाल करेगा. यह सोर्स कोड को एक बार जनरेट करने के लिए काम आता है. अगर आपको इसका इस्तेमाल कभी-कभी से ज़्यादा बार करना है, तो Starlark नियम क्लास लागू करना और `cc_common` एपीआई का इस्तेमाल करना बेहतर होता है `srcs` के लिए इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: C और C++ सोर्स फ़ाइलें: `.c`, `.cc`, `.cpp`, `.cxx`, `.c++`, `.C` C और C++ हेडर फ़ाइलें: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` सी प्रीप्रोसेसर के साथ असेंबलर: `.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`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है आपको कंपाइलर कमांड लाइन को कोई भी अतिरिक्त फ़ाइल पास करनी पड़ सकती है. जैसे, सैनिटाइज़र इग्नोरलिस्ट. यहां बताई गई फ़ाइलों का इस्तेमाल, $(location) फ़ंक्शन के साथ copts में किया जा सकता है.
`additional_linker_inputs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है ऐसी डिपेंडेंसी जो सिर्फ़ C++ लिंकर कमांड के लिए उपलब्ध कराई जाती हैं. `deps` को कंपाइल करने और लिंक करने की डिपेंडेंसी, दोनों के लिए बनाया गया है. वहीं, `additional_linker_inputs` को सिर्फ़ लिंक करने की डिपेंडेंसी के लिए बनाया गया है. यह ऐसी डिपेंडेंसी का सिग्नल देता है जो सिर्फ़ लिंक करने के लिए ज़रूरी है. उदाहरण के लिए, `linkopts` में रेफ़र की गई फ़ाइलें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.
`alwayslink`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है अगर 1, तो इस C++ लाइब्रेरी पर सीधे या परोक्ष रूप से निर्भर करने वाली कोई भी बाइनरी, `srcs` में दी गई फ़ाइलों के लिए सभी ऑब्जेक्ट फ़ाइलों में लिंक करेगी. भले ही, कुछ में बाइनरी से रेफ़रंस किए गए कोई भी सिंबल मौजूद न हों. यह तब काम आता है, जब आपके कोड को बाइनरी में कोड के ज़रिए साफ़ तौर पर कॉल नहीं किया जाता. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिले कॉलबैक को पाने के लिए रजिस्टर करता है. अगर Windows पर VS 2017 के साथ alwayslink काम नहीं करता है, तो इसकी वजह एक जानी-पहचानी समस्या है. कृपया VS 2017 को नए वर्शन में अपग्रेड करें.
`conlyopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इन विकल्पों को C कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.
`copts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है C/C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, दिए गए क्रम में `COPTS` में जोड़ा जाता है. इसके बाद, बाइनरी टारगेट को कंपाइल किया जाता है. ये फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, इसकी डिपेंडेंसी के लिए नहीं. इसलिए, किसी दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस के हिसाब से होने चाहिए. इस एट्रिब्यूट की ज़रूरत `third_party` के बाहर नहीं होनी चाहिए. अगर पैकेज में सुविधा `no_copts_tokenization` के बारे में बताया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.
`cxxopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.
`defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस और इससे जुड़े सभी टारगेट की कंपाइल लाइन में जोड़ने के लिए, डिफ़ाइन की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शेल टोकन होना चाहिए. इसे `-D` से पहले जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. इसके अलावा, इसे इस पर निर्भर हर नियम में भी जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. इस टारगेट पर निर्भर रहने वाले हर टारगेट में, परिभाषाएं जोड़ी जाती हैं. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय `local_defines` में वैल्यू तय करें.
`hdrs_check`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है अब सेवा में नहीं है, कोई कार्रवाई नहीं की जाती.
`implementation_deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है उन अन्य लाइब्रेरी की सूची जिन पर लाइब्रेरी टारगेट निर्भर करता है. `deps` के उलट, इन लाइब्रेरी के हेडर और शामिल किए गए पाथ (और इनके सभी ट्रांज़िटिव डिपेंडेंसी) का इस्तेमाल सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है. इनका इस्तेमाल उन लाइब्रेरी के लिए नहीं किया जाता जो इस पर निर्भर करती हैं. `implementation_deps` के तौर पर मार्क की गई लाइब्रेरी अब भी उन बाइनरी टारगेट से जुड़ी हैं जो इस लाइब्रेरी पर निर्भर हैं.
`include_prefix`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है इस नियम के हेडर के पाथ में जोड़ने के लिए प्रीफ़िक्स. इस एट्रिब्यूट को सेट करने पर, इस नियम के `hdrs` एट्रिब्यूट में मौजूद हेडर ऐक्सेस किए जा सकते हैं. इस एट्रिब्यूट की वैल्यू, रिपॉज़िटरी के हिसाब से उनके पाथ से पहले जोड़ी जाती है. इस प्रीफ़िक्स को जोड़ने से पहले, `strip_include_prefix` एट्रिब्यूट में मौजूद प्रीफ़िक्स हटा दिया जाता है. यह एट्रिब्यूट सिर्फ़ `third_party` के तहत मान्य है.
`includes`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है शामिल किए जाने वाले डायरेक्ट्री की सूची, जिसे कंपाइल लाइन में जोड़ा जाना है. "बदलाव के हिसाब से" विकल्प के तहत बदलाव किया जा सकता है. हर स्ट्रिंग के पहले पैकेज का पाथ जोड़ा जाता है. इसके बाद, इसे C++ टूलचेन को पास किया जाता है. ऐसा "include_paths" CROSSTOOL सुविधा के ज़रिए किया जाता है. POSIX सिस्टम पर चलने वाला टूलचेन, सामान्य सुविधाओं की परिभाषाओं के साथ `-isystem path_to_package/include_entry` जनरेट करेगा. इसका इस्तेमाल सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के लिए किया जाना चाहिए जो #include स्टेटमेंट लिखने के Google के तरीके का पालन नहीं करती हैं. COPTS के उलट, इन फ़्लैग को इस नियम और इस पर निर्भर हर नियम के लिए जोड़ा जाता है. (ध्यान दें: यह उन नियमों के बारे में नहीं है जिन पर यह निर्भर करता है!) बहुत ज़्यादा सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. अगर आपको किसी तरह का संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. जोड़े गए `include` पाथ में, जनरेट की गई फ़ाइलों के साथ-साथ सोर्स ट्री में मौजूद फ़ाइलें भी शामिल होंगी.
`linkopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है `cc_binary.linkopts` देखें. `linkopts` एट्रिब्यूट, ऐसे किसी भी टारगेट पर भी लागू होता है जो सीधे या परोक्ष रूप से इस लाइब्रेरी पर निर्भर करता है. ऐसा `deps` एट्रिब्यूट के ज़रिए होता है. इसके अलावा, यह ऐसे अन्य एट्रिब्यूट के ज़रिए भी होता है जिन्हें इसी तरह से ट्रीट किया जाता है: `cc_binary` का `malloc` एट्रिब्यूट. डिपेंडेंसी लिंकऑप्ट, डिपेंडेंट लिंकऑप्ट से ज़्यादा प्राथमिकता रखते हैं. इसका मतलब है कि डिपेंडेंसी लिंकऑप्ट, कमांड लाइन में बाद में दिखते हैं. `--linkopt` में दिए गए लिंक विकल्प, नियम के लिंक विकल्प से ज़्यादा प्राथमिकता रखते हैं. ध्यान दें कि `linkopts` एट्रिब्यूट सिर्फ़ `.so` फ़ाइलें या एक्ज़ीक्यूटेबल बनाते समय लागू होता है. `.a` या `.lo` फ़ाइलें बनाते समय यह लागू नहीं होता. इसलिए, अगर `linkstatic=True` एट्रिब्यूट सेट है, तो `linkopts` एट्रिब्यूट का इस लाइब्रेरी को बनाने पर कोई असर नहीं पड़ता. इसका असर सिर्फ़ उन अन्य टारगेट पर पड़ता है जो इस लाइब्रेरी पर निर्भर होते हैं. यह भी ध्यान रखना ज़रूरी है कि "-Wl,-soname" या "-Xlinker -soname" विकल्प काम नहीं करते हैं. इसलिए, इस एट्रिब्यूट में इन्हें कभी भी शामिल नहीं करना चाहिए. `cc_library` नियमों से जनरेट हुई `.so` फ़ाइलें, उन लाइब्रेरी से लिंक नहीं की गई हैं जिन पर वे निर्भर करती हैं. अगर आपको मुख्य रिपॉज़िटरी के बाहर इस्तेमाल करने के लिए, शेयर की गई लाइब्रेरी बनानी है, जैसे कि `dlopen()` या `LD_PRELOAD` के साथ मैन्युअल तरीके से इस्तेमाल करने के लिए, तो `linkshared=True` एट्रिब्यूट के साथ `cc_binary` नियम का इस्तेमाल करना बेहतर हो सकता है. `cc_binary.linkshared` देखें.
`linkstamp`	लेबल; डिफ़ॉल्ट वैल्यू `None` है यह विकल्प, बताई गई C++ सोर्स फ़ाइल को एक साथ कंपाइल और लिंक करके, फ़ाइनल बाइनरी में बदलता है. बाइनरी में टाइमस्टैंप की जानकारी डालने के लिए, इस तरीके का इस्तेमाल करना ज़रूरी है. अगर हमने सोर्स फ़ाइल को सामान्य तरीके से ऑब्जेक्ट फ़ाइल में कंपाइल किया, तो टाइमस्टैंप गलत होगा. लिंकस्टैंप कंपाइलेशन में कंपाइलर फ़्लैग का कोई खास सेट शामिल नहीं हो सकता. इसलिए, इसे किसी खास हेडर, कंपाइलर विकल्प या अन्य बिल्ड वैरिएबल पर निर्भर नहीं होना चाहिए. यह विकल्प सिर्फ़ `base` पैकेज में होना चाहिए.
`linkstatic`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है `cc_binary` और `cc_test` के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. `cc_library.link_static` के लिए: यहां देखें. डिफ़ॉल्ट रूप से, यह विकल्प `cc_binary` के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी संभव हो, उपयोगकर्ता लाइब्रेरी के लिए `.so`'s के बजाय `.a`'s को लिंक करें. libc जैसी सिस्टम लाइब्रेरी अब भी डाइनैमिक तरीके से लिंक की जाती हैं. हालांकि, C/C++ रनटाइम लाइब्रेरी नहीं (नीचे देखें). साथ ही, जिन लाइब्रेरी के लिए कोई स्टैटिक लाइब्रेरी नहीं है उन्हें भी डाइनैमिक तरीके से लिंक किया जाता है. इसलिए, एक्ज़ीक्यूटेबल फ़ाइल अब भी डाइनैमिक रूप से लिंक होगी. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगी. किसी एक्ज़ीक्यूटेबल को लिंक करने के तीन अलग-अलग तरीके हैं: STATIC, जिसमें पूरी तरह से स्टैटिक लिंक की सुविधा होती है. इसमें सब कुछ स्टैटिक तौर पर लिंक किया जाता है; उदाहरण के लिए, "`gcc -static foo.o libbar.a libbaz.a -lm`". इस मोड को चालू करने के लिए, `features` एट्रिब्यूट में `fully_static_link` की वैल्यू डालें. STATIC, इसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, इसमें सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है. उदाहरण के लिए, "`gcc foo.o libfoo.a libbaz.a -lm`". इस मोड को `linkstatic=True` तय करके चालू किया जाता है. डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाती हैं.ऐसा तब होता है, जब डाइनैमिक वर्शन उपलब्ध हो. उदाहरण के लिए, "`gcc foo.o libfoo.so libbaz.so -lm`". इस मोड को `linkstatic=False` को तय करके चालू किया जाता है. अगर `linkstatic` एट्रिब्यूट या `fully_static_link` in `features` का इस्तेमाल `//third_party` के बाहर किया गया है, तो कृपया नियम के पास एक टिप्पणी शामिल करें. इसमें बताएं कि ऐसा क्यों किया गया है. `cc_library()` नियम में इस्तेमाल करने पर, `linkstatic` एट्रिब्यूट का मतलब अलग होता है. C++ लाइब्रेरी के लिए, `linkstatic=True` से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई `.so` नहीं बनाया जाएगा. linkstatic=False से स्टैटिक लाइब्रेरी बनाने पर कोई असर नहीं पड़ता. इस एट्रिब्यूट का इस्तेमाल, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करने के लिए किया जाता है. प्रोडक्शन में `linkstatic=False` का इस्तेमाल करके बहुत कम कोड बनाया जाना चाहिए. अगर `linkstatic=False` है, तो बिल्ड टूल, `*.runfiles` फ़ोल्डर में मौजूद, इस्तेमाल की गई शेयर की गई लाइब्रेरी के लिए सिमलंक बनाएगा.
`local_defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है कंपाइल लाइन में जोड़ने के लिए, तय की गई वैल्यू की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शैल टोकन होना चाहिए. इसके पहले `-D` जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे इसके डिपेंडेंट में नहीं जोड़ा जाता. `defines` के उलट, इस टारगेट के लिए सिर्फ़ कंपाइल कमांड लाइन में, 'डिफ़ाइन' जोड़े जाते हैं.
`module_interfaces`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है फ़ाइलों की सूची को C++20 मॉड्यूल इंटरफ़ेस माना जाता है. C++ स्टैंडर्ड में, मॉड्यूल इंटरफ़ेस फ़ाइल एक्सटेंशन के बारे में कोई पाबंदी नहीं है Clang का इस्तेमाल करने वाले cppm GCC, किसी भी सोर्स फ़ाइल एक्सटेंशन का इस्तेमाल कर सकता है MSVC ixx का इस्तेमाल करता है इस सुविधा का इस्तेमाल, `--experimental_cpp_modules` फ़्लैग के ज़रिए किया जाता है.
`strip_include_prefix`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है इस नियम के हेडर के पाथ से हटाने के लिए प्रीफ़िक्स. इस विकल्प को सेट करने पर, इस नियम के `hdrs` एट्रिब्यूट में मौजूद हेडर, इस प्रीफ़िक्स को हटाकर उनके पाथ पर ऐक्सेस किए जा सकते हैं. अगर यह रिलेटिव पाथ है, तो इसे पैकेज के हिसाब से रिलेटिव पाथ माना जाता है. अगर यह ऐब्सलूट पाथ है, तो इसे रिपॉज़िटरी के हिसाब से रिलेटिव पाथ माना जाता है. इस प्रीफ़िक्स को हटाने के बाद, `include_prefix` एट्रिब्यूट में प्रीफ़िक्स जोड़ा जाता है. यह एट्रिब्यूट सिर्फ़ `third_party` के तहत मान्य है.
`textual_hdrs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची. इन्हें डिपेंडेंट नियमों में सोर्स के तौर पर शामिल किया जाता है. यह ऐसी हेडर फ़ाइलों के लिए जगह है जिन्हें खुद से कंपाइल नहीं किया जा सकता. इसका मतलब है कि मान्य कोड बनाने के लिए, उन्हें हमेशा अन्य सोर्स फ़ाइलों में टेक्स्ट के तौर पर शामिल करना पड़ता है.
`win_def_file`	लेबल; डिफ़ॉल्ट वैल्यू `None` है Windows की DEF फ़ाइल, जिसे लिंकर को पास किया जाना है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब टारगेट प्लैटफ़ॉर्म Windows हो. इसका इस्तेमाल, शेयर की गई लाइब्रेरी को लिंक करते समय सिंबल एक्सपोर्ट करने के लिए किया जा सकता है.

cc_shared_library

नियम का सोर्स देखें

cc_shared_library(name, deps, additional_linker_inputs, aspect_hints, compatible_with, deprecation, dynamic_deps, exec_compatible_with, exec_group_compatible_with, exec_properties, exports_filter, features, package_metadata, restricted_to, roots, shared_lib_name, static_deps, tags, target_compatible_with, testonly, toolchains, user_link_flags, visibility, win_def_file)

इससे शेयर की गई लाइब्रेरी बनती है.

उदाहरण

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

उदाहरण में, foo_shared, foo और baz को स्टैटिक तरीके से लिंक करता है. baz, ट्रांज़िटिव डिपेंडेंसी है. यह bar को लिंक नहीं करता, क्योंकि इसे dynamic_dep bar_shared पहले से ही डाइनैमिक तौर पर उपलब्ध कराता है.

foo_shared, लिंक करने वाली स्क्रिप्ट *.lds फ़ाइल का इस्तेमाल करता है. इससे यह कंट्रोल किया जा सकता है कि किन सिंबल को एक्सपोर्ट किया जाना चाहिए. cc_shared_library नियम का लॉजिक यह कंट्रोल नहीं करता कि कौनसे सिंबल एक्सपोर्ट किए जाएंगे. यह सिर्फ़ उन सिंबल का इस्तेमाल करता है जिन्हें एक्सपोर्ट किया जाना है. इससे विश्लेषण के दौरान गड़बड़ियां दिखती हैं. ऐसा तब होता है, जब दो शेयर की गई लाइब्रेरी एक ही टारगेट एक्सपोर्ट करती हैं.

cc_shared_library की हर डायरेक्ट डिपेंडेंसी को एक्सपोर्ट किया गया माना जाता है. इसलिए, विश्लेषण के दौरान Bazel यह मान लेता है कि foo को foo_shared एक्सपोर्ट कर रहा है. baz को foo_shared से एक्सपोर्ट नहीं किया जा सकता. exports_filter से मैच होने वाले हर टारगेट को भी एक्सपोर्ट किया गया माना जाता है.

उदाहरण में मौजूद हर cc_library, ज़्यादा से ज़्यादा एक cc_shared_library में दिखना चाहिए. अगर हमें baz को भी bar_shared में लिंक करना है, तो हमें baz में tags = ["LINKABLE_MORE_THAN_ONCE"] जोड़ना होगा.

shared_lib_name एट्रिब्यूट की वजह से, bar_shared से जनरेट हुई फ़ाइल का नाम bar.so होगा. हालांकि, Linux पर डिफ़ॉल्ट रूप से इसका नाम libbar.so होता है.

गड़बड़ियां

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

ऐसा तब होगा, जब एक ही टारगेट को एक्सपोर्ट करने वाली दो अलग-अलग cc_shared_library डिपेंडेंसी के साथ कोई टारगेट बनाया जा रहा हो. इस समस्या को ठीक करने के लिए, आपको cc_shared_library डिपेंडेंसी में से किसी एक में लाइब्रेरी एक्सपोर्ट करने की सुविधा बंद करनी होगी.

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

ऐसा तब होगा, जब दो अलग-अलग cc_shared_library डिपेंडेंसी वाला नया cc_shared_library बनाया जा रहा हो और दोनों एक ही टारगेट को स्टैटिक तौर पर लिंक करती हों. यह गड़बड़ी, एक्सपोर्ट से जुड़ी गड़बड़ी की तरह ही होती है.

इस समस्या को ठीक करने का एक तरीका यह है कि लाइब्रेरी को cc_shared_library की किसी एक डिपेंडेंसी से लिंक करना बंद कर दें. साथ ही, जो लाइब्रेरी अब भी लिंक है उसे लाइब्रेरी एक्सपोर्ट करनी होगी, ताकि लिंक न होने वाली लाइब्रेरी को सिंबल दिखते रहें. दूसरा तरीका यह है कि टारगेट को एक्सपोर्ट करने वाली किसी तीसरे पक्ष की लाइब्रेरी का इस्तेमाल किया जाए. तीसरा तरीका यह है कि समस्या पैदा करने वाले cc_library को LINKABLE_MORE_THAN_ONCE के साथ टैग किया जाए. हालांकि, ऐसा बहुत कम करना चाहिए. साथ ही, आपको यह पक्का करना चाहिए कि cc_library को एक से ज़्यादा बार लिंक करना सुरक्षित हो.

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

इसका मतलब है कि आपकी deps के ट्रांज़िटिव क्लोज़र में मौजूद किसी लाइब्रेरी को cc_shared_library डिपेंडेंसी में से किसी एक का इस्तेमाल किए बिना ऐक्सेस किया जा सकता है. हालांकि, यह dynamic_deps में किसी अन्य cc_shared_library से पहले ही लिंक हो चुकी है और इसे एक्सपोर्ट नहीं किया गया है.

इसका समाधान यह है कि इसे 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 में शामिल नहीं है. अगर यह पहले से कंपाइल की गई डाइनैमिक लाइब्रेरी, आपके किसी cc_libraries की डिपेंडेंसी है, तो cc_libraries को सीधे तौर पर इस पर निर्भर होना चाहिए.cc_library

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

अगर मौजूदा नियम के तहत, ऐसे टारगेट को एक्सपोर्ट करने का दावा किया जा रहा है जिसे आपकी किसी डाइनैमिक डिपेंडेंसी से पहले ही एक्सपोर्ट किया जा रहा है, तो आपको यह गड़बड़ी दिखेगी.

इसे ठीक करने के लिए, deps से टारगेट हटाएं और सिर्फ़ डाइनैमिक डिपेंडेंसी पर भरोसा करें. इसके अलावा, यह भी पक्का करें कि deps इस टारगेट को कैप्चर न करे.exports_filter

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है टॉप लेवल की ऐसी लाइब्रेरी जिन्हें पूरी तरह से संग्रहित करने के बाद, शेयर की गई लाइब्रेरी में बिना किसी शर्त के स्टैटिक रूप से लिंक किया जाएगा. इन डायरेक्ट डिपेंडेंसी की किसी भी ट्रांज़िटिव लाइब्रेरी डिपेंडेंसी को इस शेयर की गई लाइब्रेरी में तब तक लिंक किया जाएगा, जब तक उन्हें `dynamic_deps` में `cc_shared_library` ने पहले से लिंक न किया हो. विश्लेषण के दौरान, नियम लागू करने की प्रोसेस में, `deps` में शामिल किसी भी टारगेट को शेयर की गई लाइब्रेरी से एक्सपोर्ट किया गया माना जाएगा. ऐसा इसलिए किया जाएगा, ताकि एक ही टारगेट को कई `cc_shared_libraries` से एक्सपोर्ट करने पर गड़बड़ियां दिखें. नियम लागू करने से, लिंकर को यह जानकारी नहीं मिलती कि शेयर किए गए ऑब्जेक्ट को कौनसे सिंबल एक्सपोर्ट करने चाहिए. उपयोगकर्ता को लिंकर स्क्रिप्ट या सोर्स कोड में विज़िबिलिटी के एलान के ज़रिए इसका ध्यान रखना चाहिए. जब एक ही लाइब्रेरी को एक से ज़्यादा `cc_shared_library` में स्टैटिक तौर पर लिंक किया जाता है, तब भी लागू करने की यह प्रोसेस गड़बड़ियों को ट्रिगर करेगी. ऐसा होने से रोकने के लिए, `cc_library.tags` में `"LINKABLE_MORE_THAN_ONCE"` जोड़ें. इसके अलावा, `cc_library` को शेयर की गई किसी लाइब्रेरी के एक्सपोर्ट के तौर पर लिस्ट करें, ताकि एक को दूसरे का `dynamic_dep` बनाया जा सके.
`additional_linker_inputs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है लिंकर को पास की जाने वाली कोई भी अतिरिक्त फ़ाइल, जैसे कि लिंकर स्क्रिप्ट. आपको ऐसे किसी भी लिंकर फ़्लैग को अलग से पास करना होगा जिसकी ज़रूरत लिंकर को इस फ़ाइल के बारे में जानने के लिए होती है. इसके लिए, `user_link_flags` एट्रिब्यूट का इस्तेमाल करें.
`dynamic_deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है ये अन्य `cc_shared_library` डिपेंडेंसी हैं, जिन पर मौजूदा टारगेट निर्भर करता है. `cc_shared_library` को लागू करने के लिए, `dynamic_deps` की सूची का इस्तेमाल किया जाएगा.इसमें `dynamic_deps` (ट्रांज़िटिव तौर पर, यानी कि मौजूदा टारगेट के `dynamic_deps` का `dynamic_deps` भी) शामिल है. इससे यह तय किया जा सकेगा कि ट्रांज़िटिव `deps` में मौजूद कौनसे `cc_libraries` को लिंक नहीं किया जाना चाहिए, क्योंकि उन्हें पहले ही किसी दूसरे `cc_shared_library` ने उपलब्ध करा दिया है.
`exports_filter`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस एट्रिब्यूट में उन टारगेट की सूची होती है जिनके बारे में यह दावा किया जाता है कि उन्हें मौजूदा शेयर की गई लाइब्रेरी से एक्सपोर्ट किया गया है. शेयर की गई लाइब्रेरी से किसी भी टारगेट `deps` को एक्सपोर्ट किया जा सकता है. इस एट्रिब्यूट का इस्तेमाल, शेयर की गई लाइब्रेरी से एक्सपोर्ट किए गए उन सभी टारगेट को लिस्ट करने के लिए किया जाना चाहिए जो `deps` की ट्रांज़िटिव डिपेंडेंसी हैं. ध्यान दें कि यह एट्रिब्यूट, उन टारगेट में डिपेंडेंसी एज नहीं जोड़ रहा है. इसके बजाय, डिपेंडेंसी एज को `deps` से बनाया जाना चाहिए. इस एट्रिब्यूट में मौजूद एंट्री सिर्फ़ स्ट्रिंग होती हैं. ध्यान रखें कि इस एट्रिब्यूट में टारगेट सेट करने का मतलब है कि शेयर की गई लाइब्रेरी, उस टारगेट से सिंबल एक्सपोर्ट करती है. `cc_shared_library` लॉजिक, लिंकर को यह नहीं बताता कि किन सिंबल को एक्सपोर्ट किया जाना चाहिए. इस सिंटैक्स का इस्तेमाल किया जा सकता है: foo/BUILD में मौजूद किसी भी टारगेट के लिए `//foo:__pkg__` `//foo:__subpackages__` का इस्तेमाल, foo/BUILD या foo/ के नीचे मौजूद किसी अन्य पैकेज (जैसे कि foo/bar/BUILD) में मौजूद किसी टारगेट के लिए किया जाता है
`roots`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है
`shared_lib_name`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है डिफ़ॉल्ट रूप से cc_shared_library, शेयर की गई लाइब्रेरी की आउटपुट फ़ाइल के लिए एक नाम का इस्तेमाल करेगा. यह नाम, टारगेट के नाम और प्लैटफ़ॉर्म के आधार पर तय होगा. इसमें एक्सटेंशन और कभी-कभी प्रीफ़िक्स शामिल होता है. कभी-कभी आपको डिफ़ॉल्ट नाम नहीं चाहिए होता. उदाहरण के लिए, Python के लिए C++ शेयर की गई लाइब्रेरी लोड करते समय, अक्सर lib* प्रीफ़िक्स का इस्तेमाल नहीं किया जाता. ऐसे में, इस एट्रिब्यूट का इस्तेमाल करके, कस्टम नाम चुना जा सकता है.
`static_deps`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है
`user_link_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है कोई अन्य फ़्लैग जिसे आपको लिंकर को पास करना हो. उदाहरण के लिए, अगर आपको लिंक करने वाले को यह बताना है कि additional_linker_inputs के ज़रिए लिंक करने वाली स्क्रिप्ट पास की गई है, तो यहां दिए गए कोड का इस्तेमाल करें: `cc_shared_library( name = "foo_shared", additional_linker_inputs = select({ "//src/conditions:linux": [ ":foo.lds", ":additional_script.txt", ], "//conditions:default": []}), user_link_flags = select({ "//src/conditions:linux": [ "-Wl,-rpath,kittens", "-Wl,--version-script=$(location :foo.lds)", "-Wl,--script=$(location :additional_script.txt)", ], "//conditions:default": []}), ... )`
`win_def_file`	लेबल; डिफ़ॉल्ट वैल्यू `None` है Windows की DEF फ़ाइल, जिसे लिंकर को पास किया जाना है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब टारगेट प्लैटफ़ॉर्म Windows हो. इसका इस्तेमाल, शेयर की गई लाइब्रेरी को लिंक करते समय सिंबल एक्सपोर्ट करने के लिए किया जा सकता है.

cc_static_library

नियम का सोर्स देखें

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

यह टारगेट और उनकी ट्रांज़िटिव डिपेंडेंसी की सूची से एक स्टैटिक लाइब्रेरी बनाता है.

इससे बनने वाली स्टैटिक लाइब्रेरी में, deps में दी गई सूची में शामिल टारगेट की ऑब्जेक्ट फ़ाइलें होती हैं. साथ ही, उनकी ट्रांज़िटिव डिपेंडेंसी भी होती हैं. हालांकि, PIC ऑब्जेक्ट को प्राथमिकता दी जाती है.

आउटपुट ग्रुप

`linkdeps`

यह एक टेक्स्ट फ़ाइल होती है. इसमें deps में दी गई उन ट्रांज़िटिव डिपेंडेंसी के लेबल होते हैं जिन्होंने स्टैटिक लाइब्रेरी में कोई ऑब्जेक्ट फ़ाइल नहीं दी है. हालांकि, वे कम से कम एक स्टैटिक, डाइनैमिक या इंटरफ़ेस लाइब्रेरी उपलब्ध कराती हैं. लिंक करने के समय, नतीजे के तौर पर मिली स्टैटिक लाइब्रेरी के लिए इन लाइब्रेरी का उपलब्ध होना ज़रूरी हो सकता है.

`linkopts`

यह एक टेक्स्ट फ़ाइल होती है. इसमें उपयोगकर्ता की ओर से दी गई linkopts होती है. यह deps में दी गई सभी ट्रांज़िटिव डिपेंडेंसी की होती है.

डुप्लीकेट सिंबल

डिफ़ॉल्ट रूप से, cc_static_library नियम यह जांच करता है कि नतीजे के तौर पर मिली स्टैटिक लाइब्रेरी में कोई डुप्लीकेट सिंबल शामिल न हो. अगर ऐसा होता है, तो बिल्ड पूरा नहीं होता और गड़बड़ी का मैसेज दिखता है. इस मैसेज में, डुप्लीकेट सिंबल और उन्हें शामिल करने वाली ऑब्जेक्ट फ़ाइलों की सूची होती है.

इस जांच को हर टारगेट या हर पैकेज के लिए बंद किया जा सकता है. इसके लिए, features = ["-symbol_check"] सेट करें. इसके अलावा, इसे --features=-symbol_check के ज़रिए सभी टारगेट या पैकेज के लिए बंद किया जा सकता है.

`symbol_check` के लिए टूलचेन की सुविधा

Bazel के साथ शिप किए गए, अपने-आप कॉन्फ़िगर होने वाले C++ टूलचेन, सभी प्लैटफ़ॉर्म पर symbol_check सुविधा के साथ काम करते हैं. कस्टम टूलचेन, इन दो तरीकों में से किसी एक तरीके से इसके लिए सहायता जोड़ सकती हैं:

ACTION_NAMES.validate_static_library ऐक्शन लागू करना और symbol_check सुविधा की मदद से इसे चालू करना. कार्रवाई में सेट किया गया टूल, दो आर्ग्युमेंट के साथ शुरू होता है. पहला आर्ग्युमेंट, डुप्लीकेट सिंबल की जांच करने के लिए स्टैटिक लाइब्रेरी होती है. दूसरा आर्ग्युमेंट, उस फ़ाइल का पाथ होता है जिसे जांच पास होने पर बनाया जाना चाहिए.
symbol_check सुविधा चालू होने पर, आर्काइवर फ़्लैग जुड़ जाते हैं. इनकी वजह से, डुप्लीकेट सिंबल पर स्टैटिक लाइब्रेरी बनाने की कार्रवाई पूरी नहीं हो पाती.

तर्क

विशेषताएं

name

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.

deps

लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है

स्टैटिक लाइब्रेरी में शामिल किए जाने वाले टारगेट की सूची. इसमें उनकी सभी ट्रांज़िटिव डिपेंडेंसी भी शामिल हैं.

जिन डिपेंडेंसी से कोई ऑब्जेक्ट फ़ाइल नहीं मिलती उन्हें स्टैटिक लाइब्रेरी में शामिल नहीं किया जाता. हालांकि, उनके लेबल को linkdeps आउटपुट ग्रुप से मिली फ़ाइल में इकट्ठा किया जाता है.

cc_test

नियम का सोर्स देखें

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

cc_test() नियम, टेस्ट को कंपाइल करता है. यहां, टेस्ट, टेस्टिंग कोड के चारों ओर एक बाइनरी रैपर होता है.

डिफ़ॉल्ट रूप से, C++ टेस्ट डाइनैमिक तौर पर लिंक होते हैं.
यूनिट टेस्ट को स्टैटिक तौर पर लिंक करने के लिए, linkstatic=True को तय करें. यह टिप्पणी करना अच्छा होगा कि आपके टेस्ट को linkstatic की ज़रूरत क्यों है. शायद यह बात साफ़ तौर पर नहीं बताई गई है.

इंप्लिसिट आउटपुट टारगेट

name.stripped (सिर्फ़ अनुरोध करने पर बनाया जाता है): बाइनरी का स्ट्रिप्ड वर्शन. डीबग सिंबल हटाने के लिए, बाइनरी पर strip -g चलाया जाता है. कमांड लाइन पर --stripopt=-foo का इस्तेमाल करके, स्ट्रिप के अतिरिक्त विकल्प दिए जा सकते हैं.
name.dwp (सिर्फ़ अनुरोध करने पर बनाया जाता है): अगर Fission चालू है, तो यह एक डीबग जानकारी वाला पैकेज होता है. यह दूर से डिप्लॉय किए गए बाइनरी को डीबग करने के लिए सही होता है. अन्यथा: एक खाली फ़ाइल.

cc_binary() आर्ग्युमेंट देखें. हालांकि, टेस्ट के लिए stamp आर्ग्युमेंट की वैल्यू डिफ़ॉल्ट रूप से 0 पर सेट होती है. साथ ही, cc_test में टेस्ट के सभी नियमों (*_test) के लिए सामान्य एट्रिब्यूट होते हैं.

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये `cc_library` या `objc_library` टारगेट हो सकते हैं. लिंकर स्क्रिप्ट (.lds) को deps में रखने और उन्हें `linkopts` में रेफ़रंस करने की अनुमति भी है. हालांकि, कृपया इस मामले में `additional_linker_inputs` का इस्तेमाल करें.
`srcs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है C और C++ फ़ाइलों की सूची, जिन्हें लाइब्रेरी टारगेट बनाने के लिए प्रोसेस किया जाता है. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये जनरेट नहीं की गई हैं (सामान्य सोर्स कोड) या जनरेट की गई हैं. सभी `.cc`, `.c`, और `.cpp` फ़ाइलों को कंपाइल किया जाएगा. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर किसी नाम वाली फ़ाइल, किसी दूसरे नियम के `outs` में है, तो यह `cc_library` अपने-आप उस दूसरे नियम पर निर्भर करेगा. असेंबलर फ़ाइलों (.s, .asm) को पहले से प्रोसेस नहीं किया जाता है. इन्हें आम तौर पर असेंबलर का इस्तेमाल करके बनाया जाता है. प्रीप्रोसेस की गई असेंबली फ़ाइलों (.S) को प्रीप्रोसेस किया जाता है. इन्हें आम तौर पर C/C++ कंपाइलर का इस्तेमाल करके बनाया जाता है. `.h` फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, यह इस नियम के तहत आने वाले स्रोतों के लिए उपलब्ध रहेगी. `.cc` और `.h`, दोनों तरह की फ़ाइलों में, इन `srcs` में या इस नियम के `hdrs` में या `deps` आर्ग्युमेंट में दिए गए किसी भी नियम में शामिल हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी `#include`d फ़ाइलों का ज़िक्र, इस या रेफ़र की गई `cc_library` नियमों के `hdrs` एट्रिब्यूट में किया जाना चाहिए. अगर ये फ़ाइलें इस लाइब्रेरी के लिए निजी हैं, तो इन्हें `srcs` में शामिल किया जाना चाहिए. ज़्यादा जानकारी के लिए, "हेडर शामिल करने की जांच" देखें. `.so`, `.lo`, और `.a` फ़ाइलें, पहले से कंपाइल की गई फ़ाइलें हैं. अगर आपकी लाइब्रेरी में तीसरे पक्ष का ऐसा कोड इस्तेमाल किया गया है जिसका सोर्स कोड हमारे पास नहीं है, तो हो सकता है कि आपकी लाइब्रेरी में ये `srcs` के तौर पर मौजूद हों. अगर `srcs` एट्रिब्यूट में किसी दूसरे नियम का लेबल शामिल है, तो `cc_library`, कंपाइल करने के लिए उस नियम की आउटपुट फ़ाइलों को सोर्स फ़ाइलों के तौर पर इस्तेमाल करेगा. यह सोर्स कोड को एक बार जनरेट करने के लिए काम आता है. अगर आपको इसका इस्तेमाल कभी-कभी से ज़्यादा बार करना है, तो Starlark नियम क्लास लागू करना और `cc_common` एपीआई का इस्तेमाल करना बेहतर होता है `srcs` के लिए इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: C और C++ सोर्स फ़ाइलें: `.c`, `.cc`, `.cpp`, `.cxx`, `.c++`, `.C` C और C++ हेडर फ़ाइलें: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` सी प्रीप्रोसेसर के साथ असेंबलर: `.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`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है ऐसी डिपेंडेंसी जो सिर्फ़ C++ लिंकर कमांड के लिए उपलब्ध कराई जाती हैं. `deps` को कंपाइल करने और लिंक करने की डिपेंडेंसी, दोनों के लिए बनाया गया है. वहीं, `additional_linker_inputs` को सिर्फ़ लिंक करने की डिपेंडेंसी के लिए बनाया गया है. यह ऐसी डिपेंडेंसी का सिग्नल देता है जो सिर्फ़ लिंक करने के लिए ज़रूरी है. उदाहरण के लिए, `linkopts` में रेफ़र की गई फ़ाइलें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.
`conlyopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इन विकल्पों को C कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.
`copts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है C/C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, दिए गए क्रम में `COPTS` में जोड़ा जाता है. इसके बाद, बाइनरी टारगेट को कंपाइल किया जाता है. ये फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, इसकी डिपेंडेंसी के लिए नहीं. इसलिए, किसी दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस के हिसाब से होने चाहिए. इस एट्रिब्यूट की ज़रूरत `third_party` के बाहर नहीं होनी चाहिए. अगर पैकेज में सुविधा `no_copts_tokenization` के बारे में बताया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.
`cxxopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.
`defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस और इससे जुड़े सभी टारगेट की कंपाइल लाइन में जोड़ने के लिए, डिफ़ाइन की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शेल टोकन होना चाहिए. इसे `-D` से पहले जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. इसके अलावा, इसे इस पर निर्भर हर नियम में भी जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. इस टारगेट पर निर्भर रहने वाले हर टारगेट में, परिभाषाएं जोड़ी जाती हैं. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय `local_defines` में वैल्यू तय करें.
`dynamic_deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है ये अन्य `cc_shared_library` डिपेंडेंसी हैं, जिन पर मौजूदा टारगेट निर्भर करता है. `cc_shared_library` को लागू करने के लिए, `dynamic_deps` की सूची का इस्तेमाल किया जाएगा.इसमें `dynamic_deps` (ट्रांज़िटिव तौर पर, यानी कि मौजूदा टारगेट के `dynamic_deps` का `dynamic_deps` भी) शामिल है. इससे यह तय किया जा सकेगा कि ट्रांज़िटिव `deps` में मौजूद कौनसे `cc_libraries` को लिंक नहीं किया जाना चाहिए, क्योंकि उन्हें पहले ही किसी दूसरे `cc_shared_library` ने उपलब्ध करा दिया है.
`hdrs_check`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है अब सेवा में नहीं है, कोई कार्रवाई नहीं की जाती.
`includes`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है शामिल किए जाने वाले डायरेक्ट्री की सूची, जिसे कंपाइल लाइन में जोड़ा जाना है. "बदलाव के हिसाब से" विकल्प के तहत बदलाव किया जा सकता है. हर स्ट्रिंग के पहले पैकेज का पाथ जोड़ा जाता है. इसके बाद, इसे C++ टूलचेन को पास किया जाता है. ऐसा "include_paths" CROSSTOOL सुविधा के ज़रिए किया जाता है. POSIX सिस्टम पर चलने वाला टूलचेन, सामान्य सुविधाओं की परिभाषाओं के साथ `-isystem path_to_package/include_entry` जनरेट करेगा. इसका इस्तेमाल सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के लिए किया जाना चाहिए जो #include स्टेटमेंट लिखने के Google के तरीके का पालन नहीं करती हैं. COPTS के उलट, इन फ़्लैग को इस नियम और इस पर निर्भर हर नियम के लिए जोड़ा जाता है. (ध्यान दें: यह उन नियमों के बारे में नहीं है जिन पर यह निर्भर करता है!) बहुत ज़्यादा सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. अगर आपको किसी तरह का संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. जोड़े गए `include` पाथ में, जनरेट की गई फ़ाइलों के साथ-साथ सोर्स ट्री में मौजूद फ़ाइलें भी शामिल होंगी.
`link_extra_lib`	लेबल; डिफ़ॉल्ट वैल्यू `"@bazel_tools//tools/cpp:link_extra_lib"` है इस कुकी से, अन्य लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल किया जाता है. C++ बाइनरी, डिफ़ॉल्ट रूप से `@bazel_tools//tools/cpp:link_extra_lib` से लिंक होती हैं. यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग `@bazel_tools//tools/cpp:link_extra_libs` पर निर्भर करता है. फ़्लैग सेट न करने पर, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग सेट करने से, वैकल्पिक डिपेंडेंसी लिंक की जा सकती हैं. जैसे, कमज़ोर सिंबल के लिए ओवरराइड, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के विकल्पों के लिए, `malloc` या `--custom_malloc` का इस्तेमाल करें). इस एट्रिब्यूट को `None` पर सेट करने से, यह सुविधा बंद हो जाती है.
`linkopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "Make" वैरिएबल के हिसाब से बदलाव किया जा सकता है. Bourne shell टोकनाइज़ेशन और लेबल एक्सपैंशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट से लिंक करने से पहले `LINKOPTS` में जोड़ा जाता है. इस सूची का हर ऐसा एलिमेंट जो `$` या `-` से शुरू नहीं होता है उसे `deps` में टारगेट का लेबल माना जाता है. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या `deps` में इसका एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
`linkshared`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है शेयर की गई लाइब्रेरी बनाएं. इस एट्रिब्यूट को चालू करने के लिए, अपने नियम में `linkshared=True` शामिल करें. डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है. इस फ़्लैग की मौजूदगी का मतलब है कि `-shared` फ़्लैग के साथ `gcc` से लिंक किया गया है. साथ ही, इससे बनी शेयर की गई लाइब्रेरी को लोड किया जा सकता है. उदाहरण के लिए, Java प्रोग्राम में. हालांकि, बिल्ड करने के लिए इसे कभी भी निर्भर बाइनरी में लिंक नहीं किया जाएगा. ऐसा इसलिए, क्योंकि यह माना जाता है कि cc_binary नियम के साथ बनाई गई शेयर की गई लाइब्रेरी को सिर्फ़ अन्य प्रोग्राम मैन्युअल तरीके से लोड करते हैं. इसलिए, इसे cc_library नियम के विकल्प के तौर पर नहीं माना जाना चाहिए. हमारा सुझाव है कि स्केलेबिलिटी के लिए, इस तरीके का इस्तेमाल न करें. इसके बजाय, `java_library` को `cc_library` नियमों पर निर्भर रहने दें. `linkopts=['-static']` और `linkshared=True`, दोनों को तय करने पर, आपको एक ऐसी यूनिट मिलती है जिसमें सभी ज़रूरी जानकारी शामिल होती है. `linkstatic=True` और `linkshared=True`, दोनों को शामिल करने पर आपको एक यूनिट मिलती है. इसमें ज़्यादातर जानकारी शामिल होती है.
`linkstatic`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है `cc_binary` और `cc_test` के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. `cc_library.link_static` के लिए: यहां देखें. डिफ़ॉल्ट रूप से, यह विकल्प `cc_binary` के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी संभव हो, उपयोगकर्ता लाइब्रेरी के लिए `.so`'s के बजाय `.a`'s को लिंक करें. libc जैसी सिस्टम लाइब्रेरी अब भी डाइनैमिक तरीके से लिंक की जाती हैं. हालांकि, C/C++ रनटाइम लाइब्रेरी नहीं (नीचे देखें). साथ ही, जिन लाइब्रेरी के लिए कोई स्टैटिक लाइब्रेरी नहीं है उन्हें भी डाइनैमिक तरीके से लिंक किया जाता है. इसलिए, एक्ज़ीक्यूटेबल फ़ाइल अब भी डाइनैमिक रूप से लिंक होगी. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगी. किसी एक्ज़ीक्यूटेबल को लिंक करने के तीन अलग-अलग तरीके हैं: STATIC, जिसमें पूरी तरह से स्टैटिक लिंक की सुविधा होती है. इसमें सब कुछ स्टैटिक तौर पर लिंक किया जाता है; उदाहरण के लिए, "`gcc -static foo.o libbar.a libbaz.a -lm`". इस मोड को चालू करने के लिए, `features` एट्रिब्यूट में `fully_static_link` की वैल्यू डालें. STATIC, इसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, इसमें सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है. उदाहरण के लिए, "`gcc foo.o libfoo.a libbaz.a -lm`". इस मोड को `linkstatic=True` तय करके चालू किया जाता है. डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाती हैं.ऐसा तब होता है, जब डाइनैमिक वर्शन उपलब्ध हो. उदाहरण के लिए, "`gcc foo.o libfoo.so libbaz.so -lm`". इस मोड को `linkstatic=False` को तय करके चालू किया जाता है. अगर `linkstatic` एट्रिब्यूट या `fully_static_link` in `features` का इस्तेमाल `//third_party` के बाहर किया गया है, तो कृपया नियम के पास एक टिप्पणी शामिल करें. इसमें बताएं कि ऐसा क्यों किया गया है. `cc_library()` नियम में इस्तेमाल करने पर, `linkstatic` एट्रिब्यूट का मतलब अलग होता है. C++ लाइब्रेरी के लिए, `linkstatic=True` से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई `.so` नहीं बनाया जाएगा. linkstatic=False से स्टैटिक लाइब्रेरी बनाने पर कोई असर नहीं पड़ता. इस एट्रिब्यूट का इस्तेमाल, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करने के लिए किया जाता है. प्रोडक्शन में `linkstatic=False` का इस्तेमाल करके बहुत कम कोड बनाया जाना चाहिए. अगर `linkstatic=False` है, तो बिल्ड टूल, `*.runfiles` फ़ोल्डर में मौजूद, इस्तेमाल की गई शेयर की गई लाइब्रेरी के लिए सिमलंक बनाएगा.
`local_defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है कंपाइल लाइन में जोड़ने के लिए, तय की गई वैल्यू की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शैल टोकन होना चाहिए. इसके पहले `-D` जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे इसके डिपेंडेंट में नहीं जोड़ा जाता. `defines` के उलट, इस टारगेट के लिए सिर्फ़ कंपाइल कमांड लाइन में, 'डिफ़ाइन' जोड़े जाते हैं.
`malloc`	लेबल; डिफ़ॉल्ट वैल्यू `"@bazel_tools//tools/cpp:malloc"` है malloc पर डिफ़ॉल्ट डिपेंडेंसी को बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी को `//tools/cpp:malloc` के साथ लिंक किया जाता है. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी libc malloc का इस्तेमाल करती है. इस लेबल में, `cc_library` का रेफ़रंस होना चाहिए. अगर कंपाइल करने का नियम C++ का नहीं है, तो इस विकल्प का कोई असर नहीं होता. अगर `linkshared=True` एट्रिब्यूट की वैल्यू दी गई है, तो इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है.
`module_interfaces`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है फ़ाइलों की सूची को C++20 मॉड्यूल इंटरफ़ेस माना जाता है. C++ स्टैंडर्ड में, मॉड्यूल इंटरफ़ेस फ़ाइल एक्सटेंशन के बारे में कोई पाबंदी नहीं है Clang का इस्तेमाल करने वाले cppm GCC, किसी भी सोर्स फ़ाइल एक्सटेंशन का इस्तेमाल कर सकता है MSVC ixx का इस्तेमाल करता है इस सुविधा का इस्तेमाल, `--experimental_cpp_modules` फ़्लैग के ज़रिए किया जाता है.
`nocopts`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है C++ कंपाइलेशन कमांड से, मिलते-जुलते विकल्पों को हटाएं. "Make" वैरिएबल को बदला जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले किसी भी मौजूदा `COPTS` (इसमें नियम के copts एट्रिब्यूट में साफ़ तौर पर बताई गई वैल्यू भी शामिल हैं) को इस नियम को कंपाइल करने के लिए, `COPTS` से हटा दिया जाएगा. इस एट्रिब्यूट की ज़रूरत `third_party` के बाहर नहीं होनी चाहिए. साथ ही, इसका इस्तेमाल भी `third_party` के बाहर नहीं किया जाना चाहिए. "Make" वैरिएबल के बदले जाने के अलावा, वैल्यू को किसी भी तरह से पहले से प्रोसेस नहीं किया जाता है.
`reexport_deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है
`stamp`	पूर्णांक; डिफ़ॉल्ट वैल्यू `0` है बाइनरी में बिल्ड की जानकारी को कोड में बदलना है या नहीं. इन वैल्यू का इस्तेमाल किया जा सकता है: `stamp = 1`: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. भले ही, वह `--nostamp` बिल्ड हो. इस सेटिंग का इस्तेमाल नहीं करना चाहिए, क्योंकि इससे बाइनरी और उस पर निर्भर डाउनस्ट्रीम कार्रवाइयों के लिए रिमोट कैश मेमोरी बंद हो जाती है. `stamp = 0`: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे बिल्ड के नतीजों को बेहतर तरीके से कैश मेमोरी में सेव किया जा सकता है. `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने की प्रोसेस को `--[no]stamp` फ़्लैग कंट्रोल करता है. स्टैंप किए गए बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो.
`win_def_file`	लेबल; डिफ़ॉल्ट वैल्यू `None` है Windows की DEF फ़ाइल, जिसे लिंकर को पास किया जाना है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब टारगेट प्लैटफ़ॉर्म Windows हो. इसका इस्तेमाल, शेयर की गई लाइब्रेरी को लिंक करते समय सिंबल एक्सपोर्ट करने के लिए किया जा सकता है.

cc_toolchain

नियम का सोर्स देखें

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

यह C++ टूलचेन के बारे में बताता है.

यह नियम इन कामों के लिए ज़िम्मेदार है:

C++ कार्रवाइयों को चलाने के लिए ज़रूरी सभी आर्टफ़ैक्ट इकट्ठा किए जा रहे हैं. ऐसा all_files, compiler_files, linker_files या _files से खत्म होने वाले अन्य एट्रिब्यूट जैसे एट्रिब्यूट की मदद से किया जाता है. ये आम तौर पर, सभी ज़रूरी फ़ाइलों को ग्लोब करने वाले फ़ाइलग्रुप होते हैं.
C++ कार्रवाइयों के लिए सही कमांड लाइन जनरेट करना. यह काम CcToolchainConfigInfo की मदद से किया जाता है. इसकी जानकारी यहां दी गई है.

C++ टूलचेन को कॉन्फ़िगर करने के लिए, toolchain_config एट्रिब्यूट का इस्तेमाल करें. C++ टूलचेन कॉन्फ़िगरेशन और टूलचेन चुनने से जुड़े दस्तावेज़ के बारे में ज़्यादा जानकारी के लिए, यह पेज भी देखें.

bazel build //... को लागू करते समय, टूलचेन को बिना वजह बनाए जाने और कॉन्फ़िगर किए जाने से रोकने के लिए, tags = ["manual"] का इस्तेमाल करें

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`all_files`	लेबल; ज़रूरी है cc_toolchain के सभी आर्टफ़ैक्ट का कलेक्शन. इन आर्टफ़ैक्ट को, rules_cc से जुड़ी सभी कार्रवाइयों के लिए इनपुट के तौर पर जोड़ा जाएगा. हालांकि, उन कार्रवाइयों के लिए ऐसा नहीं किया जाएगा जो नीचे दिए गए एट्रिब्यूट से आर्टफ़ैक्ट के ज़्यादा सटीक सेट का इस्तेमाल कर रही हैं. Bazel यह मानता है कि `all_files`, आर्टफ़ैक्ट उपलब्ध कराने वाले सभी अन्य एट्रिब्यूट का सुपरसेट है.उदाहरण के लिए, लिंकस्टैंप कंपाइलेशन के लिए कंपाइल और लिंक, दोनों फ़ाइलों की ज़रूरत होती है. इसलिए, यह `all_files` लेता है. `cc_toolchain.files` में यह जानकारी शामिल होती है. इसका इस्तेमाल C++ टूलचेन का इस्तेमाल करने वाले सभी Starlark नियमों में किया जाता है.
`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`	लेबल; ज़रूरी है dwp कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
`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`	लेबल; ज़रूरी है objcopy कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
`output_licenses`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है
`static_runtime_lib`	लेबल; डिफ़ॉल्ट वैल्यू `None` है C++ रनटाइम लाइब्रेरी के लिए स्टैटिक लाइब्रेरी आर्टफ़ैक्ट (जैसे, libstdc++.a). इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू हो और हम डिपेंडेंसी को स्टैटिक तौर पर लिंक कर रहे हों.
`strip_files`	लेबल; ज़रूरी है स्ट्रिप ऐक्शन के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
`supports_header_parsing`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है cc_toolchain में हेडर पार्स करने की कार्रवाइयां काम करने पर, इसे True पर सेट करें.
`supports_param_files`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है cc_toolchain, लिंकिंग कार्रवाइयों के लिए पैरामीटर फ़ाइलों का इस्तेमाल करने की सुविधा देता है, तो इसे True पर सेट करें.
`toolchain_config`	लेबल; ज़रूरी है `cc_toolchain_config_info` की सुविधा देने वाले नियम का लेबल.
`toolchain_identifier`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है इस cc_toolchain को इससे मिलते-जुलते crosstool_config.toolchain से मैच करने के लिए इस्तेमाल किया गया आइडेंटिफ़ायर. समस्या #5380 ठीक होने तक, `cc_toolchain` को `CROSSTOOL.toolchain` से जोड़ने का यह तरीका सुझाया जाता है. इसे `toolchain_config` एट्रिब्यूट (#5380) से बदल दिया जाएगा.

fdo_prefetch_hints

नियम का सोर्स देखें

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

यह एक ऐसी FDO प्रीफ़ेच हिंट प्रोफ़ाइल को दिखाता है जो वर्कस्पेस में मौजूद है. उदाहरण:


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

तर्क

विशेषताएं

name

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.

profile

लेबल; ज़रूरी है

सुझाव देने वाली प्रोफ़ाइल का लेबल. हिंट फ़ाइल में .afdo एक्सटेंशन होता है लेबल, fdo_absolute_path_profile नियम की ओर भी इशारा कर सकता है.

fdo_profile

नियम का सोर्स देखें

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

यह Workspace में मौजूद FDO प्रोफ़ाइल को दिखाता है. उदाहरण:


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

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`memprof_profile`	लेबल; डिफ़ॉल्ट वैल्यू `None` है MemProf प्रोफ़ाइल का लेबल. प्रोफ़ाइल में, .profdata एक्सटेंशन (इंडेक्स की गई/सिंबल वाली memprof प्रोफ़ाइल के लिए) या .zip एक्सटेंशन (memprof.profdata फ़ाइल वाली zipfile के लिए) होना चाहिए.
`profile`	लेबल; ज़रूरी है एफ़डीओ प्रोफ़ाइल का लेबल या उसे जनरेट करने वाला नियम. FDO फ़ाइल में इनमें से कोई एक एक्सटेंशन हो सकता है: .profraw, जो इंडेक्स नहीं की गई LLVM प्रोफ़ाइल के लिए होता है, .profdata, जो इंडेक्स की गई LLVM प्रोफ़ाइल के लिए होता है, .zip, जिसमें LLVM profraw प्रोफ़ाइल होती है, .afdo, जो AutoFDO प्रोफ़ाइल के लिए होता है, .xfdo, जो XBinary प्रोफ़ाइल के लिए होता है. यह लेबल, fdo_absolute_path_profile नियम की ओर भी इशारा कर सकता है.
`proto_profile`	लेबल; डिफ़ॉल्ट वैल्यू `None` है प्रोटोबफ़ प्रोफ़ाइल का लेबल.

memprof_profile

नियम का सोर्स देखें

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

यह वर्कस्पेस में मौजूद MEMPROF प्रोफ़ाइल को दिखाता है. उदाहरण:


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

तर्क

विशेषताएं

name

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.

profile

लेबल; ज़रूरी है

MEMPROF प्रोफ़ाइल का लेबल. प्रोफ़ाइल में, .profdata एक्सटेंशन (इंडेक्स की गई/सिंबल वाली memprof प्रोफ़ाइल के लिए) या .zip एक्सटेंशन (memprof.profdata फ़ाइल वाली zipfile के लिए) होना चाहिए. यह लेबल, fdo_absolute_path_profile नियम की ओर भी इशारा कर सकता है.

propeller_optimize

नियम का सोर्स देखें

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

यह वर्कस्पेस में Propeller की ऑप्टिमाइज़ेशन प्रोफ़ाइल को दिखाता है. उदाहरण:


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

तर्क

विशेषताएं

name

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.

cc_profile

लेबल; ज़रूरी है

प्रोफ़ाइल का लेबल, जिसे अलग-अलग कंपाइल कार्रवाइयों में पास किया गया है. इस फ़ाइल में .txt एक्सटेंशन है.

ld_profile

लेबल; ज़रूरी है

लिंक करने की कार्रवाई के लिए पास की गई प्रोफ़ाइल का लेबल. इस फ़ाइल में .txt एक्सटेंशन है.

C / C++ नियम संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

नियम

cc_binary

इंप्लिसिट आउटपुट टारगेट

तर्क

cc_import

तर्क

cc_library

हेडर शामिल करने की जांच की जा रही है

उदाहरण

तर्क

cc_shared_library

उदाहरण

गड़बड़ियां

Two shared libraries in dependencies export the same symbols.

Two shared libraries in dependencies link the same library statically

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

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

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

तर्क

cc_static_library

आउटपुट ग्रुप

linkdeps

linkopts

डुप्लीकेट सिंबल

symbol_check के लिए टूलचेन की सुविधा

तर्क

cc_test

इंप्लिसिट आउटपुट टारगेट

तर्क

cc_toolchain

तर्क

fdo_prefetch_hints

तर्क

fdo_profile

तर्क

memprof_profile

तर्क

propeller_optimize

तर्क

C / C++ नियम

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

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

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

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

`linkdeps`

`linkopts`

`symbol_check` के लिए टूलचेन की सुविधा