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

C / C++ नियम

नियम

cc_binary
cc_export
cc_library
cc_proto_library
cc_shared_library के बारे में ज़्यादा जानें
fdo_mypage_hints
fdo_profile
प्रॉपेलर_ऑप्टिमाइज़
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, 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 (सिर्फ़ तब बनाया गया, जब साफ़ तौर पर अनुरोध किया गया हो): अगर फ़िक्शन चालू है, तो दूर से डिप्लॉय की गई बाइनरी को डीबग करने के लिए, डीबग की जानकारी देने वाली एक पैकेज फ़ाइल. इसके अलावा: कोई खाली फ़ाइल.

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए खास नाम.
`deps`	`List of labels; optional` बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये `cc_library` या `objc_library` टारगेट हो सकते हैं.
`srcs`	`List of labels; optional` C और C++ फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. ये C/C++ सोर्स और हेडर फ़ाइलें हैं, जो या तो जनरेट नहीं की गई हैं (सामान्य सोर्स कोड) या जनरेट की गई हैं. सभी `.cc`, `.c`, और `.cpp` फ़ाइलें कंपाइल की जाएंगी. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर किसी नाम की फ़ाइल किसी दूसरे नियम के `outs` में है, तो यह नियम अपने-आप उस नियम पर निर्भर करेगा. `.h` फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, इस नियम के तहत इसे शामिल किया जा सकेगा. `.cc` और `.h`, दोनों फ़ाइलों में इन `srcs` में शामिल हेडर शामिल किए जा सकते हैं. इसके अलावा, `deps` आर्ग्युमेंट में दिए गए किसी भी नियम के `hdrs` में सीधे तौर पर हेडर शामिल किए जा सकते हैं. इस नियम के `srcs` एट्रिब्यूट में या `cc_library()` एट्रिब्यूट की गई `hdrs` एट्रिब्यूट में, सभी `#include`d फ़ाइलों के बारे में बताना ज़रूरी है. सुझाई गई स्टाइल, किसी लाइब्रेरी से जुड़े हेडर के लिए है, जिन्हें लाइब्रेरी के `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`	`List of labels; optional` इन फ़ाइलों को C++ लिंक करने वाले निर्देश में भेजें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, कंपाइल की गई Windows .res फ़ाइलें यहां दी जा सकती हैं.
`copts`	`List of strings; optional` इन विकल्पों को C++ कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" विकल्प के तहत और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. बाइनरी टारगेट को कंपाइल करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को `COPTS` में दिए गए क्रम में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट के लिए कंपाइल करते हैं. हालांकि, इसके लिए ये डिपेंडेंसी नहीं होती हैं. इसलिए, हेडर फ़ाइलों में कहीं और शामिल की गई बातों को ध्यान में रखें. सभी पाथ, मौजूदा पैकेज के हिसाब से नहीं, बल्कि फ़ाइल फ़ोल्डर के हिसाब से होने चाहिए. अगर पैकेज में सुविधा `no_copts_tokenization` का एलान होता है, तो बॉर्न शेल टोकन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "मेक" वैरिएबल होता है.
`defines`	`List of strings; optional` कंपाइल लाइन में जोड़ने के लिए तय की गई सूची. "मेक" वैरिएबल के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. हर स्ट्रिंग में एक बोर शेल टोकन होना चाहिए. इसे `-D` से पहले जोड़ा गया है. साथ ही, इस टारगेट पर कंपाइल करने के लिए कमांड लाइन के साथ-साथ, इससे जुड़े हर नियम में इसे जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि हो सकता है कि इसका असर लंबे समय तक रहे. संदिग्ध होने पर, `local_defines` में वैल्यू तय करें.
`includes`	`List of strings; optional` कंपाइल लाइन में जोड़े जाने वाले बॉट की सूची. "वैरिएबल बनाएं" विकल्प के तहत बदलाव करें. हर स्ट्रिंग को `-isystem` से पहले और `COPTS` में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: यह नियमों पर निर्भर नहीं है!) बहुत सावधानी बरतें, क्योंकि हो सकता है कि इसका असर लंबे समय तक रहे. कोई समस्या होने पर, -COPs में "-I" फ़्लैग जोड़ें. हेडर को src या hdrs में जोड़ा जाना चाहिए, नहीं तो कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) होने पर वे निर्भर नियमों में उपलब्ध नहीं होंगे.
`linkopts`	`List of strings; optional` इन फ़्लैग को C++ लिंक करने वाले निर्देश में जोड़ें. "मेक" वैरिएबल के विकल्पों में, बॉर्न शेल टोकनाइज़ेशन और लेबल एक्सपैंशन पर निर्भर करता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को `LINKOPTS` में जोड़ दिया जाता है. इस सूची का हर ऐसा एलिमेंट जो `$` या `-` से शुरू नहीं होता है, उसे `deps` में टारगेट का लेबल माना जाता है. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंक करने के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या `deps` में इसके बारे में जानकारी नहीं दी गई है, तो एक गड़बड़ी की रिपोर्ट की जाती है.
`linkshared`	`Boolean; optional; nonconfigurable; default is False` शेयर की गई लाइब्रेरी बनाएं. इस एट्रिब्यूट को चालू करने के लिए, अपने नियम में `linkshared=True` शामिल करें. डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है. इस फ़्लैग की मौजूदगी का मतलब है कि `-shared` फ़्लैग को `gcc` से जोड़ा जाता है. साथ ही, इस वजह से शेयर की गई लाइब्रेरी, Java प्रोग्राम लोड होने के लिए सही होती है. हालांकि, बिल्ड के लिए इसे कभी भी डिपेंडेंसी बाइनरी से लिंक नहीं किया जाएगा, क्योंकि यह माना जाता है कि cc_binary नियम की मदद से बनी शेयर की गई लाइब्रेरी सिर्फ़ अन्य प्रोग्राम से ही लोड की जाती हैं. इसलिए, इसे cc_library नियम का विकल्प नहीं माना जाना चाहिए. बेहतर तरीके से इस्तेमाल करने के लिए, हमारा सुझाव है कि आप यह तरीका न अपनाएं और `java_library` को इसके बजाय `cc_library` नियमों पर निर्भर करें. अगर आप `linkopts=['-static']` और `linkshared=True`, दोनों को तय करते हैं, तो आपको पूरी तरह से अपने-आप में पूरी इकाई दिखती है. अगर आप `linkstatic=True` और `linkshared=True`, दोनों के बारे में बताते हैं, तो आपको पूरी तरह से सेल्फ़-कंटेन्ड एक यूनिट मिलती है.
`linkstatic`	`Boolean; optional; default is True` `cc_binary` और `cc_test` के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. `cc_library.linkstatic` के लिए नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प `cc_binary` के लिए और बाकियों के लिए चालू होता है. अगर इसे चालू किया गया है और यह एक बाइनरी या टेस्ट है, तो जब भी संभव हो, इस विकल्प से बिल्ड टूल को `.so` के बजाय `.a` के साथ लिंक करने की जानकारी मिलती है. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकती हैं. इनमें वे लाइब्रेरी भी शामिल हैं जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, इस एक्ज़ीक्यूटेबल को डाइनैमिक तौर पर लिंक किया जाता है, इसलिए सिर्फ़ ज़्यादातर स्टैटिक होता है. एक्ज़ीक्यूटेबल को लिंक करने के लिए तीन अलग-अलग तरीके हैं: StatIC के पास पूरी तरह से_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` तय करके चालू किया जाता है. अगर `cc_library()` नियम पर इस्तेमाल किया गया है, तो `linkstatic` एट्रिब्यूट का मतलब अलग है. C++ लाइब्रेरी के लिए, `linkstatic=True` यह बताता है कि सिर्फ़ स्टैटिक लिंक बनाने की अनुमति है. इसलिए, कोई `.so` नहीं बनाया जाएगा. linkstatic=False, स्टैटिक लाइब्रेरी बनने से नहीं रोकता है. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी के बनने की प्रक्रिया को कंट्रोल करना है. अगर `linkstatic=False`, तो बिल्ड टूल, `*.runfiles` इलाके में शेयर की गई लाइब्रेरी पर निर्भर सिमलिंक बनाएगा.
`local_defines`	`List of strings; optional` कंपाइल लाइन में जोड़ने के लिए तय की गई सूची. "मेक" वैरिएबल के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. हर स्ट्रिंग में एक बर्न शेल टोकन होना चाहिए. इसे `-D` से पहले जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंसी में नहीं.
`malloc`	`Label; optional; default is @bazel_tools//tools/cpp:malloc` मैलक पर डिफ़ॉल्ट डिपेंडेंसी को बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी, `//tools/cpp:malloc` के साथ लिंक होती हैं, जो एक खाली लाइब्रेरी है, इसलिए बाइनरी फ़ाइल libc Malloc का इस्तेमाल करके खत्म होती है. यह लेबल `cc_library` से जुड़ा होना चाहिए. अगर कंपाइलेशन किसी गैर-C++ नियम के लिए है, तो इस विकल्प का कोई असर नहीं होता. अगर `linkshared=True` बताया गया है, तो इस एट्रिब्यूट की वैल्यू को नज़रअंदाज़ कर दिया जाता है.
`nocopts`	`String; optional` C++ कंपाइलेशन निर्देश से, मैच करने के विकल्प हटाएं. "मेक" वैरिएबल के विकल्प के तहत. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस नियम को कंपाइल करने के लिए, इस रेगुलर एक्सप्रेशन से मेल खाने वाले किसी भी `COPTS` को `COPTS` से हटा दिया जाएगा. इसमें, नियम के ऑप्टस एट्रिब्यूट में दी गई वैल्यू भी शामिल हैं. इस एट्रिब्यूट की शायद ही कभी ज़रूरत पड़े.
`stamp`	`Integer; optional; default is -1` बिल्ड जानकारी को बाइनरी में एन्कोड करना है या नहीं. जितने तरह के प्लेसमेंट हो सकते हैं उनकी जानकारी यहां दी गई है: `stamp = 1`: `--nostamp` बिल्ड में हमेशा, बिल्ड की जानकारी को बाइनरी फ़ाइल में स्टैंप दें. इस सेटिंग से बचना चाहिए, क्योंकि इससे बाइनरी और इस पर निर्भर किसी भी डाउनस्ट्रीम कार्रवाई के लिए, रिमोट कैशिंग की सुविधा शायद खत्म हो जाए. `stamp = 0` बिल्ड की जानकारी को हमेशा कॉन्सटैंट वैल्यू से बदलें. इससे बिल्ड को कैश मेमोरी में सेव करने का अच्छा तरीका मिलता है. `stamp = -1`: बिल्ड की जानकारी एम्बेड करने की प्रक्रिया को `--[no]stamp` फ़्लैग से कंट्रोल किया जाता है. स्टैंपर की गई बाइनरी को तब तक फिर से नहीं बनाया जाता है, जब तक उनकी डिपेंडेंसी नहीं बदलती.
`win_def_file`	`Label; optional` 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. स्टैटिक या शेयर की गई लाइब्रेरी से लिंक करना
Unix पर:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  shared_library = "libmylib.so",
)

