C / C++ नियम

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

नियम

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

cc_binary

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

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

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

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

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये cc_library या objc_library टारगेट हो सकते हैं.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें होती हैं. ये जनरेट नहीं की गई (सामान्य सोर्स कोड) या जनरेट की गई हो सकती हैं. .cc, .c, और .cpp की सभी फ़ाइलें कंपाइल कर दी जाएंगी. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर कोई फ़ाइल किसी दूसरे नियम के outs में है, तो यह नियम अपने-आप उस दूसरे नियम पर निर्भर करेगा. .h फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, इस नियम में सोर्स के ज़रिए इसे शामिल किया जा सकता है. .cc और .h, दोनों फ़ाइलों में इन srcs में दिए गए हेडर या 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 C प्रीप्रोसेसर वाला असेंबलर: .S संग्रहित करें: .a, .pic.a "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo शेयर की गई लाइब्रेरी, वर्शन वाली या वर्शन वाली नहीं: .so, .so.version ऑब्जेक्ट फ़ाइल: .o, .pic.o ...और उन फ़ाइलों को जनरेट करने वाले नियम. अलग-अलग एक्सटेंशन, जीसीसी के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, यहां इकट्ठा की गई Windows .res फ़ाइलें दी जा सकती हैं.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. बाइनरी टारगेट को संकलित करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में COPTS में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, न कि उसकी डिपेंडेंसी के लिए. इसलिए, दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, वर्कस्पेस के हिसाब से होने चाहिए, न कि मौजूदा पैकेज के हिसाब से. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो Bourne शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल करने की कमांड लाइन में जोड़ा जाता है. साथ ही, इस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई तरह के असर पड़ सकते हैं. अगर आपको नहीं पता कि 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 शेल टोकनाइज़ेशन और लेबल एक्सपैंशन का इस्तेमाल किया जा सकता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को LINKOPTS में जोड़ा जाता है. इस सूची के हर उस एलिमेंट को deps में टारगेट का लेबल माना जाता है जो $ या - से शुरू नहीं होता. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या deps में एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
linkshared	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से False शेयर की जा सकने वाली लाइब्रेरी बनाएं. इस एट्रिब्यूट को चालू करने के लिए, अपने नियम में linkshared=True शामिल करें. डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है. इस फ़्लैग की मौजूदगी का मतलब है कि -shared फ़्लैग के साथ gcc को लिंक किया गया है. साथ ही, इससे बनी शेयर की गई लाइब्रेरी, उदाहरण के लिए, Java प्रोग्राम में लोड करने के लिए सही है. हालांकि, इसे कभी भी बिल्ड के मकसद से, डिपेंडेंट बाइनरी से लिंक नहीं किया जाएगा. ऐसा इसलिए माना जाता है, क्योंकि cc_binary नियम के साथ बनाई गई शेयर की गई लाइब्रेरी, सिर्फ़ अन्य प्रोग्राम के ज़रिए मैन्युअल रूप से लोड की जाती हैं. इसलिए, इसे cc_library नियम के विकल्प के तौर पर नहीं माना जाना चाहिए. हमारा सुझाव है कि बड़े पैमाने पर डेटा मैनेज करने के लिए, इस तरीके का इस्तेमाल न करें. इसके बजाय, java_library को cc_library नियमों पर निर्भर रहने दें. linkopts=['-static'] और linkshared=True, दोनों को तय करने पर, आपको एक ऐसी यूनिट मिलती है जिसमें सभी एलिमेंट मौजूद होते हैं. अगर आपने linkstatic=True और linkshared=True, दोनों का इस्तेमाल किया है, तो आपको एक ऐसी यूनिट मिलेगी जिसमें ज़्यादातर चीज़ें पहले से मौजूद होती हैं.
linkstatic	बूलियन; डिफ़ॉल्ट तौर पर True cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प, बाइल्ड टूल को उपयोगकर्ता लाइब्रेरी के लिए, .so के बजाय .a को लिंक करने के लिए कहता है. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकती हैं. ऐसा उन लाइब्रेरी के लिए भी किया जा सकता है जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे में मिलने वाला एक्सीक्यूटेबल अब भी डाइनैमिक तौर पर लिंक किया जाएगा. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगा. किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं: fully_static_link सुविधा के साथ स्टैटिक, जिसमें सब कुछ स्टैटिक तौर पर लिंक किया गया है; उदाहरण के लिए, "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 डालें. linkstatic एट्रिब्यूट का इस्तेमाल, cc_library() नियम के लिए करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, linkstatic=True से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई .so नहीं जनरेट होगा. linkstatic=False से, स्टैटिक लाइब्रेरी बनने से नहीं रोका जाता. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है. अगर linkstatic=False है, तो बिल्ड टूल, *.runfiles एरिया में, उन शेयर की गई लाइब्रेरी के लिए सिमलिन्क बनाएगा जिन पर इस प्रोजेक्ट का निर्भर रहना है.
local_defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इस टारगेट के लिए, स्ट्रिंग को कंपाइल करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए.
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 में शामिल करें एट्रिब्यूट का इस्तेमाल किया जा सकता है. उदाहरण के लिए:

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

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

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

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

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

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

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

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

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

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

