C / C++ नियम

नाइटली · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

नियम

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() के 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 tokenization के आधार पर बदलाव किया जा सकता है.

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

अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.

defines

स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है

कंपाइल लाइन में जोड़ने के लिए, डिफ़ाइन की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization का इस्तेमाल किया जा सकता है. हर स्ट्रिंग में एक Bourne शैल टोकन होना चाहिए. इसके आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. इसके अलावा, इसे इस पर निर्भर हर नियम में भी जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि इससे आपकी पहुंच पर बहुत ज़्यादा असर पड़ सकता है. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय local_defines एट्रिब्यूट की वैल्यू तय करें.
includes

स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है

शामिल किए जाने वाले डायरेक्ट्री की सूची, जिसे कंपाइल लाइन में जोड़ा जाना है.

"बदलाव के हिसाब से" विकल्प के तहत बदलाव किया जा सकता है. हर स्ट्रिंग के पहले -isystem जोड़ा जाता है और उसे COPTS में जोड़ा जाता है. सीओपीटीएस के उलट, इन फ़्लैग को इस नियम और इस पर निर्भर हर नियम के लिए जोड़ा जाता है. (ध्यान दें: यह उन नियमों के बारे में नहीं है जिन पर यह निर्भर करता है!) बहुत सावधानी बरतें, क्योंकि इससे आपकी पहुंच पर काफ़ी असर पड़ सकता है. अगर आपको किसी तरह का संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें.

हेडर को srcs या hdrs में जोड़ा जाना चाहिए. ऐसा न करने पर, संकलन को सैंडबॉक्स (डिफ़ॉल्ट) किए जाने पर, वे निर्भर नियमों के लिए उपलब्ध नहीं होंगे.

लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:link_extra_lib" है

इस कुकी से, अन्य लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल किया जाता है.

डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:link_extra_lib के साथ लिंक किया जाता है. यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग //tools/cpp:link_extra_libs पर निर्भर करता है. फ़्लैग सेट न करने पर, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग सेट करने से, वैकल्पिक डिपेंडेंसी लिंक की जा सकती हैं. जैसे, कमज़ोर सिंबल के लिए ओवरराइड, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के विकल्पों के लिए, malloc या --custom_malloc को प्राथमिकता दें). इस एट्रिब्यूट को None पर सेट करने से, यह सुविधा बंद हो जाती है.

linkopts

स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है

इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. Bourne shell टोकनाइज़ेशन और लेबल एक्सपैंशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट से लिंक करने से पहले LINKOPTS में जोड़ा जाता है.

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

linkshared

बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से False होता है

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

इस फ़्लैग की मौजूदगी का मतलब है कि -shared फ़्लैग के साथ gcc को लिंक किया गया है. साथ ही, इससे बनी शेयर की गई लाइब्रेरी को लोड किया जा सकता है. उदाहरण के लिए, Java प्रोग्राम में. हालांकि, बिल्ड करने के लिए इसे कभी भी निर्भर बाइनरी में लिंक नहीं किया जाएगा. ऐसा इसलिए, क्योंकि यह माना जाता है कि cc_binary नियम के साथ बनाई गई शेयर की गई लाइब्रेरी को सिर्फ़ अन्य प्रोग्राम मैन्युअल तरीके से लोड करते हैं. इसलिए, इसे cc_library नियम के विकल्प के तौर पर नहीं माना जाना चाहिए. हमारा सुझाव है कि स्केलेबिलिटी के लिए, इस तरीके का इस्तेमाल न करें. इसके बजाय, java_library को cc_library नियमों पर निर्भर रहने दें.

linkopts=['-static'] और linkshared=True, दोनों को तय करने पर, आपको एक ऐसी यूनिट मिलती है जिसमें सभी ज़रूरी चीज़ें शामिल होती हैं. linkstatic=True और linkshared=True, दोनों को शामिल करने पर आपको एक यूनिट मिलती है. इसमें ज़्यादातर जानकारी शामिल होती है.

linkstatic

बूलियन; डिफ़ॉल्ट वैल्यू True है

cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: यहां देखें.

डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू होता है और बाकी के लिए बंद होता है.

अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी संभव हो, उपयोगकर्ता लाइब्रेरी के लिए .a's के बजाय .so'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 शेल टोकन होना चाहिए. इसके पहले -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे इसके डिपेंडेंट में नहीं जोड़ा जाता.
malloc

लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:malloc" है

malloc पर डिफ़ॉल्ट डिपेंडेंसी को बदलें.

डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:malloc के साथ लिंक किया जाता है. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी libc malloc का इस्तेमाल करती है. इस लेबल में, cc_library का रेफ़रंस होना चाहिए. अगर कंपाइल करने का नियम C++ का नहीं है, तो इस विकल्प का कोई असर नहीं होता. अगर linkshared=True एट्रिब्यूट की वैल्यू दी गई है, तो इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है.

nocopts

स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है

C++ कंपाइलेशन कमांड से, मिलते-जुलते विकल्पों को हटाएं. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले किसी भी मौजूदा 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

लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है

इस प्रीकंपाइल की गई लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची. इन्हें सीधे तौर पर, निर्भरता वाले नियमों में शामिल किया जा सकता है.

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

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

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

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

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

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

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

फ़ाइल शामिल हैशामिल करने की अनुमति है
foo.hbar.h
foo.ccfoo.h bar.h
bar.hbar-impl.h baz.h
bar-impl.hbar.h baz.h
bar.ccbar.h bar-impl.h baz.h
baz.hbaz-impl.h
baz-impl.hbaz.h
baz.ccbaz.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() के 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 फ़ाइलों को यहां दिया जा सकता है, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.

बूलियन; डिफ़ॉल्ट वैल्यू False है

अगर 1 है, तो इस C++ लाइब्रेरी पर (प्रत्यक्ष या अप्रत्यक्ष तौर पर) निर्भर करने वाला कोई भी बाइनरी, srcs में दी गई फ़ाइलों के लिए सभी ऑब्जेक्ट फ़ाइलों में लिंक करेगा. भले ही, कुछ में बाइनरी से रेफ़रंस किए गए कोई भी सिंबल शामिल न हों. यह तब काम आता है, जब आपके कोड को बाइनरी में कोड के ज़रिए साफ़ तौर पर कॉल नहीं किया जाता. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिले कॉलबैक को पाने के लिए रजिस्टर करता है.

अगर Windows पर VS 2017 के साथ alwayslink काम नहीं करता है, तो इसकी वजह एक जानी-पहचानी समस्या है. कृपया VS 2017 को नए वर्शन में अपग्रेड करें.
copts

स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है

C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. "बदलाव किया जा सकता है" के आधार पर बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization के आधार पर बदलाव किया जा सकता है.

इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, दिए गए क्रम में 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 में "-I" फ़्लैग जोड़ें.

हेडर को srcs या hdrs में जोड़ा जाना चाहिए. ऐसा न करने पर, संकलन को सैंडबॉक्स किए जाने पर (डिफ़ॉल्ट रूप से), वे निर्भर नियमों के लिए उपलब्ध नहीं होंगे.

linkopts

स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है

इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. Bourne shell टोकनाइज़ेशन और लेबल एक्सपैंशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट से लिंक करने से पहले LINKOPTS में जोड़ा जाता है.

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

linkstamp

लेबल; डिफ़ॉल्ट वैल्यू None है

यह विकल्प, बताई गई C++ सोर्स फ़ाइल को एक साथ कंपाइल करता है और उसे फ़ाइनल बाइनरी से लिंक करता है. बाइनरी में टाइमस्टैंप की जानकारी डालने के लिए, इस तरीके का इस्तेमाल करना ज़रूरी है. अगर हम सोर्स फ़ाइल को सामान्य तरीके से किसी ऑब्जेक्ट फ़ाइल में कंपाइल करते हैं, तो टाइमस्टैंप गलत होगा. लिंकस्टैंप कंपाइलेशन में कंपाइलर फ़्लैग का कोई खास सेट शामिल नहीं हो सकता. इसलिए, इसे किसी खास हेडर, कंपाइलर विकल्प या अन्य बिल्ड वैरिएबल पर निर्भर नहीं होना चाहिए. यह विकल्प सिर्फ़ base पैकेज के लिए होना चाहिए.
linkstatic

बूलियन; डिफ़ॉल्ट वैल्यू False है

cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: यहां देखें.

डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू होता है और बाकी के लिए बंद होता है.

अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी संभव हो, उपयोगकर्ता लाइब्रेरी के लिए .a's के बजाय .so'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 शेल टोकन होना चाहिए. इसके पहले -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे इसके डिपेंडेंट में नहीं जोड़ा जाता.
nocopts

स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है

C++ कंपाइलेशन कमांड से, मिलते-जुलते विकल्पों को हटाएं. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले किसी भी मौजूदा 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 डिपेंडेंसी में से किसी एक में लाइब्रेरी एक्सपोर्ट करने की सुविधा बंद करनी होगी.

ऐसा तब होगा, जब दो अलग-अलग 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* प्रीफ़िक्स का इस्तेमाल नहीं किया जाता. ऐसे में, कस्टम नाम चुनने के लिए इस एट्रिब्यूट का इस्तेमाल किया जा सकता है.

स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है

कोई अन्य फ़्लैग जिसे आपको लिंकर को पास करना हो. उदाहरण के लिए, अगर आपको लिंकर को यह बताना है कि 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

स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है

एफ़डीओ प्रोफ़ाइल का ऐब्सलूट पाथ. एफ़डीओ फ़ाइल में इनमें से कोई एक एक्सटेंशन हो सकता है: .profraw, जो इंडेक्स नहीं की गई LLVM प्रोफ़ाइल के लिए होता है. .profdata, जो इंडेक्स की गई LLVM प्रोफ़ाइल के लिए होता है. .zip, जो LLVM profraw प्रोफ़ाइल के लिए होता है या .afdo, जो AutoFDO प्रोफ़ाइल के लिए होता है.
profile

लेबल; डिफ़ॉल्ट वैल्यू None है

एफ़डीओ प्रोफ़ाइल का लेबल या उसे जनरेट करने वाला नियम. एफ़डीओ फ़ाइल में इनमें से कोई एक एक्सटेंशन हो सकता है: .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 प्रोफ़ाइल के लिए) या .zip एक्सटेंशन (memprof.profdata फ़ाइल वाली zipfile के लिए) होना चाहिए. यह लेबल, 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() के 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 tokenization के आधार पर बदलाव किया जा सकता है.

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

अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही "Make" वैरिएबल होता है.

defines

स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है

कंपाइल लाइन में जोड़ने के लिए, डिफ़ाइन की सूची. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. साथ ही, Bourne shell tokenization का इस्तेमाल किया जा सकता है. हर स्ट्रिंग में एक Bourne शैल टोकन होना चाहिए. इसके आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. इसके अलावा, इसे इस पर निर्भर हर नियम में भी जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि इससे आपकी पहुंच पर बहुत ज़्यादा असर पड़ सकता है. अगर आपको नहीं पता कि GTIN सही है या नहीं, तो इसके बजाय local_defines एट्रिब्यूट की वैल्यू तय करें.
includes

स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है

शामिल किए जाने वाले डायरेक्ट्री की सूची, जिसे कंपाइल लाइन में जोड़ा जाना है.

"बदलाव के हिसाब से" विकल्प के तहत बदलाव किया जा सकता है. हर स्ट्रिंग के पहले -isystem जोड़ा जाता है और उसे COPTS में जोड़ा जाता है. सीओपीटीएस के उलट, इन फ़्लैग को इस नियम और इस पर निर्भर हर नियम के लिए जोड़ा जाता है. (ध्यान दें: यह उन नियमों के बारे में नहीं है जिन पर यह निर्भर करता है!) बहुत सावधानी बरतें, क्योंकि इससे आपकी पहुंच पर काफ़ी असर पड़ सकता है. अगर आपको किसी तरह का संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें.

हेडर को srcs या hdrs में जोड़ा जाना चाहिए. ऐसा न करने पर, संकलन को सैंडबॉक्स किए जाने पर (डिफ़ॉल्ट रूप से), वे निर्भर नियमों के लिए उपलब्ध नहीं होंगे.

लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:link_extra_lib" है

इस कुकी से, अन्य लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल किया जाता है.

डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:link_extra_lib के साथ लिंक किया जाता है. यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग //tools/cpp:link_extra_libs पर निर्भर करता है. फ़्लैग सेट न करने पर, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग सेट करने से, वैकल्पिक डिपेंडेंसी लिंक की जा सकती हैं. जैसे, कमज़ोर सिंबल के लिए ओवरराइड, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के विकल्पों के लिए, malloc या --custom_malloc को प्राथमिकता दें). इस एट्रिब्यूट को None पर सेट करने से, यह सुविधा बंद हो जाती है.

