BaselCon 2024 का रजिस्ट्रेशन अब शुरू हो गया है!

इस पेज का अनुवाद Cloud Translation API से किया गया है.

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` में, हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी `#include`d फ़ाइलों का उल्लेख, इस नियम के `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`, बॉर्न शेल टोकनाइज़ेशन सिर्फ़ स्ट्रिंग पर लागू होता है जिसमें एक "Make" वैरिएबल.
`defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे `-D` जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कमपाइल करने की कमांड लाइन में जोड़ा जाता है. साथ ही, इस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधानी बरतें, क्योंकि इससे कई चीज़ों पर असर पड़ सकता है. अगर आपको नहीं पता कि जीटीआईएन सही है या नहीं, तो इसके बजाय, `local_defines` में वैल्यू जोड़ें.
`includes`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है कंपाइल लाइन में जोड़े जाने वाले डाइरों को शामिल करने की सूची. "वैरिएबल बनाएं" विकल्प के हिसाब से बदला जा सकता है. हर स्ट्रिंग को `-isystem` से शुरू किया जाता है और `COPTS` में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और उस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: वे नियम नहीं हैं जिन पर यह निर्भर करता है!) होना ध्यान रखें, क्योंकि इसका दूर तक दूर तक असर हो सकता है. संदेह होने पर, जोड़ें "-मैं" फ़्लैग के बजाय COPTS पर फ़्लैग कर सकते हैं. हेडर, srcs या hdrs में जोड़े जाने चाहिए. ऐसा न होने पर, ये डिपेंडेंट कंपाइलेशन के सैंडबॉक्स में उपलब्ध नियम (डिफ़ॉल्ट).
`link_extra_lib`	लेबल; डिफ़ॉल्ट `"@bazel_tools//tools/cpp:link_extra_lib"` है अतिरिक्त लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल करना. डिफ़ॉल्ट रूप से, C++ बाइनरी को `//tools/cpp:link_extra_lib` से लिंक किया जाता है, यह डिफ़ॉल्ट रूप से, लेबल फ़्लैग `//tools/cpp:link_extra_libs` पर निर्भर करता है. फ़्लैग सेट किए बिना, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग सेट करना यह विकल्प डिपेंडेंसी जोड़ने की अनुमति देता है. जैसे, कमज़ोर सिंबल, इंटरसेप्टर को ओवरराइड करना या स्पेशल रनटाइम लाइब्रेरी के लिए (मैलक रिप्लेसमेंट फ़ंक्शन के लिए, `malloc` या `--custom_malloc` पसंद करें). इस एट्रिब्यूट को `None` इस व्यवहार को अक्षम कर देता है.
`linkopts`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है C++ लिंकर कमांड में ये फ़्लैग जोड़ें. "Make" वैरिएबल के बदले, Bourne शेल टोकनाइज़ेशन और लेबल एक्सपैंशन का इस्तेमाल किया जा सकता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को `LINKOPTS` में जोड़ा जाता है. इस सूची के हर उस एलिमेंट को `deps` में टारगेट का लेबल माना जाता है जो `$` या `-` से शुरू नहीं होता. कॉन्टेंट बनाने उस टारगेट से जनरेट होने वाली फ़ाइलों की सूची को लिंकर में जोड़ा जाता है के विकल्प. अगर लेबल अमान्य है या `deps` में एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
`linkshared`	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट `False` है शेयर की जा सकने वाली लाइब्रेरी बनाएं. इस एट्रिब्यूट को चालू करने के लिए, अपने नियम में `linkshared=True` शामिल करें. डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है. इस फ़्लैग के मौजूद होने का मतलब है कि लिंकिंग `-shared` फ़्लैग के साथ होती है `gcc` तक है और इससे बनने वाली शेयर लाइब्रेरी जैसे कि Java प्रोग्राम. हालांकि, बिल्ड के लिए इसे कभी भी डिपेंडेंट बाइनरी, क्योंकि यह माना जाता है कि 'शेयर की गई लाइब्रेरी' में cc_binary नियम को दूसरे प्रोग्राम सिर्फ़ मैन्युअल रूप से लोड करते हैं, इसलिए इसे cc_library का विकल्प नहीं माना जाना चाहिए नियम. स्टोरेज बढ़ाने के लिए, हमारा सुझाव है कि आप इस तरीके से पूरी तरह से बचें और बस `java_library` को `cc_library` नियमों पर निर्भर रहने देना आज़माएं. अगर `linkopts=['-static']` और `linkshared=True`, दोनों की जानकारी दी जाती है, तो तो आपको पूरी तरह से अपने में शामिल एक यूनिट मिलती है. अगर आप दोनों तय करते हैं, तो `linkstatic=True` और `linkshared=True`, आपको सिंगल बेड मिला है, ज़्यादातर समय सेल्फ़-कंटेन्ड यूनिट.
`linkstatic`	बूलियन; डिफ़ॉल्ट तौर पर `True` `cc_binary` और `cc_test`: बाइनरी को स्टैटिक से लिंक करें मोड. `cc_library.linkstatic` के लिए: नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प `cc_binary` के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह विकल्प चालू है और यह बाइनरी या टेस्ट है, तो यह विकल्प, बाइल्ड टूल को उपयोगकर्ता लाइब्रेरी के लिए, `.so` के बजाय `.a` को लिंक करने के लिए कहता है. ऐसा हो सकता है कि कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक हों. जैसे, ऐसी लाइब्रेरी यहां कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे में मिलने वाला एक्सीक्यूटेबल अब भी डाइनैमिक तौर पर लिंक किया जाएगा. इसलिए, यह सिर्फ़ ज़्यादातर स्टैटिक होगा. किसी एक्ज़ीक्यूटेबल को लिंक करने के वास्तव में तीन अलग-अलग तरीके हैं: पूरी तरह से static_link सुविधा के साथ आंकड़े, जिसमें सब कुछ स्थिर रूप से जुड़ा होता है; उदाहरण के लिए, "`gcc -static foo.o libbar.a libbaz.a -lm`". इस मोड को इसमें `fully_static_link` तय करके चालू किया जाता है `features` एट्रिब्यूट. 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`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग के आगे `-D` जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए, संकलन करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए.
`malloc`	लेबल; डिफ़ॉल्ट `"@bazel_tools//tools/cpp:malloc"` है malloc पर डिफ़ॉल्ट डिपेंडेंसी को बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी को `//tools/cpp:malloc` से लिंक किया जाता है, यह एक खाली लाइब्रेरी है. इसलिए, बाइनरी फ़ाइल के आखिर में libc मैलडॉक का इस्तेमाल किया जाता है. यह लेबल किसी `cc_library` से जुड़ा होना चाहिए. अगर कंपाइलेशन, C++ के अलावा किसी दूसरे नियम के लिए है, तो इस विकल्प का कोई असर नहीं पड़ता. इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है, अगर `linkshared=True` बताया गया है.
`nocopts`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` C++ कंपाइलेशन कमांड से मैच करने के विकल्प हटाएं. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन के तौर पर उपलब्ध है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस रेगुलर एक्सप्रेशन से मैच करने वाले सभी मौजूदा `COPTS` (इसमें नियम के copts एट्रिब्यूट में साफ़ तौर पर बताई गई वैल्यू भी शामिल हैं) को इस नियम को कॉम्पाइल करने के लिए, `COPTS` से हटा दिया जाएगा. इस एट्रिब्यूट की ज़रूरत बहुत कम पड़ती है.
`stamp`	पूर्णांक; डिफ़ॉल्ट वैल्यू `-1` है बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. वैल्यू, इनमें से कोई हो सकती है: `stamp = 1`: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. ऐसा `--nostamp` बिल्ड में भी करें. यह सेटिंग से बचना चाहिए, क्योंकि यह बाइनरी और ऐसी डाउनस्ट्रीम कार्रवाइयां जो उस पर निर्भर करती हैं. `stamp = 0`: बिल्ड की जानकारी को हमेशा कॉन्सटैंट वैल्यू से बदलें. इससे, बिल्ड के नतीजे को कैश मेमोरी में सेव करने की सुविधा मिलती है. `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने का कंट्रोल, `--[no]stamp` फ़्लैग. स्टैंप की गई बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो.
`win_def_file`	लेबल; डिफ़ॉल्ट रूप से `None` है लिंकर को भेजी जाने वाली Windows DEF फ़ाइल. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब Windows टारगेट प्लैटफ़ॉर्म हो. इसका इस्तेमाल इन कामों के लिए किया जा सकता है शेयर की गई लाइब्रेरी लिंक करते समय सिंबल एक्सपोर्ट करें.

