C / C++ नियम

समस्या की शिकायत करें सोर्स देखें

नाइटली · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

नियम

• cc_binary
• cc_import
• cc_library
• cc_shared_library
• cc_static_library
• cc_test
• cc_toolchain
• cc_toolchain_suite
• fdo_prefetch_hints
• fdo_profile
• memprof_profile
• propeller_optimize

cc_binary

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

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

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

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

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये cc_library या objc_library टारगेट हो सकते हैं. लिंकर स्क्रिप्ट (.lds) को deps में रखने और उन्हें linkopts में रेफ़रंस करने की भी अनुमति है.
srcs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है लाइब्रेरी टारगेट बनाने के लिए, प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये जनरेट नहीं की गई हैं (सामान्य सोर्स कोड) या जनरेट की गई हैं. सभी .cc, .c, और .cpp फ़ाइलों को कंपाइल किया जाएगा. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर किसी नाम वाली फ़ाइल, किसी दूसरे नियम के outs में है, तो यह cc_library उस दूसरे नियम पर अपने-आप निर्भर करेगा. असेंबलर फ़ाइलें (.s, .asm) पहले से प्रोसेस नहीं की जाती हैं. इन्हें आम तौर पर असेंबलर का इस्तेमाल करके बनाया जाता है. प्रीप्रोसेस की गई असेंबली फ़ाइलों (.S) को प्रीप्रोसेस किया जाता है. इन्हें आम तौर पर, C/C++ कंपाइलर का इस्तेमाल करके बनाया जाता है. .h फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, यह इस नियम के तहत आने वाले सोर्स में शामिल करने के लिए उपलब्ध होगी. .cc और .h, दोनों तरह की फ़ाइलों में, इन srcs में या इस नियम के hdrs में या deps आर्ग्युमेंट में दिए गए किसी भी नियम में शामिल हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी #included फ़ाइलों को इस या रेफ़र की गई 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++ लिंकर कमांड में पास करें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.
conlyopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इन विकल्पों को C कंपाइलेशन कमांड में जोड़ें. "बदलाव किया जा सकता है" के आधार पर बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के आधार पर बदलाव किया जा सकता है.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C/C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "बदलाव किया जा सकता है" के आधार पर बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के आधार पर बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट कंपाइल करने से पहले, दिए गए क्रम में COPTS में जोड़ा जाता है. ये फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, इसकी डिपेंडेंसी के लिए नहीं. इसलिए, किसी दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस के हिसाब से होने चाहिए. इस एट्रिब्यूट की ज़रूरत third_party के बाहर नहीं होनी चाहिए. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.
cxxopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "बदलाव किया जा सकता है" के आधार पर बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के आधार पर बदलाव किया जा सकता है.
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++ बाइनरी को //tools/cpp:link_extra_lib के साथ लिंक किया जाता है. यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग //tools/cpp:link_extra_libs पर निर्भर करता है. फ़्लैग सेट न करने पर, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग सेट करने से, वैकल्पिक डिपेंडेंसी लिंक करने की अनुमति मिलती है. जैसे, कमज़ोर सिंबल के लिए ओवरराइड, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के विकल्पों के लिए, malloc या --custom_malloc को प्राथमिकता दें). इस एट्रिब्यूट को None पर सेट करने से, यह सुविधा बंद हो जाती है.
linkopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, 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 के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी हो सके, उपयोगकर्ता लाइब्रेरी के लिए .a's के बजाय .so'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 जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे डिपेंडेंट के लिए नहीं जोड़ा जाता.
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++ कंपाइलेशन कमांड से, मिलते-जुलते विकल्पों को हटाएं. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले किसी भी मौजूदा 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, distribs, exec_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, 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 = 1,
)

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

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

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

Unix पर:

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

Windows पर:

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

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

Unix पर:

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

Windows पर:

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

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

Unix पर:

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

Windows पर:

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

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

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

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

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

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

तर्क

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

cc_library

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

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

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 फ़ाइल के कंपाइलेशन में, 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 = 1,
)

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

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

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

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

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

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

तर्क

विशेषताएं
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 आर्ग्युमेंट में दिए गए किसी भी नियम में शामिल हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी #included फ़ाइलों को इस या रेफ़र की गई 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++ लिंकर कमांड में पास करें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.
alwayslink	बूलियन; डिफ़ॉल्ट वैल्यू False है अगर 1, तो इस C++ लाइब्रेरी पर सीधे या परोक्ष रूप से निर्भर करने वाली कोई भी बाइनरी, srcs में दी गई फ़ाइलों के लिए सभी ऑब्जेक्ट फ़ाइलों में लिंक करेगी. भले ही, उनमें से कुछ में बाइनरी से रेफ़र किए गए कोई भी सिंबल शामिल न हों. यह तब काम आता है, जब आपके कोड को बाइनरी में कोड के ज़रिए साफ़ तौर पर कॉल नहीं किया जाता. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिले कॉलबैक को पाने के लिए रजिस्टर करता है. अगर Windows पर VS 2017 के साथ alwayslink काम नहीं करता है, तो इसकी वजह एक जानी-पहचानी समस्या है. कृपया VS 2017 को नए वर्शन में अपग्रेड करें.
conlyopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इन विकल्पों को C कंपाइलेशन कमांड में जोड़ें. "बदलाव किया जा सकता है" के आधार पर बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के आधार पर बदलाव किया जा सकता है.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C/C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "बदलाव किया जा सकता है" के आधार पर बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के आधार पर बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट कंपाइल करने से पहले, दिए गए क्रम में COPTS में जोड़ा जाता है. ये फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, इसकी डिपेंडेंसी के लिए नहीं. इसलिए, किसी दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस के हिसाब से होने चाहिए. इस एट्रिब्यूट की ज़रूरत third_party के बाहर नहीं होनी चाहिए. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.
cxxopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "बदलाव किया जा सकता है" के आधार पर बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के आधार पर बदलाव किया जा सकता है.
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 के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी हो सके, उपयोगकर्ता लाइब्रेरी के लिए .a's के बजाय .so'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 जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे डिपेंडेंट के लिए नहीं जोड़ा जाता.
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, distribs, dynamic_deps, exec_compatible_with, exec_properties, experimental_disable_topo_sort_do_not_use_remove_before_7_0, exports_filter, features, restricted_to, roots, shared_lib_name, static_deps, tags, target_compatible_with, testonly, toolchains, user_link_flags, visibility, win_def_file)

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

