C / C++ नियम

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें नाइटली · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

नियम

• cc_binary
• cc_import
• cc_library
• cc_proto_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, copts, defines, deprecation, distribs, dynamic_deps, env, exec_compatible_with, exec_properties, features, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, module_interfaces, nocopts, output_licenses, reexport_deps, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

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

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

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

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

तर्क

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

cc_import

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

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

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

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

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है 2. शेयर की गई लाइब्रेरी (Unix) को लिंक करना

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है 3. इंटरफ़ेस लाइब्रेरी के साथ शेयर लाइब्रेरी को लिंक करना

यूनिक्स पर:

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 से शेयर की गई लाइब्रेरी को लिंक करना

यूनिक्स पर:

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

Windows पर:

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है 5. स्टैटिक या शेयर की गई लाइब्रेरी से लिंक करना

यूनिक्स पर:

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

Windows पर:

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

Unix और Windows पर बाकी सुविधाएं एक जैसी हैं:

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

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

cc_import में एक एट्रिब्यूट शामिल किया जा सकता है. जैसे:

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 के साथ काम नहीं करता है, तो इसकी वजह से आम समस्या, कृपया अपने VS 2017 को सबसे नए वर्शन में अपग्रेड करें.
includes	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है कंपाइल लाइन में जोड़े जाने वाले डाइरों को शामिल करने की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. हर स्ट्रिंग को पैकेज पाथ के साथ जोड़ा जाता है. साथ ही, इसे "include_paths" के ज़रिए एक्सपैंशन CROSSTOOL सुविधा. POSIX सिस्टम पर चल रहा टूलचेन साथ ही, किसी ख़ास सुविधा की मदद से -isystem path_to_package/include_entry. इसका उपयोग केवल ऐसी तृतीय-पक्ष लाइब्रेरी के लिए किया जाना चाहिए #इन्क्लूड स्टेटमेंट लिखने की Google शैली के अनुरूप नहीं हैं. COPS के उलट, इस नियम के लिए ये फ़्लैग जोड़े जाते हैं और इस पर निर्भर सभी नियमों के लिए बनाया गया है. (ध्यान दें: वे नियम नहीं हैं जिन पर यह निर्भर करता है!) होना ध्यान रखें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. संदेह होने पर, जोड़ें "-मैं" फ़्लैग करने के बजाय COPTS पर फ़्लैग कर सकते हैं. डिफ़ॉल्ट include पाथ में, जनरेट किया गया डेटा शामिल नहीं होता फ़ाइलें शामिल हैं. अगर आपको जनरेट किए गए हेडर को #include करना है फ़ाइल, उसे srcs में सूचीबद्ध करें.
interface_library	लेबल; डिफ़ॉल्ट रूप से None है शेयर की गई लाइब्रेरी को लिंक करने के लिए सिंगल इंटरफ़ेस लाइब्रेरी. अनुमति वाले फ़ाइल टाइप: .ifso, .tbd, .lib, .so या .dylib
linkopts	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन, बॉर्न शेल टोकनाइज़ेशन और लेबल एक्सपैंशन. इस एट्रिब्यूट की हर स्ट्रिंग को पहले LINKOPTS में जोड़ दिया गया है बाइनरी टारगेट को लिंक करना. इस सूची का हर वह एलिमेंट जो $ या - से शुरू नहीं होता है deps में किसी टारगेट का लेबल माना जाता है. कॉन्टेंट बनाने उस टारगेट से जनरेट होने वाली फ़ाइलों की सूची को लिंकर में जोड़ा जाता है के विकल्प. अगर लेबल अमान्य है, तो एक गड़बड़ी की रिपोर्ट की जाती है, या deps में नहीं बताया गया.
objects	लेबल की सूची; डिफ़ॉल्ट रूप से [] है
pic_objects	लेबल की सूची; डिफ़ॉल्ट रूप से [] है
pic_static_library	लेबल; डिफ़ॉल्ट रूप से None है
shared_library	लेबल; डिफ़ॉल्ट रूप से None है पहले से कंपाइल की गई सिंगल शेयर लाइब्रेरी. Baze, पक्का करता है कि यह कंपनी बाइनरी, जो रनटाइम के दौरान इस पर निर्भर करती है. अनुमति वाले फ़ाइल टाइप: .so, .dll या .dylib
static_library	लेबल; डिफ़ॉल्ट रूप से None है पहले से कंपाइल की गई एक स्टैटिक लाइब्रेरी. अनुमति वाले फ़ाइल टाइप: .a, .pic.a या .lib
system_provided	बूलियन; False डिफ़ॉल्ट है अगर 1 है, तो इसका मतलब है कि रनटाइम के दौरान, शेयर की गई लाइब्रेरी ज़रूरी है, जिसे सिस्टम उपलब्ध कराता है. तय सीमा में इस मामले में, interface_library को तय किया जाना चाहिए और shared_library खाली होनी चाहिए.