तर्क

विशेषताएं
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 C प्रीप्रोसेसर वाला असेंबलर: .S संग्रहित करें: .a, .pic.a "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo शेयर की गई लाइब्रेरी, वर्शन वाली या वर्शन वाली नहीं: .so, .so.version ऑब्जेक्ट फ़ाइल: .o, .pic.o ...और उन फ़ाइलों को जनरेट करने वाले नियम. अलग-अलग एक्सटेंशन, जीसीसी के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
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++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. बाइनरी टारगेट को संकलित करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में COPTS में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, न कि उसकी डिपेंडेंसी के लिए. इसलिए, दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, वर्कस्पेस के हिसाब से होने चाहिए, न कि मौजूदा पैकेज के हिसाब से. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो Bourne शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल करने की कमांड लाइन में जोड़ा जाता है. साथ ही, इस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई तरह के असर पड़ सकते हैं. अगर आपको नहीं पता कि 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 शेल टोकनाइज़ेशन और लेबल एक्सपैंशन का इस्तेमाल किया जा सकता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को LINKOPTS में जोड़ा जाता है. इस सूची के हर उस एलिमेंट को deps में टारगेट का लेबल माना जाता है जो $ या - से शुरू नहीं होता. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या deps में एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
linkstamp	लेबल; डिफ़ॉल्ट रूप से None साथ ही, यह बताई गई C++ सोर्स फ़ाइल को फ़ाइनल बाइनरी में इकट्ठा और लिंक करता है. बाइनरी में टाइमस्टैंप की जानकारी डालने के लिए, यह तरकीब ज़रूरी है. अगर हम सोर्स फ़ाइल को सामान्य तरीके से ऑब्जेक्ट फ़ाइल में कंपाइल करते हैं, तो टाइमस्टैंप गलत होगा. हो सकता है कि लिंकस्टैंप कंपाइलेशन में, compiler flags का कोई खास सेट शामिल न हो. इसलिए, यह किसी खास हेडर, compiler option या दूसरे बिल्ड वैरिएबल पर निर्भर नहीं होना चाहिए. यह विकल्प सिर्फ़ base पैकेज में ज़रूरी है.
linkstatic	बूलियन; डिफ़ॉल्ट तौर पर False cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प, बाइल्ड टूल को उपयोगकर्ता लाइब्रेरी के लिए, .so के बजाय .a को लिंक करने के लिए कहता है. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकती हैं. ऐसा उन लाइब्रेरी के लिए भी किया जा सकता है जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे में मिलने वाला एक्सीक्यूटेबल अब भी डाइनैमिक तौर पर लिंक किया जाएगा. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगा. किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं: fully_static_link सुविधा के साथ स्टैटिक, जिसमें सब कुछ स्टैटिक तौर पर लिंक किया गया है; उदाहरण के लिए, "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 डालें. linkstatic एट्रिब्यूट का इस्तेमाल, cc_library() नियम के लिए करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, linkstatic=True से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई .so नहीं जनरेट होगा. linkstatic=False से, स्टैटिक लाइब्रेरी बनने से नहीं रोका जाता. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है. अगर linkstatic=False है, तो बिल्ड टूल, *.runfiles एरिया में, उन शेयर की गई लाइब्रेरी के लिए सिमलिन्क बनाएगा जिन पर इस प्रोजेक्ट का निर्भर रहना है.
local_defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इस टारगेट के लिए, स्ट्रिंग को कंपाइल करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए.
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	लेबल की सूची; डिफ़ॉल्ट [] है C++ कोड जनरेट करने के लिए, proto_library नियमों की सूची.

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 होगा, न कि libbar.so, जो कि Linux पर डिफ़ॉल्ट रूप से होता है.