# first will link to libmylib.a
cc_binary(
  name = "first",
  srcs = ["first.cc"],
  deps = [":mylib"],
  linkstatic = 1, # default value
)

# second will link to libmylib.so
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)

Windows पर:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.lib", # A normal static library
  interface_library = "mylib.lib", # An import library for mylib.dll
  shared_library = "mylib.dll",
)

# first will link to libmylib.lib
cc_binary(
  name = "first",
  srcs = ["first.cc"],
  deps = [":mylib"],
  linkstatic = 1, # default value
)

# second will link to mylib.dll through mylib.lib
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)

cc_import में शामिल एट्रिब्यूट की सुविधा है. उदाहरण के लिए:

  cc_import(
  name = "curl_lib",
  hdrs = glob(["vendor/curl/include/curl/*.h"]),
  includes = [ "vendor/curl/include" ],
  shared_library = "vendor/curl/lib/.libs/libcurl.dylib",
)

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए खास नाम.
`deps`	`List of labels; optional` उन अन्य लाइब्रेरी की सूची जिन पर टारगेट निर्भर करता है. ज़्यादातर बिल्ड नियमों से तय की गई सामान्य विशेषताओं पर `deps` के बारे में सामान्य टिप्पणियां देखें.
`hdrs`	`List of labels; optional` इस कंपाइल की गई लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची, डिपेंडेंट नियमों में सीधे तौर पर शामिल की जानी चाहिए.
`alwayslink`	`Boolean; optional; default is False` अगर 1, इस C++ के साथ पहले से कंपाइल की गई लाइब्रेरी पर निर्भर (सीधे तौर पर या किसी दूसरे तरीके से) कोई बाइनरी फ़ाइल, स्टैटिक लाइब्रेरी में संग्रहित की गई सभी ऑब्जेक्ट फ़ाइलों से लिंक कर देगी, भले ही कुछ में बाइनरी से रेफ़र किया गया कोई भी निशान न हो. अगर आपके कोड को बाइनरी कोड से साफ़ तौर पर कॉल नहीं किया जाता है, तो यह काम का होता है. उदाहरण के लिए, अगर आपका कोड कुछ सेवा से मिले कुछ कॉलबैक पाने के लिए रजिस्टर होता है. अगर Windows पर, VS 2017 के साथ हमेशा लिंक काम नहीं करता है, तो किसी सामान्य समस्या की वजह से, VS 2017 को नए वर्शन पर अपग्रेड कर लें.
`interface_library`	`Label; optional` शेयर की गई लाइब्रेरी को जोड़ने के लिए सिंगल इंटरफ़ेस लाइब्रेरी. इन फ़ाइल टाइप का इस्तेमाल किया जा सकता है: `.ifso`, `.tbd`, `.lib`, `.so` या `.dylib`
`shared_library`	`Label; optional` एक कंपाइल की गई शेयर की गई लाइब्रेरी. बेज़ल यह पक्का करता है कि यह उस बाइनरी के लिए उपलब्ध हो जो रनटाइम के दौरान इस पर निर्भर करती है. इन फ़ाइल टाइप का इस्तेमाल किया जा सकता है: `.so`, `.dll` या `.dylib`
`static_library`	`Label; optional` एक ही कंपाइल की गई स्टैटिक लाइब्रेरी. इन फ़ाइल टाइप का इस्तेमाल किया जा सकता है: `.a`, `.pic.a` या `.lib`
`system_provided`	`Boolean; optional; default is False` अगर 1 है, तो यह बताता है कि रनटाइम के दौरान ज़रूरी शेयर की गई लाइब्रेरी, सिस्टम ने उपलब्ध कराई है या नहीं. इस मामले में, `interface_library` तय होना चाहिए और `shared_library` खाली होना चाहिए.

