💚 Bazel को बेहतर बनाने में हमारी मदद करने के लिए, Bazel के उपयोगकर्ताओं के लिए उपलब्ध सर्वे में हिस्सा लें: https://bazel.build/survey 💚

इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.2 · 8.1 · 8.0 · 7.6 · 7.5

cc_binary

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

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

इससे एक ऐसी बाइनरी बनती है जिसे चलाया जा सकता है.

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

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

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

तर्क

विशेषताएं
`name`	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये `cc_library` या `objc_library` टारगेट हो सकते हैं. लिंकर स्क्रिप्ट (.lds) को डिपेंडेंसी में डालने और `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` 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`	लेबल की सूची; डिफ़ॉल्ट `[]` है ऐसी डिपेंडेंसी जो सिर्फ़ C++ लिंकर कमांड के लिए उपलब्ध होती हैं. `deps`, कॉम्पाइलेशन और लिंक करने के लिए बनाया गया है. वहीं, `additional_linker_inputs` सिर्फ़ लिंक करने के लिए बनाया गया है. यह सिर्फ़ उस डिपेंडेंसी के बारे में बताता है जो सिर्फ़ लिंक करने के लिए ज़रूरी है. उदाहरण के लिए, `linkopts` में रेफ़र की गई फ़ाइलें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, यहां इकट्ठा की गई Windows .res फ़ाइलें दी जा सकती हैं.
`conlyopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` C कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.
`copts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` C/C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. बाइनरी टारगेट को संकलित करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में `COPTS` में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, न कि उसकी डिपेंडेंसी के लिए. इसलिए, दूसरी जगह शामिल हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस से जुड़े होने चाहिए. `third_party` के अलावा, इस एट्रिब्यूट की ज़रूरत नहीं होती. अगर पैकेज में feature `no_copts_tokenization` का एलान किया गया है, तो Bourne shell टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल होता है.
`cxxopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.
`defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस और उन सभी टारगेट की कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची जिन पर यह निर्भर है. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे `-D` जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल करने की कमांड लाइन में और उस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई तरह के असर पड़ सकते हैं -- इस टारगेट पर निर्भर हर टारगेट में, परिभाषाएं जोड़ी जाती हैं. अगर आपको नहीं पता कि 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`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` कंपाइल लाइन में जोड़ी जाने वाली शामिल डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प के हिसाब से बदला जा सकता है. हर स्ट्रिंग को पैकेज पाथ के साथ जोड़ा जाता है और "include_paths" CROSSTOOL सुविधा की मदद से, C++ टूलचेन को बड़ा करने के लिए पास किया जाता है. सामान्य सुविधाओं की परिभाषाओं के साथ, POSIX सिस्टम पर चलने वाला टूलचेन, `-isystem path_to_package/include_entry` जनरेट करेगा. इसका इस्तेमाल सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के लिए किया जाना चाहिए जो #include स्टेटमेंट लिखने के Google के स्टाइल के मुताबिक नहीं हैं. COPTS के उलट, ये फ़्लैग इस नियम और उस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: उन नियमों के बारे में नहीं जिन पर यह निर्भर करता है!) बहुत सावधान रहें, क्योंकि इससे काफ़ी असर पड़ सकता है. अगर आपको कोई संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. जोड़े गए `include` पाथ में, जनरेट की गई फ़ाइलों के साथ-साथ सोर्स ट्री में मौजूद फ़ाइलें भी शामिल होंगी.
`link_extra_lib`	लेबल; डिफ़ॉल्ट `"@bazel_tools//tools/cpp:link_extra_lib"` है अतिरिक्त लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल करना. डिफ़ॉल्ट रूप से, C++ बाइनरी `//tools/cpp:link_extra_lib` के साथ लिंक होती हैं. यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग `//tools/cpp:link_extra_libs` पर निर्भर करता है. फ़्लैग सेट किए बिना, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग सेट करने पर, वैकल्पिक डिपेंडेंसी को लिंक किया जा सकता है. जैसे, कमज़ोर सिंबल के लिए बदलाव, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के बदले, `malloc` या `--custom_malloc` का इस्तेमाल करें). इस एट्रिब्यूट को `None` पर सेट करने से, यह सुविधा बंद हो जाती है.
`linkopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` C++ लिंकर कमांड में ये फ़्लैग जोड़ें. "Make" वैरिएबल के बदले, Bourne शेल टोकनाइज़ेशन और लेबल एक्सपैंशन का इस्तेमाल किया जा सकता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को `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` के बजाय `.a` को लिंक करने के लिए कहता है. libc जैसी सिस्टम लाइब्रेरी (लेकिन C/C++ रनटाइम लाइब्रेरी नहीं, नीचे देखें) अब भी डाइनैमिक तौर पर लिंक की जाती हैं. साथ ही, ऐसी लाइब्रेरी भी डाइनैमिक तौर पर लिंक की जाती हैं जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे में मिलने वाला एक्सीक्यूटेबल अब भी डाइनैमिक तौर पर लिंक किया जाएगा. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगा. किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं: fully_static_link सुविधा के साथ स्टैटिक, जिसमें सब कुछ स्टैटिक तौर पर लिंक किया गया है; उदाहरण के लिए, "`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` डालकर, यह मोड चालू किया जाता है. अगर `features` में `linkstatic` एट्रिब्यूट या `fully_static_link` का इस्तेमाल `//third_party` के बाहर किया गया है, तो कृपया नियम के बगल में एक टिप्पणी शामिल करें और बताएं कि ऐसा क्यों किया गया है. `linkstatic` एट्रिब्यूट का इस्तेमाल `cc_library()` नियम के लिए करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, `linkstatic=True` से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई `.so` नहीं बनाया जाएगा. linkstatic=False से स्टैटिक लाइब्रेरी बनने से नहीं रोका जा सकता. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है. प्रोडक्शन में, `linkstatic=False` के साथ बहुत कम कोड बनाया जाना चाहिए. अगर `linkstatic=False` है, तो बिल्ड टूल `*.runfiles` एरिया में, उन शेयर की गई लाइब्रेरी के लिए सिंबललिंक बनाएगा जिन पर निर्भर किया गया है.
`local_defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` कंपाइल लाइन में जोड़ने के लिए, डिफ़ाइन की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे `-D` जोड़ा जाता है. साथ ही, इस टारगेट के लिए, स्ट्रिंग को कंपाइल करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए. `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` के अलावा, इस एट्रिब्यूट की ज़रूरत नहीं होनी चाहिए या इसका इस्तेमाल नहीं किया जाना चाहिए. वैल्यू को "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, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, package_metadata, pic_objects, pic_static_library, restricted_to, shared_library, static_library, 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 में 'शामिल करें' एट्रिब्यूट का इस्तेमाल किया जा सकता है. उदाहरण के लिए:


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` अगर 1 है, तो सी++ की इस पहले से संकलित लाइब्रेरी पर सीधे या किसी अन्य तरीके से निर्भर रहने वाली कोई भी बाइनरी, स्टैटिक लाइब्रेरी में संग्रहित सभी ऑब्जेक्ट फ़ाइलों को लिंक करेगी. भले ही, उनमें से कुछ में बाइनरी के रेफ़रंस वाले कोई सिंबल न हो. यह तब काम आता है, जब बाइनरी में कोड से आपके कोड को साफ़ तौर पर कॉल नहीं किया जाता. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिलने वाला कॉलबैक पाने के लिए रजिस्टर करता है. अगर Windows पर VS 2017 के साथ alwayslink काम नहीं करता है, तो इसकी वजह पहले से मौजूद समस्या है. कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें.
`includes`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` कंपाइल लाइन में जोड़ी जाने वाली शामिल डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प के हिसाब से बदला जा सकता है. हर स्ट्रिंग को पैकेज पाथ के साथ जोड़ा जाता है और "include_paths" CROSSTOOL सुविधा की मदद से, C++ टूलचेन को बड़ा करने के लिए पास किया जाता है. सामान्य सुविधाओं की परिभाषाओं के साथ, 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 शेल टोकनाइज़ेशन और लेबल एक्सपैंशन का इस्तेमाल किया जा सकता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को `LINKOPTS` में जोड़ा जाता है. इस सूची के हर उस एलिमेंट को `deps` में टारगेट का लेबल माना जाता है जो `$` या `-` से शुरू नहीं होता. उस टारगेट से जनरेट हुई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या `deps` में एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
`objects`	लेबल की सूची; डिफ़ॉल्ट `[]` है
`pic_objects`	लेबल की सूची; डिफ़ॉल्ट `[]` है
`pic_static_library`	लेबल; डिफ़ॉल्ट `None` है
`shared_library`	लेबल; डिफ़ॉल्ट `None` है पहले से कंपाइल की गई एक शेयर की गई लाइब्रेरी. Bazel यह पक्का करता है कि वह रनटाइम के दौरान, उस बाइनरी के लिए उपलब्ध हो जिस पर वह निर्भर करता है. इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: `.so`, `.dll` या `.dylib`
`static_library`	लेबल; डिफ़ॉल्ट `None` है पहले से कंपाइल की गई एक स्टैटिक लाइब्रेरी. इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: `.a`, `.pic.a` या `.lib`
`system_provided`	बूलियन; डिफ़ॉल्ट तौर पर `False` अगर 1 है, तो इसका मतलब है कि रनटाइम के दौरान ज़रूरी शेयर की गई लाइब्रेरी, सिस्टम से मिलती है. इस मामले में, `interface_library` की वैल्यू दी जानी चाहिए और `shared_library` खाली होना चाहिए.

