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
• 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, dynamic_deps, env, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, module_interfaces, nocopts, output_licenses, package_metadata, reexport_deps, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

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

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

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

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

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये cc_library या objc_library टारगेट हो सकते हैं. लिंकर स्क्रिप्ट (.lds) को डिपेंडेंसी में डालने और linkopts में उनका रेफ़रंस देने की भी अनुमति है. हालांकि, इस्तेमाल के उस उदाहरण के लिए, कृपया additional_linker_inputs का इस्तेमाल करें.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है लाइब्रेरी टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें होती हैं. ये जनरेट नहीं की गई (सामान्य सोर्स कोड) या जनरेट की गई हो सकती हैं. .cc, .c, और .cpp की सभी फ़ाइलें संकलित की जाएंगी. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर कोई नाम वाली फ़ाइल किसी दूसरे नियम के outs में है, तो यह cc_library अपने-आप उस दूसरे नियम पर निर्भर करेगा. असेंबलर की फ़ाइलों (.s, .asm) को पहले से प्रोसेस नहीं किया जाता. आम तौर पर, इन्हें असेंबलर का इस्तेमाल करके बनाया जाता है. पहले से प्रोसेस की गई असेंबली फ़ाइलों (.S) को पहले से प्रोसेस किया जाता है और आम तौर पर, C/C++ कंपाइलर का इस्तेमाल करके बनाया जाता है. .h फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, इस नियम में सोर्स के लिए, इसे शामिल करने की सुविधा उपलब्ध होगी. .cc और .h, दोनों फ़ाइलों में इन srcs या इस नियम के hdrs में बताए गए हेडर या deps आर्ग्युमेंट में बताए गए किसी भी नियम को सीधे तौर पर शामिल किया जा सकता है. सभी #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 C प्रीप्रोसेसर वाला असेंबलर: .S संग्रहित करें: .a, .pic.a "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo शेयर की गई लाइब्रेरी, वर्शन वाली या वर्शन वाली नहीं: .so, .so.version ऑब्जेक्ट फ़ाइल: .o, .pic.o ... और उन फ़ाइलों को बनाने वाले सभी नियम (उदाहरण के लिए, cc_embed_data). अलग-अलग एक्सटेंशन, gcc के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
data	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. data के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. अगर data, जनरेट की गई फ़ाइल का नाम है, तो यह cc_library नियम, जनरेट करने वाले नियम पर अपने-आप निर्भर करता है. अगर data किसी नियम का नाम है, तो यह cc_library नियम अपने-आप उस नियम पर निर्भर करता है, और उस नियम के outs, इस cc_library की डेटा फ़ाइलों में अपने-आप जुड़ जाते हैं. आपका C++ कोड इन डेटा फ़ाइलों को इस तरह ऐक्सेस कर सकता है: const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी डिपेंडेंसी जो सिर्फ़ C++ लिंकर कमांड के लिए उपलब्ध होती हैं. deps, कॉम्पाइलेशन और लिंक करने के लिए बनाया गया है. वहीं, additional_linker_inputs सिर्फ़ लिंक करने के लिए बनाया गया है. यह सिर्फ़ उस डिपेंडेंसी के बारे में बताता है जो सिर्फ़ लिंक करने के लिए ज़रूरी है. उदाहरण के लिए, linkopts में रेफ़र की गई फ़ाइलें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, यहां इकट्ठा की गई Windows .res फ़ाइलें दी जा सकती हैं.
conlyopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] C कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] C/C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. बाइनरी टारगेट को संकलित करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में COPTS में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, न कि इसकी डिपेंडेंसी के लिए. इसलिए, दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस से जुड़े होने चाहिए. third_party के अलावा, इस एट्रिब्यूट की ज़रूरत नहीं होती. अगर पैकेज में feature no_copts_tokenization का एलान किया गया है, तो Bourne shell टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल होता है.
cxxopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस और उन सभी टारगेट की कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची जिन पर यह निर्भर है. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल करने की कमांड लाइन में और उस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई तरह के असर पड़ सकते हैं -- इस टारगेट पर निर्भर हर टारगेट में, परिभाषाएं जोड़ी जाती हैं. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय, local_defines में वैल्यू जोड़ें.
dynamic_deps	लेबल की सूची; डिफ़ॉल्ट [] है ये cc_shared_library की अन्य डिपेंडेंसी हैं, जिन पर मौजूदा टारगेट निर्भर करता है. cc_shared_library लागू करने के लिए, dynamic_deps की सूची का इस्तेमाल किया जाएगा.इसमें, ट्रांज़िटिव deps में मौजूद किस cc_libraries को लिंक नहीं किया जाना चाहिए, यह तय करने के लिए, मौजूदा टारगेट के dynamic_deps का dynamic_deps भी शामिल किया जाएगा. ऐसा इसलिए किया जाता है, क्योंकि ये cc_libraries पहले से ही किसी दूसरे cc_shared_library से दिए गए होते हैं.
hdrs_check	स्ट्रिंग; डिफ़ॉल्ट रूप से "" अब काम नहीं करता.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ी जाने वाली शामिल डायरेक्ट्री की सूची. "वैरिएबल बनाएं" के बदले इस्तेमाल किया जा सकता है. हर स्ट्रिंग के आगे पैकेज पाथ जोड़ा जाता है. साथ ही, "include_paths" CROSSTOOL सुविधा की मदद से, स्ट्रिंग को बड़ा करने के लिए C++ टूलचेन को पास किया जाता है. POSIX सिस्टम पर चलने वाला टूलचेन, सामान्य सुविधाओं की परिभाषाओं के साथ -isystem path_to_package/include_entry जनरेट करेगा. इसका इस्तेमाल सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के लिए किया जाना चाहिए जो #include स्टेटमेंट लिखने के Google के स्टाइल के मुताबिक नहीं हैं. COPTS के उलट, ये फ़्लैग इस नियम और उस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: उन नियमों के बारे में नहीं जिन पर यह निर्भर करता है!) बहुत सावधान रहें, क्योंकि इससे काफ़ी असर पड़ सकता है. अगर आपको कोई संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. जोड़े गए include पाथ में, जनरेट की गई फ़ाइलों के साथ-साथ सोर्स ट्री में मौजूद फ़ाइलें भी शामिल होंगी.
link_extra_lib	लेबल; डिफ़ॉल्ट रूप से "@bazel_tools//tools/cpp:link_extra_lib" अतिरिक्त लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल करना. डिफ़ॉल्ट रूप से, C++ बाइनरी //tools/cpp:link_extra_lib के साथ लिंक होती हैं. यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग //tools/cpp:link_extra_libs पर निर्भर करता है. फ़्लैग सेट किए बिना, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग को सेट करने पर, वैकल्पिक डिपेंडेंसी को लिंक किया जा सकता है. जैसे, कमज़ोर सिंबल के लिए बदलाव, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के बदले, malloc या --custom_malloc का इस्तेमाल करें). इस एट्रिब्यूट को None पर सेट करने से, यह सुविधा बंद हो जाती है.
linkopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] C++ लिंकर कमांड में ये फ़्लैग जोड़ें. "Make" वैरिएबल के बदले, Bourne शेल टोकनाइज़ेशन और लेबल एक्सपैंशन का इस्तेमाल किया जा सकता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को LINKOPTS में जोड़ा जाता है. इस सूची के हर उस एलिमेंट को deps में टारगेट का लेबल माना जाता है जो $ या - से शुरू नहीं होता. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या deps में एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
linkshared	बूलियन; डिफ़ॉल्ट तौर पर False शेयर की जा सकने वाली लाइब्रेरी बनाएं. इस एट्रिब्यूट को चालू करने के लिए, अपने नियम में linkshared=True शामिल करें. यह विकल्प डिफ़ॉल्ट रूप से बंद होता है. इस फ़्लैग की मौजूदगी का मतलब है कि -shared फ़्लैग के साथ gcc को लिंक किया गया है. साथ ही, इससे बनी शेयर की गई लाइब्रेरी, उदाहरण के लिए, Java प्रोग्राम में लोड करने के लिए सही है. हालांकि, इसे कभी भी बिल्ड के मकसद से, डिपेंडेंट बाइनरी से लिंक नहीं किया जाएगा. ऐसा इसलिए माना जाता है, क्योंकि cc_binary नियम के साथ बनाई गई शेयर की गई लाइब्रेरी, सिर्फ़ अन्य प्रोग्राम के ज़रिए मैन्युअल तरीके से लोड की जाती हैं. इसलिए, इसे cc_library नियम के विकल्प के तौर पर नहीं माना जाना चाहिए. हमारा सुझाव है कि बड़े पैमाने पर डेटा का इस्तेमाल करने के लिए, इस तरीके का इस्तेमाल न करें. इसके बजाय, java_library को cc_library नियमों पर निर्भर रहने दें. linkopts=['-static'] और linkshared=True, दोनों को तय करने पर, आपको एक ऐसी यूनिट मिलती है जिसमें सभी एलिमेंट मौजूद होते हैं. अगर आपने linkstatic=True और linkshared=True, दोनों का इस्तेमाल किया है, तो आपको एक ऐसी यूनिट मिलेगी जिसमें ज़्यादातर चीज़ें पहले से मौजूद होती हैं.
linkstatic	बूलियन; डिफ़ॉल्ट तौर पर True cc_binary और cc_test के लिए: स्टैटिक मोड में बाइनरी को लिंक करें. cc_library.link_static के लिए: नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प, बिल्ड टूल को उपयोगकर्ता लाइब्रेरी के लिए, .so के बजाय .a को लिंक करने के लिए कहता है. libc जैसी सिस्टम लाइब्रेरी (लेकिन C/C++ रनटाइम लाइब्रेरी नहीं, नीचे देखें) अब भी डाइनैमिक तौर पर लिंक की जाती हैं. साथ ही, ऐसी लाइब्रेरी भी डाइनैमिक तौर पर लिंक की जाती हैं जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे में मिलने वाला एक्सीक्यूटेबल अब भी डाइनैमिक तौर पर लिंक किया जाएगा. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगा. किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं: fully_static_link सुविधा के साथ स्टैटिक, जिसमें सब कुछ स्टैटिक तौर पर लिंक किया गया है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm". features एट्रिब्यूट में fully_static_link डालकर, यह मोड चालू किया जाता है. स्टैटिक, जिसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है, जैसे कि "gcc foo.o libfoo.a libbaz.a -lm". linkstatic=True की वैल्यू डालकर, यह मोड चालू किया जाता है. डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाती हैं (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "gcc foo.o libfoo.so libbaz.so -lm". linkstatic=False की जानकारी देकर, यह मोड चालू किया जाता है. अगर features में मौजूद linkstatic एट्रिब्यूट या fully_static_link का इस्तेमाल, //third_party के बाहर किया गया है, तो कृपया नियम के बगल में एक टिप्पणी शामिल करें और बताएं कि ऐसा क्यों किया गया है. linkstatic एट्रिब्यूट का इस्तेमाल cc_library() नियम के लिए करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, linkstatic=True से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई .so नहीं बनाया जाएगा. linkstatic=False से स्टैटिक लाइब्रेरी बनने से नहीं रोका जा सकता. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है. प्रोडक्शन में linkstatic=False के साथ बहुत कम कोड बनाया जाना चाहिए. अगर linkstatic=False है, तो बिल्ड टूल *.runfiles एरिया में, उन शेयर की गई लाइब्रेरी के लिए सिंबललिंक बनाएगा जिन पर निर्भर किया गया है.
local_defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इस टारगेट के लिए, स्ट्रिंग को कंपाइल करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए. defines के उलट, इस टारगेट के लिए, परिभाषाओं को सिर्फ़ कमांड लाइन में जोड़ा जाता है.
malloc	लेबल; डिफ़ॉल्ट रूप से "@bazel_tools//tools/cpp:malloc" malloc पर डिफ़ॉल्ट डिपेंडेंसी को बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी //tools/cpp:malloc से लिंक होती हैं, जो एक खाली लाइब्रेरी है. इसलिए, बाइनरी libc malloc का इस्तेमाल करती है. यह लेबल, किसी cc_library से जुड़ा होना चाहिए. अगर कंपाइलेशन, C++ के अलावा किसी दूसरे नियम के लिए है, तो इस विकल्प का कोई असर नहीं पड़ता. अगर linkshared=True की वैल्यू दी गई है, तो इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है.
module_interfaces	लेबल की सूची; डिफ़ॉल्ट [] है फ़ाइलों की सूची को C++20 मॉड्यूल इंटरफ़ेस माना जाता है. C++ स्टैंडर्ड में, मॉड्यूल इंटरफ़ेस फ़ाइल एक्सटेंशन के लिए कोई पाबंदी नहीं है Clang 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, 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 में शामिल करें एट्रिब्यूट का इस्तेमाल किया जा सकता है. उदाहरण के लिए:

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 है, तो सी++ की इस पहले से संकलित लाइब्रेरी पर सीधे या किसी दूसरे तरीके से निर्भर रहने वाली कोई भी बाइनरी, स्टैटिक लाइब्रेरी में संग्रहित सभी ऑब्जेक्ट फ़ाइलों को लिंक करेगी. भले ही, कुछ में बाइनरी के रेफ़रंस वाले कोई सिंबल न हों. यह तब काम आता है, जब बाइनरी में कोड से आपके कोड को साफ़ तौर पर कॉल नहीं किया जाता. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिलने वाला कॉलबैक पाने के लिए रजिस्टर करता है. अगर alwayslink, Windows पर VS 2017 के साथ काम नहीं करता है, तो इसकी वजह पहले से मौजूद समस्या है. कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ी जाने वाली शामिल डायरेक्ट्री की सूची. "वैरिएबल बनाएं" के बदले इस्तेमाल किया जा सकता है. हर स्ट्रिंग के आगे पैकेज पाथ जोड़ा जाता है. साथ ही, "include_paths" CROSSTOOL सुविधा की मदद से, स्ट्रिंग को बड़ा करने के लिए C++ टूलचेन को पास किया जाता है. POSIX सिस्टम पर चलने वाला टूलचेन, सामान्य सुविधाओं की परिभाषाओं के साथ -isystem path_to_package/include_entry जनरेट करेगा. इसका इस्तेमाल सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के लिए किया जाना चाहिए जो #include स्टेटमेंट लिखने के Google के स्टाइल के मुताबिक नहीं हैं. COPTS के उलट, ये फ़्लैग इस नियम और उस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: उन नियमों के बारे में नहीं जिन पर यह निर्भर करता है!) बहुत सावधान रहें, क्योंकि इससे काफ़ी असर पड़ सकता है. अगर आपको कोई संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. डिफ़ॉल्ट include पाथ में जनरेट की गई फ़ाइलें शामिल नहीं होती हैं. अगर आपको जनरेट की गई हेडर फ़ाइल #include करनी है, तो उसे srcs में शामिल करें.
interface_library	लेबल; डिफ़ॉल्ट रूप से None शेयर की गई लाइब्रेरी को लिंक करने के लिए, एक इंटरफ़ेस लाइब्रेरी. इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: .ifso, .tbd, .lib, .so या .dylib
linkopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] C++ लिंकर कमांड में ये फ़्लैग जोड़ें. "Make" वैरिएबल के बदले, Bourne शेल टोकनाइज़ेशन और लेबल एक्सपैंशन का इस्तेमाल किया जा सकता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को LINKOPTS में जोड़ा जाता है. इस सूची के हर उस एलिमेंट को deps में टारगेट का लेबल माना जाता है जो $ या - से शुरू नहीं होता. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या deps में एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
objects	लेबल की सूची; डिफ़ॉल्ट [] है
pic_objects	लेबल की सूची; डिफ़ॉल्ट [] है
pic_static_library	लेबल; डिफ़ॉल्ट रूप से None
shared_library	लेबल; डिफ़ॉल्ट रूप से None पहले से कंपाइल की गई एक शेयर की गई लाइब्रेरी. Bazel यह पक्का करता है कि वह रनटाइम के दौरान, उस बाइनरी के लिए उपलब्ध हो जिस पर वह निर्भर करता है. इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: .so, .dll या .dylib
static_library	लेबल; डिफ़ॉल्ट रूप से None पहले से कंपाइल की गई एक स्टैटिक लाइब्रेरी. इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: .a, .pic.a या .lib
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, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hdrs_check, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, module_interfaces, package_metadata, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

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

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

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

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

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

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

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

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

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

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

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

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