cc_import

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

cc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)

cc_import नियमों की मदद से, उपयोगकर्ता पहले से कंपाइल की गई C/C++ लाइब्रेरी इंपोर्ट कर सकते हैं.

यहां इस्तेमाल के सामान्य उदाहरण दिए गए हैं:
1. स्टैटिक लाइब्रेरी लिंक करना

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  # If alwayslink is turned on,
  # libmylib.a will be forcely linked into any binary that depends on it.
  # alwayslink = 1,
)

2. शेयर की गई लाइब्रेरी (यूनिक्स) को लिंक करना

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. स्टैटिक या शेयर की गई लाइब्रेरी
से लिंक किया जा रहा है यूनिक्स पर:

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 है, तो कोई भी बाइनरी जो इस C++ पर (सीधे तौर पर या किसी दूसरे तरीके से) निर्भर करती है पहले से कंपाइल की गई लाइब्रेरी, स्टैटिक लाइब्रेरी में संग्रहित सभी ऑब्जेक्ट फ़ाइलों से लिंक होगी, भले ही कुछ में बाइनरी से रेफ़र किया गया कोई सिंबल न हो. यह तब काम आता है, जब आपके कोड को बाइनरी में कोड से साफ़ तौर पर कॉल न किया गया हो. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिलने वाला कॉलबैक पाने के लिए रजिस्टर करता है. अगर हमेशा लिंक Windows पर VS 2017 के साथ काम नहीं करता है, तो इसकी वजह से आम समस्या, कृपया अपने 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.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 में ट्रांज़िटिव तौर पर कोई भी हेडर फ़ाइल शामिल हो सकती है. तय सीमा में इस केस में कंपाइलर baz.h और baz-impl.h को पढ़ सकता है foo.cc को कंपाइल करते समय, लेकिन foo.cc को #include "baz.h" शामिल है. इसके लिए अनुमति है, baz को deps में जोड़ना ज़रूरी है foo महीने में से.