cc_library

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

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

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

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

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

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

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

cc_library नियमों के लिए, hdrs के हेडर में ये शामिल होते हैं लाइब्रेरी का सार्वजनिक इंटरफ़ेस और इसे सीधे दोनों में शामिल किया जा सकता है लाइब्रेरी की hdrs और srcs की फ़ाइलों से साथ ही, hdrs और srcs में मौजूद फ़ाइलों से cc_* नियमों में से, जो लाइब्रेरी को अपने 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	फ़ू.ह बार.ह
bar.h	Bar-impl.h baz.h
बार-इंप्लि.एच	बार.ह बाज़.एच
bar.cc	बार.ह बार-इंप्ल.ह बाज़.एच
baz.h	बाज़-इंप्ल॰एच
बाज़-इंप्ल॰एच	baz.h
baz.cc	बाज़.ह बाज़-इंप्ल.एच

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

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

उदाहरण

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

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

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

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

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

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

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

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

तर्क

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

cc_proto_library

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

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

cc_proto_library, .proto फ़ाइलों से C++ कोड जनरेट करता है.

deps फ़ंक्शन, proto_library के नियमों पर ले जाने वाला होना चाहिए.

उदाहरण:

cc_library(
    name = "lib",
    deps = [":foo_cc_proto"],
)

cc_proto_library(
    name = "foo_cc_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
)

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट रूप से [] है proto_library की सूची C++ कोड जनरेट करने के नियम तय करें.

cc_shared_library

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

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

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

उदाहरण

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

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

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

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

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

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

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

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

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

तर्क

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

cc_static_library

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

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

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

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

आउटपुट ग्रुप

linkdeps

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

linkopts

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

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

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

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

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

Baज़र के साथ काम करने वाले, अपने-आप कॉन्फ़िगर होने वाले 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, copts, defines, deprecation, distribs, dynamic_deps, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local, local_defines, malloc, module_interfaces, nocopts, reexport_deps, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

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

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

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

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

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

तर्क

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

cc_toolchain

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

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

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

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

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

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

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

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
all_files	लेबल; आवश्यक सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. इन आर्टफ़ैक्ट को इनपुट के तौर पर सभी रूल_सीसी से जुड़ी कार्रवाइयां (उन कार्रवाइयों को छोड़कर जो इसके ज़्यादा सटीक सेट का इस्तेमाल करती हैं आर्टफ़ैक्ट के बारे में ज़्यादा जानें). बेज़ल यह मानता है कि all_files एक सुपरसेट है आर्टफ़ैक्ट देने वाले दूसरे सभी एट्रिब्यूट शामिल हैं.उदाहरण के लिए, linkstamp को कंपाइल करना ज़रूरी है. इसके लिए, और लिंक फ़ाइलें, इसलिए इसमें all_files लगता है). cc_toolchain.files में यही कॉन्टेंट होता है और सभी Starlark इसका इस्तेमाल करते हैं C++ टूलचेन का इस्तेमाल करने के नियम तय करते हैं.
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 आर्टफ़ैक्ट का कलेक्शन. अगर इसके बारे में नहीं बताया गया है, सभी फ़ाइलों का इस्तेमाल किया जाता है.
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	लेबल; आवश्यक objकॉपी की कार्रवाइयों के लिए, सभी 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	String; "" डिफ़ॉल्ट है इस cc_toolchain का मिलान संबंधित प्रॉडक्ट से करने के लिए इस्तेमाल किया जाने वाला आइडेंटिफ़ायर crosstool_config.toolchain. समस्या #5380 के ठीक होने तक यह cc_toolchain को CROSSTOOL.toolchain. इसे toolchain_config से बदल दिया जाएगा एट्रिब्यूट (#5380).

cc_toolchain_suite

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

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

बहिष्कृत: नियम नो-ऑप है और इसे हटा दिया जाएगा.

तर्क

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

fdo_prefetch_hints

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

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

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

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

तर्क

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

fdo_profile

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

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

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

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

तर्क

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

memprof_profile

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

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

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

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

तर्क

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

propeller_optimize

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

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

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

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

तर्क

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