linkopts

स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है

इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. Bourne shell टोकनाइज़ेशन और लेबल एक्सपैंशन के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट में मौजूद हर स्ट्रिंग को, बाइनरी टारगेट से लिंक करने से पहले LINKOPTS में जोड़ा जाता है.

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

linkstatic

बूलियन; डिफ़ॉल्ट वैल्यू False है

cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: यहां देखें.

डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू होता है और बाकी के लिए बंद होता है.

अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को बताता है कि जब भी संभव हो, उपयोगकर्ता लाइब्रेरी के लिए .a's के बजाय .so'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 शेल टोकन होना चाहिए. इसके पहले -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. हालांकि, इसे इसके डिपेंडेंट में नहीं जोड़ा जाता.
malloc

लेबल; डिफ़ॉल्ट वैल्यू "@bazel_tools//tools/cpp:malloc" है

malloc पर डिफ़ॉल्ट डिपेंडेंसी को बदलें.

डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:malloc के साथ लिंक किया जाता है. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी libc malloc का इस्तेमाल करती है. इस लेबल में, cc_library का रेफ़रंस होना चाहिए. अगर कंपाइल करने का नियम C++ का नहीं है, तो इस विकल्प का कोई असर नहीं होता. अगर linkshared=True एट्रिब्यूट की वैल्यू दी गई है, तो इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है.

nocopts

स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है

C++ कंपाइलेशन कमांड से, मिलते-जुलते विकल्पों को हटाएं. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले किसी भी मौजूदा 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++ टूलचेन कॉन्फ़िगरेशन और टूलचेन चुनने से जुड़े दस्तावेज़ के बारे में ज़्यादा जानने के लिए, यह पेज भी देखें.

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

तर्क

विशेषताएं
name

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
all_files

लेबल; ज़रूरी है

cc_toolchain के सभी आर्टफ़ैक्ट का कलेक्शन. इन आर्टफ़ैक्ट को, rules_cc से जुड़ी सभी कार्रवाइयों के लिए इनपुट के तौर पर जोड़ा जाएगा. हालांकि, ऐसा उन कार्रवाइयों के लिए नहीं किया जाएगा जिनमें नीचे दिए गए एट्रिब्यूट से, आर्टफ़ैक्ट के ज़्यादा सटीक सेट का इस्तेमाल किया जा रहा है. Bazel यह मानता है कि all_files, आर्टफ़ैक्ट उपलब्ध कराने वाले अन्य सभी एट्रिब्यूट का सुपरसेट है.उदाहरण के लिए, लिंकस्टैंप कंपाइलेशन के लिए कंपाइल और लिंक, दोनों फ़ाइलों की ज़रूरत होती है. इसलिए, यह all_files लेता है.

cc_toolchain.files में यह जानकारी शामिल होती है. इसका इस्तेमाल, C++ टूलचेन का इस्तेमाल करने वाले Starlark के सभी नियमों में किया जाता है.
ar_files

लेबल; डिफ़ॉल्ट वैल्यू None है

आर्काइव करने की कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
as_files

लेबल; डिफ़ॉल्ट वैल्यू None है

असेंबली की कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
compiler_files

लेबल; ज़रूरी है

cc_toolchain के सभी आर्टफ़ैक्ट का कलेक्शन, जो कंपाइल करने की कार्रवाइयों के लिए ज़रूरी हैं.
compiler_files_without_includes

लेबल; डिफ़ॉल्ट वैल्यू None है

इनपुट डिस्कवरी की सुविधा के साथ काम करने वाले सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. फ़िलहाल, यह सुविधा सिर्फ़ Google के लिए उपलब्ध है.
coverage_files

लेबल; डिफ़ॉल्ट वैल्यू None है

कवरेज की कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. अगर यह जानकारी नहीं दी जाती है, तो all_files का इस्तेमाल किया जाता है.
dwp_files

लेबल; ज़रूरी है

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, लिंकिंग कार्रवाइयों के लिए param फ़ाइलों का इस्तेमाल करने की सुविधा देता है, तो इसे 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",
            },
          )