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 ...और उन फ़ाइलों को बनाने वाले किसी भी नियम के बारे में बताया है. अलग-अलग एक्सटेंशन, जीसीसी के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
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 टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई चीज़ों पर असर पड़ सकता है. अगर आपको नहीं पता कि जीटीआईएन सही है या नहीं, तो इसके बजाय, local_defines में वैल्यू जोड़ें.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़े जाने वाले डाइरों को शामिल करने की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. हर स्ट्रिंग को -isystem से शुरू किया जाता है और COPTS में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और उस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: उन नियमों के बारे में नहीं जिन पर यह निर्भर करता है!) बहुत सावधान रहें, क्योंकि इससे कई चीज़ों पर असर पड़ सकता है. अगर आपको कोई संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. हेडर को src या 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 को लिंक करने के लिए कहता है. ऐसा हो सकता है कि कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की गई हों. जैसे, ऐसी लाइब्रेरी जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं होती. इसलिए, नतीजे के तौर पर मिलने वाला एक्ज़ीक्यूटेबल अब भी डाइनैमिक लिंक होगा. इसलिए, सिर्फ़ ज़्यादातर स्टैटिक तरीके से ही लिंक होगा. किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं: पूरी तरह से 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" वैरिएबल के बदले और 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 के साथ काम नहीं करती है, तो इसकी वजह पहले से मालूम समस्या है, तो कृपया अपने VS 2017 को सबसे नए वर्शन में अपग्रेड करें.
interface_library	लेबल; डिफ़ॉल्ट None है शेयर की गई लाइब्रेरी को लिंक करने के लिए, एक इंटरफ़ेस लाइब्रेरी. इन फ़ाइल टाइप को इस्तेमाल करने की अनुमति है: .ifso, .tbd, .lib, .so या .dylib
shared_library	लेबल; डिफ़ॉल्ट None है पहले से कंपाइल की गई एक शेयर की गई लाइब्रेरी. Basel यह पक्का करता है कि यह रनटाइम के दौरान बाइनरी पर उपलब्ध हो. इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: .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 ...और उन फ़ाइलों को बनाने वाले किसी भी नियम के बारे में बताया है. अलग-अलग एक्सटेंशन, gcc कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
hdrs	लेबल की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची, ताकि सोर्स उन्हें सीधे तौर पर, डिपेंडेंट नियमों में शामिल कर सकें. लाइब्रेरी के इंटरफ़ेस की जानकारी देने वाली हेडर फ़ाइलों का एलान करने के लिए, इस जगह का सुझाव दिया जाता है. इन हेडर को इस नियम या इससे जुड़े नियमों में, सोर्स के ज़रिए शामिल करने के लिए उपलब्ध कराया जाएगा. जिन हेडर को इस लाइब्रेरी के क्लाइंट को शामिल नहीं करना है उन्हें srcs एट्रिब्यूट में शामिल किया जाना चाहिए. भले ही, उन्हें पब्लिश किए गए हेडर में शामिल किया गया हो. ज़्यादा जानकारी के लिए, "हेडलाइन में शामिल करने की जांच" देखें.
additional_compiler_inputs	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी कोई भी अतिरिक्त फ़ाइल जिसे आपको कंपाइलर कमांड लाइन में पास करना है. उदाहरण के लिए, सैनिटाइज़र की सूची को नज़रअंदाज़ करना. इसके बाद, यहां बताई गई फ़ाइलों का इस्तेमाल, $(location) फ़ंक्शन के साथ copts में किया जा सकता है.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है.
alwayslink	बूलियन; डिफ़ॉल्ट तौर पर False अगर 1 है, तो सीधे या किसी अन्य तरीके से इस C++ लाइब्रेरी पर निर्भर रहने वाली कोई भी बाइनरी, srcs में दी गई फ़ाइलों की सभी ऑब्जेक्ट फ़ाइलों को लिंक करेगी. भले ही, कुछ फ़ाइलों में बाइनरी का रेफ़रंस देने वाला कोई सिंबल न हो. यह तब काम आता है, जब आपके कोड को बाइनरी में कोड से साफ़ तौर पर कॉल न किया गया हो. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिलने वाला कॉलबैक पाने के लिए रजिस्टर करता है. अगर Windows पर VS 2017 के साथ alwayslink काम नहीं करता है, तो इसकी वजह जानी-पहचानी समस्या है. कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है इन विकल्पों को C++ कंपाइलेशन कमांड में जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. बाइनरी टारगेट को संकलित करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में COPTS में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट को इकट्ठा करने के लिए लागू होते हैं, इनकी डिपेंडेंसी के लिए नहीं. इसलिए, कहीं और शामिल की गई हेडर फ़ाइलों को लेकर सावधान रहें. सभी पाथ, वर्कस्पेस के हिसाब से होने चाहिए, न कि मौजूदा पैकेज के हिसाब से. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो Bourne शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए, को -D से पहले जोड़ा जाता है. इसके बाद, स्ट्रिंग को इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. साथ ही, स्ट्रिंग पर निर्भर हर नियम में भी इसे जोड़ा जाता है. बहुत सावधान रहें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. जब भी आपको पता न हो कि वैल्यू कहां दी गई हैं, तब 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++ कंपाइलेशन कमांड से मैच करने वाले विकल्प हटाएं. "बनाएं" वैरिएबल के विकल्प पर निर्भर करता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस रेगुलर एक्सप्रेशन से मैच करने वाले सभी मौजूदा 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 को लिंक करता है. यहां बाद वाली डिपेंडेंसी, ट्रांज़िटिव डिपेंडेंसी है. यह 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/BUILD में किसी भी टारगेट को पूरा करने के लिए //foo:__package__ foo/BUILD में टारगेट किए गए किसी भी टारगेट या foo/ जैसे कि foo/bar/BUILD से कम के किसी भी अन्य पैकेज को शामिल करने के लिए //foo:__subpackages__
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 फ़ाइल में इनमें से कोई एक एक्सटेंशन हो सकता है: इंडेक्स नहीं की गई LLVM प्रोफ़ाइल के लिए .profraw, इंडेक्स की गई LLVM प्रोफ़ाइल के लिए .profdata, .zip जिसमें LLVM profraw प्रोफ़ाइल हो या AutoFDO प्रोफ़ाइल के लिए .afdo.
profile	लेबल; डिफ़ॉल्ट None है एफ़डीओ प्रोफ़ाइल का लेबल या उसे जनरेट करने वाला नियम. एफ़डीओ फ़ाइल में, इनमें से कोई एक एक्सटेंशन हो सकता है: इंडेक्स नहीं की गई एलएलवीएम प्रोफ़ाइल के लिए .profraw, इंडेक्स की गई एलएलवीएम प्रोफ़ाइल के लिए .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 एक्सटेंशन हो सकता है. साथ ही, 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)

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

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

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

