तारीख सेव करें: BazelCon 2023, 24 से 25 अक्टूबर तक Google म्यूनिख में होगा! ज़्यादा जानें

C / C++ नियम

समस्या की शिकायत करें स्रोत देखें

नियम

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 एट्रिब्यूट में, सभी #included फ़ाइलों के बारे में बताना ज़रूरी है. सुझाई गई स्टाइल, किसी लाइब्रेरी से जुड़े हेडर के लिए है, जिन्हें लाइब्रेरी के 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,
)

तर्क

विशेषताएं
name

Name; required

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

List of labels; optional

उन अन्य लाइब्रेरी की सूची जिन पर टारगेट निर्भर करता है. ज़्यादातर बिल्ड नियमों से तय की गई सामान्य विशेषताओं पर deps के बारे में सामान्य टिप्पणियां देखें.
hdrs

List of labels; optional

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

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 को नहीं.

इसमें फ़ाइल शामिल हैशामिल किए जाने की अनुमति है
फ़ूबार
foofoo.h Bar.h
बारBar-impl.h baz.h
बार-इंफ़ॉर्म.hBar.h baz.h
बार.सीसीBar.h Bar-impl.h baz.h
CANNOT TRANSLATEbaz-impl.h
baz-impl.hCANNOT TRANSLATE
बाज़ारbaz.h baz-impl.h

शामिल करने के लिए जांच के नियम सिर्फ़ सीधे तौर पर शामिल करने पर लागू होते हैं. ऊपर दिए गए उदाहरण में foo.cc को bar.h शामिल करने की अनुमति है, जिसमें baz.h शामिल हो सकता है, जो baz-impl.h को शामिल करने की अनुमति है. तकनीकी रूप से, .cc फ़ाइल के कंपाइलेशन में, कुछ समय के लिए hdrs या srcs की कोई भी हेडर फ़ाइल, ट्रांज़िटिव deps बंद हो सकती है. इस मामले में, कंपाइलर 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 एट्रिब्यूट में, सभी #included फ़ाइलों के बारे में बताना ज़रूरी है. सुझाई गई स्टाइल, किसी लाइब्रेरी से जुड़े हेडर के लिए है, जिन्हें लाइब्रेरी के 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 एट्रिब्यूट की जगह इन्हें शामिल किया जाना चाहिए. भले ही, वे पब्लिश किए गए हेडर में शामिल हों. ज़्यादा जानकारी के लिए, "हेडर शामिल करने की जांच" देखें.

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++ कोड जनरेट किया जाता है.

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 एट्रिब्यूट में, सभी #included फ़ाइलों के बारे में बताना ज़रूरी है. सुझाई गई स्टाइल, किसी लाइब्रेरी से जुड़े हेडर के लिए है, जिन्हें लाइब्रेरी के 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",
            },
          )