C / C++ नियम

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

नाइटली रिलीज़ · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

नियम

• cc_binary
• cc_import
• cc_library
• cc_proto_library
• cc_shared_library
• cc_static_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 में दिए गए हेडर या deps आर्ग्युमेंट में दिए गए किसी भी नियम के hdrs में दिए गए हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी #included फ़ाइलों को इस नियम के srcs एट्रिब्यूट में या रेफ़र की गई cc_library()s के 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 सी प्रीप्रोसेसर के साथ असेंबलर: .S संग्रहित करें: .a, .pic.a "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo शेयर की गई लाइब्रेरी, वर्शन वाली या बिना वर्शन वाली: .so, .so.version ऑब्जेक्ट फ़ाइल: .o, .pic.o ...और उन फ़ाइलों को जनरेट करने वाले नियम. अलग-अलग एक्सटेंशन, gcc के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, दिए गए क्रम में COPTS में जोड़ा जाता है. ऐसा बाइनरी टारगेट को कंपाइल करने से पहले किया जाता है. ये फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, इसकी डिपेंडेंसी के लिए नहीं. इसलिए, किसी दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस के हिसाब से होने चाहिए. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है कंपाइल लाइन में जोड़ने के लिए, तय की गई वैल्यू की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शेल टोकन होना चाहिए. इसके आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. इसके अलावा, इसे इस पर निर्भर हर नियम में भी जोड़ा जाता है. सावधानी बरतें, क्योंकि इससे कई चीज़ों पर, बड़े स्तर पर असर पड़ सकता है. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय local_defines में वैल्यू तय करें.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है शामिल किए जाने वाले डायरेक्ट्री की सूची, जिसे कंपाइल लाइन में जोड़ा जाना है. "बदलाव के हिसाब से" विकल्प के तहत बदलाव किया जा सकता है. हर स्ट्रिंग के पहले -isystem जोड़ा जाता है और उसे COPTS में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: यह उन नियमों के बारे में नहीं है जिन पर यह निर्भर करता है!) बहुत सावधानी बरतें, क्योंकि इसका असर कई चीज़ों पर पड़ सकता है. अगर आपको किसी तरह का संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. हेडर को srcs या hdrs में जोड़ा जाना चाहिए. ऐसा न करने पर, जब कंपाइलेशन सैंडबॉक्स किया जाता है (डिफ़ॉल्ट रूप से), तब वे निर्भर नियमों के लिए उपलब्ध नहीं होंगे.
link_extra_lib	लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:link_extra_lib" है इस कुकी से, अन्य लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल किया जाता है. डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:link_extra_lib के साथ लिंक किया जाता है. यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग //tools/cpp:link_extra_libs पर निर्भर करता है. फ़्लैग सेट न करने पर, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग सेट करने से, वैकल्पिक डिपेंडेंसी लिंक की जा सकती हैं. जैसे, कमज़ोर सिंबल के लिए ओवरराइड, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के विकल्पों के लिए, malloc या --custom_malloc का इस्तेमाल करें). इस एट्रिब्यूट को None पर सेट करने से, यह सुविधा बंद हो जाती है.
linkopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "Make" वैरिएबल के हिसाब से बदलाव किया जा सकता है. इसके अलावा, Bourne shell टोकनाइज़ेशन और लेबल एक्सपैंशन भी किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट से लिंक करने से पहले LINKOPTS में जोड़ा जाता है. इस सूची का हर ऐसा एलिमेंट जो $ या - से शुरू नहीं होता है उसे deps में मौजूद टारगेट का लेबल माना जाता है. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या deps में इसका एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
linkshared	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से False होता है शेयर की गई लाइब्रेरी बनाएं. इस एट्रिब्यूट को चालू करने के लिए, अपने नियम में linkshared=True शामिल करें. डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है. इस फ़्लैग की मौजूदगी का मतलब है कि -shared फ़्लैग के साथ gcc से लिंक किया गया है. साथ ही, शेयर की गई लाइब्रेरी को Java प्रोग्राम में लोड किया जा सकता है. हालांकि, बिल्ड करने के लिए इसे कभी भी निर्भर बाइनरी में लिंक नहीं किया जाएगा. ऐसा इसलिए, क्योंकि यह माना जाता है कि cc_binary नियम के साथ बनाई गई शेयर की गई लाइब्रेरी को सिर्फ़ अन्य प्रोग्राम मैन्युअल तरीके से लोड करते हैं. इसलिए, इसे cc_library नियम के विकल्प के तौर पर नहीं माना जाना चाहिए. हमारा सुझाव है कि स्केलेबिलिटी के लिए, इस तरीके का इस्तेमाल न करें. इसके बजाय, java_library को cc_library नियमों पर निर्भर रहने दें. linkopts=['-static'] और linkshared=True, दोनों को तय करने पर, आपको एक ही यूनिट मिलती है. linkstatic=True और linkshared=True, दोनों को शामिल करने पर आपको एक यूनिट मिलती है. इसमें ज़्यादातर जानकारी शामिल होती है.
linkstatic	बूलियन; डिफ़ॉल्ट वैल्यू True है cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: यहां देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी संभव हो, उपयोगकर्ता लाइब्रेरी के लिए .so's के बजाय .a's को लिंक करें. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तरीके से लिंक की जा सकती हैं. साथ ही, वे लाइब्रेरी भी डाइनैमिक तरीके से लिंक की जा सकती हैं जिनके लिए कोई स्टैटिक लाइब्रेरी उपलब्ध नहीं है. इसलिए, एक्ज़ीक्यूटेबल फ़ाइल अब भी डाइनैमिक रूप से लिंक होगी. इसलिए, यह सिर्फ़ कुछ हद तक स्टैटिक होगी. किसी एक्ज़ीक्यूटेबल को लिंक करने के तीन अलग-अलग तरीके हैं: STATIC, जिसमें पूरी तरह से स्टैटिक लिंक की सुविधा होती है. इसमें सब कुछ स्टैटिक तौर पर लिंक किया जाता है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm". इस मोड को चालू करने के लिए, features एट्रिब्यूट में fully_static_link की वैल्यू डालें. STATIC, इसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है), लेकिन सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है. उदाहरण के लिए, "gcc foo.o libfoo.a libbaz.a -lm". इस मोड को linkstatic=True तय करके चालू किया जाता है. डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाती हैं (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "gcc foo.o libfoo.so libbaz.so -lm". इस मोड को linkstatic=False को तय करके चालू किया जाता है. cc_library() नियम में linkstatic एट्रिब्यूट का इस्तेमाल करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, linkstatic=True से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई .so नहीं बनाया जाएगा. linkstatic=False से स्टैटिक लाइब्रेरी बनाने पर कोई असर नहीं पड़ता. इस एट्रिब्यूट का इस्तेमाल, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करने के लिए किया जाता है. अगर linkstatic=False है, तो बिल्ड टूल, *.runfiles एरिया में मौजूद, इस्तेमाल की गई शेयर की गई लाइब्रेरी के लिए सिमलंक बनाएगा.
local_defines	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है कंपाइल लाइन में जोड़ने के लिए, तय की गई वैल्यू की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne shell टोकन होना चाहिए. इसके पहले -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे इसके डिपेंडेंट में नहीं जोड़ा जाता.
malloc	लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:malloc" है malloc पर डिफ़ॉल्ट डिपेंडेंसी को बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:malloc के साथ लिंक किया जाता है. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी libc malloc का इस्तेमाल करती है. इस लेबल में, cc_library का रेफ़रंस होना चाहिए. अगर कंपाइल करने का नियम C++ का नहीं है, तो इस विकल्प का कोई असर नहीं होता. अगर linkshared=True वैल्यू दी गई है, तो इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है.
nocopts	स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है C++ कंपाइलेशन कमांड से, मिलते-जुलते विकल्पों को हटाएं. "Make" वैरिएबल को बदला जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले सभी मौजूदा COPTS हटा दिए जाएंगे. इनमें वे वैल्यू भी शामिल हैं जिन्हें नियम के 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. स्टैटिक या शेयर की गई लाइब्रेरी
से लिंक करना Unix पर:

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 में include एट्रिब्यूट काम करता है. उदाहरण के लिए:

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है उन अन्य लाइब्रेरी की सूची जिन पर टारगेट निर्भर करता है. deps के बारे में सामान्य टिप्पणियां देखें. इसके लिए, ज़्यादातर बिल्ड नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट पर जाएं.
hdrs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है इस सूची में, पहले से कंपाइल की गई लाइब्रेरी की पब्लिश की गई हेडर फ़ाइलों की सूची होती है. इन्हें सीधे तौर पर, निर्भरता वाले नियमों में शामिल किया जाता है.
alwayslink	बूलियन; डिफ़ॉल्ट वैल्यू False है अगर 1, तो इस C++ प्रीकंपाइल की गई लाइब्रेरी पर (सीधे या परोक्ष तौर पर) निर्भर रहने वाली कोई भी बाइनरी, स्टैटिक लाइब्रेरी में संग्रहित की गई सभी ऑब्जेक्ट फ़ाइलों में लिंक हो जाएगी. भले ही, कुछ में बाइनरी से रेफ़रंस किए गए कोई भी सिंबल मौजूद न हों. यह तब काम आता है, जब आपके कोड को बाइनरी में कोड के ज़रिए साफ़ तौर पर कॉल नहीं किया जाता. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिले कॉलबैक को पाने के लिए रजिस्टर करता है. अगर Windows पर VS 2017 के साथ alwayslink काम नहीं करता है, तो इसकी वजह एक जानी-पहचानी समस्या है. कृपया VS 2017 को नए वर्शन में अपग्रेड करें.
interface_library	लेबल; डिफ़ॉल्ट वैल्यू None है शेयर की गई लाइब्रेरी को लिंक करने के लिए, एक इंटरफ़ेस लाइब्रेरी. इन फ़ाइल टाइप का इस्तेमाल किया जा सकता है: .ifso, .tbd, .lib, .so या .dylib
shared_library	लेबल; डिफ़ॉल्ट वैल्यू None है पहले से कंपाइल की गई एक शेयर की गई लाइब्रेरी. Bazel यह पक्का करता है कि रनटाइम के दौरान, यह उस बाइनरी के लिए उपलब्ध हो जो इस पर निर्भर करती है. इन फ़ाइल टाइप का इस्तेमाल किया जा सकता है: .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)

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