cc_library

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

cc_library(name, deps, srcs, data, hdrs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

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

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

cc_library नियमों के लिए, hdrs के हेडर में लाइब्रेरी का सार्वजनिक इंटरफ़ेस शामिल होता है. इन्हें लाइब्रेरी की hdrs और srcs, दोनों फ़ाइलों से सीधे तौर पर शामिल किया जा सकता है. इसके अलावा, 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	foo.h Bar.h
बार	Bar-impl.h baz.h
बार-इंफ़ॉर्म.h	Bar.h baz.h
बार.सीसी	Bar.h Bar-impl.h baz.h
CANNOT TRANSLATE	baz-impl.h
baz-impl.h	CANNOT TRANSLATE
बाज़ार	baz.h baz-impl.h

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

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

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए खास नाम.
`deps`	`List of labels; optional` बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये `cc_library` या `objc_library` टारगेट हो सकते हैं.
`srcs`	`List of labels; optional` C और C++ फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. ये C/C++ सोर्स और हेडर फ़ाइलें हैं, जो या तो जनरेट नहीं की गई हैं (सामान्य सोर्स कोड) या जनरेट की गई हैं. सभी `.cc`, `.c`, और `.cpp` फ़ाइलें कंपाइल की जाएंगी. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर किसी नाम की फ़ाइल किसी दूसरे नियम के `outs` में है, तो यह नियम अपने-आप उस नियम पर निर्भर करेगा. `.h` फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, इस नियम के तहत इसे शामिल किया जा सकेगा. `.cc` और `.h`, दोनों फ़ाइलों में इन `srcs` में शामिल हेडर शामिल किए जा सकते हैं. इसके अलावा, `deps` आर्ग्युमेंट में दिए गए किसी भी नियम के `hdrs` में सीधे तौर पर हेडर शामिल किए जा सकते हैं. इस नियम के `srcs` एट्रिब्यूट में या `cc_library()` एट्रिब्यूट की गई `hdrs` एट्रिब्यूट में, सभी `#include`d फ़ाइलों के बारे में बताना ज़रूरी है. सुझाई गई स्टाइल, किसी लाइब्रेरी से जुड़े हेडर के लिए है, जिन्हें लाइब्रेरी के `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`	`List of labels; optional` इस लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची, जिन पर निर्भर करने वाले नियमों में सोर्स शामिल करने हैं. यह लाइब्रेरी के इंटरफ़ेस के बारे में जानकारी देने वाली, हेडर फ़ाइलों के बारे में जानकारी देने के लिए, सबसे ज़्यादा पसंदीदा जगह है. इन हेडर को इस नियम या इससे जुड़े नियमों के तहत सोर्स में शामिल करने के लिए उपलब्ध कराया जाएगा. अगर इस लाइब्रेरी के क्लाइंट को हेडर का इस्तेमाल नहीं करना है, तो `srcs` एट्रिब्यूट की जगह इन्हें शामिल किया जाना चाहिए. भले ही, वे पब्लिश किए गए हेडर में शामिल हों. ज़्यादा जानकारी के लिए, "हेडर शामिल करने की जांच" देखें.
`alwayslink`	`Boolean; optional; default is False` अगर 1, तो इस C++ लाइब्रेरी पर निर्भर (सीधे तौर पर या किसी दूसरे तरीके से) कोई भी बाइनरी, `srcs` में मौजूद फ़ाइलों के लिए, सभी ऑब्जेक्ट फ़ाइलों से लिंक करेगा, भले ही कुछ में बाइनरी से रेफ़र किया गया कोई भी निशान न हो. अगर आपके कोड को बाइनरी कोड से साफ़ तौर पर कॉल नहीं किया जाता है, तो यह काम का होता है. उदाहरण के लिए, अगर आपका कोड कुछ सेवा से मिले कुछ कॉलबैक पाने के लिए रजिस्टर होता है. अगर Windows पर, VS 2017 के साथ हमेशा लिंक काम नहीं करता है, तो किसी सामान्य समस्या की वजह से, VS 2017 को नए वर्शन पर अपग्रेड कर लें.
`copts`	`List of strings; optional` इन विकल्पों को C++ कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" विकल्प के तहत और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. बाइनरी टारगेट को कंपाइल करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को `COPTS` में दिए गए क्रम में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट के लिए कंपाइल करते हैं. हालांकि, इसके लिए ये डिपेंडेंसी नहीं होती हैं. इसलिए, हेडर फ़ाइलों में कहीं और शामिल की गई बातों को ध्यान में रखें. सभी पाथ, मौजूदा पैकेज के हिसाब से नहीं, बल्कि फ़ाइल फ़ोल्डर के हिसाब से होने चाहिए. अगर पैकेज में सुविधा `no_copts_tokenization` का एलान होता है, तो बॉर्न शेल टोकन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "मेक" वैरिएबल होता है.
`defines`	`List of strings; optional` कंपाइल लाइन में जोड़ने के लिए तय की गई सूची. "मेक" वैरिएबल के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. हर स्ट्रिंग में एक बोर शेल टोकन होना चाहिए. इसे `-D` से पहले जोड़ा गया है. साथ ही, इस टारगेट पर कंपाइल करने के लिए कमांड लाइन के साथ-साथ, इससे जुड़े हर नियम में इसे जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि हो सकता है कि इसका असर लंबे समय तक रहे. संदिग्ध होने पर, `local_defines` में वैल्यू तय करें.
`implementation_deps`	`List of labels; optional` उन अन्य लाइब्रेरी की सूची जिन पर लाइब्रेरी टारगेट की जाती है. `deps` के उलट, इन लाइब्रेरी और उनके सभी ट्रांज़िटिव पाथ के हेडर का इस्तेमाल, सिर्फ़ इस लाइब्रेरी के संग्रह के लिए किया जाता है, न कि इस पर निर्भर लाइब्रेरी के लिए. `implementation_deps` के साथ तय की गई लाइब्रेरी, अब भी उन बाइनरी टारगेट से लिंक की गई हैं जो इस लाइब्रेरी से जुड़ी हैं. फ़िलहाल, इसे cc_libries तक सीमित किया गया है और इसे `--experimental_cc_implementation_deps` फ़्लैग करता है.
`include_prefix`	`String; optional` इस नियम के हेडर के पाथ में जोड़ा जाने वाला प्रीफ़िक्स. सेट होने पर, इस नियम के `hdrs` एट्रिब्यूट में मौजूद हेडर को ऐक्सेस किया जा सकता है. इस एट्रिब्यूट की वैल्यू, डेटा स्टोर करने की जगह से जुड़े पाथ से पहले जोड़ी जाती है. इस प्रीफ़िक्स को जोड़ने से पहले, `strip_include_prefix` एट्रिब्यूट से जुड़ा प्रीफ़िक्स हटा दिया जाता है.
`includes`	`List of strings; optional` कंपाइल लाइन में जोड़े जाने वाले बॉट की सूची. "वैरिएबल बनाएं" विकल्प के तहत बदलाव करें. हर स्ट्रिंग को `-isystem` से पहले और `COPTS` में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: यह नियमों पर निर्भर नहीं है!) बहुत सावधानी बरतें, क्योंकि हो सकता है कि इसका असर लंबे समय तक रहे. कोई समस्या होने पर, -COPs में "-I" फ़्लैग जोड़ें. हेडर को src या hdrs में जोड़ा जाना चाहिए, नहीं तो कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) होने पर वे निर्भर नियमों में उपलब्ध नहीं होंगे.
`linkopts`	`List of strings; optional` इन फ़्लैग को C++ लिंक करने वाले निर्देश में जोड़ें. "मेक" वैरिएबल के विकल्पों में, बॉर्न शेल टोकनाइज़ेशन और लेबल एक्सपैंशन पर निर्भर करता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को `LINKOPTS` में जोड़ दिया जाता है. इस सूची का हर ऐसा एलिमेंट जो `$` या `-` से शुरू नहीं होता है, उसे `deps` में टारगेट का लेबल माना जाता है. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंक करने के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या `deps` में इसके बारे में जानकारी नहीं दी गई है, तो एक गड़बड़ी की रिपोर्ट की जाती है.
`linkstamp`	`Label; optional` एक साथ कई C++ सोर्स फ़ाइल को कंपाइल और लिंक करने के बाद, फ़ाइनल बाइनरी में लिंक करता है. यह धोखेबाज़ी, बाइनरी में टाइमस्टैंप की जानकारी देने के लिए ज़रूरी है; अगर हमने सोर्स फ़ाइल को आम तौर पर किसी ऑब्जेक्ट फ़ाइल के तौर पर कंपाइल किया है, तो टाइमस्टैंप गलत होगा. लिंकस्टैंप कंपाइलेशन में कंपाइलर फ़्लैग के किसी खास सेट का इस्तेमाल नहीं किया जा सकता है. इसलिए, यह किसी खास हेडर, कंपाइलर के विकल्प या दूसरे बिल्ड वैरिएबल पर निर्भर नहीं होना चाहिए. इस विकल्प की ज़रूरत सिर्फ़ `base` पैकेज में होनी चाहिए.
`linkstatic`	`Boolean; optional; default is False` `cc_binary` और `cc_test` के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. `cc_library.linkstatic` के लिए नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प `cc_binary` के लिए और बाकियों के लिए चालू होता है. अगर इसे चालू किया गया है और यह एक बाइनरी या टेस्ट है, तो जब भी संभव हो, इस विकल्प से बिल्ड टूल को `.so` के बजाय `.a` के साथ लिंक करने की जानकारी मिलती है. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकती हैं. इनमें वे लाइब्रेरी भी शामिल हैं जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, इस एक्ज़ीक्यूटेबल को डाइनैमिक तौर पर लिंक किया जाता है, इसलिए सिर्फ़ ज़्यादातर स्टैटिक होता है. एक्ज़ीक्यूटेबल को लिंक करने के लिए तीन अलग-अलग तरीके हैं: StatIC के पास पूरी तरह से_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` तय करके चालू किया जाता है. अगर `cc_library()` नियम पर इस्तेमाल किया गया है, तो `linkstatic` एट्रिब्यूट का मतलब अलग है. C++ लाइब्रेरी के लिए, `linkstatic=True` यह बताता है कि सिर्फ़ स्टैटिक लिंक बनाने की अनुमति है. इसलिए, कोई `.so` नहीं बनाया जाएगा. linkstatic=False, स्टैटिक लाइब्रेरी बनने से नहीं रोकता है. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी के बनने की प्रक्रिया को कंट्रोल करना है. अगर `linkstatic=False`, तो बिल्ड टूल, `*.runfiles` इलाके में शेयर की गई लाइब्रेरी पर निर्भर सिमलिंक बनाएगा.
`local_defines`	`List of strings; optional` कंपाइल लाइन में जोड़ने के लिए तय की गई सूची. "मेक" वैरिएबल के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. हर स्ट्रिंग में एक बर्न शेल टोकन होना चाहिए. इसे `-D` से पहले जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंसी में नहीं.
`nocopts`	`String; optional` C++ कंपाइलेशन निर्देश से, मैच करने के विकल्प हटाएं. "मेक" वैरिएबल के विकल्प के तहत. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस नियम को कंपाइल करने के लिए, इस रेगुलर एक्सप्रेशन से मेल खाने वाले किसी भी `COPTS` को `COPTS` से हटा दिया जाएगा. इसमें, नियम के ऑप्टस एट्रिब्यूट में दी गई वैल्यू भी शामिल हैं. इस एट्रिब्यूट की शायद ही कभी ज़रूरत पड़े.
`strip_include_prefix`	`String; optional` इस नियम के हेडर के पाथ से अलग करने के लिए प्रीफ़िक्स. सेट होने पर, इस नियम के `hdrs` एट्रिब्यूट में मौजूद हेडर को अपने पाथ में ऐक्सेस किया जा सकता है. इसके लिए, इस प्रीफ़िक्स का इस्तेमाल किया जाता है. अगर यह रिलेटिव पाथ है, तो इसे पैकेज-रिलेटिव पाथ माना जाता है. अगर यह निरपेक्ष सवाल है, तो इसे रिपॉज़िटरी-रिलेटिव पाथ के तौर पर समझा जाता है. इस प्रीफ़िक्स को हटाने के बाद, `include_prefix` एट्रिब्यूट में प्रीफ़िक्स जोड़ा जाता है.
`textual_hdrs`	`List of labels; optional` इस लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची, टेक्स्ट को डिपेंडेंट नियमों में टेक्स्ट के रूप में शामिल की जाती है. यह वह जगह है जहां हेडर फ़ाइलों को खुद से इकट्ठा नहीं किया जा सकता. इसका मतलब है कि मान्य कोड बनाने के लिए, इन्हें अन्य सोर्स फ़ाइलों में टेक्स्ट के रूप में शामिल करना होगा.
`win_def_file`	`Label; optional` 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

Name; required

इस टारगेट के लिए खास नाम.

deps

List of labels; optional

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 को लिंक नहीं करता, क्योंकि यह पहले से ही dynamic_dep bar_shared की मदद से डाइनैमिक तरीके से दिया जा चुका है.

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 डिपेंडेंसी से लिंक न किया जाए. साथ ही, लाइब्रेरी को लिंक करने के लिए, लाइब्रेरी को एक्सपोर्ट करना ज़रूरी है. इससे इमेज को लिंक न करने पर, उस इमेज को सिंबल के साथ दिखाया जा सकेगा. एक और तरीका है, टारगेट को एक्सपोर्ट करने वाली तीसरी लाइब्रेरी को हटाना. तीसरा तरीका है कि अपराधी को LINKABLE_MORE_THAN_ONCE के साथ टैग किया जाए cc_libraryहालांकि, ऐसा कभी-कभी ही होता है. हालांकि, आपको यह पक्का करना होगा कि cc_library को एक से ज़्यादा बार लिंक किया जाए.

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

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

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

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

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

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

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

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

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए खास नाम.
`deps`	`List of labels; optional` टॉप लेवल की लाइब्रेरी, पूरी तरह से संग्रहित होने के बाद, शेयर की गई लाइब्रेरी में बिना किसी शर्त के जुड़ जाएंगी. इन डायरेक्ट डिप का कोई ट्रांज़िशनरी लाइब्रेरी डिफ़रेंस, इस शेयर की गई लाइब्रेरी से तब तक लिंक रहेगा, जब तक कि इसे पहले से ही `dynamic_deps` में किसी `cc_shared_library` से लिंक न किया गया हो. विश्लेषण करने के दौरान, नियम लागू करने का मतलब है कि `deps` में शामिल किसी भी टारगेट को, शेयर की गई लाइब्रेरी से एक्सपोर्ट किया जाएगा. ऐसा इसलिए किया जाता है, ताकि जब `cc_shared_libraries` के एक जैसे टारगेट को एक से ज़्यादा बार एक्सपोर्ट किया जाए, तो गड़बड़ियां दी जा सकें. नियम लागू करने से, लिंकर को यह जानकारी नहीं मिलती कि शेयर किए गए ऑब्जेक्ट से कौनसे सिंबल एक्सपोर्ट किए जाने चाहिए. सोर्स कोड में, लिंकर स्क्रिप्ट या 'किसको दिखे' निर्देशों का इस्तेमाल करते समय, उपयोगकर्ता को इस बात का ध्यान रखना चाहिए. लागू करने पर गड़बड़ियां भी ट्रिगर होंगी. ऐसा तब होता है, जब एक ही लाइब्रेरी को स्टैटिक तौर पर एक से ज़्यादा `cc_shared_library` से जोड़ा गया हो. इससे बचने के लिए `"LINKABLE_MORE_THAN_ONCE"` को `cc_library.tags` में जोड़ें या `cc_library` को शेयर की गई किसी लाइब्रेरी के एक्सपोर्ट के तौर पर जोड़कर दिखाएं, ताकि एक लाइब्रेरी दूसरी लाइब्रेरी से `dynamic_dep` बन सके.
`additional_linker_inputs`	`List of labels; optional` ऐसी अन्य फ़ाइलें जिन्हें आपको लिंक करने वाले को भेजना है, जैसे कि लिंकर स्क्रिप्ट. अगर लिंक करने वाले को इस फ़ाइल के बारे में पता होना है, तो आपको उस लिंकर फ़्लैग को अलग से पास करना होगा. ऐसा करने के लिए, `user_link_flags` एट्रिब्यूट का इस्तेमाल करें.
`dynamic_deps`	`List of labels; optional` ये `cc_shared_library` डिपेंडेंसी हैं जो मौजूदा टारगेट पर निर्भर करती हैं. `cc_shared_library` लागू करने के लिए, `dynamic_deps` की सूची (कुछ समय के लिए (यानी कि `dynamic_deps` का मौजूदा `dynamic_deps`) भी) का इस्तेमाल करके यह तय किया जाएगा कि ट्रांज़िट समय में `deps` के लिए किस `cc_libraries` को नहीं जोड़ा जाना चाहिए, क्योंकि वह पहले से ही किसी अलग `cc_shared_library` से जोड़ा जा रहा है.
`exports_filter`	`List of strings; optional` इस एट्रिब्यूट में उन टारगेट की सूची शामिल है जिन पर मौजूदा शेयर की गई लाइब्रेरी से एक्सपोर्ट करने का दावा किया जाता है. `deps` के टारगेट को पहले ही, शेयर की गई लाइब्रेरी से एक्सपोर्ट किया जा चुका है. इस एट्रिब्यूट का इस्तेमाल, उन टारगेट की सूची बनाने के लिए किया जाना चाहिए जो शेयर की गई लाइब्रेरी से एक्सपोर्ट किए गए हैं. हालांकि, ये `deps` की डिपेंडेंसी डिपेंडेंसी हैं. ध्यान दें कि यह एट्रिब्यूट असल में उन टारगेट में डिपेंडेंसी एज नहीं जोड़ता है. इसके बजाय, डिपेंडेंसी एज `deps` तक बनाया जाना चाहिए. इस एट्रिब्यूट में दी गई एंट्री सिर्फ़ स्ट्रिंग हैं. ध्यान रखें कि इस एट्रिब्यूट में टारगेट रखने पर, यह दावा किया जाता है कि शेयर की गई लाइब्रेरी उस टारगेट से सिंबल एक्सपोर्ट करती है. असल में, `cc_shared_library` लॉजिक, लिंकर को यह नहीं बताता कि कौनसे सिंबल एक्सपोर्ट किए जाने चाहिए. इस सिंटैक्स की अनुमति है: foo/BUILD के किसी भी टारगेट के लिए `//foo:__package__` foo/BUILD में मौजूद किसी भी टारगेट के लिए `//foo:__subpackages__` या foo/Bar/BUILD जैसे किसी अन्य पैकेज के लिए
`shared_lib_name`	`String; optional` cc_shared_library डिफ़ॉल्ट रूप से, शेयर की गई लाइब्रेरी की आउटपुट फ़ाइल का नाम इस्तेमाल करेगी. यह नाम, टारगेट के नाम और प्लैटफ़ॉर्म के हिसाब से होगा. इसमें कोई एक्सटेंशन और कभी-कभी एक प्रीफ़िक्स शामिल होता है. कभी-कभी हो सकता है कि आप डिफ़ॉल्ट नाम न चाहें. उदाहरण के लिए, Python के लिए C++ शेयर की गई लाइब्रेरी लोड करते समय, डिफ़ॉल्ट lib* प्रीफ़िक्स आम तौर पर काम नहीं करता. ऐसे में, इस एट्रिब्यूट का इस्तेमाल करके पसंद के मुताबिक नाम चुना जा सकता है.
`user_link_flags`	`List of strings; optional` लिंक करने वाले को दिया गया कोई भी अतिरिक्त फ़्लैग. उदाहरण के लिए, अतिरिक्त 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`	`Label; optional` Windows DEF फ़ाइल को लिंकर को पास करना होगा. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब Windows टारगेट किया गया प्लैटफ़ॉर्म हो. इसका इस्तेमाल, शेयर की गई लाइब्रेरी को लिंक करने के दौरान सिंबल एक्सपोर्ट करने के लिए किया जा सकता है.

CANNOT TRANSLATE

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

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

Name; required

इस टारगेट के लिए खास नाम.

profile

Label; optional

संकेत वाली प्रोफ़ाइल का लेबल. संकेत फ़ाइल में .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`	`Name; required` इस टारगेट के लिए खास नाम.
`absolute_path_profile`	`String; optional` FDO प्रोफ़ाइल का पूरा पाथ. FDO फ़ाइल में सिर्फ़ .afdo एक्सटेंशन हो सकता है.
`profile`	`Label; optional` एफ़डीओ प्रोफ़ाइल या इसे जनरेट करने वाले नियम का लेबल. FDO फ़ाइल में, इनमें से कोई एक एक्सटेंशन हो सकता है: इंडेक्स नहीं की गई LLVM प्रोफ़ाइल के लिए .profraw, इंडेक्स की गई LLVM प्रोफ़ाइल के लिए .profdata, LLVM प्रोफ़ाइल के लिए .zip, AutoFDO प्रोफ़ाइल के लिए .afdo, XBinary प्रोफ़ाइल के लिए .ffdo लेबल, किसी fdo_absolute_path_profile नियम पर भी ले जा सकता है.
`proto_profile`	`Label; optional` प्रोटोबफ़ प्रोफ़ाइल का लेबल.