cc_library

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

cc_library(name, deps, srcs, data, hdrs, additional_compiler_inputs, additional_linker_inputs, alwayslink, compatible_with, conlyopts, copts, cxxopts, defines, deprecation, 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 पर निर्भर करती है, तो उस पर निर्भर लाइब्रेरी के नियम का आउटपुट .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 फ़ाइल को कंपाइल करने पर, deps क्लोज़र में मौजूद किसी भी cc_library में, hdrs या srcs में ट्रांज़िटिव तौर पर कोई भी हेडर फ़ाइल शामिल हो सकती है. इस मामले में, foo.cc को कंपाइल करते समय कंपाइलर, baz.h और baz-impl.h को पढ़ सकता है. हालांकि, foo.cc में #include "baz.h" नहीं होना चाहिए. इसके लिए, foo के deps में baz को जोड़ना होगा.

शामिल करने की जांच के नियमों को लागू करने के लिए, 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 = 1,
)

यह उदाहरण 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` C प्रीप्रोसेसर वाला असेंबलर: `.S` संग्रहित करें: `.a`, `.pic.a` "हमेशा लिंक करें" लाइब्रेरी: `.lo`, `.pic.lo` शेयर की गई लाइब्रेरी, वर्शन वाली या वर्शन वाली नहीं: `.so`, `.so.version` ऑब्जेक्ट फ़ाइल: `.o`, `.pic.o` ... और उन फ़ाइलों को बनाने वाले सभी नियम (उदाहरण के लिए, `cc_embed_data`). अलग-अलग एक्सटेंशन, gcc के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
`data`	लेबल की सूची; डिफ़ॉल्ट `[]` है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. `data` के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों से तय किए गए सामान्य एट्रिब्यूट पर जाएं. अगर `data`, जनरेट की गई फ़ाइल का नाम है, तो यह `cc_library` नियम, जनरेट करने वाले नियम पर अपने-आप निर्भर करता है. अगर `data` किसी नियम का नाम है, तो यह `cc_library` नियम अपने-आप उस नियम पर निर्भर करता है, और उस नियम के `outs`, इस `cc_library` की डेटा फ़ाइलों में अपने-आप जुड़ जाते हैं. आपका C++ कोड इन डेटा फ़ाइलों को इस तरह ऐक्सेस कर सकता है: `const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");`
`hdrs`	लेबल की सूची; डिफ़ॉल्ट `[]` है इस लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची, ताकि सोर्स उन्हें सीधे तौर पर, डिपेंडेंट नियमों में शामिल कर सकें. लाइब्रेरी के इंटरफ़ेस के बारे में बताने वाली हेडर फ़ाइलों को यहां एलान करना सबसे सही होता है. इन हेडर को इस नियम या उससे जुड़े नियमों में सोर्स के ज़रिए शामिल करने के लिए उपलब्ध कराया जाएगा. जिन हेडर को इस लाइब्रेरी के क्लाइंट को शामिल नहीं करना है उन्हें `srcs` एट्रिब्यूट में शामिल किया जाना चाहिए. भले ही, उन्हें पब्लिश किए गए हेडर में शामिल किया गया हो. ज़्यादा जानकारी के लिए, "हेडलाइन में शामिल करने की जांच" देखें. `headers` फ़ाइल टाइप के लिए अनुमति है: `.h`, `.hh`, `.hpp`, `.hxx`.
`additional_compiler_inputs`	लेबल की सूची; डिफ़ॉल्ट `[]` है ऐसी कोई भी अतिरिक्त फ़ाइल जिसे आपको कंपाइलर कमांड लाइन में पास करना है. उदाहरण के लिए, sanitizer की सूची. इसके बाद, यहां बताई गई फ़ाइलों का इस्तेमाल, copts में $(location) फ़ंक्शन के साथ किया जा सकता है.
`additional_linker_inputs`	लेबल की सूची; डिफ़ॉल्ट `[]` है ऐसी डिपेंडेंसी जो सिर्फ़ C++ लिंकर कमांड के लिए उपलब्ध होती हैं. `deps`, कॉम्पाइलेशन और लिंक करने के लिए बनाया गया है. वहीं, `additional_linker_inputs` सिर्फ़ लिंक करने के लिए बनाया गया है. यह सिर्फ़ उस डिपेंडेंसी के बारे में बताता है जो सिर्फ़ लिंक करने के लिए ज़रूरी है. उदाहरण के लिए, `linkopts` में रेफ़र की गई फ़ाइलें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, यहां इकट्ठा की गई Windows .res फ़ाइलें दी जा सकती हैं.
`alwayslink`	बूलियन; डिफ़ॉल्ट तौर पर `False` अगर 1 है, तो सीधे या किसी दूसरे तरीके से इस C++ लाइब्रेरी पर निर्भर रहने वाली कोई भी बाइनरी, `srcs` में दी गई फ़ाइलों की सभी ऑब्जेक्ट फ़ाइलों को लिंक करेगी. भले ही, कुछ फ़ाइलों में बाइनरी का रेफ़रंस देने वाला कोई सिंबल न हो. यह तब काम आता है, जब बाइनरी में कोड से आपके कोड को साफ़ तौर पर कॉल नहीं किया जाता. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिलने वाला कॉलबैक पाने के लिए रजिस्टर करता है. अगर Windows पर VS 2017 के साथ alwayslink काम नहीं करता है, तो इसकी वजह पहले से मौजूद समस्या है. कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें.
`conlyopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` C कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.
`copts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` C/C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. बाइनरी टारगेट को संकलित करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में `COPTS` में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, न कि उसकी डिपेंडेंसी के लिए. इसलिए, दूसरी जगह शामिल हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस से जुड़े होने चाहिए. `third_party` के अलावा, इस एट्रिब्यूट की ज़रूरत नहीं होती. अगर पैकेज में feature `no_copts_tokenization` का एलान किया गया है, तो Bourne shell टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल होता है.
`cxxopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.
`defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस और उन सभी टारगेट की कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची जिन पर यह निर्भर है. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे `-D` जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल करने की कमांड लाइन में और उस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई तरह के असर पड़ सकते हैं -- इस टारगेट पर निर्भर हर टारगेट में, परिभाषाएं जोड़ी जाती हैं. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय, `local_defines` में वैल्यू जोड़ें.
`hdrs_check`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` अब काम नहीं करता.
`implementation_deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है लाइब्रेरी टारगेट पर निर्भर अन्य लाइब्रेरी की सूची. `deps` के उलट, इन लाइब्रेरी के हेडर और शामिल किए गए पाथ (और उन सभी ट्रांज़िशन डिपेंडेंसी) का इस्तेमाल सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है, न कि उन लाइब्रेरी के लिए जिन पर यह निर्भर करती है. `implementation_deps` के साथ बताई गई लाइब्रेरी अब भी उन बाइनरी टारगेट में लिंक हैं जो इस लाइब्रेरी पर निर्भर हैं.
`include_prefix`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` इस नियम के हेडर के पाथ में जोड़ने के लिए प्रीफ़िक्स. सेट होने पर, इस नियम के `hdrs` एट्रिब्यूट में मौजूद हेडर ऐक्सेस किए जा सकते हैं. यह इस एट्रिब्यूट की वैल्यू है, जो उनके रिपॉज़िटरी के हिसाब से पाथ में जोड़ी जाती है. इस प्रीफ़िक्स को जोड़ने से पहले, `strip_include_prefix` एट्रिब्यूट में मौजूद प्रीफ़िक्स हटा दिया जाता है. यह एट्रिब्यूट सिर्फ़ `third_party` के तहत मान्य है.
`includes`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` कंपाइल लाइन में जोड़ी जाने वाली शामिल डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प के हिसाब से बदला जा सकता है. हर स्ट्रिंग को पैकेज पाथ के साथ जोड़ा जाता है और "include_paths" CROSSTOOL सुविधा की मदद से, C++ टूलचेन को बड़ा करने के लिए पास किया जाता है. सामान्य सुविधाओं की परिभाषाओं के साथ, 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` के बजाय `.a` को लिंक करने के लिए कहता है. libc जैसी सिस्टम लाइब्रेरी (लेकिन C/C++ रनटाइम लाइब्रेरी नहीं, नीचे देखें) अब भी डाइनैमिक तौर पर लिंक की जाती हैं. साथ ही, ऐसी लाइब्रेरी भी डाइनैमिक तौर पर लिंक की जाती हैं जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे में मिलने वाला एक्सीक्यूटेबल अब भी डाइनैमिक तौर पर लिंक किया जाएगा. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगा. किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं: fully_static_link सुविधा के साथ स्टैटिक, जिसमें सब कुछ स्टैटिक तौर पर लिंक किया गया है; उदाहरण के लिए, "`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` डालकर, यह मोड चालू किया जाता है. अगर `features` में `linkstatic` एट्रिब्यूट या `fully_static_link` का इस्तेमाल `//third_party` के बाहर किया गया है, तो कृपया नियम के बगल में एक टिप्पणी शामिल करें और बताएं कि ऐसा क्यों किया गया है. `linkstatic` एट्रिब्यूट का इस्तेमाल `cc_library()` नियम के लिए करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, `linkstatic=True` से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई `.so` नहीं बनाया जाएगा. linkstatic=False से स्टैटिक लाइब्रेरी बनने से नहीं रोका जा सकता. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है. प्रोडक्शन में, `linkstatic=False` के साथ बहुत कम कोड बनाया जाना चाहिए. अगर `linkstatic=False` है, तो बिल्ड टूल `*.runfiles` एरिया में, उन शेयर की गई लाइब्रेरी के लिए सिंबललिंक बनाएगा जिन पर निर्भर किया गया है.
`local_defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` कंपाइल लाइन में जोड़ने के लिए, डिफ़ाइन की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे `-D` जोड़ा जाता है. साथ ही, इस टारगेट के लिए, स्ट्रिंग को कंपाइल करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए. `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, 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 होगा, न कि libbar.so, जो कि Linux पर डिफ़ॉल्ट रूप से होता है.

गड़बड़ियां

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

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

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

इसे ठीक करने के लिए, 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:__pkg__`, foo/BUILD में किसी भी टारगेट को ध्यान में रखते हुए `//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, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

फ़िलहाल, यह नियम एक्सपेरिमेंट के तौर पर उपलब्ध है. इसका इस्तेमाल सिर्फ़ --experimental_cc_static_library फ़्लैग के साथ किया जा सकता है. टारगेट और उनकी ट्रांज़िशन डिपेंडेंसी की सूची से स्टैटिक लाइब्रेरी बनाता है.

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

आउटपुट ग्रुप

`linkdeps`

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

`linkopts`

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

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

डिफ़ॉल्ट रूप से, 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, 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) को डिपेंडेंसी में डालने और `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` 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`	लेबल की सूची; डिफ़ॉल्ट `[]` है ऐसी डिपेंडेंसी जो सिर्फ़ C++ लिंकर कमांड के लिए उपलब्ध होती हैं. `deps`, कॉम्पाइलेशन और लिंक करने के लिए बनाया गया है. वहीं, `additional_linker_inputs` सिर्फ़ लिंक करने के लिए बनाया गया है. यह सिर्फ़ उस डिपेंडेंसी के बारे में बताता है जो सिर्फ़ लिंक करने के लिए ज़रूरी है. उदाहरण के लिए, `linkopts` में रेफ़र की गई फ़ाइलें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, यहां इकट्ठा की गई Windows .res फ़ाइलें दी जा सकती हैं.
`conlyopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` C कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.
`copts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` C/C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. बाइनरी टारगेट को संकलित करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में `COPTS` में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, न कि उसकी डिपेंडेंसी के लिए. इसलिए, दूसरी जगह शामिल हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस से जुड़े होने चाहिए. `third_party` के अलावा, इस एट्रिब्यूट की ज़रूरत नहीं होती. अगर पैकेज में feature `no_copts_tokenization` का एलान किया गया है, तो Bourne shell टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल होता है.
`cxxopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.
`defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस और उन सभी टारगेट की कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची जिन पर यह निर्भर है. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे `-D` जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल करने की कमांड लाइन में और उस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई तरह के असर पड़ सकते हैं -- इस टारगेट पर निर्भर हर टारगेट में, परिभाषाएं जोड़ी जाती हैं. अगर आपको नहीं पता कि 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`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` कंपाइल लाइन में जोड़ी जाने वाली शामिल डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प के हिसाब से बदला जा सकता है. हर स्ट्रिंग को पैकेज पाथ के साथ जोड़ा जाता है और "include_paths" CROSSTOOL सुविधा की मदद से, C++ टूलचेन को बड़ा करने के लिए पास किया जाता है. सामान्य सुविधाओं की परिभाषाओं के साथ, POSIX सिस्टम पर चलने वाला टूलचेन, `-isystem path_to_package/include_entry` जनरेट करेगा. इसका इस्तेमाल सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के लिए किया जाना चाहिए जो #include स्टेटमेंट लिखने के Google के स्टाइल के मुताबिक नहीं हैं. COPTS के उलट, ये फ़्लैग इस नियम और उस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: उन नियमों के बारे में नहीं जिन पर यह निर्भर करता है!) बहुत सावधान रहें, क्योंकि इससे काफ़ी असर पड़ सकता है. अगर आपको कोई संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. जोड़े गए `include` पाथ में, जनरेट की गई फ़ाइलों के साथ-साथ सोर्स ट्री में मौजूद फ़ाइलें भी शामिल होंगी.
`link_extra_lib`	लेबल; डिफ़ॉल्ट `"@bazel_tools//tools/cpp:link_extra_lib"` है अतिरिक्त लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल करना. डिफ़ॉल्ट रूप से, C++ बाइनरी `//tools/cpp:link_extra_lib` के साथ लिंक होती हैं. यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग `//tools/cpp:link_extra_libs` पर निर्भर करता है. फ़्लैग सेट किए बिना, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग सेट करने पर, वैकल्पिक डिपेंडेंसी को लिंक किया जा सकता है. जैसे, कमज़ोर सिंबल के लिए बदलाव, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के बदले, `malloc` या `--custom_malloc` का इस्तेमाल करें). इस एट्रिब्यूट को `None` पर सेट करने से, यह सुविधा बंद हो जाती है.
`linkopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` C++ लिंकर कमांड में ये फ़्लैग जोड़ें. "Make" वैरिएबल के बदले, Bourne शेल टोकनाइज़ेशन और लेबल एक्सपैंशन का इस्तेमाल किया जा सकता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को `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` के बजाय `.a` को लिंक करने के लिए कहता है. libc जैसी सिस्टम लाइब्रेरी (लेकिन C/C++ रनटाइम लाइब्रेरी नहीं, नीचे देखें) अब भी डाइनैमिक तौर पर लिंक की जाती हैं. साथ ही, ऐसी लाइब्रेरी भी डाइनैमिक तौर पर लिंक की जाती हैं जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे में मिलने वाला एक्सीक्यूटेबल अब भी डाइनैमिक तौर पर लिंक किया जाएगा. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगा. किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं: fully_static_link सुविधा के साथ स्टैटिक, जिसमें सब कुछ स्टैटिक तौर पर लिंक किया गया है; उदाहरण के लिए, "`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` डालकर, यह मोड चालू किया जाता है. अगर `features` में `linkstatic` एट्रिब्यूट या `fully_static_link` का इस्तेमाल `//third_party` के बाहर किया गया है, तो कृपया नियम के बगल में एक टिप्पणी शामिल करें और बताएं कि ऐसा क्यों किया गया है. `linkstatic` एट्रिब्यूट का इस्तेमाल `cc_library()` नियम के लिए करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, `linkstatic=True` से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई `.so` नहीं बनाया जाएगा. linkstatic=False से स्टैटिक लाइब्रेरी बनने से नहीं रोका जा सकता. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है. प्रोडक्शन में, `linkstatic=False` के साथ बहुत कम कोड बनाया जाना चाहिए. अगर `linkstatic=False` है, तो बिल्ड टूल `*.runfiles` एरिया में, उन शेयर की गई लाइब्रेरी के लिए सिंबललिंक बनाएगा जिन पर निर्भर किया गया है.
`local_defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` कंपाइल लाइन में जोड़ने के लिए, डिफ़ाइन की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे `-D` जोड़ा जाता है. साथ ही, इस टारगेट के लिए, स्ट्रिंग को कंपाइल करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए. `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` के अलावा, इस एट्रिब्यूट की ज़रूरत नहीं होनी चाहिए या इसका इस्तेमाल नहीं किया जाना चाहिए. वैल्यू को "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, 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, हेडर पार्स करने की कार्रवाइयों के साथ काम करता है, तो इसे 'सही है' पर सेट करें.
`supports_param_files`	बूलियन; डिफ़ॉल्ट तौर पर `True` जब cc_toolchain, कार्रवाइयों को लिंक करने के लिए पैरामीटर फ़ाइलों का इस्तेमाल करने की सुविधा देता है, तो इसे 'सही है' पर सेट करें.
`toolchain_config`	लेबल; ज़रूरी है `cc_toolchain_config_info` की जानकारी देने वाले नियम का लेबल.
`toolchain_identifier`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` इस cc_toolchain को मिलते-जुलते crosstool_config.toolchain से मैच करने के लिए इस्तेमाल किया जाने वाला आइडेंटिफ़ायर. जब तक #5380 वाली समस्या ठीक नहीं हो जाती, तब तक `cc_toolchain` को `CROSSTOOL.toolchain` से जोड़ने के लिए, यह तरीका अपनाएं. इसे `toolchain_config` एट्रिब्यूट (#5380) से बदल दिया जाएगा.

cc_toolchain_suite

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

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

अब काम नहीं करता: यह नियम काम नहीं करता और इसे हटा दिया जाएगा.

तर्क

विशेषताएं

name

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

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

fdo_prefetch_hints

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

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

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


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

तर्क

विशेषताएं

name

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

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

profile

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

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

fdo_profile

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

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

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


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

तर्क

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

memprof_profile

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

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

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


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

तर्क

विशेषताएं

name

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

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

profile

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

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

propeller_optimize

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

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

Workspace में 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

तर्क

cc_toolchain_suite

तर्क

fdo_prefetch_hints

तर्क

fdo_profile

तर्क

memprof_profile

तर्क

propeller_optimize

तर्क

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

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

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

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

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

`linkdeps`

`linkopts`

`symbol_check` के लिए टूलचेन की सहायता