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

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

C / C++ नियम

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की रिपोर्ट करें सोर्स देखें नाइटली · 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` या इनमें सूचीबद्ध किसी भी नियम के `hdrs` में `deps` तर्क को बदल दिया गया है. सभी `#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++ कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के विकल्प पर निर्भर करता है और बोर्न शेल टोकनाइज़ेशन. इस एट्रिब्यूट की हर स्ट्रिंग, दिए गए क्रम में `COPTS` से पहले जोड़ दी जाती है बाइनरी टारगेट को कंपाइल करना. फ़्लैग सिर्फ़ इस टारगेट को इकट्ठा करने के लिए लागू होते हैं, नहीं पर निर्भर नहीं होना चाहिए, इसलिए कहीं भी शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ को फ़ाइल फ़ोल्डर से संबंधित होनी चाहिए, न कि मौजूदा पैकेज से. अगर पैकेज, सुविधा का एलान करता है `no_copts_tokenization`, बॉर्न शेल टोकनाइज़ेशन सिर्फ़ स्ट्रिंग पर लागू होता है जिसमें एक "Make" वैरिएबल.
`defines`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को `-D` के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, सभी नियम लागू कर सकते हैं. बहुत सावधान रहें, क्योंकि दूर तक पहुंचने के लिए. संदेह होने पर, 'तय करें' वैल्यू इसके बजाय, `local_defines` का इस्तेमाल करें.
`includes`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है कंपाइल लाइन में जोड़े जाने वाले डाइरों को शामिल करने की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. हर स्ट्रिंग, `-isystem` से पहले जोड़ी जाती है और `COPTS` में जोड़ दी जाती है. COPS के उलट, इस नियम के लिए ये फ़्लैग जोड़े जाते हैं और इस पर निर्भर सभी नियमों के लिए बनाया गया है. (ध्यान दें: वे नियम नहीं हैं जिन पर यह निर्भर करता है!) होना ध्यान रखें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. संदेह होने पर, जोड़ें "-मैं" फ़्लैग करने के बजाय 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++ लिंकर कमांड में जोड़ें. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन, बॉर्न शेल टोकनाइज़ेशन और लेबल एक्सपैंशन. इस एट्रिब्यूट की हर स्ट्रिंग को पहले `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` एट्रिब्यूट. आंकड़े, जिसमें सभी उपयोगकर्ता लाइब्रेरी स्थिर रूप से लिंक की जाती हैं (अगर वर्शन उपलब्ध है), लेकिन सिस्टम लाइब्रेरी (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` के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, हालाँकि, डिपेंडेंट लोगों के लिए लागू हो सकता है.
`malloc`	लेबल; डिफ़ॉल्ट रूप से `"@bazel_tools//tools/cpp:malloc"` है मॉलोक पर डिफ़ॉल्ट डिपेंडेंसी बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी को `//tools/cpp:malloc` से लिंक किया जाता है, यह एक खाली लाइब्रेरी है. इसलिए, बाइनरी फ़ाइल के आखिर में libc मैलडॉक का इस्तेमाल किया जाता है. यह लेबल किसी `cc_library` से जुड़ा होना चाहिए. अगर कंपाइलेशन बिना C++ वाली नियम के तहत, इस विकल्प का कोई असर नहीं पड़ता. इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है, अगर `linkshared=True` बताया गया है.
`nocopts`	String; `""` डिफ़ॉल्ट है C++ कंपाइलेशन कमांड से मैच करने के विकल्प हटाएं. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन के तौर पर उपलब्ध है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाला कोई भी पहले से मौजूद `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. स्टैटिक या शेयर की गई लाइब्रेरी
से लिंक किया जा रहा है यूनिक्स पर:

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` है पहले से कंपाइल की गई सिंगल शेयर लाइब्रेरी. Baze, पक्का करता है कि यह कंपनी बाइनरी, जो रनटाइम के दौरान इस पर निर्भर करती है. अनुमति वाले फ़ाइल टाइप: `.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	फ़ू.ह बार.ह
bar.h	Bar-impl.h baz.h
बार-इंप्लि.एच	बार.ह बाज़.एच
bar.cc	बार.ह बार-इंप्ल.ह बाज़.एच
baz.h	बाज़-इंप्ल॰एच
बाज़-इंप्ल॰एच	baz.h
baz.cc	बाज़.ह बाज़-इंप्ल.एच

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

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

तर्क

विशेषताएं
`name`	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट रूप से `[]` है बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये `cc_library` या `objc_library` हो सकते हैं टारगेट के लिए.
`srcs`	लेबल की सूची; डिफ़ॉल्ट रूप से `[]` है टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें हैं. ये फ़ाइलें या तो जनरेट नहीं होती हैं (सामान्य सोर्स) कोड) या जनरेट किया गया हो. सभी `.cc`, `.c`, और `.cpp` फ़ाइलें कंपाइल नहीं किए जाएंगे. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर नाम वाली कोई फ़ाइल कुछ अन्य नियम का `outs`, यह नियम अपने आप उस दूसरे नियम पर निर्भर हो जाएगा. `.h` फ़ाइल को कंपाइल नहीं किया जाएगा, लेकिन वह को इस नियम में सोर्स के हिसाब से शामिल किया जाता है. `.cc` और, दोनों `.h` फ़ाइलों में, सूची में दिए गए हेडर सीधे शामिल किए जा सकते हैं ये `srcs` या इनमें सूचीबद्ध किसी भी नियम के `hdrs` में `deps` तर्क को बदल दिया गया है. सभी `#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 कन्वेंशन के मुताबिक होना चाहिए.
`hdrs`	लेबल की सूची; डिफ़ॉल्ट रूप से `[]` है उन हेडर फ़ाइलों की सूची जिन्हें इन्होंने पब्लिश किया है इस लाइब्रेरी को डिपेंडेंट नियमों में शामिल सोर्स से सीधे तौर पर जोड़ा जाएगा. यह हेडर फ़ाइलों का एलान करने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है लाइब्रेरी के इंटरफ़ेस के बारे में बताता है. इन हेडर को का इस्तेमाल, इस नियम में मौजूद सोर्स से या अलग-अलग नियमों के तहत किया जा सकता है. ऐसे हेडर जिन्हें इस लाइब्रेरी के क्लाइंट द्वारा शामिल नहीं किया जाना चाहिए इसके बजाय, `srcs` एट्रिब्यूट में लिस्ट किया गया है, भले ही वे एक पब्लिश किए गए हेडर के ज़रिए शामिल किया जाता है. "हेडर शामिल करना" देखें चेक कर रहा है".
`additional_compiler_inputs`	लेबल की सूची; डिफ़ॉल्ट रूप से `[]` है ऐसी कोई भी अतिरिक्त फ़ाइल जिसे आप कंपाइलर कमांड लाइन को भेजना चाहें, जैसे कि सैनिटाइज़र उदाहरण के लिए, अनदेखा करने की सूचियां. यहां बताई गई फ़ाइलों को $(location) फ़ंक्शन.
`additional_linker_inputs`	लेबल की सूची; डिफ़ॉल्ट रूप से `[]` है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां एम्बेड किया जा सकता है, ताकि उन्हें बाइनरी टारगेट.
`alwayslink`	बूलियन; `False` डिफ़ॉल्ट है अगर 1 है, तो इस C++ पर निर्भर कोई भी बाइनरी (सीधे तौर पर या किसी अन्य तरीके से) लाइब्रेरी में सूचीबद्ध फ़ाइलों की सभी ऑब्जेक्ट फ़ाइलों से `srcs`, भले ही कुछ में बाइनरी से रेफ़र किया गया कोई सिंबल मौजूद न हो. यह तब उपयोगी होता है, जब आपके कोड को स्पष्ट रूप से कोड द्वारा कॉल नहीं किया जाता है बाइनरी, जैसे कि अगर आपका कोड कुछ कॉलबैक पाने के लिए रजिस्टर होता है कुछ सेवाओं ने उपलब्ध कराया है. अगर हमेशा लिंक Windows पर VS 2017 के साथ काम नहीं करता है, तो इसकी वजह से आम समस्या, कृपया अपने VS 2017 को सबसे नए वर्शन में अपग्रेड करें.
`copts`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है इन विकल्पों को C++ कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के विकल्प पर निर्भर करता है और बोर्न शेल टोकनाइज़ेशन. इस एट्रिब्यूट की हर स्ट्रिंग, दिए गए क्रम में `COPTS` से पहले जोड़ दी जाती है बाइनरी टारगेट को कंपाइल करना. फ़्लैग सिर्फ़ इस टारगेट को इकट्ठा करने के लिए लागू होते हैं, नहीं पर निर्भर नहीं होना चाहिए, इसलिए कहीं भी शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ को फ़ाइल फ़ोल्डर से संबंधित होनी चाहिए, न कि मौजूदा पैकेज से. अगर पैकेज, सुविधा का एलान करता है `no_copts_tokenization`, बॉर्न शेल टोकनाइज़ेशन सिर्फ़ स्ट्रिंग पर लागू होता है जिसमें एक "Make" वैरिएबल.
`defines`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को `-D` के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, सभी नियम लागू कर सकते हैं. बहुत सावधान रहें, क्योंकि दूर तक पहुंचने के लिए. संदेह होने पर, 'तय करें' वैल्यू इसके बजाय, `local_defines` का इस्तेमाल करें.
`implementation_deps`	लेबल की सूची; डिफ़ॉल्ट रूप से `[]` है लाइब्रेरी टारगेट की जाने वाली दूसरी लाइब्रेरी की सूची, इस पर निर्भर करती है. इससे नापसंद करें `deps`, हेडर और इन लाइब्रेरी के पाथ (और उनके सभी ट्रांज़िटिव डिप) का इस्तेमाल सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है, न कि उन लाइब्रेरी के लिए जिन्हें निर्भर है. `implementation_deps` के साथ तय की गई लाइब्रेरी अब भी इसमें लिंक हैं इस लाइब्रेरी पर निर्भर बाइनरी टारगेट. फ़िलहाल, इसका इस्तेमाल cc_लाइब्रेरी तक सीमित किया गया है और उसे फ़्लैग किया गया है `--experimental_cc_implementation_deps`.
`include_prefix`	String; `""` डिफ़ॉल्ट है इस नियम के हेडर के पाथ में जोड़ा जाने वाला प्रीफ़िक्स. अगर नीति को सेट किया जाता है, तो इस नियम के `hdrs` एट्रिब्यूट में मौजूद हेडर को ऐक्सेस किया जा सकता है पर इस एट्रिब्यूट का मान है जो उनके रिपॉज़िटरी-रिलेटिव पाथ से पहले है. इससे पहले `strip_include_prefix` एट्रिब्यूट का प्रीफ़िक्स हटा दिया जाता है उपसर्ग जोड़ा गया है.
`includes`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है कंपाइल लाइन में जोड़े जाने वाले डाइरों को शामिल करने की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. हर स्ट्रिंग, `-isystem` से पहले जोड़ी जाती है और `COPTS` में जोड़ दी जाती है. COPS के उलट, इस नियम के लिए ये फ़्लैग जोड़े जाते हैं और इस पर निर्भर सभी नियमों के लिए बनाया गया है. (ध्यान दें: वे नियम नहीं हैं जिन पर यह निर्भर करता है!) होना ध्यान रखें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. संदेह होने पर, जोड़ें "-मैं" फ़्लैग करने के बजाय 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` को लागू किया जाता है. ऐसा हो सकता है कि कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक हों. जैसे, ऐसी लाइब्रेरी यहां कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे के तौर पर मिलने वाला एक्ज़ीक्यूटेबल अब भी डाइनैमिक होगा लिंक किया गया है, इसलिए सिर्फ़ ज़्यादातर स्थिर है. किसी एक्ज़ीक्यूटेबल को लिंक करने के वास्तव में तीन अलग-अलग तरीके हैं: पूरी तरह से 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`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को `-D` के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, हालाँकि, डिपेंडेंट लोगों के लिए लागू हो सकता है.
`nocopts`	String; `""` डिफ़ॉल्ट है C++ कंपाइलेशन कमांड से मैच करने के विकल्प हटाएं. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन के तौर पर उपलब्ध है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाला कोई भी पहले से मौजूद `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

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

proto_library की सूची C++ कोड जनरेट करने के नियम तय करें.

cc_shared_library

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

cc_shared_library(name, deps, additional_linker_inputs, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, win_def_file)

इससे एक शेयर की गई लाइब्रेरी बनती है.

उदाहरण

cc_shared_library(
    name = "foo_shared",
    deps = [
        ":foo",
    ],
    dynamic_deps = [
        ":bar_shared",
    ],
    additional_linker_inputs = [
        ":foo.lds",
    ],
    user_link_flags = [
        "-Wl,--version-script=$(location :foo.lds)",
    ],
)
cc_library(
    name = "foo",
    srcs = ["foo.cc"],
    hdrs = ["foo.h"],
    deps = [
        ":bar",
        ":baz",
    ],
)
cc_shared_library(
    name = "bar_shared",
    shared_lib_name = "bar.so",
    deps = [":bar"],
)
cc_library(
    name = "bar",
    srcs = ["bar.cc"],
    hdrs = ["bar.h"],
)
cc_library(
    name = "baz",
    srcs = ["baz.cc"],
    hdrs = ["baz.h"],
)

उदाहरण foo_shared में, foo को स्टैटिक रूप से लिंक किया गया है और baz हैं, जो एक ट्रांज़िटिव डिपेंडेंसी है. इस काम नहीं किया लिंक bar क्योंकि यह पहले से ही डायनामिक रूप से bar_shared dynamic_dep.

foo_shared लिंकर स्क्रिप्ट *.lds फ़ाइल का इस्तेमाल करके तय करता है कि किस चिह्न एक्सपोर्ट किए जा सकते हैं. cc_shared_library नियम का तर्क यह करता है यह इस पर कंट्रोल नहीं करता कि कौनसे सिंबल एक्सपोर्ट किए जा सकते हैं. यह सिर्फ़ उन चिह्नों का इस्तेमाल करता है जिन्हें एक्सपोर्ट किया जाता है अगर दो शेयर की गई लाइब्रेरी, टारगेट नहीं किए जा रहे हैं.

सीधे तौर पर होने वाली cc_shared_library की डिपेंडेंसी को यह माना जाता है कि निर्यात किया गया. इसलिए, बेज़ल विश्लेषण के दौरान यह मान लेता है कि 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`	लेबल की सूची; डिफ़ॉल्ट रूप से `[]` है टॉप लेवल लाइब्रेरी, जिन्हें शेयर की गई लाइब्रेरी में बिना किसी शर्त के स्टैटिक तौर पर लिंक किया जाएगा को संग्रहित कर लें. इन डायरेक्ट डिपार्टमेंट की सभी ट्रांज़िटिव लाइब्रेरी डिपेंडेंसी को शेयर किए गए इस डेटा में लिंक कर दिया जाएगा लाइब्रेरी को तभी जोड़ा जा सकता है, जब उसे पहले से किसी `cc_shared_library` से लिंक न किया गया हो `dynamic_deps` में. विश्लेषण के दौरान, नियम लागू होने के दौरान, नीचे दी गई सूची में मौजूद किसी भी टारगेट पर विचार किया जाएगा `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/BUILD में किसी भी टारगेट को पूरा करने के लिए `//foo:__package__` foo/BUILD या किसी दूसरे टारगेट में शामिल टारगेट के लिए `//foo:__subpackages__` foo/ जैसे foo/bar/BUILD के नीचे दिया गया पैकेज
`shared_lib_name`	String; `""` डिफ़ॉल्ट है डिफ़ॉल्ट रूप से, cc_shared_library, शेयर की गई लाइब्रेरी की आउटपुट फ़ाइल के लिए इस आधार पर नाम का इस्तेमाल करेगा टारगेट का नाम और प्लैटफ़ॉर्म. इसमें, एक्सटेंशन और कभी-कभी प्रीफ़िक्स शामिल होते हैं. कभी-कभी ऐसा हो सकता है कि आपको डिफ़ॉल्ट नाम न डालना पड़े. उदाहरण के लिए, जब C++ शेयर की गई लाइब्रेरी लोड हो रही हों Python के लिए डिफ़ॉल्ट 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`	String; `""` डिफ़ॉल्ट है एफ़डीओ प्रोफ़ाइल का ऐब्सलूट पाथ. FDO फ़ाइल में सिर्फ़ .afdo एक्सटेंशन हो सकता है.
`profile`	लेबल; डिफ़ॉल्ट रूप से `None` है एफ़डीओ प्रोफ़ाइल का लेबल या इसे जनरेट करने वाला नियम. FDO फ़ाइल में इनमें से कोई एक हो सकता है नीचे दिए गए एक्सटेंशन: इंडेक्स नहीं की गई एलएलवीएम प्रोफ़ाइल के लिए .profraw, इंडेक्स किए गए LLVM के लिए .profdata प्रोफ़ाइल, .zip, जिसमें LLVM Profraw प्रोफ़ाइल, AutoFDO प्रोफ़ाइल के लिए .afdo, और .xfdo के लिए .xfdo है XBinary प्रोफ़ाइल. यह लेबल किसी 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` या इनमें सूचीबद्ध किसी भी नियम के `hdrs` में `deps` तर्क को बदल दिया गया है. सभी `#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++ कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" के विकल्प पर निर्भर करता है और बोर्न शेल टोकनाइज़ेशन. इस एट्रिब्यूट की हर स्ट्रिंग, दिए गए क्रम में `COPTS` से पहले जोड़ दी जाती है बाइनरी टारगेट को कंपाइल करना. फ़्लैग सिर्फ़ इस टारगेट को इकट्ठा करने के लिए लागू होते हैं, नहीं पर निर्भर नहीं होना चाहिए, इसलिए कहीं भी शामिल की गई हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ को फ़ाइल फ़ोल्डर से संबंधित होनी चाहिए, न कि मौजूदा पैकेज से. अगर पैकेज, सुविधा का एलान करता है `no_copts_tokenization`, बॉर्न शेल टोकनाइज़ेशन सिर्फ़ स्ट्रिंग पर लागू होता है जिसमें एक "Make" वैरिएबल.
`defines`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को `-D` के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, सभी नियम लागू कर सकते हैं. बहुत सावधान रहें, क्योंकि दूर तक पहुंचने के लिए. संदेह होने पर, 'तय करें' वैल्यू इसके बजाय, `local_defines` का इस्तेमाल करें.
`includes`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है कंपाइल लाइन में जोड़े जाने वाले डाइरों को शामिल करने की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. हर स्ट्रिंग, `-isystem` से पहले जोड़ी जाती है और `COPTS` में जोड़ दी जाती है. COPS के उलट, इस नियम के लिए ये फ़्लैग जोड़े जाते हैं और इस पर निर्भर सभी नियमों के लिए बनाया गया है. (ध्यान दें: वे नियम नहीं हैं जिन पर यह निर्भर करता है!) होना ध्यान रखें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. संदेह होने पर, जोड़ें "-मैं" फ़्लैग करने के बजाय 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++ लिंकर कमांड में जोड़ें. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन, बॉर्न शेल टोकनाइज़ेशन और लेबल एक्सपैंशन. इस एट्रिब्यूट की हर स्ट्रिंग को पहले `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`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन और बोर्न शेल टोकनाइज़ेशन. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए. को `-D` के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, हालाँकि, डिपेंडेंट लोगों के लिए लागू हो सकता है.
`malloc`	लेबल; डिफ़ॉल्ट रूप से `"@bazel_tools//tools/cpp:malloc"` है मॉलोक पर डिफ़ॉल्ट डिपेंडेंसी बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी को `//tools/cpp:malloc` से लिंक किया जाता है, यह एक खाली लाइब्रेरी है. इसलिए, बाइनरी फ़ाइल के आखिर में libc मैलडॉक का इस्तेमाल किया जाता है. यह लेबल किसी `cc_library` से जुड़ा होना चाहिए. अगर कंपाइलेशन बिना C++ वाली नियम के तहत, इस विकल्प का कोई असर नहीं पड़ता. इस एट्रिब्यूट की वैल्यू को अनदेखा कर दिया जाता है, अगर `linkshared=True` बताया गया है.
`nocopts`	String; `""` डिफ़ॉल्ट है C++ कंपाइलेशन कमांड से मैच करने के विकल्प हटाएं. "बनाएं" पर निर्भर करता है वैरिएबल सब्सिट्यूशन के तौर पर उपलब्ध है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन माना जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाला कोई भी पहले से मौजूद `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 एट्रिब्यूट का इस्तेमाल करें. इसे भी देखें पेज पढ़ें.

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

तर्क

विशेषताएं
`name`	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
`all_files`	लेबल; आवश्यक सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. इन आर्टफ़ैक्ट को इनपुट के तौर पर सभी रूल_सीसी से जुड़ी कार्रवाइयां (उन कार्रवाइयों को छोड़कर जो इसके ज़्यादा सटीक सेट का इस्तेमाल करती हैं आर्टफ़ैक्ट के बारे में ज़्यादा जानें). बेज़ल यह मानता है कि `all_files` एक सुपरसेट है आर्टफ़ैक्ट देने वाले दूसरे सभी एट्रिब्यूट शामिल हैं.उदाहरण के लिए, linkstamp को कंपाइल करना ज़रूरी है. इसके लिए, और लिंक फ़ाइलें, इसलिए इसमें `all_files` लगता है). `cc_toolchain.files` में यही कॉन्टेंट होता है और सभी Starlark इसका इस्तेमाल करते हैं C++ टूलचेन का इस्तेमाल करने के नियम तय करते हैं.
`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 आर्टफ़ैक्ट का कलेक्शन. अगर इसके बारे में नहीं बताया गया है, सभी फ़ाइलों का इस्तेमाल किया जाता है.
`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`	लेबल; आवश्यक objकॉपी की कार्रवाइयों के लिए, सभी 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 विकल्पों के आधार पर एक टूलचेन चुनना को भेजा गया.

इसे भी देखें पेज पढ़ें.

तर्क

विशेषताएं

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",
            },
          )