तर्क

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

cc_test

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

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

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये cc_library या objc_library टारगेट हो सकते हैं.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें होती हैं. ये जनरेट नहीं की गई (सामान्य सोर्स कोड) या जनरेट की गई हो सकती हैं. .cc, .c, और .cpp की सभी फ़ाइलें कंपाइल कर दी जाएंगी. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर कोई फ़ाइल किसी दूसरे नियम के outs में है, तो यह नियम अपने-आप उस दूसरे नियम पर निर्भर करेगा. .h फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, इस नियम में सोर्स के ज़रिए इसे शामिल किया जा सकता है. .cc और .h, दोनों फ़ाइलों में इन srcs में दिए गए हेडर या deps आर्ग्युमेंट में दिए गए किसी भी नियम के hdrs में, हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी #included फ़ाइलों का उल्लेख, इस नियम के srcs एट्रिब्यूट या बताए गए cc_library() के hdrs एट्रिब्यूट में किया जाना चाहिए. हमारा सुझाव है कि लाइब्रेरी से जुड़े हेडर को उस लाइब्रेरी के hdrs एट्रिब्यूट में शामिल करें और इस नियम के सोर्स से जुड़े बाकी सभी हेडर को srcs में शामिल करें. ज़्यादा जानकारी के लिए, "हेडर शामिल किए जाने की जांच" देखें. अगर किसी नियम का नाम srcs में है, तो यह नियम अपने-आप उस नियम पर निर्भर करता है. अगर नाम वाले नियम के outs, C या C++ वाली सोर्स फ़ाइलें हैं, तो उन्हें इस नियम में कॉम्पाइल किया जाता है; अगर वे लाइब्रेरी फ़ाइलें हैं, तो उन्हें लिंक किया जाता है. srcs फ़ाइल टाइप के लिए अनुमति है: C और C++ सोर्स फ़ाइलें: .c, .cc, .cpp, .cxx, .c++, .C C और C++ हेडर फ़ाइलें: .h, .hh, .hpp, .hxx, .inc, .inl, .H 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 के बारे में जानकारी देता है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल मौजूद होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. यह "Make" वैरिएबल के विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए, कमपाइल करने की कमांड लाइन में जोड़ा जाता है. साथ ही, इस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई चीज़ों पर असर पड़ सकता है. अगर आपको नहीं पता कि जीटीआईएन सही है या नहीं, तो इसके बजाय, local_defines में वैल्यू जोड़ें.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ी जाने वाली शामिल डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प के हिसाब से बदला जा सकता है. हर स्ट्रिंग को -isystem से शुरू किया जाता है और COPTS में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और उस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: उन नियमों के बारे में नहीं जिन पर यह निर्भर करता है!) बहुत सावधान रहें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. अगर आपको कोई संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. हेडर को src या 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", }, )