C / C++ नियम

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

नियम

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

cc_binary

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

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

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

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

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये cc_library या objc_library टारगेट हो सकते हैं. लिंकर स्क्रिप्ट (.lds) को deps में रखने और उन्हें linkopts में रेफ़रंस करने की अनुमति भी है. हालांकि, कृपया इस्तेमाल के इस उदाहरण के लिए additional_linker_inputs पर विचार करें.
srcs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है लाइब्रेरी टारगेट बनाने के लिए, प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये जनरेट नहीं की गई हैं (सामान्य सोर्स कोड) या जनरेट की गई हैं. सभी .cc, .c, और .cpp फ़ाइलें कंपाइल की जाएंगी. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर किसी नाम वाली फ़ाइल, किसी दूसरे नियम के outs में है, तो यह cc_library अपने-आप उस दूसरे नियम पर निर्भर करेगा. प्योर असेंबलर फ़ाइलों (.s, .asm) को पहले से प्रोसेस नहीं किया जाता है. इन्हें आम तौर पर असेंबलर का इस्तेमाल करके बनाया जाता है. प्रीप्रोसेस की गई असेंबली फ़ाइलें (.S) प्रीप्रोसेस की जाती हैं. इन्हें आम तौर पर C/C++ कंपाइलर का इस्तेमाल करके बनाया जाता है. .h फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, यह इस नियम के तहत आने वाले सोर्स में शामिल करने के लिए उपलब्ध होगी. .cc और .h, दोनों तरह की फ़ाइलों में, इन srcs में या इस नियम के hdrs में या deps आर्ग्युमेंट में दिए गए किसी भी नियम में शामिल हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी #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++ लिंकर कमांड के लिए उपलब्ध कराई जाती हैं. deps को कंपाइल करने और लिंक करने की डिपेंडेंसी, दोनों के लिए बनाया गया है. वहीं, additional_linker_inputs को सिर्फ़ लिंक करने की डिपेंडेंसी के लिए बनाया गया है. यह ऐसी डिपेंडेंसी का सिग्नल देता है जो सिर्फ़ लिंक करने के लिए ज़रूरी है. उदाहरण के लिए, linkopts में रेफ़र की गई फ़ाइलें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.
conlyopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इन विकल्पों को C कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C/C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट कंपाइल करने से पहले COPTS में दिए गए क्रम में जोड़ा जाता है. ये फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, इसकी डिपेंडेंसी के लिए नहीं. इसलिए, दूसरी जगहों पर शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस के हिसाब से होने चाहिए. इस एट्रिब्यूट की ज़रूरत third_party के बाहर नहीं होनी चाहिए. अगर पैकेज में सुविधा no_copts_tokenization के बारे में बताया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.
cxxopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इस और इससे जुड़े सभी टारगेट की कंपाइल लाइन में जोड़ने के लिए, डिफ़ाइन की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शेल टोकन होना चाहिए. इसे -D से पहले जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. इसके अलावा, इसे इस पर निर्भर हर नियम में भी जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. इस टारगेट पर निर्भर रहने वाले हर टारगेट में, ये डेफ़िनिशन जोड़ी जाती हैं. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय local_defines एट्रिब्यूट की वैल्यू तय करें.
dynamic_deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है ये अन्य cc_shared_library डिपेंडेंसी हैं जिन पर मौजूदा टारगेट निर्भर करता है. cc_shared_library को लागू करने के लिए, dynamic_deps की सूची का इस्तेमाल किया जाएगा.इसमें dynamic_deps (ट्रांज़िटिव तौर पर, यानी कि मौजूदा टारगेट के dynamic_deps का dynamic_deps भी) शामिल है. इससे यह तय किया जाएगा कि ट्रांज़िटिव deps में मौजूद कौनसे cc_libraries को लिंक नहीं किया जाना चाहिए, क्योंकि उन्हें पहले से ही किसी दूसरे cc_shared_library ने उपलब्ध कराया है.
hdrs_check	स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है अब सेवा में नहीं है, कोई कार्रवाई नहीं की जाती.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है कंपाइल लाइन में शामिल किए जाने वाले डायरेक्ट्री की सूची. "बदलाव के हिसाब से" विकल्प के तहत बदलाव किया जा सकता है. हर स्ट्रिंग के पहले पैकेज का पाथ जोड़ा जाता है. इसके बाद, इसे C++ टूलचेन को पास किया जाता है. ऐसा "include_paths" CROSSTOOL सुविधा के ज़रिए किया जाता है. POSIX सिस्टम पर चलने वाला टूलचेन, सामान्य सुविधाओं की परिभाषाओं के साथ -isystem path_to_package/include_entry जनरेट करेगा. इसका इस्तेमाल सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के लिए किया जाना चाहिए जो #include स्टेटमेंट लिखने के Google के तरीके का पालन नहीं करती हैं. COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: यह उन नियमों के बारे में नहीं है जिन पर यह निर्भर करता है!) बहुत ज़्यादा सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. अगर आपको किसी तरह का संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. जोड़े गए include पाथ में, जनरेट की गई फ़ाइलों के साथ-साथ सोर्स ट्री में मौजूद फ़ाइलें भी शामिल होंगी.
link_extra_lib	लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:link_extra_lib" है इस कुकी से, अतिरिक्त लाइब्रेरी लिंक करने की सुविधा को कंट्रोल किया जाता है. C++ बाइनरी, डिफ़ॉल्ट रूप से //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 के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी संभव हो, उपयोगकर्ता लाइब्रेरी के लिए .so's के बजाय .a's को लिंक करें. libc जैसी सिस्टम लाइब्रेरी अब भी डाइनैमिक तरीके से लिंक की जाती हैं. हालांकि, C/C++ रनटाइम लाइब्रेरी (नीचे देखें) नहीं. इसके अलावा, जिन लाइब्रेरी के लिए स्टैटिक लाइब्रेरी उपलब्ध नहीं है उन्हें भी डाइनैमिक तरीके से लिंक किया जाता है. इसलिए, एक्ज़ीक्यूटेबल फ़ाइल अब भी डाइनैमिक रूप से लिंक होगी. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगी. किसी एक्ज़ीक्यूटेबल को लिंक करने के तीन अलग-अलग तरीके हैं: STATIC, जिसमें पूरी तरह से स्टैटिक लिंक की सुविधा होती है. इसमें सब कुछ स्टैटिक तौर पर लिंक किया जाता है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm". इस मोड को चालू करने के लिए, features एट्रिब्यूट में fully_static_link की वैल्यू डालें. STATIC, इसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, इसमें सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है. उदाहरण के लिए, "gcc foo.o libfoo.a libbaz.a -lm". इस मोड को linkstatic=True तय करके चालू किया जाता है. DYNAMIC, जिसमें सभी लाइब्रेरी को डाइनैमिक रूप से लिंक किया जाता है (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "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 shell टोकन होना चाहिए. इसके पहले -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे इसके डिपेंडेंट में नहीं जोड़ा जाता. defines के उलट, इस टारगेट के लिए सिर्फ़ कंपाइल कमांड लाइन में डेफ़िनिशन जोड़े जाते हैं.
malloc	लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:malloc" है malloc पर डिफ़ॉल्ट डिपेंडेंसी को बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:malloc के साथ लिंक किया जाता है. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी libc malloc का इस्तेमाल करती है. इस लेबल में, cc_library का रेफ़रंस होना चाहिए. अगर कंपाइल करने का नियम C++ का नहीं है, तो इस विकल्प का कोई असर नहीं होता. अगर linkshared=True एट्रिब्यूट की वैल्यू दी गई है, तो इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है.
module_interfaces	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है फ़ाइलों की सूची को C++20 मॉड्यूल इंटरफ़ेस माना जाता है. C++ स्टैंडर्ड में, मॉड्यूल इंटरफ़ेस फ़ाइल के एक्सटेंशन के बारे में कोई पाबंदी नहीं है Clang use 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, aspect_hints, 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, strip_include_prefix, system_provided, tags, target_compatible_with, testonly, toolchains, visibility)

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

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

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

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

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

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