गड़बड़ियां

Two shared libraries in dependencies export the same symbols.

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

Two shared libraries in dependencies link the same library statically

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

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

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

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

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

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

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

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

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

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

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है टॉप लेवल लाइब्रेरी, जिन्हें पूरी तरह से संग्रहित करने के बाद, शेयर की गई लाइब्रेरी में स्टैटिक तौर पर लिंक किया जाएगा. इन डायरेक्ट डिपेंडेंसी की ट्रांज़िटिव लाइब्रेरी डिपेंडेंसी को इस शेयर की गई लाइब्रेरी में तब तक लिंक किया जाएगा, जब तक कि उन्हें dynamic_deps में cc_shared_library से पहले से लिंक नहीं किया गया है. विश्लेषण के दौरान, नियम लागू करने की प्रोसेस में deps में मौजूद किसी भी टारगेट को शेयर की गई लाइब्रेरी से एक्सपोर्ट किया गया टारगेट माना जाएगा. ऐसा इसलिए किया जाता है, ताकि एक से ज़्यादा cc_shared_libraries एक ही टारगेट को एक्सपोर्ट करने पर गड़बड़ियां दिखें. नियम लागू करने की प्रोसेस में, लिंकर को यह जानकारी नहीं दी जाती कि शेयर किए गए ऑब्जेक्ट से कौनसे सिंबल एक्सपोर्ट किए जाने चाहिए. उपयोगकर्ता को सोर्स कोड में लिंकर स्क्रिप्ट या दिखने की जानकारी के एलान की मदद से, इस बात का ध्यान रखना चाहिए. जब एक ही लाइब्रेरी को एक से ज़्यादा cc_shared_library में स्टैटिक तौर पर लिंक किया जाता है, तो लागू करने पर गड़बड़ियां भी ट्रिगर होंगी. cc_library.tags में "LINKABLE_MORE_THAN_ONCE" जोड़कर या शेयर की गई किसी लाइब्रेरी के एक्सपोर्ट के तौर पर, `cc_library` को सूची में शामिल करके, इस गड़बड़ी से बचा जा सकता है. इससे, एक लाइब्रेरी को दूसरी लाइब्रेरी का dynamic_dep बनाया जा सकता है.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी अन्य फ़ाइलें जिन्हें आपको लिंकर को पास करना है. उदाहरण के लिए, लिंकर स्क्रिप्ट. आपको लिंकर के लिए, लिंकर फ़्लैग को अलग से पास करना होगा, ताकि लिंकर को इस फ़ाइल के बारे में पता चल सके. ऐसा करने के लिए, user_link_flags एट्रिब्यूट का इस्तेमाल करें.
dynamic_deps	लेबल की सूची; डिफ़ॉल्ट [] है ये cc_shared_library की अन्य डिपेंडेंसी हैं, जिन पर मौजूदा टारगेट निर्भर करता है. cc_shared_library लागू करने के लिए, dynamic_deps की सूची का इस्तेमाल किया जाएगा.इसमें ट्रांज़िटिव dynamic_deps (यानी मौजूदा टारगेट के dynamic_deps का dynamic_deps) भी शामिल है. इससे यह तय किया जा सकेगा कि ट्रांज़िटिव deps में मौजूद किस cc_libraries को लिंक नहीं किया जाना चाहिए, क्योंकि उन्हें पहले से ही किसी दूसरे cc_shared_library से उपलब्ध कराया गया है.
exports_filter	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस एट्रिब्यूट में उन टारगेट की सूची होती है जिनके बारे में दावा किया जाता है कि उन्हें मौजूदा शेयर की गई लाइब्रेरी से एक्सपोर्ट किया गया है. शेयर की गई लाइब्रेरी से, किसी भी टारगेट deps को पहले ही एक्सपोर्ट किया जा चुका है. इस एट्रिब्यूट का इस्तेमाल उन सभी टारगेट की सूची बनाने के लिए किया जाना चाहिए जिन्हें शेयर की गई लाइब्रेरी से एक्सपोर्ट किया गया है, लेकिन जो deps की ट्रांज़िशन डिपेंडेंसी हैं. ध्यान दें कि यह एट्रिब्यूट, उन टारगेट में डिपेंडेंसी एज नहीं जोड़ रहा है. इसके बजाय, डिपेंडेंसी एज को deps से बनाया जाना चाहिए. इस एट्रिब्यूट की एंट्री सिर्फ़ स्ट्रिंग होती हैं. ध्यान रखें कि इस एट्रिब्यूट में कोई टारगेट डालने पर, इसे एक दावे के तौर पर माना जाता है. इसका मतलब है कि शेयर की गई लाइब्रेरी, उस टारगेट से सिंबल एक्सपोर्ट करती है. cc_shared_library लॉजिक, लिंकर को यह बताने की सुविधा नहीं देता कि किन सिंबल को एक्सपोर्ट किया जाना चाहिए. इस सिंटैक्स का इस्तेमाल किया जा सकता है: //foo:__package__, foo/BUILD में किसी भी टारगेट को ध्यान में रखते हुए //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 टारगेट प्लैटफ़ॉर्म हो. इसका इस्तेमाल, शेयर की गई लाइब्रेरी को लिंक करते समय सिंबल एक्सपोर्ट करने के लिए किया जा सकता है.

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_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	स्ट्रिंग; डिफ़ॉल्ट रूप से "" एफ़डीओ प्रोफ़ाइल का ऐब्सलूट पाथ. FDO फ़ाइल में सिर्फ़ .afdo एक्सटेंशन हो सकता है.
profile	लेबल; डिफ़ॉल्ट रूप से None एफ़डीओ प्रोफ़ाइल का लेबल या उसे जनरेट करने वाला नियम. FDO फ़ाइल में इनमें से कोई एक एक्सटेंशन हो सकता है: इंडेक्स नहीं की गई LLVM प्रोफ़ाइल के लिए .profraw, इंडेक्स की गई LLVM प्रोफ़ाइल के लिए .profdata, LLVM profraw प्रोफ़ाइल को होस्ट करने वाली .zip, AutoFDO प्रोफ़ाइल के लिए .afdo, और XBinary प्रोफ़ाइल के लिए .xfdo. लेबल, fdo_absolute_path_profile नियम पर भी ले जा सकता है.
proto_profile	लेबल; डिफ़ॉल्ट रूप से None protobuf प्रोफ़ाइल का लेबल.