फ़ाइल शामिल करना	शामिल किए जा सकने वाले आइटम
foo.h	bar.h
foo.cc	foo.h bar.h
bar.h	bar-impl.h baz.h
bar-impl.h	bar.h baz.h
bar.cc	bar.h bar-impl.h baz.h
baz.h	baz-impl.h
baz-impl.h	baz.h
baz.cc	baz.h baz-impl.h

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

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

उदाहरण

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

cc_library(
    name = "ast_inspector_lib",
    srcs = ["ast_inspector_lib.cc"],
    hdrs = ["ast_inspector_lib.h"],
    visibility = ["//visibility:public"],
    deps = ["//third_party/llvm/llvm/tools/clang:frontend"],
    # alwayslink as we want to be able to call things in this library at
    # debug time, even if they aren't used anywhere in the code.
    alwayslink = 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 C प्रीप्रोसेसर वाला असेंबलर: .S संग्रहित करें: .a, .pic.a "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo शेयर की गई लाइब्रेरी, वर्शन वाली या वर्शन वाली नहीं: .so, .so.version ऑब्जेक्ट फ़ाइल: .o, .pic.o ... और उन फ़ाइलों को बनाने वाले सभी नियम (उदाहरण के लिए, cc_embed_data). अलग-अलग एक्सटेंशन, gcc के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
data	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. data के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. अगर data, जनरेट की गई फ़ाइल का नाम है, तो यह cc_library नियम, जनरेट करने वाले नियम पर अपने-आप निर्भर करता है. अगर data किसी नियम का नाम है, तो यह cc_library नियम अपने-आप उस नियम पर निर्भर करता है, और उस नियम के outs, इस cc_library की डेटा फ़ाइलों में अपने-आप जुड़ जाते हैं. आपका C++ कोड इन डेटा फ़ाइलों को इस तरह ऐक्सेस कर सकता है: const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
hdrs	लेबल की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची, ताकि सोर्स उन्हें सीधे तौर पर, डिपेंडेंट नियमों में शामिल कर सकें. लाइब्रेरी के इंटरफ़ेस के बारे में बताने वाली हेडर फ़ाइलों को यहां एलान करना सबसे सही होता है. इन हेडर को इस नियम या उससे जुड़े नियमों में सोर्स के ज़रिए शामिल करने के लिए उपलब्ध कराया जाएगा. जिन हेडर को इस लाइब्रेरी के क्लाइंट को शामिल नहीं करना है उन्हें srcs एट्रिब्यूट में शामिल किया जाना चाहिए. भले ही, उन्हें पब्लिश किए गए हेडर में शामिल किया गया हो. ज़्यादा जानकारी के लिए, "हेडर में शामिल करने की जांच" देखें. headers फ़ाइल टाइप के लिए अनुमति है: .h, .hh, .hpp, .hxx.
additional_compiler_inputs	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी कोई भी अतिरिक्त फ़ाइल जिसे आपको कंपाइलर कमांड लाइन में पास करना है. उदाहरण के लिए, sanitizer की सूची. यहां बताई गई फ़ाइलों का इस्तेमाल, copts में $(location) फ़ंक्शन के साथ किया जा सकता है.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी डिपेंडेंसी जो सिर्फ़ C++ लिंकर कमांड के लिए उपलब्ध होती हैं. deps, कॉम्पाइलेशन और लिंक करने के लिए बनाया गया है. वहीं, additional_linker_inputs सिर्फ़ लिंक करने के लिए बनाया गया है. यह सिर्फ़ उस डिपेंडेंसी के बारे में बताता है जो सिर्फ़ लिंक करने के लिए ज़रूरी है. उदाहरण के लिए, linkopts में रेफ़र की गई फ़ाइलें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, यहां इकट्ठा की गई Windows .res फ़ाइलें दी जा सकती हैं.
alwayslink	बूलियन; डिफ़ॉल्ट तौर पर False अगर 1 है, तो सीधे या किसी अन्य तरीके से इस C++ लाइब्रेरी पर निर्भर रहने वाली कोई भी बाइनरी, srcs में दी गई फ़ाइलों के लिए सभी ऑब्जेक्ट फ़ाइलों को लिंक करेगी. भले ही, कुछ फ़ाइलों में बाइनरी का रेफ़रंस देने वाला कोई सिंबल न हो. यह तब काम आता है, जब बाइनरी में कोड से आपके कोड को साफ़ तौर पर कॉल नहीं किया जाता. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिलने वाला कॉलबैक पाने के लिए रजिस्टर करता है. अगर alwayslink, Windows पर VS 2017 के साथ काम नहीं करता है, तो इसकी वजह पहले से मौजूद समस्या है. कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें.
conlyopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] C कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] C/C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. बाइनरी टारगेट को संकलित करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में COPTS में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, न कि इसकी डिपेंडेंसी के लिए. इसलिए, दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस से जुड़े होने चाहिए. third_party के अलावा, इस एट्रिब्यूट की ज़रूरत नहीं होती. अगर पैकेज में feature no_copts_tokenization का एलान किया गया है, तो Bourne shell टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल होता है.
cxxopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस और उन सभी टारगेट की कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची जिन पर यह निर्भर है. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल करने की कमांड लाइन में और उस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई तरह के असर पड़ सकते हैं -- इस टारगेट पर निर्भर हर टारगेट में, परिभाषाएं जोड़ी जाती हैं. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय, local_defines में वैल्यू जोड़ें.
hdrs_check	स्ट्रिंग; डिफ़ॉल्ट रूप से "" अब काम नहीं करता.
implementation_deps	लेबल की सूची; डिफ़ॉल्ट [] है लाइब्रेरी टारगेट पर निर्भर अन्य लाइब्रेरी की सूची. deps के उलट, इन लाइब्रेरी के हेडर और शामिल किए गए पाथ (और इनके सभी ट्रांज़िशन डिपेंडेंसी) का इस्तेमाल सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है, न कि उन लाइब्रेरी के लिए जिन पर यह निर्भर करती है. implementation_deps के साथ बताई गई लाइब्रेरी अब भी उन बाइनरी टारगेट में लिंक हैं जो इस लाइब्रेरी पर निर्भर हैं.
include_prefix	स्ट्रिंग; डिफ़ॉल्ट रूप से "" इस नियम के हेडर के पाथ में जोड़ने के लिए प्रीफ़िक्स. सेट होने पर, इस नियम के hdrs एट्रिब्यूट में मौजूद हेडर ऐक्सेस किए जा सकते हैं. यह इस एट्रिब्यूट की वैल्यू है, जिसे उनके रिपॉज़िटरी के हिसाब से पाथ के आगे जोड़ा जाता है. इस प्रीफ़िक्स को जोड़ने से पहले, strip_include_prefix एट्रिब्यूट में मौजूद प्रीफ़िक्स हटा दिया जाता है. यह एट्रिब्यूट सिर्फ़ third_party के तहत मान्य है.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ी जाने वाली शामिल डायरेक्ट्री की सूची. "वैरिएबल बनाएं" के बदले इस्तेमाल किया जा सकता है. हर स्ट्रिंग के आगे पैकेज पाथ जोड़ा जाता है. साथ ही, "include_paths" CROSSTOOL सुविधा की मदद से, स्ट्रिंग को बड़ा करने के लिए C++ टूलचेन को पास किया जाता है. POSIX सिस्टम पर चलने वाला टूलचेन, सामान्य सुविधाओं की परिभाषाओं के साथ -isystem path_to_package/include_entry जनरेट करेगा. इसका इस्तेमाल सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के लिए किया जाना चाहिए जो #include स्टेटमेंट लिखने के Google के स्टाइल के मुताबिक नहीं हैं. COPTS के उलट, ये फ़्लैग इस नियम और उस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: उन नियमों के बारे में नहीं जिन पर यह निर्भर करता है!) बहुत सावधान रहें, क्योंकि इससे काफ़ी असर पड़ सकता है. अगर आपको कोई संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. जोड़े गए include पाथ में, जनरेट की गई फ़ाइलों के साथ-साथ सोर्स ट्री में मौजूद फ़ाइलें भी शामिल होंगी.
linkopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] cc_binary.linkopts देखें. linkopts एट्रिब्यूट, किसी भी ऐसे टारगेट पर भी लागू होता है जो deps एट्रिब्यूट के ज़रिए, सीधे या अप्रत्यक्ष रूप से इस लाइब्रेरी पर निर्भर करता है. इसके अलावा, यह एट्रिब्यूट उन अन्य एट्रिब्यूट पर भी लागू होता है जिन्हें इसी तरह माना जाता है: cc_binary का malloc एट्रिब्यूट.डिपेंडेंसी लिंकऑप्ट, डिपेंडेंट लिंकऑप्ट से पहले दिखते हैं. इसका मतलब है कि डिपेंडेंसी लिंकऑप्ट, कमांड लाइन में बाद में दिखते हैं. --linkopt में बताए गए लिंकऑप्ट, नियम के लिंकऑप्ट से ज़्यादा प्राथमिकता पाते हैं. ध्यान दें कि linkopts एट्रिब्यूट का इस्तेमाल सिर्फ़ .so फ़ाइलें या एक्ज़ीक्यूटेबल बनाने के लिए किया जाता है, न कि .a या .lo फ़ाइलें बनाने के लिए. इसलिए, अगर linkstatic=True एट्रिब्यूट सेट है, तो linkopts एट्रिब्यूट का इस लाइब्रेरी के बनने पर कोई असर नहीं पड़ता. इसका असर सिर्फ़ उन दूसरे टारगेट पर पड़ता है जो इस लाइब्रेरी पर निर्भर करते हैं. यह भी ध्यान रखें कि "-Wl,-soname" या "-Xlinker -soname" विकल्प काम नहीं करते. साथ ही, इस एट्रिब्यूट में इन विकल्पों को कभी भी नहीं दिया जाना चाहिए. cc_library नियमों से जनरेट की गई .so फ़ाइलें, उन लाइब्रेरी से लिंक नहीं होतीं जिन पर वे निर्भर करती हैं. अगर आपको मुख्य रिपॉज़िटरी के बाहर इस्तेमाल करने के लिए शेयर की गई लाइब्रेरी बनानी है, जैसे कि dlopen() या LD_PRELOAD के साथ मैन्युअल इस्तेमाल के लिए, तो linkshared=True एट्रिब्यूट के साथ cc_binary नियम का इस्तेमाल करना बेहतर होगा. cc_binary.linkshared देखें.
linkstamp	लेबल; डिफ़ॉल्ट रूप से None यह एक साथ, बताई गई C++ सोर्स फ़ाइल को फ़ाइनल बाइनरी में कॉम्पाइल और लिंक करता है. बाइनरी में टाइमस्टैंप की जानकारी जोड़ने के लिए, यह तरकीब ज़रूरी है. अगर हम सोर्स फ़ाइल को सामान्य तरीके से ऑब्जेक्ट फ़ाइल में कंपाइल करते हैं, तो टाइमस्टैंप गलत होगा. हो सकता है कि लिंकस्टैंप कंपाइलेशन में, कंपाइलर फ़्लैग का कोई खास सेट शामिल न हो. इसलिए, यह किसी खास हेडर, कंपाइलर विकल्प या दूसरे बिल्ड वैरिएबल पर निर्भर नहीं होना चाहिए. यह विकल्प सिर्फ़ base पैकेज में ज़रूरी है.
linkstatic	बूलियन; डिफ़ॉल्ट तौर पर False cc_binary और cc_test के लिए: स्टैटिक मोड में बाइनरी को लिंक करें. cc_library.link_static के लिए: नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प, बिल्ड टूल को उपयोगकर्ता लाइब्रेरी के लिए, .so के बजाय .a को लिंक करने के लिए कहता है. libc जैसी सिस्टम लाइब्रेरी (लेकिन C/C++ रनटाइम लाइब्रेरी नहीं, नीचे देखें) अब भी डाइनैमिक तौर पर लिंक की जाती हैं. साथ ही, ऐसी लाइब्रेरी भी डाइनैमिक तौर पर लिंक की जाती हैं जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे में मिलने वाला एक्सीक्यूटेबल अब भी डाइनैमिक तौर पर लिंक किया जाएगा. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगा. किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं: fully_static_link सुविधा के साथ स्टैटिक, जिसमें सब कुछ स्टैटिक तौर पर लिंक किया गया है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm". features एट्रिब्यूट में fully_static_link डालकर, यह मोड चालू किया जाता है. स्टैटिक, जिसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है, जैसे कि "gcc foo.o libfoo.a libbaz.a -lm". linkstatic=True की वैल्यू डालकर, यह मोड चालू किया जाता है. डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाती हैं (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "gcc foo.o libfoo.so libbaz.so -lm". linkstatic=False की जानकारी देकर, यह मोड चालू किया जाता है. अगर features में मौजूद linkstatic एट्रिब्यूट या fully_static_link का इस्तेमाल, //third_party के बाहर किया गया है, तो कृपया नियम के बगल में एक टिप्पणी शामिल करें और बताएं कि ऐसा क्यों किया गया है. linkstatic एट्रिब्यूट का इस्तेमाल cc_library() नियम के लिए करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, linkstatic=True से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई .so नहीं बनाया जाएगा. linkstatic=False से स्टैटिक लाइब्रेरी बनने से नहीं रोका जा सकता. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है. प्रोडक्शन में linkstatic=False के साथ बहुत कम कोड बनाया जाना चाहिए. अगर linkstatic=False है, तो बिल्ड टूल *.runfiles एरिया में, उन शेयर की गई लाइब्रेरी के लिए सिंबललिंक बनाएगा जिन पर निर्भर किया गया है.
local_defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इस टारगेट के लिए, स्ट्रिंग को कंपाइल करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए. defines के उलट, इस टारगेट के लिए, परिभाषाओं को सिर्फ़ कमांड लाइन में जोड़ा जाता है.
module_interfaces	लेबल की सूची; डिफ़ॉल्ट [] है फ़ाइलों की सूची को C++20 मॉड्यूल इंटरफ़ेस माना जाता है. C++ स्टैंडर्ड में, मॉड्यूल इंटरफ़ेस फ़ाइल एक्सटेंशन के लिए कोई पाबंदी नहीं है Clang 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, compatible_with, deprecation, dynamic_deps, exec_compatible_with, exec_group_compatible_with, exec_properties, exports_filter, features, package_metadata, restricted_to, roots, shared_lib_name, static_deps, tags, target_compatible_with, testonly, toolchains, user_link_flags, visibility, win_def_file)

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