बिल्ड में इस्तेमाल की गई सभी हेडर फ़ाइलों को, cc_* नियमों के hdrs या 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	foo.h bar.h
bar.h	bar-impl.h baz.h
bar-impl.h	bar.h baz.h
bar.cc	bar.h bar-impl.h baz.h
baz.h	baz-impl.h
baz-impl.h	baz.h
baz.cc	baz.h baz-impl.h

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये cc_library या objc_library टारगेट हो सकते हैं.
srcs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये जनरेट नहीं की गई हैं (सामान्य सोर्स कोड) या जनरेट की गई हैं. सभी .cc, .c, और .cpp फ़ाइलों को कंपाइल किया जाएगा. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर किसी नाम वाली फ़ाइल, किसी अन्य नियम के outs में है, तो यह नियम अपने-आप उस अन्य नियम पर निर्भर करेगा. .h फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, यह इस नियम के तहत आने वाले स्रोतों के लिए उपलब्ध रहेगी. .cc और .h, दोनों तरह की फ़ाइलों में, srcs में दिए गए हेडर या deps आर्ग्युमेंट में दिए गए किसी भी नियम के hdrs में दिए गए हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी #included फ़ाइलों को इस नियम के srcs एट्रिब्यूट में या रेफ़र की गई cc_library()s के 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 सी प्रीप्रोसेसर के साथ असेंबलर: .S संग्रहित करें: .a, .pic.a "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo शेयर की गई लाइब्रेरी, वर्शन वाली या बिना वर्शन वाली: .so, .so.version ऑब्जेक्ट फ़ाइल: .o, .pic.o ...और उन फ़ाइलों को जनरेट करने वाले नियम. अलग-अलग एक्सटेंशन, gcc के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
hdrs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है इस लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची. इन्हें सीधे तौर पर, निर्भरता वाले नियमों के सोर्स में शामिल किया जाना चाहिए. हेडर फ़ाइलों को इस जगह पर डिक्लेयर करना सबसे अच्छा होता है. ये फ़ाइलें, लाइब्रेरी के इंटरफ़ेस के बारे में बताती हैं. इन हेडर को इस नियम या इससे जुड़े नियमों में शामिल करने के लिए उपलब्ध कराया जाएगा. इस लाइब्रेरी के क्लाइंट को जिन हेडर को शामिल नहीं करना है उन्हें srcs एट्रिब्यूट में लिस्ट किया जाना चाहिए. भले ही, उन्हें पब्लिश किए गए हेडर में शामिल किया गया हो. ज़्यादा जानकारी के लिए, "हेडर शामिल करने की जांच" देखें.
additional_compiler_inputs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है ऐसी कोई भी अतिरिक्त फ़ाइल जिसे आपको कंपाइलर कमांड लाइन में पास करना हो. उदाहरण के लिए, सैनिटाइज़र इग्नोरलिस्ट. यहां बताई गई फ़ाइलों का इस्तेमाल, $(location) फ़ंक्शन के साथ copts में किया जा सकता है.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.
alwayslink	बूलियन; डिफ़ॉल्ट वैल्यू False है अगर 1, तो इस C++ लाइब्रेरी पर सीधे या परोक्ष रूप से निर्भर करने वाला कोई भी बाइनरी, srcs में दी गई फ़ाइलों के लिए सभी ऑब्जेक्ट फ़ाइलों में लिंक करेगा. भले ही, कुछ में बाइनरी से रेफ़रंस किए गए कोई भी सिंबल मौजूद न हों. यह तब काम आता है, जब आपके कोड को बाइनरी में मौजूद कोड से साफ़ तौर पर कॉल नहीं किया जाता. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिले कॉलबैक को पाने के लिए रजिस्टर करता है. अगर Windows पर VS 2017 के साथ alwayslink काम नहीं करता है, तो इसकी वजह एक जानी-पहचानी समस्या है. कृपया VS 2017 को नए वर्शन में अपग्रेड करें.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, दिए गए क्रम में COPTS में जोड़ा जाता है. ऐसा बाइनरी टारगेट को कंपाइल करने से पहले किया जाता है. ये फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, इसकी डिपेंडेंसी के लिए नहीं. इसलिए, किसी दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस के हिसाब से होने चाहिए. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है कंपाइल लाइन में जोड़ने के लिए, तय की गई वैल्यू की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शेल टोकन होना चाहिए. इसके आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. इसके अलावा, इसे इस पर निर्भर हर नियम में भी जोड़ा जाता है. सावधानी बरतें, क्योंकि इससे कई चीज़ों पर, बड़े स्तर पर असर पड़ सकता है. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय local_defines में वैल्यू तय करें.
implementation_deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है उन अन्य लाइब्रेरी की सूची जिन पर लाइब्रेरी टारगेट निर्भर करता है. deps के उलट, इन लाइब्रेरी के हेडर और शामिल किए गए पाथ (और इनके सभी ट्रांज़िटिव डिपेंडेंसी) का इस्तेमाल सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है. इनका इस्तेमाल उन लाइब्रेरी के लिए नहीं किया जाता जो इस पर निर्भर करती हैं. implementation_deps के तौर पर मार्क की गई लाइब्रेरी अब भी उन बाइनरी टारगेट से जुड़ी हैं जो इस लाइब्रेरी पर निर्भर हैं. फ़िलहाल, इसका इस्तेमाल cc_libraries तक ही सीमित है. साथ ही, इसे --experimental_cc_implementation_deps फ़्लैग से सुरक्षित किया गया है.
include_prefix	स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है इस नियम के हेडर के पाथ में जोड़ने के लिए प्रीफ़िक्स. इस नियम के hdrs एट्रिब्यूट में मौजूद हेडर सेट होने पर, उन तक पहुंचा जा सकता है. इस एट्रिब्यूट की वैल्यू, रिपॉज़िटरी के हिसाब से उनके पाथ से पहले जोड़ी जाती है. इस प्रीफ़िक्स को जोड़ने से पहले, strip_include_prefix एट्रिब्यूट में मौजूद प्रीफ़िक्स को हटा दिया जाता है.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है शामिल किए जाने वाले डायरेक्ट्री की सूची, जिसे कंपाइल लाइन में जोड़ा जाना है. "बदलाव के हिसाब से" विकल्प के तहत बदलाव किया जा सकता है. हर स्ट्रिंग के पहले -isystem जोड़ा जाता है और उसे COPTS में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: यह उन नियमों के बारे में नहीं है जिन पर यह निर्भर करता है!) बहुत सावधानी बरतें, क्योंकि इसका असर कई चीज़ों पर पड़ सकता है. अगर आपको किसी तरह का संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. हेडर को srcs या hdrs में जोड़ा जाना चाहिए. ऐसा न करने पर, जब कंपाइलेशन सैंडबॉक्स किया जाता है (डिफ़ॉल्ट रूप से), तब वे निर्भर नियमों के लिए उपलब्ध नहीं होंगे.
linkopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "Make" वैरिएबल के हिसाब से बदलाव किया जा सकता है. इसके अलावा, Bourne shell टोकनाइज़ेशन और लेबल एक्सपैंशन भी किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट से लिंक करने से पहले LINKOPTS में जोड़ा जाता है. इस सूची का हर ऐसा एलिमेंट जो $ या - से शुरू नहीं होता है उसे deps में मौजूद टारगेट का लेबल माना जाता है. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या deps में इसका एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
linkstamp	लेबल; डिफ़ॉल्ट वैल्यू None है यह विकल्प, बताई गई C++ सोर्स फ़ाइल को एक साथ कंपाइल और लिंक करके फ़ाइनल बाइनरी में बदलता है. बाइनरी में टाइमस्टैंप की जानकारी डालने के लिए, इस तरीके का इस्तेमाल करना ज़रूरी है. अगर हम सोर्स फ़ाइल को सामान्य तरीके से किसी ऑब्जेक्ट फ़ाइल में कंपाइल करते हैं, तो टाइमस्टैंप गलत होगा. लिंकस्टैंप कंपाइलेशन में कंपाइलर फ़्लैग का कोई खास सेट शामिल नहीं हो सकता. इसलिए, इसे किसी खास हेडर, कंपाइलर विकल्प या अन्य बिल्ड वैरिएबल पर निर्भर नहीं होना चाहिए. यह विकल्प सिर्फ़ base पैकेज के लिए होना चाहिए.
linkstatic	बूलियन; डिफ़ॉल्ट वैल्यू False है cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: यहां देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी संभव हो, उपयोगकर्ता लाइब्रेरी के लिए .so's के बजाय .a's को लिंक करें. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तरीके से लिंक की जा सकती हैं. साथ ही, वे लाइब्रेरी भी डाइनैमिक तरीके से लिंक की जा सकती हैं जिनके लिए कोई स्टैटिक लाइब्रेरी उपलब्ध नहीं है. इसलिए, एक्ज़ीक्यूटेबल फ़ाइल अब भी डाइनैमिक रूप से लिंक होगी. इसलिए, यह सिर्फ़ कुछ हद तक स्टैटिक होगी. किसी एक्ज़ीक्यूटेबल को लिंक करने के तीन अलग-अलग तरीके हैं: STATIC, जिसमें पूरी तरह से स्टैटिक लिंक की सुविधा होती है. इसमें सब कुछ स्टैटिक तौर पर लिंक किया जाता है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm". इस मोड को चालू करने के लिए, features एट्रिब्यूट में fully_static_link की वैल्यू डालें. STATIC, इसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है), लेकिन सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है. उदाहरण के लिए, "gcc foo.o libfoo.a libbaz.a -lm". इस मोड को linkstatic=True तय करके चालू किया जाता है. डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाती हैं (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "gcc foo.o libfoo.so libbaz.so -lm". इस मोड को linkstatic=False को तय करके चालू किया जाता है. cc_library() नियम में linkstatic एट्रिब्यूट का इस्तेमाल करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, linkstatic=True से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई .so नहीं बनाया जाएगा. linkstatic=False से स्टैटिक लाइब्रेरी बनाने पर कोई असर नहीं पड़ता. इस एट्रिब्यूट का इस्तेमाल, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करने के लिए किया जाता है. अगर linkstatic=False है, तो बिल्ड टूल, *.runfiles एरिया में मौजूद, इस्तेमाल की गई शेयर की गई लाइब्रेरी के लिए सिमलंक बनाएगा.
local_defines	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है कंपाइल लाइन में जोड़ने के लिए, तय की गई वैल्यू की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne shell टोकन होना चाहिए. इसके पहले -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे इसके डिपेंडेंट में नहीं जोड़ा जाता.
nocopts	स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है C++ कंपाइलेशन कमांड से, मिलते-जुलते विकल्पों को हटाएं. "Make" वैरिएबल को बदला जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले सभी मौजूदा COPTS हटा दिए जाएंगे. इनमें वे वैल्यू भी शामिल हैं जिन्हें नियम के copts एट्रिब्यूट में साफ़ तौर पर बताया गया है. ऐसा इसलिए किया जाएगा, ताकि इस नियम को कंपाइल किया जा सके.COPTS इस एट्रिब्यूट की ज़रूरत बहुत कम पड़ती है.
strip_include_prefix	स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है इस नियम के हेडर के पाथ से हटाने के लिए प्रीफ़िक्स. इस विकल्प को सेट करने पर, इस नियम के 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 को स्टैटिक तरीके से लिंक करता है. baz, ट्रांज़िटिव डिपेंडेंसी है. यह bar को लिंक नहीं करता, क्योंकि इसे dynamic_dep bar_shared पहले से ही डाइनैमिक तौर पर उपलब्ध कराता है.

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

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

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

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