Unix पर:

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

Windows पर:

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

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

Unix पर:

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

Windows पर:

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

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

Unix पर:

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

Windows पर:

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

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

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

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

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है उन अन्य लाइब्रेरी की सूची जिन पर टारगेट निर्भर करता है. deps ज़्यादातर बिल्ड नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट के बारे में सामान्य टिप्पणियां देखें.
hdrs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है इस प्रीकंपाइल की गई लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची. इन्हें सीधे तौर पर, निर्भरता वाले नियमों में शामिल किया जाता है.
alwayslink	बूलियन; डिफ़ॉल्ट वैल्यू False है अगर 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, aspect_hints, compatible_with, conlyopts, copts, cxxopts, defines, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hdrs_check, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, module_interfaces, package_metadata, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

उदाहरण

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

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

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

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

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

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

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

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

तर्क

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

cc_shared_library

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

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

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

उदाहरण

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

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

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

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

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

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

गड़बड़ियां

Two shared libraries in dependencies export the same symbols.

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

Two shared libraries in dependencies link the same library statically

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

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

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

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

इसका समाधान यह है कि इसे cc_shared_library डिपेंडेंसी से एक्सपोर्ट करें या इसे एक्सपोर्ट करने वाली तीसरी cc_shared_library को बाहर निकालें.

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