प्रोपेलर_ऑप्टिमाइज़

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

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

Name; required

इस टारगेट के लिए खास नाम.

ld_profile

Label; optional

लिंक कार्रवाई को भेजी गई प्रोफ़ाइल का लेबल. इस फ़ाइल का .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, 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`	`Name; required` इस टारगेट के लिए खास नाम.
`deps`	`List of labels; optional` बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये `cc_library` या `objc_library` टारगेट हो सकते हैं.
`srcs`	`List of labels; optional` C और C++ फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. ये C/C++ सोर्स और हेडर फ़ाइलें हैं, जो या तो जनरेट नहीं की गई हैं (सामान्य सोर्स कोड) या जनरेट की गई हैं. सभी `.cc`, `.c`, और `.cpp` फ़ाइलें कंपाइल की जाएंगी. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर किसी नाम की फ़ाइल किसी दूसरे नियम के `outs` में है, तो यह नियम अपने-आप उस नियम पर निर्भर करेगा. `.h` फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, इस नियम के तहत इसे शामिल किया जा सकेगा. `.cc` और `.h`, दोनों फ़ाइलों में इन `srcs` में शामिल हेडर शामिल किए जा सकते हैं. इसके अलावा, `deps` आर्ग्युमेंट में दिए गए किसी भी नियम के `hdrs` में सीधे तौर पर हेडर शामिल किए जा सकते हैं. इस नियम के `srcs` एट्रिब्यूट में या `cc_library()` एट्रिब्यूट की गई `hdrs` एट्रिब्यूट में, सभी `#include`d फ़ाइलों के बारे में बताना ज़रूरी है. सुझाई गई स्टाइल, किसी लाइब्रेरी से जुड़े हेडर के लिए है, जिन्हें लाइब्रेरी के `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`	`List of labels; optional` इन फ़ाइलों को C++ लिंक करने वाले निर्देश में भेजें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, कंपाइल की गई Windows .res फ़ाइलें यहां दी जा सकती हैं.
`copts`	`List of strings; optional` इन विकल्पों को C++ कंपाइलेशन कमांड में जोड़ें. "वैरिएबल बनाएं" विकल्प के तहत और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. बाइनरी टारगेट को कंपाइल करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को `COPTS` में दिए गए क्रम में जोड़ा जाता है. फ़्लैग सिर्फ़ इस टारगेट के लिए कंपाइल करते हैं. हालांकि, इसके लिए ये डिपेंडेंसी नहीं होती हैं. इसलिए, हेडर फ़ाइलों में कहीं और शामिल की गई बातों को ध्यान में रखें. सभी पाथ, मौजूदा पैकेज के हिसाब से नहीं, बल्कि फ़ाइल फ़ोल्डर के हिसाब से होने चाहिए. अगर पैकेज में सुविधा `no_copts_tokenization` का एलान होता है, तो बॉर्न शेल टोकन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "मेक" वैरिएबल होता है.
`defines`	`List of strings; optional` कंपाइल लाइन में जोड़ने के लिए तय की गई सूची. "मेक" वैरिएबल के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. हर स्ट्रिंग में एक बोर शेल टोकन होना चाहिए. इसे `-D` से पहले जोड़ा गया है. साथ ही, इस टारगेट पर कंपाइल करने के लिए कमांड लाइन के साथ-साथ, इससे जुड़े हर नियम में इसे जोड़ा जाता है. बहुत सावधानी बरतें, क्योंकि हो सकता है कि इसका असर लंबे समय तक रहे. संदिग्ध होने पर, `local_defines` में वैल्यू तय करें.
`includes`	`List of strings; optional` कंपाइल लाइन में जोड़े जाने वाले बॉट की सूची. "वैरिएबल बनाएं" विकल्प के तहत बदलाव करें. हर स्ट्रिंग को `-isystem` से पहले और `COPTS` में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: यह नियमों पर निर्भर नहीं है!) बहुत सावधानी बरतें, क्योंकि हो सकता है कि इसका असर लंबे समय तक रहे. कोई समस्या होने पर, -COPs में "-I" फ़्लैग जोड़ें. हेडर को src या hdrs में जोड़ा जाना चाहिए, नहीं तो कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) होने पर वे निर्भर नियमों में उपलब्ध नहीं होंगे.
`linkopts`	`List of strings; optional` इन फ़्लैग को C++ लिंक करने वाले निर्देश में जोड़ें. "मेक" वैरिएबल के विकल्पों में, बॉर्न शेल टोकनाइज़ेशन और लेबल एक्सपैंशन पर निर्भर करता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को `LINKOPTS` में जोड़ दिया जाता है. इस सूची का हर ऐसा एलिमेंट जो `$` या `-` से शुरू नहीं होता है, उसे `deps` में टारगेट का लेबल माना जाता है. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंक करने के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या `deps` में इसके बारे में जानकारी नहीं दी गई है, तो एक गड़बड़ी की रिपोर्ट की जाती है.
`linkstatic`	`Boolean; optional; default is False` `cc_binary` और `cc_test` के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. `cc_library.linkstatic` के लिए नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प `cc_binary` के लिए और बाकियों के लिए चालू होता है. अगर इसे चालू किया गया है और यह एक बाइनरी या टेस्ट है, तो जब भी संभव हो, इस विकल्प से बिल्ड टूल को `.so` के बजाय `.a` के साथ लिंक करने की जानकारी मिलती है. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकती हैं. इनमें वे लाइब्रेरी भी शामिल हैं जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, इस एक्ज़ीक्यूटेबल को डाइनैमिक तौर पर लिंक किया जाता है, इसलिए सिर्फ़ ज़्यादातर स्टैटिक होता है. एक्ज़ीक्यूटेबल को लिंक करने के लिए तीन अलग-अलग तरीके हैं: StatIC के पास पूरी तरह से_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` तय करके चालू किया जाता है. अगर `cc_library()` नियम पर इस्तेमाल किया गया है, तो `linkstatic` एट्रिब्यूट का मतलब अलग है. C++ लाइब्रेरी के लिए, `linkstatic=True` यह बताता है कि सिर्फ़ स्टैटिक लिंक बनाने की अनुमति है. इसलिए, कोई `.so` नहीं बनाया जाएगा. linkstatic=False, स्टैटिक लाइब्रेरी बनने से नहीं रोकता है. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी के बनने की प्रक्रिया को कंट्रोल करना है. अगर `linkstatic=False`, तो बिल्ड टूल, `*.runfiles` इलाके में शेयर की गई लाइब्रेरी पर निर्भर सिमलिंक बनाएगा.
`local_defines`	`List of strings; optional` कंपाइल लाइन में जोड़ने के लिए तय की गई सूची. "मेक" वैरिएबल के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. हर स्ट्रिंग में एक बर्न शेल टोकन होना चाहिए. इसे `-D` से पहले जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंसी में नहीं.
`malloc`	`Label; optional; default is @bazel_tools//tools/cpp:malloc` मैलक पर डिफ़ॉल्ट डिपेंडेंसी को बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी, `//tools/cpp:malloc` के साथ लिंक होती हैं, जो एक खाली लाइब्रेरी है, इसलिए बाइनरी फ़ाइल libc Malloc का इस्तेमाल करके खत्म होती है. यह लेबल `cc_library` से जुड़ा होना चाहिए. अगर कंपाइलेशन किसी गैर-C++ नियम के लिए है, तो इस विकल्प का कोई असर नहीं होता. अगर `linkshared=True` बताया गया है, तो इस एट्रिब्यूट की वैल्यू को नज़रअंदाज़ कर दिया जाता है.
`nocopts`	`String; optional` C++ कंपाइलेशन निर्देश से, मैच करने के विकल्प हटाएं. "मेक" वैरिएबल के विकल्प के तहत. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस नियम को कंपाइल करने के लिए, इस रेगुलर एक्सप्रेशन से मेल खाने वाले किसी भी `COPTS` को `COPTS` से हटा दिया जाएगा. इसमें, नियम के ऑप्टस एट्रिब्यूट में दी गई वैल्यू भी शामिल हैं. इस एट्रिब्यूट की शायद ही कभी ज़रूरत पड़े.
`stamp`	`Integer; optional; default is 0` बिल्ड जानकारी को बाइनरी में एन्कोड करना है या नहीं. जितने तरह के प्लेसमेंट हो सकते हैं उनकी जानकारी यहां दी गई है: `stamp = 1`: `--nostamp` बिल्ड में हमेशा, बिल्ड की जानकारी को बाइनरी फ़ाइल में स्टैंप दें. इस सेटिंग से बचना चाहिए, क्योंकि इससे बाइनरी और इस पर निर्भर किसी भी डाउनस्ट्रीम कार्रवाई के लिए, रिमोट कैशिंग की सुविधा शायद खत्म हो जाए. `stamp = 0` बिल्ड की जानकारी को हमेशा कॉन्सटैंट वैल्यू से बदलें. इससे बिल्ड को कैश मेमोरी में सेव करने का अच्छा तरीका मिलता है. `stamp = -1`: बिल्ड की जानकारी एम्बेड करने की प्रक्रिया को `--[no]stamp` फ़्लैग से कंट्रोल किया जाता है. स्टैंपर की गई बाइनरी को तब तक फिर से नहीं बनाया जाता है, जब तक उनकी डिपेंडेंसी नहीं बदलती.
`win_def_file`	`Label; optional` Windows DEF फ़ाइल को लिंकर को पास करना होगा. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब Windows टारगेट किया गया प्लैटफ़ॉर्म हो. इसका इस्तेमाल, शेयर की गई लाइब्रेरी को लिंक करने के दौरान सिंबल एक्सपोर्ट करने के लिए किया जा सकता है.