उदाहरण

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

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

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

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

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

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

गड़बड़ियां

Two shared libraries in dependencies export the same symbols.

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

Two shared libraries in dependencies link the same library statically

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

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

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

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

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

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

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

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

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

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

तर्क

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

cc_static_library

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

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

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

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

आउटपुट ग्रुप

linkdeps

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

linkopts

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

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

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

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

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

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

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

तर्क

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

cc_test

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

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

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

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

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

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

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

तर्क

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

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

इस नियम की वजह से:

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

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

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

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
all_files	लेबल; ज़रूरी है सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. इन आर्टफ़ैक्ट को, rules_cc से जुड़ी सभी कार्रवाइयों में इनपुट के तौर पर जोड़ा जाएगा. हालांकि, उन कार्रवाइयों को छोड़कर जो यहां दिए गए एट्रिब्यूट से आर्टफ़ैक्ट के ज़्यादा सटीक सेट का इस्तेमाल कर रही हैं. Bazel मानता है कि all_files, आर्टफ़ैक्ट उपलब्ध कराने वाले सभी अन्य एट्रिब्यूट का सुपरसेट है.उदाहरण के लिए, लिंकस्टैंप कंपाइलेशन के लिए, कंपाइल और लिंक फ़ाइलों, दोनों की ज़रूरत होती है. इसलिए, इसमें all_files का इस्तेमाल किया जाता है. cc_toolchain.files में यही होता है. C++ टूलचेन का इस्तेमाल करने वाले सभी Starlark नियमों में इसका इस्तेमाल किया जाता है.
ar_files	लेबल; डिफ़ॉल्ट रूप से None कार्रवाइयों को संग्रहित करने के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
as_files	लेबल; डिफ़ॉल्ट रूप से None असेंबली ऐक्शन के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
compiler_files	लेबल; ज़रूरी है कंपाइल करने की कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
compiler_files_without_includes	लेबल; डिफ़ॉल्ट रूप से None इनपुट डिस्कवरी की सुविधा के काम करने पर, cc_toolchain के सभी आर्टफ़ैक्ट का कलेक्शन, जो कंपाइल करने की कार्रवाइयों के लिए ज़रूरी होता है. फ़िलहाल, यह सुविधा सिर्फ़ Google पर काम करती है.
coverage_files	लेबल; डिफ़ॉल्ट रूप से None कवरेज ऐक्शन के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. अगर यह जानकारी नहीं दी गई है, तो all_files का इस्तेमाल किया जाता है.
dwp_files	लेबल; ज़रूरी है dwp कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
dynamic_runtime_lib	लेबल; डिफ़ॉल्ट रूप से None C++ रनटाइम लाइब्रेरी (उदाहरण के लिए, libstdc++.so) के लिए डाइनैमिक लाइब्रेरी आर्टफ़ैक्ट. इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू हो और हम डिपेंडेंसी को डाइनैमिक तौर पर लिंक कर रहे हों.
exec_transition_for_inputs	बूलियन; डिफ़ॉल्ट तौर पर False समर्थन नहीं होना या रुकना. कोई कार्रवाई नहीं.
libc_top	लेबल; डिफ़ॉल्ट रूप से None libc के लिए आर्टफ़ैक्ट का कलेक्शन, जिसे कंपाइल/लिंक करने की कार्रवाइयों के इनपुट के तौर पर पास किया जाता है.
linker_files	लेबल; ज़रूरी है कार्रवाइयों को लिंक करने के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
module_map	लेबल; डिफ़ॉल्ट रूप से None मॉड्यूलर बिल्ड के लिए इस्तेमाल किया जाने वाला मॉड्यूल मैप आर्टफ़ैक्ट.
objcopy_files	लेबल; ज़रूरी है objcopy ऐक्शन के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
output_licenses	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []
static_runtime_lib	लेबल; डिफ़ॉल्ट रूप से None C++ रनटाइम लाइब्रेरी (उदाहरण के लिए, libstdc++.a) के लिए स्टैटिक लाइब्रेरी आर्टफ़ैक्ट. इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू हो और हम डिपेंडेंसी को स्टैटिक तौर पर लिंक कर रहे हों.
strip_files	लेबल; ज़रूरी है स्ट्रिप ऐक्शन के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
supports_header_parsing	बूलियन; डिफ़ॉल्ट तौर पर False जब cc_toolchain, हेडर पार्स करने की कार्रवाइयों के साथ काम करता है, तो इसे 'सही है' पर सेट करें.
supports_param_files	बूलियन; डिफ़ॉल्ट तौर पर True जब cc_toolchain, कार्रवाइयों को लिंक करने के लिए पैरामीटर फ़ाइलों का इस्तेमाल करने की सुविधा देता है, तो इसे 'सही है' पर सेट करें.
toolchain_config	लेबल; ज़रूरी है cc_toolchain_config_info की जानकारी देने वाले नियम का लेबल.
toolchain_identifier	स्ट्रिंग; डिफ़ॉल्ट रूप से "" इस cc_toolchain को उससे जुड़े crosstool_config.toolchain से मैच करने के लिए इस्तेमाल किया जाने वाला आइडेंटिफ़ायर. जब तक #5380 वाली समस्या ठीक नहीं हो जाती, तब तक cc_toolchain को CROSSTOOL.toolchain से जोड़ने के लिए, यह तरीका अपनाएं. इसे toolchain_config एट्रिब्यूट (#5380) से बदल दिया जाएगा.

cc_toolchain_suite

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

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

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

तर्क

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

fdo_prefetch_hints

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

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

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

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

तर्क

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

fdo_profile

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

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

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

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

तर्क

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

memprof_profile

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

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

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

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

तर्क

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

propeller_optimize

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

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

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

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

तर्क

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