C / C++ नियम

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

नियम

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

cc_binary

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

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

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

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

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट रूप से [] है बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये cc_library या objc_library हो सकते हैं टारगेट के लिए.
srcs	लेबल की सूची; डिफ़ॉल्ट रूप से [] है टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये फ़ाइलें या तो जनरेट नहीं होती हैं (सामान्य सोर्स) कोड) या जनरेट किया गया हो. सभी .cc, .c, और .cpp फ़ाइलें कंपाइल नहीं किए जाएंगे. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर नाम वाली कोई फ़ाइल कुछ अन्य नियम का outs, यह नियम अपने आप उस दूसरे नियम पर निर्भर हो जाएगा. .h फ़ाइल को कंपाइल नहीं किया जाएगा, लेकिन वह को इस नियम में सोर्स के हिसाब से शामिल किया जाता है. .cc और, दोनों .h फ़ाइलों में, सूची में दिए गए हेडर सीधे शामिल किए जा सकते हैं ये srcs या इनमें सूचीबद्ध किसी भी नियम के hdrs में deps तर्क को बदल दिया गया है. सभी #included फ़ाइलों का उल्लेख इसमें होना चाहिए: srcs एट्रिब्यूट का इस्तेमाल करें या बताए गए cc_library() की hdrs एट्रिब्यूट. सुझाई गई स्टाइल लाइब्रेरी से जुड़े हेडर के लिए है उस लाइब्रेरी के hdrs एट्रिब्यूट में मौजूद होती है और बाकी सभी एट्रिब्यूट के लिए इस नियम के सोर्स से जुड़े हेडर, जिन्हें इसमें शामिल किया जाएगा srcs. "हेडर शामिल किए जाने की जांच" देखें देखें. अगर किसी नियम का नाम srcs में है, तो यह नियम अपने आप उस नियम पर निर्भर करता है. अगर नाम वाले नियम के outs C या C++ हैं सोर्स फ़ाइलें सेव की जाती हैं, तो उन्हें इस नियम में इकट्ठा किया जाता है; अगर वे लाइब्रेरी फ़ाइलें हैं, तो वे उनमें लिंक की हुई होती हैं. अनुमति वाले 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 ...और उन फ़ाइलों को बनाने वाले किसी भी नियम की जानकारी शामिल कर सकते हैं. अलग-अलग एक्सटेंशन, अलग-अलग प्रोग्रामिंग भाषाओं को gcc कन्वेंशन के मुताबिक होना चाहिए.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट रूप से [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां एम्बेड किया जा सकता है, ताकि उन्हें बाइनरी टारगेट.
copts	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है इन विकल्पों को C++ कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के विकल्प पर निर्भर करता है और बोर्न शेल टोकनाइज़ेशन. इस एट्रिब्यूट की हर स्ट्रिंग, दिए गए क्रम में COPTS से पहले जोड़ दी जाती है बाइनरी टारगेट को कंपाइल करना. फ़्लैग सिर्फ़ इस टारगेट को इकट्ठा करने के लिए लागू होते हैं, नहीं पर निर्भर नहीं होना चाहिए, इसलिए कहीं भी शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ को फ़ाइल फ़ोल्डर से संबंधित होनी चाहिए, न कि मौजूदा पैकेज से. अगर पैकेज, सुविधा का एलान करता है no_copts_tokenization, बॉर्न शेल टोकनाइज़ेशन सिर्फ़ स्ट्रिंग पर लागू होता है जिसमें एक "Make" वैरिएबल.
defines	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को -D के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, सभी नियम लागू कर सकते हैं. बहुत सावधान रहें, क्योंकि दूर तक पहुंचने के लिए. संदेह होने पर, 'तय करें' वैल्यू इसके बजाय, local_defines का इस्तेमाल करें.
includes	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है कंपाइल लाइन में जोड़े जाने वाले डाइरों को शामिल करने की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. हर स्ट्रिंग, -isystem से पहले जोड़ी जाती है और COPTS में जोड़ दी जाती है. COPS के उलट, इस नियम के लिए ये फ़्लैग जोड़े जाते हैं और इस पर निर्भर सभी नियमों के लिए बनाया गया है. (ध्यान दें: वे नियम नहीं हैं जिन पर यह निर्भर करता है!) होना ध्यान रखें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. संदेह होने पर, जोड़ें "-मैं" फ़्लैग करने के बजाय COPTS पर फ़्लैग कर सकते हैं. हेडर, srcs या hdrs में जोड़े जाने चाहिए. ऐसा न होने पर, ये डिपेंडेंट कंपाइलेशन के सैंडबॉक्स में उपलब्ध नियम (डिफ़ॉल्ट).
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.linkstatic के लिए: नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू और बाकी के लिए बंद रहता है. अगर यह नीति चालू है और यह एक बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को जब भी मुमकिन हो, तब यूज़र लाइब्रेरी के लिए .so के बजाय, .a को लागू किया जाता है. ऐसा हो सकता है कि कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक हों. जैसे, ऐसी लाइब्रेरी यहां कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे के तौर पर मिलने वाला एक्ज़ीक्यूटेबल अब भी डाइनैमिक होगा लिंक किया गया है, इसलिए सिर्फ़ ज़्यादातर स्थिर है. किसी एक्ज़ीक्यूटेबल को लिंक करने के वास्तव में तीन अलग-अलग तरीके हैं: पूरी तरह से 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 एट्रिब्यूट का इस्तेमाल किसी cc_library() नियम. C++ लाइब्रेरी के लिए, linkstatic=True बताता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है, इसलिए कोई .so नहीं बनाया जाएगा. linkstatic=False यह करता है स्टैटिक लाइब्रेरी को बनाए जाने से नहीं रोकें. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की सुविधा मिलती है. अगर linkstatic=False है, तो बिल्ड टूल यह *.runfiles इलाके में शेयर की गई लाइब्रेरी पर निर्भर करती है.
local_defines	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को -D के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, हालाँकि, डिपेंडेंट लोगों के लिए लागू हो सकता है.
malloc	लेबल; डिफ़ॉल्ट रूप से "@bazel_tools//tools/cpp:malloc" है मॉलोक पर डिफ़ॉल्ट डिपेंडेंसी बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:malloc से लिंक किया जाता है, यह एक खाली लाइब्रेरी है. इसलिए, बाइनरी फ़ाइल के आखिर में libc मैलडॉक का इस्तेमाल किया जाता है. यह लेबल किसी cc_library से जुड़ा होना चाहिए. अगर कंपाइलेशन बिना C++ वाली नियम के तहत, इस विकल्प का कोई असर नहीं पड़ता. इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है, अगर linkshared=True बताया गया है.
nocopts	String; "" डिफ़ॉल्ट है C++ कंपाइलेशन कमांड से मैच करने के विकल्प हटाएं. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन के तौर पर उपलब्ध है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाला कोई भी पहले से मौजूद COPTS (इसमें वे वैल्यू भी शामिल हैं जो नियम के कोप्ट एट्रिब्यूट में साफ़ तौर पर दी गई हैं) इस नियम को कंपाइल करने के लिए, COPTS का इस्तेमाल किया जाएगा. इस एट्रिब्यूट की ज़रूरत बहुत कम पड़ती है.
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, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, 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. इंटरफ़ेस लाइब्रेरी (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 (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",
)

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

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

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",
)

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