cc_toolchain

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

cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler, compiler_files, compiler_files_without_includes, coverage_files, cpu, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, visibility)

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

यह नियम इनके लिए ज़िम्मेदार है:

C++ कार्रवाइयां करने के लिए, सभी आर्टफ़ैक्ट इकट्ठा करना. ऐसा all_files, compiler_files, linker_files या _files से खत्म होने वाले अन्य एट्रिब्यूट जैसे एट्रिब्यूट के ज़रिए किया जाता है. ये आम तौर पर ऐसे सभी फ़ाइल ग्रुप होते हैं जिनमें सभी ज़रूरी फ़ाइलें ग्लोब को फ़ॉर्मैट किया जाता है.
C++ कार्रवाइयों के लिए सही कमांड लाइन जनरेट करना. ऐसा CcToolchainConfigInfo सेवा देने वाली कंपनी की मदद से किया जाता है. इसकी जानकारी नीचे दी गई है.

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

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

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए खास नाम.
`all_files`	`Label; required` सभी cc_toolchain कलाकृतियों का संग्रह. इन आर्टफ़ैक्ट को अलग-अलग नियम से जुड़ी कार्रवाइयों के लिए, इनपुट के तौर पर जोड़ा जाएगा. हालांकि, उन कार्रवाइयों को छोड़कर जो नीचे दी गई विशेषताओं से, आर्टफ़ैक्ट के ज़्यादा सटीक सेट इस्तेमाल करते हैं. बेज़ल का मानना है कि `all_files`, आर्टफ़ैक्ट से जुड़े दूसरे सभी एट्रिब्यूट की सुपरसेट है (जैसे कि linksamp कंपाइलेशन के लिए कंपाइल और लिंक, दोनों फ़ाइलें ज़रूरी हैं, इसलिए इसमें `all_files` लगते हैं). `cc_toolchain.files` में यह शामिल है और इसका इस्तेमाल C++ टूलचेन का इस्तेमाल करके, Starlark के सभी नियमों के लिए किया जाता है.
`ar_files`	`Label; optional` संग्रह की कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain कलाकृतियों का संग्रह.
`as_files`	`Label; optional` असेंबली कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का संग्रह.
`compiler`	`String; optional; nonconfigurable` समर्थन नहीं होना या रुकना. इसके बजाय, `toolchain_identifier` एट्रिब्यूट का इस्तेमाल करें. CROSSTOOL के स्टारलार्क में माइग्रेट किए जाने के बाद यह ग़ैर-ज़रूरी आवाज़ें कम कर देगा. साथ ही, इसे #7075 तक हटा दिया जाएगा. अगर यह नीति सेट है, तो उसे क्रॉसटूल_config.toolchain चुनने में इस्तेमाल किया जाएगा. इसे --सीपीयू बेज़ल विकल्प के मुकाबले प्राथमिकता दी जाएगी.
`compiler_files`	`Label; required` कंपाइल की जाने वाली कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
`compiler_files_without_includes`	`Label; optional` इनपुट डिस्कवरी के साथ काम करने पर, कंपाइल करने के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन (फ़िलहाल, यह सिर्फ़ Google के लिए है).
`coverage_files`	`Label; optional` कवरेज से जुड़ी कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain कलाकृतियों का संग्रह. अगर बताया नहीं गया है, तो all_files का इस्तेमाल किया जाता है.
`cpu`	`String; optional; nonconfigurable` समर्थन नहीं होना या रुकना. इसके बजाय, Toolchain_identifier एट्रिब्यूट का इस्तेमाल करें. CROSSTOOL पर माइग्रेट करने के लिए, Starlark का इस्तेमाल नहीं किया जा सकता के लिए ग़ैर-ज़रूरी आवाज़ें कम की जाएंगी. साथ ही, इन्हें #7075 तक हटा दिया जाएगा. अगर यह नीति सेट है, तो उसे क्रॉसटूल_config.toolchain चुनने में इस्तेमाल किया जाएगा. इसे --सीपीयू बेज़ल विकल्प के मुकाबले प्राथमिकता दी जाएगी.
`dwp_files`	`Label; required` dwp कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain कलाकृतियों का संग्रह.
`dynamic_runtime_lib`	`Label; optional` C++ रनटाइम लाइब्रेरी (उदाहरण के लिए, libstdc++.so) के लिए डाइनैमिक लाइब्रेरी आर्टफ़ैक्ट. इसका इस्तेमाल 'static_link_cpp_runtimes' सुविधा के चालू होने पर, और डिपेंडेंसी को डाइनैमिक तौर पर लिंक किया जाएगा.
`exec_transition_for_inputs`	`Boolean; optional; default is True` ट्रांज़िशन करने के बजाय (जैसे कि डिफ़ॉल्ट रूप से टारगेट प्लैटफ़ॉर्म) exe
`libc_top`	`Label; optional` libc के लिए आर्टफ़ैक्ट का ऐसा संग्रह जिसे कंपाइल/लिंक करने के लिए इनपुट के तौर पर पास किया जाता है.
`linker_files`	`Label; required` लिंक करने की कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain कलाकृतियों का संग्रह.
`module_map`	`Label; optional` मॉड्यूलर बिल्ड के लिए इस्तेमाल किया जाने वाला मॉड्यूल मैप आर्टफ़ैक्ट.
`objcopy_files`	`Label; required` objcopy कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain कलाकृतियों का संग्रह.
`static_runtime_lib`	`Label; optional` C++ रनटाइम लाइब्रेरी (उदाहरण के लिए, libstdc++.a) के लिए स्टैटिक लाइब्रेरी आर्टफ़ैक्ट. इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू हो और हम डिपेंडेंसी को स्टैटिक तौर पर लिंक कर रहे हों.
`strip_files`	`Label; required` स्ट्रिप कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain कलाकृतियों का संग्रह.
`supports_header_parsing`	`Boolean; optional; default is False` जब cc_toolchain हेडर पार्स करने वाली कार्रवाइयों के साथ काम करता है, तब इसे 'सही' पर सेट करें.
`supports_param_files`	`Boolean; optional; default is True` जब cc_toolchain लिंक करने की कार्रवाइयों के लिए पैरामीटर फ़ाइलों का इस्तेमाल करता है, तो इसे 'सही' पर सेट करें.
`toolchain_config`	`Label; required` `cc_toolchain_config_info` से जुड़े नियम का लेबल.
`toolchain_identifier`	`String; optional; nonconfigurable` इस cc_toolchain का मिलान, इससे जुड़े क्रॉसटूल_config.toolchain से करने के लिए आइडेंटिफ़ायर का इस्तेमाल किया जाता है. जब तक समस्या #5380 ठीक नहीं हो जाती, तब तक `cc_toolchain` को `CROSSTOOL.toolchain` से जोड़ने का यह सुझाया गया तरीका है. इसे `toolchain_config` एट्रिब्यूट (#5380) से बदल दिया जाएगा.

cc_toolchain_suite

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

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

C++ टूलचेन के संग्रह को दर्शाता है.

यह नियम इनके लिए ज़िम्मेदार है:

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

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

तर्क

विशेषताएं

name

Name; required

इस टारगेट के लिए खास नाम.

toolchains

Dictionary mapping strings to labels; required; nonconfigurable

"<cpu>" या "<cpu>|<compiler>" स्ट्रिंग को cc_toolchain लेबल से दिखाया गया मैप. अगर "--cpu," और "--compiler" दोनों को "Bel" में पास किया जाता है, तो "<cpu>" का इस्तेमाल --cpu को सिर्फ़ तब किया जाएगा, जब "<cpu>|<compiler>" का इस्तेमाल किया जाएगा. उदाहरण:

          cc_toolchain_suite(
            name = "toolchain",
            toolchains = {
              "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",
              "piii": ":my_cc_toolchain_for_piii_using_default_compiler",
            },
          )