C / C++ नियम

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

नियम

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

cc_binary

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

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

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

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

तर्क

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

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

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

cc_library के नियमों के हिसाब से, hdrs के हेडर, लाइब्रेरी का सार्वजनिक इंटरफ़ेस होते हैं. साथ ही, इन्हें लाइब्रेरी की hdrs और srcs, दोनों फ़ाइलों में सीधे शामिल किया जा सकता है. साथ ही, इन्हें hdrs और cc_* नियमों की srcs फ़ाइलों में भी शामिल किया जा सकता है, जो deps में लाइब्रेरी के बारे में जानकारी देते हैं. srcs के हेडर, सिर्फ़ लाइब्रेरी के hdrs और srcs की फ़ाइलों से ही शामिल किए जाने चाहिए. हेडर को hdrs या srcs में डालने का फ़ैसला करते समय, आपको यह तय करना चाहिए कि क्या आपको इस लाइब्रेरी के उपभोक्ताओं को इसे सीधे तौर पर शामिल करने की अनुमति देनी है. यह फ़ैसला, प्रोग्रामिंग भाषाओं में public और private के बीच विज़िबिलिटी तय करने के फ़ैसले जैसा ही है.

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

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

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

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

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

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

फ़ाइल शामिल करना	शामिल करने की अनुमति है
foo.h	bar.h
foo.cc	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 ...और उन फ़ाइलों को जनरेट करने वाले नियम. अलग-अलग एक्सटेंशन, gcc कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
hdrs	लेबल की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची, जिसे डिपेंडेंट नियमों वाले सोर्स में सीधे तौर पर शामिल किया जाएगा. लाइब्रेरी के इंटरफ़ेस के बारे में बताने वाली हेडर फ़ाइलों को एलान करने के लिए, यह सबसे सही जगह है. ये हेडर, इस नियम में मौजूद सोर्स से या अलग-अलग नियमों में शामिल किए जाने के लिए उपलब्ध कराए जाएंगे. जिन हेडर को इस लाइब्रेरी के क्लाइंट को शामिल नहीं करना है उन्हें srcs एट्रिब्यूट में शामिल किया जाना चाहिए. भले ही, उन्हें पब्लिश किए गए हेडर में शामिल किया गया हो. ज़्यादा जानकारी के लिए, "हेडलाइन में शामिल करने की जांच" देखें.
additional_compiler_inputs	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी कोई भी अतिरिक्त फ़ाइल जिसे आपको कंपाइलर कमांड लाइन में पास करना है. उदाहरण के लिए, सैनिटाइज़र की सूची को नज़रअंदाज़ करना. इसके बाद, यहां दी गई फ़ाइलों को $(location) फ़ंक्शन के साथ कॉप्ट में इस्तेमाल किया जा सकता है.
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 के बारे में जानकारी देता है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल मौजूद होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. यह "Make" वैरिएबल के विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए, कमपाइल करने की कमांड लाइन में जोड़ा जाता है. साथ ही, इस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई चीज़ों पर असर पड़ सकता है. अगर आपको नहीं पता कि जीटीआईएन सही है या नहीं, तो इसके बजाय, 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 डालें. आंकड़े, जिसमें सभी यूज़र लाइब्रेरी स्टैटिक रूप से लिंक की जाती हैं (अगर स्टैटिक वर्शन उपलब्ध है), लेकिन जहां सिस्टम लाइब्रेरी (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" वैरिएबल के विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. हर स्ट्रिंग के आगे -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 होगा, जबकि Linux का नाम डिफ़ॉल्ट रूप से libbar.so होगा.

गड़बड़ियां

Two shared libraries in dependencies export the same symbols.

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

Two shared libraries in dependencies link the same library statically

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

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

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

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

इसे ठीक करने के लिए, इसे cc_shared_library डिपेंडेंसी से एक्सपोर्ट करें या इसे एक्सपोर्ट करने वाले तीसरे cc_shared_library का इस्तेमाल करें.

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

अगर आपके पास पहले से कंपाइल की गई डाइनैमिक लाइब्रेरी है, तो इसे मौजूदा cc_shared_library टारगेट के साथ स्टैटिक रूप से लिंक करने की ज़रूरत नहीं है और न ही इसे लिंक किया जा सकता है. इसलिए, यह 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). यह तय करने के लिए कि ट्रांज़िटिव 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 है प्रोटोबफ़ प्रोफ़ाइल का लेबल.

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

propeller_optimize

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

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

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++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. यह "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. बाइनरी टारगेट को संकलित करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में COPTS में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट को इकट्ठा करने के लिए लागू होते हैं, इनकी डिपेंडेंसी के लिए नहीं. इसलिए, कहीं और शामिल की गई हेडर फ़ाइलों को लेकर सावधान रहें. सभी पाथ, वर्कस्पेस के हिसाब से होने चाहिए, न कि मौजूदा पैकेज के हिसाब से. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो Bourne शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए, को -D से पहले जोड़ा जाता है. इसके बाद, स्ट्रिंग को इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. साथ ही, स्ट्रिंग पर निर्भर हर नियम में भी इसे जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि इससे कई चीज़ों पर असर पड़ सकता है. अगर आपको नहीं पता कि जीटीआईएन सही है या नहीं, तो इसके बजाय, 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" वैरिएबल के विकल्प, बॉर्न शेल टोकनाइज़ेशन, और लेबल एक्सपैंशन पर निर्भर करता है. इस एट्रिब्यूट की हर स्ट्रिंग को बाइनरी टारगेट को लिंक करने से पहले, 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 Basel को पास किया गया हो. साथ ही, "<cpu>|<compiler>" का इस्तेमाल तब किया जाएगा, जब --cpu और --compiler, दोनों Basel को पास किए गए हों. उदाहरण: cc_toolchain_suite( name = "toolchain", toolchains = { "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc", "piii": ":my_cc_toolchain_for_piii_using_default_compiler", }, )