memprof_profile

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

memprof_profile(name, 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 एक्सटेंशन हो सकता है. साथ ही, ज़िप फ़ाइल में memprof.profdata फ़ाइल होनी चाहिए.
profile	लेबल; डिफ़ॉल्ट रूप से None MEMPROF प्रोफ़ाइल का लेबल. प्रोफ़ाइल में .profdata एक्सटेंशन (इंडेक्स की गई/सिंबल वाली memprof प्रोफ़ाइल के लिए) या .zip एक्सटेंशन होना चाहिए. .zip एक्सटेंशन वाली फ़ाइल में memprof.profdata फ़ाइल होनी चाहिए. लेबल, 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)

Workspace में 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 C प्रीप्रोसेसर वाला असेंबलर: .S संग्रहित करें: .a, .pic.a "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo शेयर की गई लाइब्रेरी, वर्शन वाली या वर्शन वाली नहीं: .so, .so.version ऑब्जेक्ट फ़ाइल: .o, .pic.o ...और उन फ़ाइलों को जनरेट करने वाले नियम. अलग-अलग एक्सटेंशन, जीसीसी के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, यहां इकट्ठा की गई Windows .res फ़ाइलें दी जा सकती हैं.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. बाइनरी टारगेट को संकलित करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में COPTS में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, न कि उसकी डिपेंडेंसी के लिए. इसलिए, दूसरी जगह शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, वर्कस्पेस के हिसाब से होने चाहिए, न कि मौजूदा पैकेज के हिसाब से. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो Bourne शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल करने की कमांड लाइन में जोड़ा जाता है. साथ ही, इस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई तरह के असर पड़ सकते हैं. अगर आपको नहीं पता कि 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 शेल टोकनाइज़ेशन और लेबल एक्सपैंशन का इस्तेमाल किया जा सकता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को LINKOPTS में जोड़ा जाता है. इस सूची के हर उस एलिमेंट को deps में टारगेट का लेबल माना जाता है जो $ या - से शुरू नहीं होता. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या deps में एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
linkstatic	बूलियन; डिफ़ॉल्ट तौर पर False cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प, बाइल्ड टूल को उपयोगकर्ता लाइब्रेरी के लिए, .so के बजाय .a को लिंक करने के लिए कहता है. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकती हैं. ऐसा उन लाइब्रेरी के लिए भी किया जा सकता है जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे में मिलने वाला एक्सीक्यूटेबल अब भी डाइनैमिक तौर पर लिंक किया जाएगा. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगा. किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं: fully_static_link सुविधा के साथ स्टैटिक, जिसमें सब कुछ स्टैटिक तौर पर लिंक किया गया है; उदाहरण के लिए, "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 डालें. linkstatic एट्रिब्यूट का इस्तेमाल, cc_library() नियम के लिए करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, linkstatic=True से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई .so नहीं जनरेट होगा. linkstatic=False से, स्टैटिक लाइब्रेरी बनने से नहीं रोका जाता. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है. अगर linkstatic=False है, तो बिल्ड टूल, *.runfiles एरिया में, उन शेयर की गई लाइब्रेरी के लिए सिमलिन्क बनाएगा जिन पर इस प्रोजेक्ट का निर्भर रहना है.
local_defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इस टारगेट के लिए, स्ट्रिंग को कंपाइल करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए.
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 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, हेडर पार्स करने की कार्रवाइयों के साथ काम करता है, तो इसे 'सही है' पर सेट करें.
supports_param_files	बूलियन; डिफ़ॉल्ट तौर पर True जब cc_toolchain, कार्रवाइयों को लिंक करने के लिए पैरामीटर फ़ाइलों का इस्तेमाल करने की सुविधा देता है, तो इसे 'सही है' पर सेट करें.
toolchain_config	लेबल; ज़रूरी है cc_toolchain_config_info की जानकारी देने वाले नियम का लेबल.
toolchain_identifier	स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट "" है इस cc_toolchain को उससे जुड़े crosstool_config.toolchain से मैच करने के लिए इस्तेमाल किया जाने वाला आइडेंटिफ़ायर. जब तक #5380 वाली समस्या ठीक नहीं हो जाती, तब तक cc_toolchain को CROSSTOOL.toolchain से जोड़ने के लिए, यह तरीका अपनाएं. इसे toolchain_config एट्रिब्यूट (#5380) से बदल दिया जाएगा.

cc_toolchain_suite

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

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

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

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

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

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

तर्क

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