अगर आपके पास पहले से कंपाइल की गई डाइनैमिक लाइब्रेरी है, तो इसे मौजूदा cc_shared_library टारगेट में स्टैटिक तौर पर लिंक करने की ज़रूरत नहीं है. साथ ही, इसे लिंक नहीं किया जा सकता. इसलिए, यह deps के cc_shared_library में शामिल नहीं है. अगर यह पहले से कंपाइल की गई डाइनैमिक लाइब्रेरी, आपके किसी cc_libraries की डिपेंडेंसी है, तो cc_libraries को सीधे तौर पर इस पर निर्भर होना चाहिए.cc_library

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

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

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

तर्क

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

cc_static_library

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

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

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

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

आउटपुट ग्रुप

linkdeps

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

linkopts

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

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

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

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

symbol_check के लिए टूलचेन का इस्तेमाल किया जा सकता है

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है स्टैटिक लाइब्रेरी में शामिल किए जाने वाले टारगेट की सूची. इसमें उनकी सभी ट्रांज़िटिव डिपेंडेंसी भी शामिल हैं. जिन डिपेंडेंसी से कोई ऑब्जेक्ट फ़ाइल नहीं मिलती उन्हें स्टैटिक लाइब्रेरी में शामिल नहीं किया जाता. हालांकि, उनके लेबल को linkdeps आउटपुट ग्रुप से मिली फ़ाइल में इकट्ठा किया जाता है.