बिना किसी भेदभाव के सभी को शामिल करने की जांच से जुड़े नियमों को लागू करने के लिए, Baze, टूलचेन की सुविधा पर निर्भर करता है. layering_check सुविधा, टूलचेन के साथ काम करती हो और साफ़ तौर पर अनुरोध किया गया है, उदाहरण के लिए --features=layering_check कमांड लाइन फ़्लैग या features पैरामीटर package फ़ंक्शन. 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` में, हेडर सीधे तौर पर शामिल किए जा सकते हैं. सभी `#include`d फ़ाइलों का उल्लेख, इस नियम के `srcs` एट्रिब्यूट में या रेफ़र की गई `cc_library()`s के `hdrs` एट्रिब्यूट में किया जाना चाहिए. सुझाई गई स्टाइल लाइब्रेरी से जुड़े हेडर के लिए है उस लाइब्रेरी के `hdrs` एट्रिब्यूट में मौजूद होती है और बाकी सभी एट्रिब्यूट के लिए इस नियम के सोर्स से जुड़े हेडर, जिन्हें इसमें शामिल किया जाएगा `srcs`. "हेडर शामिल किए जाने की जांच" देखें देखें. अगर किसी नियम का नाम `srcs` में है, तो यह नियम अपने-आप उस नियम पर निर्भर करता है. अगर नाम वाले नियम के `outs` C या C++ वाली सोर्स फ़ाइलें हैं, तो उन्हें इस नियम में कॉम्पाइल किया जाता है; अगर वे लाइब्रेरी फ़ाइलें हैं, तो उन्हें लिंक किया जाता है. अनुमति वाले `srcs` फ़ाइल टाइप: C और C++ सोर्स फ़ाइलें: `.c`, `.cc`, `.cpp`, `.cxx`, `.c++`, और `.C` C और C++ हेडर फ़ाइलें: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, और `.H` C प्रीप्रोसेसर वाला असेंबलर: `.S` संग्रहित करें: `.a`, `.pic.a` "हमेशा लिंक करें" लाइब्रेरी: `.lo`, `.pic.lo` शेयर की गई लाइब्रेरी, वर्शन वाली या वर्शन वाली नहीं: `.so`, `.so.version` ऑब्जेक्ट फ़ाइल: `.o`, `.pic.o` ...और उन फ़ाइलों को बनाने वाले किसी भी नियम के बारे में बताया है. अलग-अलग एक्सटेंशन, जीसीसी के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
`hdrs`	लेबल की सूची; डिफ़ॉल्ट `[]` है उन हेडर फ़ाइलों की सूची जिन्हें इन्होंने पब्लिश किया है इस लाइब्रेरी को डिपेंडेंट नियमों में शामिल सोर्स से सीधे तौर पर जोड़ा जाएगा. लाइब्रेरी के इंटरफ़ेस के बारे में बताने वाली हेडर फ़ाइलों को एलान करने के लिए, यह सबसे सही जगह है. इन हेडर को इस नियम या इससे जुड़े नियमों में, सोर्स के ज़रिए शामिल करने के लिए उपलब्ध कराया जाएगा. ऐसे हेडर जिन्हें इस लाइब्रेरी के क्लाइंट द्वारा शामिल नहीं किया जाना चाहिए इसके बजाय, `srcs` एट्रिब्यूट में लिस्ट किया गया है, भले ही वे एक पब्लिश किए गए हेडर के ज़रिए शामिल किया जाता है. ज़्यादा जानकारी के लिए, "हेडलाइन में शामिल करने की जांच" देखें.
`additional_compiler_inputs`	लेबल की सूची; डिफ़ॉल्ट रूप से `[]` है ऐसी कोई भी अतिरिक्त फ़ाइल जिसे आप कंपाइलर कमांड लाइन को भेजना चाहें, जैसे कि सैनिटाइज़र उदाहरण के लिए, अनदेखा करने की सूचियां. इसके बाद, यहां बताई गई फ़ाइलों का इस्तेमाल, $(location) फ़ंक्शन के साथ copts में किया जा सकता है.
`additional_linker_inputs`	लेबल की सूची; डिफ़ॉल्ट रूप से `[]` है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां एम्बेड किया जा सकता है, ताकि उन्हें बाइनरी टारगेट.
`alwayslink`	बूलियन; `False` डिफ़ॉल्ट है अगर 1 है, तो इस C++ पर निर्भर कोई भी बाइनरी (सीधे तौर पर या किसी अन्य तरीके से) लाइब्रेरी में सूचीबद्ध फ़ाइलों की सभी ऑब्जेक्ट फ़ाइलों से `srcs`, भले ही कुछ में बाइनरी से रेफ़र किया गया कोई सिंबल न हो. यह तब काम आता है, जब आपके कोड को बाइनरी में कोड से साफ़ तौर पर कॉल न किया गया हो. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिलने वाला कॉलबैक पाने के लिए रजिस्टर करता है. अगर हमेशा लिंक Windows पर VS 2017 के साथ काम नहीं करता है, तो इसकी वजह से आम समस्या, कृपया अपने VS 2017 को सबसे नए वर्शन में अपग्रेड करें.
`copts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इन विकल्पों को C++ कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के विकल्प पर निर्भर करता है और बोर्न शेल टोकनाइज़ेशन. बाइनरी टारगेट को संकलित करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में `COPTS` में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, न कि पर निर्भर नहीं होना चाहिए, इसलिए कहीं भी शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ को फ़ाइल फ़ोल्डर से संबंधित होनी चाहिए, न कि मौजूदा पैकेज से. अगर पैकेज, सुविधा का एलान करता है `no_copts_tokenization`, बॉर्न शेल टोकनाइज़ेशन सिर्फ़ स्ट्रिंग पर लागू होता है जिसमें एक "Make" वैरिएबल.
`defines`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को `-D` के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, सभी नियम लागू कर सकते हैं. बहुत सावधानी बरतें, क्योंकि इससे कई चीज़ों पर असर पड़ सकता है. अगर आपको नहीं पता कि जीटीआईएन सही है या नहीं, तो इसके बजाय, `local_defines` में वैल्यू जोड़ें.
`implementation_deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है लाइब्रेरी टारगेट पर निर्भर अन्य लाइब्रेरी की सूची. इससे नापसंद करें `deps`, हेडर और इन लाइब्रेरी के पाथ (और उनके सभी ट्रांज़िटिव डिप) का इस्तेमाल सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है, न कि उन लाइब्रेरी के लिए जिन्हें निर्भर है. `implementation_deps` के साथ बताई गई लाइब्रेरी अब भी उन बिनेरी टारगेट में लिंक होती हैं जो इस लाइब्रेरी पर निर्भर करती हैं. फ़िलहाल, इसका इस्तेमाल cc_लाइब्रेरी तक सीमित किया गया है और उसे फ़्लैग किया गया है `--experimental_cc_implementation_deps`.
`include_prefix`	String; `""` डिफ़ॉल्ट है इस नियम के हेडर के पाथ में जोड़ा जाने वाला प्रीफ़िक्स. अगर नीति को सेट किया जाता है, तो इस नियम के `hdrs` एट्रिब्यूट में मौजूद हेडर को ऐक्सेस किया जा सकता है पर इस एट्रिब्यूट का मान है जो उनके रिपॉज़िटरी-रिलेटिव पाथ से पहले है. इस प्रीफ़िक्स को जोड़ने से पहले, `strip_include_prefix` एट्रिब्यूट में मौजूद प्रीफ़िक्स को हटा दिया जाता है.
`includes`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है कंपाइल लाइन में जोड़ी जाने वाली शामिल डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. हर स्ट्रिंग को `-isystem` से शुरू किया जाता है और `COPTS` में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और उस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: वे नियम नहीं हैं जिन पर यह निर्भर करता है!) बहुत सावधान रहें, क्योंकि इससे कई चीज़ों पर असर पड़ सकता है. संदेह होने पर, जोड़ें "-मैं" फ़्लैग करने के बजाय COPTS पर फ़्लैग कर सकते हैं. हेडर, srcs या hdrs में जोड़े जाने चाहिए. ऐसा न होने पर, ये डिपेंडेंट कंपाइलेशन के सैंडबॉक्स में उपलब्ध नियम (डिफ़ॉल्ट).
`linkopts`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है C++ लिंकर कमांड में ये फ़्लैग जोड़ें. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन, बॉर्न शेल टोकनाइज़ेशन और लेबल एक्सपैंशन. इस एट्रिब्यूट की हर स्ट्रिंग को पहले `LINKOPTS` में जोड़ दिया गया है बाइनरी टारगेट को लिंक करना. इस सूची का हर वह एलिमेंट जो `$` या `-` से शुरू नहीं होता है `deps` में किसी टारगेट का लेबल माना जाता है. कॉन्टेंट बनाने उस टारगेट से जनरेट होने वाली फ़ाइलों की सूची को लिंकर में जोड़ा जाता है के विकल्प. अगर लेबल अमान्य है, तो एक गड़बड़ी की रिपोर्ट की जाती है, या `deps` में नहीं बताया गया.
`linkstamp`	लेबल; डिफ़ॉल्ट रूप से `None` है साथ ही, यह तय की गई C++ सोर्स फ़ाइल को फ़ाइनल बाइनरी में इकट्ठा और लिंक करता है. टाइमस्टैंप लागू करने के लिए, यह ट्रिकरी ज़रूरी है बाइनरी में जानकारी; अगर हम सोर्स फ़ाइल को किसी ऑब्जेक्ट फ़ाइल को सामान्य तरीके से सबमिट करते हैं, तो टाइमस्टैंप गलत होगा. लिंकस्टैम्प कंपाइलेशन में कंपाइलर फ़्लैग और इसलिए किसी खास हेडर, कंपाइलर विकल्प या अन्य बिल्ड वैरिएबल. इस विकल्प की ज़रूरत सिर्फ़ `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" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे `-D` जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए, संकलन करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए.
`nocopts`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` C++ कंपाइलेशन कमांड से मैच करने वाले विकल्प हटाएं. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन के तौर पर उपलब्ध है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस रेगुलर एक्सप्रेशन से मैच करने वाले सभी मौजूदा `COPTS` (इसमें नियम के copts एट्रिब्यूट में साफ़ तौर पर बताई गई वैल्यू भी शामिल हैं) को इस नियम को कॉम्पाइल करने के लिए, `COPTS` से हटा दिया जाएगा. इस एट्रिब्यूट की ज़रूरत बहुत कम पड़ती है.
`strip_include_prefix`	String; `""` डिफ़ॉल्ट है इस नियम के हेडर के पाथ से हटाने के लिए प्रीफ़िक्स. सेट होने पर, इस नियम के `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 हमें जोड़ना होगा tags = ["LINKABLE_MORE_THAN_ONCE"] से baz.

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 टारगेट में स्टैटिक तौर पर लिंक करने की ज़रूरत नहीं है और न ही इसे लिंक किया जा सकता है. इसलिए, यह इसके deps में नहीं आता है cc_shared_library. अगर पहले से कंपाइल की गई यह डाइनैमिक लाइब्रेरी, किसी एक की डिपेंडेंसी है आपके 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`) तय करें कि किस `cc_libraries` को ट्रांज़िटिव `deps` को लिंक नहीं किया जाना चाहिए, क्योंकि वे पहले ही दिए जा चुके हैं किसी भिन्न `cc_shared_library` द्वारा.
`exports_filter`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है इस एट्रिब्यूट में ऐसे टारगेट की सूची है जिन्हें मौजूदा रिपोर्ट से एक्सपोर्ट करने का दावा किया गया है शेयर की गई लाइब्रेरी पर टैप करें. टारगेट `deps` को पहले से ही, शेयर की गई लाइब्रेरी से एक्सपोर्ट किया जा सकता है. इस एट्रिब्यूट का इस्तेमाल, उन सभी टारगेट की सूची बनाने के लिए किया जाना चाहिए जिन्हें शेयर की गई लाइब्रेरी से एक्सपोर्ट किया गया है, लेकिन जो `deps` की ट्रांज़िशन डिपेंडेंसी हैं. ध्यान दें कि यह एट्रिब्यूट असल में उन टारगेट में डिपेंडेंसी एज नहीं जोड़ रहा है, इसके बजाय, `deps` को डिपेंडेंसी एज बनाना चाहिए.इसमें मौजूद एंट्री एट्रिब्यूट सिर्फ़ स्ट्रिंग हैं. ध्यान रखें कि इस एट्रिब्यूट में कोई टारगेट डालने पर, इसे एक दावे के तौर पर माना जाता है. इसका मतलब है कि शेयर की गई लाइब्रेरी, उस टारगेट से सिंबल एक्सपोर्ट करती है. `cc_shared_library` लॉजिक, असल में लिंकर को यह नहीं बता पाता कि चिह्न एक्सपोर्ट किए जा सकते हैं. इस सिंटैक्स की अनुमति है: `//foo:__package__`, foo/BUILD में किसी भी टारगेट को ध्यान में रखते हुए foo/BUILD या किसी दूसरे टारगेट में शामिल टारगेट के लिए `//foo:__subpackages__` foo/ जैसे foo/bar/BUILD के नीचे दिया गया पैकेज
`shared_lib_name`	String; `""` डिफ़ॉल्ट है डिफ़ॉल्ट रूप से, cc_shared_library, शेयर की गई लाइब्रेरी की आउटपुट फ़ाइल के लिए इस आधार पर नाम का इस्तेमाल करेगा टारगेट का नाम और प्लैटफ़ॉर्म. इसमें, एक्सटेंशन और कभी-कभी प्रीफ़िक्स शामिल होते हैं. कभी-कभी, आपको डिफ़ॉल्ट नाम नहीं चाहिए. उदाहरण के लिए, Python के लिए C++ शेयर की गई लाइब्रेरी लोड करते समय, अक्सर डिफ़ॉल्ट lib* प्रीफ़िक्स का इस्तेमाल नहीं किया जाता. ऐसे में, कस्टम नाम चुनने के लिए इस एट्रिब्यूट का इस्तेमाल किया जा सकता है.
`user_link_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` ऐसे अन्य फ़्लैग जिन्हें शायद आप लिंकर को भेजना चाहें. उदाहरण के लिए, लिंकर को अतिरिक्त_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_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 फ़ाइल में इनमें से कोई एक एक्सटेंशन हो सकता है: इंडेक्स नहीं की गई एलएलवीएम प्रोफ़ाइल के लिए .profraw, इंडेक्स की गई एलएलवीएम प्रोफ़ाइल के लिए .profdata, .zip जिसके पास LLVM Profraw प्रोफ़ाइल या AutoFDO प्रोफ़ाइल के लिए .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

String; "" डिफ़ॉल्ट है

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)

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

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

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`	String; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से `""` है इस cc_toolchain को उससे जुड़े crosstool_config.toolchain से मैच करने के लिए इस्तेमाल किया जाने वाला आइडेंटिफ़ायर. समस्या #5380 के ठीक होने तक यह `cc_toolchain` को `CROSSTOOL.toolchain`. इसे `toolchain_config` से बदल दिया जाएगा एट्रिब्यूट (#5380).

cc_toolchain_suite

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

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

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

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

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

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

तर्क

विशेषताएं

name

नाम; आवश्यक

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

toolchains

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

"<cpu>" या "<cpu>|<compiler>" स्ट्रिंग से cc_toolchain लेबल पर मैप. "<cpu>" का इस्तेमाल सिर्फ़ तब किया जाएगा, जब --cpu बेज़ल को पास किया जाता है, और "<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",
            },
          )