उदाहरण

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

उदाहरण में, foo_shared, foo और baz को स्टैटिक तरीके से लिंक करता है. इनमें से 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 ने उपलब्ध करा दिया है.
experimental_disable_topo_sort_do_not_use_remove_before_7_0	बूलियन; डिफ़ॉल्ट वैल्यू False है
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, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, 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, compatible_with, conlyopts, copts, cxxopts, defines, deprecation, distribs, dynamic_deps, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local, local_defines, malloc, module_interfaces, nocopts, reexport_deps, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

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

डिफ़ॉल्ट रूप से, 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 में रेफ़रंस करने की भी अनुमति है.
srcs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है लाइब्रेरी टारगेट बनाने के लिए, प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये जनरेट नहीं की गई हैं (सामान्य सोर्स कोड) या जनरेट की गई हैं. सभी .cc, .c, और .cpp फ़ाइलों को कंपाइल किया जाएगा. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर किसी नाम वाली फ़ाइल, किसी दूसरे नियम के outs में है, तो यह cc_library उस दूसरे नियम पर अपने-आप निर्भर करेगा. असेंबलर फ़ाइलें (.s, .asm) पहले से प्रोसेस नहीं की जाती हैं. इन्हें आम तौर पर असेंबलर का इस्तेमाल करके बनाया जाता है. प्रीप्रोसेस की गई असेंबली फ़ाइलों (.S) को प्रीप्रोसेस किया जाता है. इन्हें आम तौर पर, C/C++ कंपाइलर का इस्तेमाल करके बनाया जाता है. .h फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, यह इस नियम के तहत आने वाले सोर्स में शामिल करने के लिए उपलब्ध होगी. .cc और .h, दोनों तरह की फ़ाइलों में, इन srcs में या इस नियम के hdrs में या deps आर्ग्युमेंट में दिए गए किसी भी नियम में शामिल हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी #included फ़ाइलों को इस या रेफ़र की गई 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++ लिंकर कमांड में पास करें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.
conlyopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इन विकल्पों को C कंपाइलेशन कमांड में जोड़ें. "बदलाव किया जा सकता है" के आधार पर बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के आधार पर बदलाव किया जा सकता है.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C/C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "बदलाव किया जा सकता है" के आधार पर बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के आधार पर बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट कंपाइल करने से पहले, दिए गए क्रम में COPTS में जोड़ा जाता है. ये फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, इसकी डिपेंडेंसी के लिए नहीं. इसलिए, किसी दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस के हिसाब से होने चाहिए. इस एट्रिब्यूट की ज़रूरत third_party के बाहर नहीं होनी चाहिए. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.
cxxopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "बदलाव किया जा सकता है" के आधार पर बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के आधार पर बदलाव किया जा सकता है.
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++ बाइनरी को //tools/cpp:link_extra_lib के साथ लिंक किया जाता है. यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग //tools/cpp:link_extra_libs पर निर्भर करता है. फ़्लैग सेट न करने पर, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग सेट करने से, वैकल्पिक डिपेंडेंसी लिंक करने की अनुमति मिलती है. जैसे, कमज़ोर सिंबल के लिए ओवरराइड, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के विकल्पों के लिए, malloc या --custom_malloc को प्राथमिकता दें). इस एट्रिब्यूट को None पर सेट करने से, यह सुविधा बंद हो जाती है.
linkopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, 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 के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी हो सके, उपयोगकर्ता लाइब्रेरी के लिए .a's के बजाय .so'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 जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे डिपेंडेंट के लिए नहीं जोड़ा जाता.
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++ कंपाइलेशन कमांड से, मिलते-जुलते विकल्पों को हटाएं. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले किसी भी मौजूदा 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, distribs, dwp_files, dynamic_runtime_lib, exec_compatible_with, exec_properties, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, output_licenses, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, toolchains, visibility)

यह C++ टूलचेन को दिखाता है.

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

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

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

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

तर्क

विशेषताएं
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, लिंकिंग कार्रवाइयों के लिए param फ़ाइलों का इस्तेमाल करने की सुविधा देता है, तो इसे True पर सेट करें.
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, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.

fdo_prefetch_hints

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

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

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

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

तर्क

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

fdo_profile

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

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

यह 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, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, 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 फ़ाइल वाली zipfile के लिए) होना चाहिए. यह लेबल, fdo_absolute_path_profile नियम की ओर भी इशारा कर सकता है.

propeller_optimize

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

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

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
cc_profile	लेबल; ज़रूरी है प्रोफ़ाइल का लेबल, जिसे अलग-अलग कंपाइल कार्रवाइयों में पास किया जाता है. इस फ़ाइल में .txt एक्सटेंशन है.
ld_profile	लेबल; ज़रूरी है लिंक करने की कार्रवाई के लिए पास की गई प्रोफ़ाइल का लेबल. इस फ़ाइल में .txt एक्सटेंशन है.