गड़बड़ियां

Two shared libraries in dependencies export the same symbols.

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

Two shared libraries in dependencies link the same library statically

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

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

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

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

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

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

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

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

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

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

तर्क

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

cc_static_library

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

cc_static_library(name, deps, tags)

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

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

आउटपुट ग्रुप

linkdeps

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

linkopts

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

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

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

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

symbol_check के लिए टूलचेन की सुविधा

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

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

तर्क

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

fdo_prefetch_hints

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

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

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

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 प्रोफ़ाइल को दिखाता है जो वर्कस्पेस में है या किसी तय किए गए ऐब्सलूट पाथ पर है. उदाहरण:

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	स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है एफ़डीओ प्रोफ़ाइल का ऐब्सलूट पाथ. एफ़डीओ फ़ाइल में सिर्फ़ .afdo एक्सटेंशन हो सकता है.
profile	लेबल; डिफ़ॉल्ट वैल्यू None है एफ़डीओ प्रोफ़ाइल का लेबल या उसे जनरेट करने वाला नियम. FDO फ़ाइल में इनमें से कोई एक एक्सटेंशन हो सकता है: .profraw, .profdata, .zip, .afdo, .xfdo. यह लेबल, 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	स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है MEMPROF प्रोफ़ाइल का ऐब्सलूट पाथ. फ़ाइल में सिर्फ़ .profdata या .zip एक्सटेंशन हो सकता है. .zip फ़ाइल में memprof.profdata फ़ाइल होनी चाहिए.
profile	लेबल; डिफ़ॉल्ट वैल्यू None है MEMPROF प्रोफ़ाइल का लेबल. प्रोफ़ाइल में, .profdata एक्सटेंशन (इंडेक्स की गई/सिंबलाइज़ की गई memprof प्रोफ़ाइल के लिए) या memprof .profdata फ़ाइल वाली zipfile के लिए.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 की ऑप्टिमाइज़ेशन प्रोफ़ाइल को दिखाता है. उदाहरण:

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 में दिए गए हेडर या deps आर्ग्युमेंट में दिए गए किसी भी नियम के hdrs में दिए गए हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी #included फ़ाइलों को इस नियम के srcs एट्रिब्यूट में या रेफ़र की गई cc_library()s के 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 सी प्रीप्रोसेसर के साथ असेंबलर: .S संग्रहित करें: .a, .pic.a "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo शेयर की गई लाइब्रेरी, वर्शन वाली या बिना वर्शन वाली: .so, .so.version ऑब्जेक्ट फ़ाइल: .o, .pic.o ...और उन फ़ाइलों को जनरेट करने वाले नियम. अलग-अलग एक्सटेंशन, gcc के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, दिए गए क्रम में COPTS में जोड़ा जाता है. ऐसा बाइनरी टारगेट को कंपाइल करने से पहले किया जाता है. ये फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, इसकी डिपेंडेंसी के लिए नहीं. इसलिए, किसी दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, मौजूदा पैकेज के बजाय वर्कस्पेस के हिसाब से होने चाहिए. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है कंपाइल लाइन में जोड़ने के लिए, तय की गई वैल्यू की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne शेल टोकन होना चाहिए. इसके आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. इसके अलावा, इसे इस पर निर्भर हर नियम में भी जोड़ा जाता है. सावधानी बरतें, क्योंकि इससे कई चीज़ों पर, बड़े स्तर पर असर पड़ सकता है. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय local_defines में वैल्यू तय करें.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है शामिल किए जाने वाले डायरेक्ट्री की सूची, जिसे कंपाइल लाइन में जोड़ा जाना है. "बदलाव के हिसाब से" विकल्प के तहत बदलाव किया जा सकता है. हर स्ट्रिंग के पहले -isystem जोड़ा जाता है और उसे COPTS में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: यह उन नियमों के बारे में नहीं है जिन पर यह निर्भर करता है!) बहुत सावधानी बरतें, क्योंकि इसका असर कई चीज़ों पर पड़ सकता है. अगर आपको किसी तरह का संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. हेडर को srcs या hdrs में जोड़ा जाना चाहिए. ऐसा न करने पर, जब कंपाइलेशन सैंडबॉक्स किया जाता है (डिफ़ॉल्ट रूप से), तब वे निर्भर नियमों के लिए उपलब्ध नहीं होंगे.
link_extra_lib	लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:link_extra_lib" है इस कुकी से, अन्य लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल किया जाता है. डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:link_extra_lib के साथ लिंक किया जाता है. यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग //tools/cpp:link_extra_libs पर निर्भर करता है. फ़्लैग सेट न करने पर, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग सेट करने से, वैकल्पिक डिपेंडेंसी लिंक की जा सकती हैं. जैसे, कमज़ोर सिंबल के लिए ओवरराइड, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के विकल्पों के लिए, malloc या --custom_malloc का इस्तेमाल करें). इस एट्रिब्यूट को None पर सेट करने से, यह सुविधा बंद हो जाती है.
linkopts	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "Make" वैरिएबल के हिसाब से बदलाव किया जा सकता है. इसके अलावा, Bourne shell टोकनाइज़ेशन और लेबल एक्सपैंशन भी किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट से लिंक करने से पहले LINKOPTS में जोड़ा जाता है. इस सूची का हर ऐसा एलिमेंट जो $ या - से शुरू नहीं होता है उसे deps में मौजूद टारगेट का लेबल माना जाता है. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या deps में इसका एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
linkstatic	बूलियन; डिफ़ॉल्ट वैल्यू False है cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: यहां देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी संभव हो, उपयोगकर्ता लाइब्रेरी के लिए .so's के बजाय .a's को लिंक करें. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तरीके से लिंक की जा सकती हैं. साथ ही, वे लाइब्रेरी भी डाइनैमिक तरीके से लिंक की जा सकती हैं जिनके लिए कोई स्टैटिक लाइब्रेरी उपलब्ध नहीं है. इसलिए, एक्ज़ीक्यूटेबल फ़ाइल अब भी डाइनैमिक रूप से लिंक होगी. इसलिए, यह सिर्फ़ कुछ हद तक स्टैटिक होगी. किसी एक्ज़ीक्यूटेबल को लिंक करने के तीन अलग-अलग तरीके हैं: STATIC, जिसमें पूरी तरह से स्टैटिक लिंक की सुविधा होती है. इसमें सब कुछ स्टैटिक तौर पर लिंक किया जाता है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm". इस मोड को चालू करने के लिए, features एट्रिब्यूट में fully_static_link की वैल्यू डालें. STATIC, इसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है), लेकिन सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है. उदाहरण के लिए, "gcc foo.o libfoo.a libbaz.a -lm". इस मोड को linkstatic=True तय करके चालू किया जाता है. डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाती हैं (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "gcc foo.o libfoo.so libbaz.so -lm". इस मोड को linkstatic=False को तय करके चालू किया जाता है. cc_library() नियम में linkstatic एट्रिब्यूट का इस्तेमाल करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, linkstatic=True से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई .so नहीं बनाया जाएगा. linkstatic=False से स्टैटिक लाइब्रेरी बनाने पर कोई असर नहीं पड़ता. इस एट्रिब्यूट का इस्तेमाल, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करने के लिए किया जाता है. अगर linkstatic=False है, तो बिल्ड टूल, *.runfiles एरिया में मौजूद, इस्तेमाल की गई शेयर की गई लाइब्रेरी के लिए सिमलंक बनाएगा.
local_defines	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है कंपाइल लाइन में जोड़ने के लिए, तय की गई वैल्यू की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के हिसाब से बदलाव किया जा सकता है. हर स्ट्रिंग में एक Bourne shell टोकन होना चाहिए. इसके पहले -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे इसके डिपेंडेंट में नहीं जोड़ा जाता.
malloc	लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:malloc" है malloc पर डिफ़ॉल्ट डिपेंडेंसी को बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:malloc के साथ लिंक किया जाता है. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी libc malloc का इस्तेमाल करती है. इस लेबल में, cc_library का रेफ़रंस होना चाहिए. अगर कंपाइल करने का नियम C++ का नहीं है, तो इस विकल्प का कोई असर नहीं होता. अगर linkshared=True वैल्यू दी गई है, तो इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है.
nocopts	स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है C++ कंपाइलेशन कमांड से, मिलते-जुलते विकल्पों को हटाएं. "Make" वैरिएबल को बदला जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले सभी मौजूदा COPTS हटा दिए जाएंगे. इनमें वे वैल्यू भी शामिल हैं जिन्हें नियम के 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 एट्रिब्यूट का इस्तेमाल करें. C++ टूलचेन कॉन्फ़िगरेशन और टूलचेन चुनने से जुड़े दस्तावेज़ के बारे में ज़्यादा जानकारी के लिए, यह पेज भी देखें.

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

तर्क

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

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 विकल्पों के आधार पर, एक टूलचेन चुनना. ये विकल्प Bazel को पास किए जाते हैं.

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

तर्क

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