# second will link to mylib.dll through mylib.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 को सबसे नए वर्शन में अपग्रेड करें.
interface_library	लेबल; डिफ़ॉल्ट रूप से None है शेयर की गई लाइब्रेरी को लिंक करने के लिए सिंगल इंटरफ़ेस लाइब्रेरी. अनुमति वाले फ़ाइल टाइप: .ifso, .tbd, .lib, .so या .dylib
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, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

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

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

cc_library नियमों के लिए, hdrs में हेडर लाइब्रेरी से शामिल किया जा सकता है और उसे hdrs और लाइब्रेरी के srcs और hdrs और cc_* में से 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	फ़ू.ह बार.ह
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 के साथ काम करती है.

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट रूप से [] है बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये cc_library या objc_library हो सकते हैं टारगेट के लिए.
srcs	लेबल की सूची; डिफ़ॉल्ट रूप से [] है टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये फ़ाइलें या तो जनरेट नहीं होती हैं (सामान्य सोर्स) कोड) या जनरेट किया गया हो. सभी .cc, .c, और .cpp फ़ाइलें कंपाइल नहीं किए जाएंगे. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर नाम वाली कोई फ़ाइल कुछ अन्य नियम का outs, यह नियम अपने आप उस दूसरे नियम पर निर्भर हो जाएगा. .h फ़ाइल को कंपाइल नहीं किया जाएगा, लेकिन वह को इस नियम में सोर्स के हिसाब से शामिल किया जाता है. .cc और, दोनों .h फ़ाइलों में, सूची में दिए गए हेडर सीधे शामिल किए जा सकते हैं ये srcs या इनमें सूचीबद्ध किसी भी नियम के hdrs में deps तर्क को बदल दिया गया है. सभी #included फ़ाइलों का उल्लेख इसमें होना चाहिए: srcs एट्रिब्यूट का इस्तेमाल करें या बताए गए cc_library() की hdrs एट्रिब्यूट. सुझाई गई स्टाइल लाइब्रेरी से जुड़े हेडर के लिए है उस लाइब्रेरी के hdrs एट्रिब्यूट में मौजूद होती है और बाकी सभी एट्रिब्यूट के लिए इस नियम के सोर्स से जुड़े हेडर, जिन्हें इसमें शामिल किया जाएगा srcs. "हेडर शामिल किए जाने की जांच" देखें देखें. अगर किसी नियम का नाम srcs में है, तो यह नियम अपने आप उस नियम पर निर्भर करता है. अगर नाम वाले नियम के outs C या C++ हैं सोर्स फ़ाइलें सेव की जाती हैं, तो उन्हें इस नियम में इकट्ठा किया जाता है; अगर वे लाइब्रेरी फ़ाइलें हैं, तो वे उनमें लिंक की हुई होती हैं. अनुमति वाले 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 ...और उन फ़ाइलों को बनाने वाले किसी भी नियम की जानकारी शामिल कर सकते हैं. अलग-अलग एक्सटेंशन, अलग-अलग प्रोग्रामिंग भाषाओं को gcc कन्वेंशन के मुताबिक होना चाहिए.
hdrs	लेबल की सूची; डिफ़ॉल्ट रूप से [] है उन हेडर फ़ाइलों की सूची जिन्हें इन्होंने पब्लिश किया है इस लाइब्रेरी को डिपेंडेंट नियमों में शामिल सोर्स से सीधे तौर पर जोड़ा जाएगा. यह हेडर फ़ाइलों का एलान करने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है लाइब्रेरी के इंटरफ़ेस के बारे में बताता है. इन हेडर को का इस्तेमाल, इस नियम में मौजूद सोर्स से या अलग-अलग नियमों के तहत किया जा सकता है. ऐसे हेडर जिन्हें इस लाइब्रेरी के क्लाइंट द्वारा शामिल नहीं किया जाना चाहिए इसके बजाय, srcs एट्रिब्यूट में लिस्ट किया गया है, भले ही वे एक पब्लिश किए गए हेडर के ज़रिए शामिल किया जाता है. "हेडर शामिल करना" देखें चेक कर रहा है".
additional_compiler_inputs	लेबल की सूची; डिफ़ॉल्ट रूप से [] है ऐसी कोई भी अतिरिक्त फ़ाइल जिसे आप कंपाइलर कमांड लाइन को भेजना चाहें, जैसे कि सैनिटाइज़र उदाहरण के लिए, अनदेखा करने की सूचियां. यहां बताई गई फ़ाइलों को $(location) फ़ंक्शन.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट रूप से [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां एम्बेड किया जा सकता है, ताकि उन्हें बाइनरी टारगेट.
alwayslink	बूलियन; False डिफ़ॉल्ट है अगर 1 है, तो इस C++ पर निर्भर कोई भी बाइनरी (सीधे तौर पर या किसी अन्य तरीके से) लाइब्रेरी में सूचीबद्ध फ़ाइलों की सभी ऑब्जेक्ट फ़ाइलों से srcs, भले ही कुछ में बाइनरी से रेफ़र किया गया कोई सिंबल मौजूद न हो. यह तब उपयोगी होता है, जब आपके कोड को स्पष्ट रूप से कोड द्वारा कॉल नहीं किया जाता है बाइनरी, जैसे कि अगर आपका कोड कुछ कॉलबैक पाने के लिए रजिस्टर होता है कुछ सेवाओं ने उपलब्ध कराया है. अगर हमेशा लिंक Windows पर VS 2017 के साथ काम नहीं करता है, तो इसकी वजह से आम समस्या, कृपया अपने VS 2017 को सबसे नए वर्शन में अपग्रेड करें.
copts	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है इन विकल्पों को C++ कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के विकल्प पर निर्भर करता है और बोर्न शेल टोकनाइज़ेशन. इस एट्रिब्यूट की हर स्ट्रिंग, दिए गए क्रम में COPTS से पहले जोड़ दी जाती है बाइनरी टारगेट को कंपाइल करना. फ़्लैग सिर्फ़ इस टारगेट को इकट्ठा करने के लिए लागू होते हैं, नहीं पर निर्भर नहीं होना चाहिए, इसलिए कहीं भी शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ को फ़ाइल फ़ोल्डर से संबंधित होनी चाहिए, न कि मौजूदा पैकेज से. अगर पैकेज, सुविधा का एलान करता है no_copts_tokenization, बॉर्न शेल टोकनाइज़ेशन सिर्फ़ स्ट्रिंग पर लागू होता है जिसमें एक "Make" वैरिएबल.
defines	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को -D के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, सभी नियम लागू कर सकते हैं. बहुत सावधान रहें, क्योंकि दूर तक पहुंचने के लिए. संदेह होने पर, 'तय करें' वैल्यू इसके बजाय, local_defines का इस्तेमाल करें.
implementation_deps	लेबल की सूची; डिफ़ॉल्ट रूप से [] है लाइब्रेरी टारगेट की जाने वाली दूसरी लाइब्रेरी की सूची, इस पर निर्भर करती है. इससे नापसंद करें deps, हेडर और इन लाइब्रेरी के पाथ (और उनके सभी ट्रांज़िटिव डिप) का इस्तेमाल सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है, न कि उन लाइब्रेरी के लिए जिन्हें निर्भर है. implementation_deps के साथ तय की गई लाइब्रेरी अब भी इसमें लिंक हैं इस लाइब्रेरी पर निर्भर बाइनरी टारगेट. फ़िलहाल, इसका इस्तेमाल cc_लाइब्रेरी तक सीमित किया गया है और उसे फ़्लैग किया गया है --experimental_cc_implementation_deps.
include_prefix	String; "" डिफ़ॉल्ट है इस नियम के हेडर के पाथ में जोड़ा जाने वाला प्रीफ़िक्स. अगर नीति को सेट किया जाता है, तो इस नियम के hdrs एट्रिब्यूट में मौजूद हेडर को ऐक्सेस किया जा सकता है पर इस एट्रिब्यूट का मान है जो उनके रिपॉज़िटरी-रिलेटिव पाथ से पहले है. इससे पहले strip_include_prefix एट्रिब्यूट का प्रीफ़िक्स हटा दिया जाता है उपसर्ग जोड़ा गया है.
includes	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है कंपाइल लाइन में जोड़े जाने वाले डाइरों को शामिल करने की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. हर स्ट्रिंग, -isystem से पहले जोड़ी जाती है और COPTS में जोड़ दी जाती है. COPS के उलट, इस नियम के लिए ये फ़्लैग जोड़े जाते हैं और इस पर निर्भर सभी नियमों के लिए बनाया गया है. (ध्यान दें: वे नियम नहीं हैं जिन पर यह निर्भर करता है!) होना ध्यान रखें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. संदेह होने पर, जोड़ें "-मैं" फ़्लैग करने के बजाय COPTS पर फ़्लैग कर सकते हैं. हेडर, srcs या hdrs में जोड़े जाने चाहिए. ऐसा न होने पर, ये डिपेंडेंट कंपाइलेशन के सैंडबॉक्स में उपलब्ध नियम (डिफ़ॉल्ट).
linkopts	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन, बॉर्न शेल टोकनाइज़ेशन और लेबल एक्सपैंशन. इस एट्रिब्यूट की हर स्ट्रिंग को पहले LINKOPTS में जोड़ दिया गया है बाइनरी टारगेट को लिंक करना. इस सूची का हर वह एलिमेंट जो $ या - से शुरू नहीं होता है deps में किसी टारगेट का लेबल माना जाता है. कॉन्टेंट बनाने उस टारगेट से जनरेट होने वाली फ़ाइलों की सूची को लिंकर में जोड़ा जाता है के विकल्प. अगर लेबल अमान्य है, तो एक गड़बड़ी की रिपोर्ट की जाती है, या deps में नहीं बताया गया.
linkstamp	लेबल; डिफ़ॉल्ट रूप से None है C++ सोर्स फ़ाइल को एक साथ कंपाइल और फ़ाइनल में लिंक करता है बाइनरी. टाइमस्टैंप लागू करने के लिए, यह ट्रिकरी ज़रूरी है बाइनरी में जानकारी; अगर हम सोर्स फ़ाइल को किसी ऑब्जेक्ट फ़ाइल को सामान्य तरीके से सबमिट करते हैं, तो टाइमस्टैंप गलत होगा. लिंकस्टैम्प कंपाइलेशन में कंपाइलर फ़्लैग और इसलिए किसी खास हेडर, कंपाइलर विकल्प या अन्य बिल्ड वैरिएबल. इस विकल्प की ज़रूरत सिर्फ़ base पैकेज.
linkstatic	बूलियन; False डिफ़ॉल्ट है cc_binary और cc_test: बाइनरी को स्टैटिक से लिंक करें मोड. cc_library.linkstatic के लिए: नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू और बाकी के लिए बंद रहता है. अगर यह नीति चालू है और यह एक बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को जब भी मुमकिन हो, तब यूज़र लाइब्रेरी के लिए .so के बजाय, .a को लागू किया जाता है. ऐसा हो सकता है कि कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक हों. जैसे, ऐसी लाइब्रेरी यहां कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे के तौर पर मिलने वाला एक्ज़ीक्यूटेबल अब भी डाइनैमिक होगा लिंक किया गया है, इसलिए सिर्फ़ ज़्यादातर स्थिर है. किसी एक्ज़ीक्यूटेबल को लिंक करने के वास्तव में तीन अलग-अलग तरीके हैं: पूरी तरह से 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 एट्रिब्यूट का इस्तेमाल किसी cc_library() नियम. C++ लाइब्रेरी के लिए, linkstatic=True बताता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है, इसलिए कोई .so नहीं बनाया जाएगा. linkstatic=False यह करता है स्टैटिक लाइब्रेरी को बनाए जाने से नहीं रोकें. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की सुविधा मिलती है. अगर linkstatic=False है, तो बिल्ड टूल यह *.runfiles इलाके में शेयर की गई लाइब्रेरी पर निर्भर करती है.
local_defines	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को -D के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, हालाँकि, डिपेंडेंट लोगों के लिए लागू हो सकता है.
nocopts	String; "" डिफ़ॉल्ट है C++ कंपाइलेशन कमांड से मैच करने के विकल्प हटाएं. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन के तौर पर उपलब्ध है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाला कोई भी पहले से मौजूद COPTS (इसमें वे वैल्यू भी शामिल हैं जो नियम के कोप्ट एट्रिब्यूट में साफ़ तौर पर दी गई हैं) इस नियम को कंपाइल करने के लिए, COPTS का इस्तेमाल किया जाएगा. इस एट्रिब्यूट की ज़रूरत बहुत कम पड़ती है.
strip_include_prefix	String; "" डिफ़ॉल्ट है इस नियम के हेडर के पाथ से स्ट्रिप किया जाने वाला प्रीफ़िक्स. अगर नीति को सेट किया जाता है, तो इस नियम के hdrs एट्रिब्यूट में मौजूद हेडर को ऐक्सेस किया जा सकता है अपने पाथ पर इस प्रीफ़िक्स कट ऑफ़ के साथ. अगर यह रिलेटिव पाथ है, तो इसे पैकेज के हिसाब से लिया जाता है. अगर यह पूरी तरह से सही है, तो इसे रिपॉज़िटरी-रिलेटिव पाथ के तौर पर समझा जाएगा. include_prefix एट्रिब्यूट में यह प्रीफ़िक्स इस प्रीफ़िक्स के बाद जोड़ा गया है हटाया गया.
textual_hdrs	लेबल की सूची; डिफ़ॉल्ट रूप से [] है उन हेडर फ़ाइलों की सूची जिन्हें इन्होंने पब्लिश किया है इस लाइब्रेरी में मौजूद सोर्स, डिपेंडेंट नियमों में टेक्स्ट के तौर पर शामिल होंगे. यहां उन हेडर फ़ाइलों का एलान किया जाता है जिन्हें खुद इकट्ठा नहीं किया जा सकता; इसका मतलब है कि उन्हें अन्य सोर्स फ़ाइलों में हमेशा टेक्स्ट के तौर पर शामिल किया जाना चाहिए, ताकि वे कोड.
win_def_file	लेबल; डिफ़ॉल्ट रूप से None है लिंकर को भेजी जाने वाली Windows DEF फ़ाइल. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब करना चाहिए, जब Windows टारगेट किया गया प्लैटफ़ॉर्म हो. इसका इस्तेमाल इन कामों के लिए किया जा सकता है शेयर की गई लाइब्रेरी लिंक करते समय सिंबल एक्सपोर्ट करें.

cc_proto_library

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

cc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, 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, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, 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 द्वारा.
exports_filter	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है इस एट्रिब्यूट में ऐसे टारगेट की सूची है जिन्हें मौजूदा रिपोर्ट से एक्सपोर्ट करने का दावा किया गया है शेयर की गई लाइब्रेरी पर टैप करें. टारगेट deps को पहले से ही, शेयर की गई लाइब्रेरी से एक्सपोर्ट किया जा सकता है. इस एट्रिब्यूट का इस्तेमाल, शेयर की गई लाइब्रेरी से एक्सपोर्ट किए गए किसी भी टारगेट की सूची बनाने के लिए किया जाना चाहिए लेकिन deps की ट्रांज़िटिव डिपेंडेंसी हैं. ध्यान दें कि यह एट्रिब्यूट असल में उन टारगेट में डिपेंडेंसी एज नहीं जोड़ रहा है, इसके बजाय, deps को डिपेंडेंसी एज बनाना चाहिए.इसमें मौजूद एंट्री एट्रिब्यूट सिर्फ़ स्ट्रिंग हैं. ध्यान रखें कि इस एट्रिब्यूट में कोई टारगेट डालते समय, इसे ऐसा दावा माना जाता है कि शेयर की गई लाइब्रेरी उस टारगेट से सिंबल एक्सपोर्ट करती है. cc_shared_library लॉजिक, असल में लिंकर को यह नहीं बता पाता कि चिह्न एक्सपोर्ट किए जा सकते हैं. इस सिंटैक्स की अनुमति है: foo/BUILD में किसी भी टारगेट को पूरा करने के लिए //foo:__package__ foo/BUILD या किसी दूसरे टारगेट में शामिल टारगेट के लिए //foo:__subpackages__ foo/ जैसे foo/bar/BUILD के नीचे दिया गया पैकेज
shared_lib_name	String; "" डिफ़ॉल्ट है डिफ़ॉल्ट रूप से, cc_shared_library, शेयर की गई लाइब्रेरी की आउटपुट फ़ाइल के लिए इस आधार पर नाम का इस्तेमाल करेगा टारगेट का नाम और प्लैटफ़ॉर्म. इसमें, एक्सटेंशन और कभी-कभी प्रीफ़िक्स शामिल होते हैं. कभी-कभी ऐसा हो सकता है कि आपको डिफ़ॉल्ट नाम न डालना पड़े. उदाहरण के लिए, जब C++ शेयर की गई लाइब्रेरी लोड हो रही हों Python के लिए डिफ़ॉल्ट lib* प्रीफ़िक्स की ज़रूरत नहीं होती. इस स्थिति में इसका इस्तेमाल किया जा सकता है एट्रिब्यूट का इस्तेमाल करें.
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 टारगेट किया गया प्लैटफ़ॉर्म हो. इसका इस्तेमाल इन कामों के लिए किया जा सकता है शेयर की गई लाइब्रेरी लिंक करते समय सिंबल एक्सपोर्ट करें.

fdo_prefetch_hints

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

fdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

fdo_profile(
  name = "hints_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

तर्क

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

fdo_profile

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

fdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

fdo_profile(
  name = "fdo_abs",
  absolute_path_profile = "/absolute/path/profile.zip",
)

तर्क

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

memprof_profile

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

memprof_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

यह ऐसी MEMPROF प्रोफ़ाइल है जो वर्कस्पेस में या किसी ऐसे प्लैटफ़ॉर्म पर ऐब्सलूट पाथ. उदाहरण:

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

memprof_profile(
  name = "memprof_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

तर्क

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

propeller_optimize

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

propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

propeller_optimize(
    name = "layout_absolute",
    absolute_cc_profile = "/absolute/cc_profile.txt",
    absolute_ld_profile = "/absolute/ld_profile.txt"
)

तर्क

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

cc_test

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

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

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट रूप से [] है बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये cc_library या objc_library हो सकते हैं टारगेट के लिए.
srcs	लेबल की सूची; डिफ़ॉल्ट रूप से [] है टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये फ़ाइलें या तो जनरेट नहीं होती हैं (सामान्य सोर्स) कोड) या जनरेट किया गया हो. सभी .cc, .c, और .cpp फ़ाइलें कंपाइल नहीं किए जाएंगे. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर नाम वाली कोई फ़ाइल कुछ अन्य नियम का outs, यह नियम अपने आप उस दूसरे नियम पर निर्भर हो जाएगा. .h फ़ाइल को कंपाइल नहीं किया जाएगा, लेकिन वह को इस नियम में सोर्स के हिसाब से शामिल किया जाता है. .cc और, दोनों .h फ़ाइलों में, सूची में दिए गए हेडर सीधे शामिल किए जा सकते हैं ये srcs या इनमें सूचीबद्ध किसी भी नियम के hdrs में deps तर्क को बदल दिया गया है. सभी #included फ़ाइलों का उल्लेख इसमें होना चाहिए: srcs एट्रिब्यूट का इस्तेमाल करें या बताए गए cc_library() की hdrs एट्रिब्यूट. सुझाई गई स्टाइल लाइब्रेरी से जुड़े हेडर के लिए है उस लाइब्रेरी के hdrs एट्रिब्यूट में मौजूद होती है और बाकी सभी एट्रिब्यूट के लिए इस नियम के सोर्स से जुड़े हेडर, जिन्हें इसमें शामिल किया जाएगा srcs. "हेडर शामिल किए जाने की जांच" देखें देखें. अगर किसी नियम का नाम srcs में है, तो यह नियम अपने आप उस नियम पर निर्भर करता है. अगर नाम वाले नियम के outs C या C++ हैं सोर्स फ़ाइलें सेव की जाती हैं, तो उन्हें इस नियम में इकट्ठा किया जाता है; अगर वे लाइब्रेरी फ़ाइलें हैं, तो वे उनमें लिंक की हुई होती हैं. अनुमति वाले 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 ...और उन फ़ाइलों को बनाने वाले किसी भी नियम की जानकारी शामिल कर सकते हैं. अलग-अलग एक्सटेंशन, अलग-अलग प्रोग्रामिंग भाषाओं को gcc कन्वेंशन के मुताबिक होना चाहिए.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट रूप से [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां एम्बेड किया जा सकता है, ताकि उन्हें बाइनरी टारगेट.
copts	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है इन विकल्पों को C++ कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के विकल्प पर निर्भर करता है और बोर्न शेल टोकनाइज़ेशन. इस एट्रिब्यूट की हर स्ट्रिंग, दिए गए क्रम में COPTS से पहले जोड़ दी जाती है बाइनरी टारगेट को कंपाइल करना. फ़्लैग सिर्फ़ इस टारगेट को इकट्ठा करने के लिए लागू होते हैं, नहीं पर निर्भर नहीं होना चाहिए, इसलिए कहीं भी शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ को फ़ाइल फ़ोल्डर से संबंधित होनी चाहिए, न कि मौजूदा पैकेज से. अगर पैकेज, सुविधा का एलान करता है no_copts_tokenization, बॉर्न शेल टोकनाइज़ेशन सिर्फ़ स्ट्रिंग पर लागू होता है जिसमें एक "Make" वैरिएबल.
defines	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को -D के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, सभी नियम लागू कर सकते हैं. बहुत सावधान रहें, क्योंकि दूर तक पहुंचने के लिए. संदेह होने पर, 'तय करें' वैल्यू इसके बजाय, local_defines का इस्तेमाल करें.
includes	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है कंपाइल लाइन में जोड़े जाने वाले डाइरों को शामिल करने की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. हर स्ट्रिंग, -isystem से पहले जोड़ी जाती है और COPTS में जोड़ दी जाती है. COPS के उलट, इस नियम के लिए ये फ़्लैग जोड़े जाते हैं और इस पर निर्भर सभी नियमों के लिए बनाया गया है. (ध्यान दें: वे नियम नहीं हैं जिन पर यह निर्भर करता है!) होना ध्यान रखें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. संदेह होने पर, जोड़ें "-मैं" फ़्लैग करने के बजाय COPTS पर फ़्लैग कर सकते हैं. हेडर, srcs या hdrs में जोड़े जाने चाहिए. ऐसा न होने पर, ये डिपेंडेंट कंपाइलेशन के सैंडबॉक्स में उपलब्ध नियम (डिफ़ॉल्ट).
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 में नहीं बताया गया.
linkstatic	बूलियन; False डिफ़ॉल्ट है cc_binary और cc_test: बाइनरी को स्टैटिक से लिंक करें मोड. cc_library.linkstatic के लिए: नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू और बाकी के लिए बंद रहता है. अगर यह नीति चालू है और यह एक बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को जब भी मुमकिन हो, तब यूज़र लाइब्रेरी के लिए .so के बजाय, .a को लागू किया जाता है. ऐसा हो सकता है कि कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक हों. जैसे, ऐसी लाइब्रेरी यहां कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे के तौर पर मिलने वाला एक्ज़ीक्यूटेबल अब भी डाइनैमिक होगा लिंक किया गया है, इसलिए सिर्फ़ ज़्यादातर स्थिर है. किसी एक्ज़ीक्यूटेबल को लिंक करने के वास्तव में तीन अलग-अलग तरीके हैं: पूरी तरह से 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 एट्रिब्यूट का इस्तेमाल किसी cc_library() नियम. C++ लाइब्रेरी के लिए, linkstatic=True बताता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है, इसलिए कोई .so नहीं बनाया जाएगा. linkstatic=False यह करता है स्टैटिक लाइब्रेरी को बनाए जाने से नहीं रोकें. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की सुविधा मिलती है. अगर linkstatic=False है, तो बिल्ड टूल यह *.runfiles इलाके में शेयर की गई लाइब्रेरी पर निर्भर करती है.
local_defines	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को -D के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, हालाँकि, डिपेंडेंट लोगों के लिए लागू हो सकता है.
malloc	लेबल; डिफ़ॉल्ट रूप से "@bazel_tools//tools/cpp:malloc" है मॉलोक पर डिफ़ॉल्ट डिपेंडेंसी बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:malloc से लिंक किया जाता है, यह एक खाली लाइब्रेरी है. इसलिए, बाइनरी फ़ाइल के आखिर में libc मैलडॉक का इस्तेमाल किया जाता है. यह लेबल किसी cc_library से जुड़ा होना चाहिए. अगर कंपाइलेशन बिना C++ वाली नियम के तहत, इस विकल्प का कोई असर नहीं पड़ता. इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है, अगर linkshared=True बताया गया है.
nocopts	String; "" डिफ़ॉल्ट है C++ कंपाइलेशन कमांड से मैच करने के विकल्प हटाएं. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन के तौर पर उपलब्ध है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाला कोई भी पहले से मौजूद COPTS (इसमें वे वैल्यू भी शामिल हैं जो नियम के कोप्ट एट्रिब्यूट में साफ़ तौर पर दी गई हैं) इस नियम को कंपाइल करने के लिए, COPTS का इस्तेमाल किया जाएगा. इस एट्रिब्यूट की ज़रूरत बहुत कम पड़ती है.
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_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, 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	बूलियन; True डिफ़ॉल्ट है exec प्लैटफ़ॉर्म के लिए cc_toolchain में सभी फ़ाइल इनपुट बनाने के लिए 'सही' पर सेट करें, जिसमें कोई ट्रांज़िशन न हो (जैसे, डिफ़ॉल्ट रूप से टारगेट प्लैटफ़ॉर्म).
libc_top	लेबल; डिफ़ॉल्ट रूप से None है libc के लिए आर्टफ़ैक्ट का कलेक्शन, जिसे कंपाइल/लिंक करने की कार्रवाइयों के इनपुट के तौर पर पास किया जाता है.
linker_files	लेबल; आवश्यक लिंक करने की कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन ज़रूरी है.
module_map	लेबल; डिफ़ॉल्ट रूप से None है मॉड्यूलर बिल्ड के लिए मॉड्यूल मैप आर्टफ़ैक्ट का इस्तेमाल किया जाएगा.
objcopy_files	लेबल; आवश्यक objकॉपी की कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन होना चाहिए.
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)

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

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

• C++ के सभी ज़रूरी टूलचेन इकट्ठा करना.
• --cpu और --compiler विकल्पों के आधार पर एक टूलचेन चुनना को भेजा गया.

इसे भी देखें पेज पढ़ें.

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
toolchains	लेबल के लिए शब्दकोश मैपिंग; कॉन्फ़िगर नहीं किया जा सकता; आवश्यक "<cpu>" से मिला मैप या "<cpu>|<compiler>" स्ट्रिंग से एक cc_toolchain लेबल. "<cpu>" का इस्तेमाल सिर्फ़ तब किया जाएगा, जब --cpu बेज़ल को पास किया जाता है, और "<cpu>|<compiler>" का उपयोग तब किया जाएगा जब दोनों --cpu और --compiler, Basel को भेज दिए गए हैं. उदाहरण: cc_toolchain_suite( name = "toolchain", toolchains = { "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc", "piii": ":my_cc_toolchain_for_piii_using_default_compiler", }, )