cc_test

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

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

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

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

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

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये cc_library या objc_library टारगेट हो सकते हैं. लिंकर स्क्रिप्ट (.lds) को deps में रखने और उन्हें linkopts में रेफ़रंस करने की अनुमति भी है. हालांकि, कृपया इस्तेमाल के इस उदाहरण के लिए additional_linker_inputs पर विचार करें.
srcs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है लाइब्रेरी टारगेट बनाने के लिए, प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये जनरेट नहीं की गई हैं (सामान्य सोर्स कोड) या जनरेट की गई हैं. सभी .cc, .c, और .cpp फ़ाइलें कंपाइल की जाएंगी. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर किसी नाम वाली फ़ाइल, किसी दूसरे नियम के outs में है, तो यह cc_library अपने-आप उस दूसरे नियम पर निर्भर करेगा. प्योर असेंबलर फ़ाइलों (.s, .asm) को पहले से प्रोसेस नहीं किया जाता है. इन्हें आम तौर पर असेंबलर का इस्तेमाल करके बनाया जाता है. प्रीप्रोसेस की गई असेंबली फ़ाइलें (.S) प्रीप्रोसेस की जाती हैं. इन्हें आम तौर पर C/C++ कंपाइलर का इस्तेमाल करके बनाया जाता है. .h फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, यह इस नियम के तहत आने वाले सोर्स में शामिल करने के लिए उपलब्ध होगी. .cc और .h, दोनों तरह की फ़ाइलों में, इन srcs में या इस नियम के hdrs में या deps आर्ग्युमेंट में दिए गए किसी भी नियम में शामिल हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी #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++ लिंकर कमांड के लिए उपलब्ध कराई जाती हैं. deps को कंपाइल करने और लिंक करने की डिपेंडेंसी, दोनों के लिए बनाया गया है. वहीं, additional_linker_inputs को सिर्फ़ लिंक करने की डिपेंडेंसी के लिए बनाया गया है. यह ऐसी डिपेंडेंसी का सिग्नल देता है जो सिर्फ़ लिंक करने के लिए ज़रूरी है. उदाहरण के लिए, linkopts में रेफ़र की गई फ़ाइलें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.
conlyopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इन विकल्पों को C कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C/C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट कंपाइल करने से पहले COPTS में दिए गए क्रम में जोड़ा जाता है. ये फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, इसकी डिपेंडेंसी के लिए नहीं. इसलिए, दूसरी जगहों पर शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस के हिसाब से होने चाहिए. इस एट्रिब्यूट की ज़रूरत third_party के बाहर नहीं होनी चाहिए. अगर पैकेज में सुविधा no_copts_tokenization के बारे में बताया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.
cxxopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इस और इससे जुड़े सभी टारगेट की कंपाइल लाइन में जोड़ने के लिए, डिफ़ाइन की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शेल टोकन होना चाहिए. इसे -D से पहले जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. इसके अलावा, इसे इस पर निर्भर हर नियम में भी जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. इस टारगेट पर निर्भर रहने वाले हर टारगेट में, ये डेफ़िनिशन जोड़ी जाती हैं. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय local_defines एट्रिब्यूट की वैल्यू तय करें.
dynamic_deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है ये अन्य cc_shared_library डिपेंडेंसी हैं जिन पर मौजूदा टारगेट निर्भर करता है. cc_shared_library को लागू करने के लिए, dynamic_deps की सूची का इस्तेमाल किया जाएगा.इसमें dynamic_deps (ट्रांज़िटिव तौर पर, यानी कि मौजूदा टारगेट के dynamic_deps का dynamic_deps भी) शामिल है. इससे यह तय किया जाएगा कि ट्रांज़िटिव deps में मौजूद कौनसे cc_libraries को लिंक नहीं किया जाना चाहिए, क्योंकि उन्हें पहले से ही किसी दूसरे cc_shared_library ने उपलब्ध कराया है.
hdrs_check	स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है अब सेवा में नहीं है, कोई कार्रवाई नहीं की जाती.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है कंपाइल लाइन में शामिल किए जाने वाले डायरेक्ट्री की सूची. "बदलाव के हिसाब से" विकल्प के तहत बदलाव किया जा सकता है. हर स्ट्रिंग के पहले पैकेज का पाथ जोड़ा जाता है. इसके बाद, इसे C++ टूलचेन को पास किया जाता है. ऐसा "include_paths" CROSSTOOL सुविधा के ज़रिए किया जाता है. POSIX सिस्टम पर चलने वाला टूलचेन, सामान्य सुविधाओं की परिभाषाओं के साथ -isystem path_to_package/include_entry जनरेट करेगा. इसका इस्तेमाल सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के लिए किया जाना चाहिए जो #include स्टेटमेंट लिखने के Google के तरीके का पालन नहीं करती हैं. COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: यह उन नियमों के बारे में नहीं है जिन पर यह निर्भर करता है!) बहुत ज़्यादा सावधानी बरतें, क्योंकि इससे काफ़ी असर पड़ सकता है. अगर आपको किसी तरह का संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. जोड़े गए include पाथ में, जनरेट की गई फ़ाइलों के साथ-साथ सोर्स ट्री में मौजूद फ़ाइलें भी शामिल होंगी.
link_extra_lib	लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:link_extra_lib" है इस कुकी से, अतिरिक्त लाइब्रेरी लिंक करने की सुविधा को कंट्रोल किया जाता है. C++ बाइनरी, डिफ़ॉल्ट रूप से //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 के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी संभव हो, उपयोगकर्ता लाइब्रेरी के लिए .so's के बजाय .a's को लिंक करें. libc जैसी सिस्टम लाइब्रेरी अब भी डाइनैमिक तरीके से लिंक की जाती हैं. हालांकि, C/C++ रनटाइम लाइब्रेरी (नीचे देखें) नहीं. इसके अलावा, जिन लाइब्रेरी के लिए स्टैटिक लाइब्रेरी उपलब्ध नहीं है उन्हें भी डाइनैमिक तरीके से लिंक किया जाता है. इसलिए, एक्ज़ीक्यूटेबल फ़ाइल अब भी डाइनैमिक रूप से लिंक होगी. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगी. किसी एक्ज़ीक्यूटेबल को लिंक करने के तीन अलग-अलग तरीके हैं: STATIC, जिसमें पूरी तरह से स्टैटिक लिंक की सुविधा होती है. इसमें सब कुछ स्टैटिक तौर पर लिंक किया जाता है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm". इस मोड को चालू करने के लिए, features एट्रिब्यूट में fully_static_link की वैल्यू डालें. STATIC, इसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, इसमें सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है. उदाहरण के लिए, "gcc foo.o libfoo.a libbaz.a -lm". इस मोड को linkstatic=True तय करके चालू किया जाता है. DYNAMIC, जिसमें सभी लाइब्रेरी को डाइनैमिक रूप से लिंक किया जाता है (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "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 shell टोकन होना चाहिए. इसके पहले -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे इसके डिपेंडेंट में नहीं जोड़ा जाता. defines के उलट, इस टारगेट के लिए सिर्फ़ कंपाइल कमांड लाइन में डेफ़िनिशन जोड़े जाते हैं.
malloc	लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:malloc" है malloc पर डिफ़ॉल्ट डिपेंडेंसी को बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:malloc के साथ लिंक किया जाता है. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी libc malloc का इस्तेमाल करती है. इस लेबल में, cc_library का रेफ़रंस होना चाहिए. अगर कंपाइल करने का नियम C++ का नहीं है, तो इस विकल्प का कोई असर नहीं होता. अगर linkshared=True एट्रिब्यूट की वैल्यू दी गई है, तो इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है.
module_interfaces	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है फ़ाइलों की सूची को C++20 मॉड्यूल इंटरफ़ेस माना जाता है. C++ स्टैंडर्ड में, मॉड्यूल इंटरफ़ेस फ़ाइल के एक्सटेंशन के बारे में कोई पाबंदी नहीं है Clang use 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, aspect_hints, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, deprecation, dwp_files, dynamic_runtime_lib, exec_compatible_with, exec_group_compatible_with, exec_properties, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, output_licenses, package_metadata, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, toolchains, visibility)

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

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

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

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

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	लेबल; ज़रूरी है डीडब्ल्यूपी कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
dynamic_runtime_lib	लेबल; डिफ़ॉल्ट वैल्यू None है C++ रनटाइम लाइब्रेरी के लिए डाइनैमिक लाइब्रेरी आर्टफ़ैक्ट (जैसे, libstdc++.so). इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू हो और हम डिपेंडेंसी को डाइनैमिक तरीके से लिंक कर रहे हों.
exec_transition_for_inputs	बूलियन; डिफ़ॉल्ट वैल्यू False है समर्थन नहीं होना या रुकना. कोई कार्रवाई नहीं की गई.
libc_top	लेबल; डिफ़ॉल्ट वैल्यू None है libc के लिए आर्टफ़ैक्ट का कलेक्शन, जिसे कंपाइल/लिंक करने की कार्रवाइयों के लिए इनपुट के तौर पर पास किया जाता है.
linker_files	लेबल; ज़रूरी है कार्रवाइयों को लिंक करने के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
module_map	लेबल; डिफ़ॉल्ट वैल्यू None है मॉड्यूलर बिल्ड के लिए इस्तेमाल किया जाने वाला मॉड्यूल मैप आर्टफ़ैक्ट.
objcopy_files	लेबल; ज़रूरी है objcopy कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
output_licenses	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है
static_runtime_lib	लेबल; डिफ़ॉल्ट वैल्यू None है C++ रनटाइम लाइब्रेरी के लिए स्टैटिक लाइब्रेरी आर्टफ़ैक्ट (जैसे, libstdc++.a). इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू हो और हम डिपेंडेंसी को स्टैटिक तौर पर लिंक कर रहे हों.
strip_files	लेबल; ज़रूरी है स्ट्रिप ऐक्शन के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
supports_header_parsing	बूलियन; डिफ़ॉल्ट वैल्यू False है cc_toolchain में हेडर पार्स करने की कार्रवाइयों की सुविधा होने पर, इसे True पर सेट करें.
supports_param_files	बूलियन; डिफ़ॉल्ट वैल्यू True है cc_toolchain, लिंकिंग कार्रवाइयों के लिए पैरामीटर फ़ाइलों का इस्तेमाल करने की सुविधा देता है, तो इसे True पर सेट करें.
toolchain_config	लेबल; ज़रूरी है cc_toolchain_config_info की जानकारी देने वाले नियम का लेबल.
toolchain_identifier	स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है इस आइडेंटिफ़ायर का इस्तेमाल, इस cc_toolchain को इससे मिलते-जुलते crosstool_config.toolchain से मैच करने के लिए किया जाता है. समस्या #5380 ठीक होने तक, cc_toolchain को CROSSTOOL.toolchain से जोड़ने का यही तरीका इस्तेमाल करें. इसे toolchain_config एट्रिब्यूट (#5380) से बदल दिया जाएगा.

fdo_prefetch_hints

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

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

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

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

तर्क

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

fdo_profile

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

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

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

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

तर्क

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

memprof_profile

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

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

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

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

तर्क

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

propeller_optimize

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

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

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

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

तर्क

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