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 में, सीधे तौर पर हेडर शामिल किए जा सकते हैं.

सभी #included फ़ाइलें, इस नियम के srcs एट्रिब्यूट या रेफ़र किए गए cc_library() के hdrs एट्रिब्यूट में शामिल होनी चाहिए. सुझाई गई स्टाइल, किसी लाइब्रेरी से जुड़े हेडर के लिए है, जिन्हें उस लाइब्रेरी के hdrs एट्रिब्यूट में शामिल किया जाना चाहिए. साथ ही, इस नियम के सोर्स से जुड़े बाकी हेडर को srcs में शामिल किया जाना चाहिए. ज़्यादा जानकारी के लिए, "हेडर शामिल करने की जांच" देखें.

अगर किसी नियम का नाम srcs में है, तो यह नियम अपने-आप उस नियम पर निर्भर करता है. अगर नाम वाले नियम की outs, C या C++ सोर्स फ़ाइलें हैं, तो उन्हें इस नियम के तहत इकट्ठा किया जाता है. अगर वे लाइब्रेरी फ़ाइलें हैं, तो उन्हें आपस में लिंक किया जाता है.

srcs फ़ाइल टाइप की अनुमति है:

  • C और C++ सोर्स फ़ाइलें: .c, .cc, .cpp, .cxx, .c++, .C
  • C और C++ हेडर फ़ाइलें: .h, .hh, .hpp, .hxx, .inc, .inl, .H
  • C प्रीप्रोसेसर के साथ असेंबलर: .S
  • संग्रह: .a, .pic.a
  • "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo
  • शेयर की गई लाइब्रेरी, जिसका वर्शन या वर्शन हटाया गया: .so, .so.version
  • ऑब्जेक्ट फ़ाइल: .o, .pic.o

...और उन फ़ाइलों को बनाने वाले किसी भी नियम के बारे में बताता है. अलग-अलग एक्सटेंशन, जीसीसी कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.

additional_linker_inputs

List of labels; optional

इन फ़ाइलों को C++ लिंकर कमांड को भेजें.

उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलें यहां दी जा सकती हैं, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.

copts

List of strings; optional

C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है.

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

अगर पैकेज, सुविधा no_copts_tokenization का एलान करता है, तो बॉर्न शेल टोकन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "मेक" वैरिएबल शामिल होता है.

defines

List of strings; optional

कंपाइल लाइन में जोड़ने के लिए डिफ़ाइन की सूची. यह नीति, "Make" वैरिएबल के रिप्लेसमेंट और बर्न शेल टोकनाइज़ेशन पर निर्भर करती है. हर स्ट्रिंग, जिसमें सिर्फ़ एक बॉर्न शेल टोकन होना चाहिए उसे -D से पहले जोड़ा जाता है. साथ ही, इस टारगेट के साथ-साथ, इस पर निर्भर हर नियम के साथ कंपाइल कमांड लाइन में जोड़ा जाता है. सावधानी बरतें, क्योंकि इसके बहुत बुरे नतीजे हो सकते हैं. अगर आपको नहीं पता कि एमपीएन सही है या नहीं, तो local_defines में वैल्यू जोड़ें.
includes

List of strings; optional

कंपाइल लाइन में जोड़ने के लिए, शामिल की जाने वाली डायरेक्ट्री की सूची.

यह विकल्प "वैरिएबल बनाएं" पर निर्भर करता है. हर स्ट्रिंग को -isystem से पहले जोड़ा जाता है और COPTS में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: वे नियम नहीं जिन पर निर्भर करता है!) सावधानी बरतें, क्योंकि इसके कई गंभीर नतीजे हो सकते हैं. संदेह होने पर, "-I" फ़्लैग को COPTS में जोड़ें.

हेडर को srcs या hdrs में जोड़ना ज़रूरी है. ऐसा न होने पर, कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) होने के दौरान, वे डिपेंडेंट नियमों के लिए उपलब्ध नहीं होंगे.

linkopts

List of strings; optional

इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. यह विकल्प "Make" वैरिएबल के बदले, बॉर्न शेल टोकनाइज़ेशन, और लेबल एक्सपैंशन पर निर्भर करता है. इस एट्रिब्यूट की हर स्ट्रिंग को बाइनरी टारगेट को जोड़ने से पहले, 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 से लिंक करने को कहा जाता है. ऐसा हो सकता है कि कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकें. ठीक वैसे ही, ऐसी लाइब्रेरी जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं होती. इसलिए, एक्ज़ीक्यूटेबल फ़ॉर्मैट अब भी डाइनैमिक तरीके से लिंक किया जाएगा, इसलिए ज़्यादातर स्टैटिक होगा.

एक्ज़ीक्यूटेबल लिंक को लिंक करने के तीन अलग-अलग तरीके हैं:

  • पूरी तरह से_स्टैटिक लिंक की सुविधा के साथ आंकड़े. इस सुविधा में सब कुछ स्टैटिक रूप से लिंक होता है; जैसे, "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

कंपाइल लाइन में जोड़ने के लिए डिफ़ाइन की सूची. यह नीति, "Make" वैरिएबल के रिप्लेसमेंट और बर्न शेल टोकनाइज़ेशन पर निर्भर करती है. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए उसे -D के साथ जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, लेकिन डिपेंडेंट के साथ नहीं.
malloc

Label; optional; default is @bazel_tools//tools/cpp:malloc

यह Malloc पर डिफ़ॉल्ट डिपेंडेंसी को ओवरराइड करता है.

डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:malloc से लिंक किया जाता है. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी, libc मैलक का इस्तेमाल करके खत्म होती है. इस लेबल में cc_library होना चाहिए. अगर कंपाइलेशन बिना C++ नियम के है, तो इस विकल्प से कोई असर नहीं पड़ता. अगर linkshared=True दिया गया है, तो इस एट्रिब्यूट की वैल्यू को नज़रअंदाज़ कर दिया जाता है.

nocopts

String; optional

C++ कंपाइलेशन कमांड से मैच करने के विकल्प हटाएं. "बनाएं" वैरिएबल के विकल्प पर निर्भर करता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर इंटरप्रेट किया जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले पहले से मौजूद सभी COPTS (इसमें नियम के 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, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)

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

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

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  # If alwayslink is turned on,
  # libmylib.a will be forcely linked into any binary that depends on it.
  # alwayslink = 1,
)
2. शेयर की गई लाइब्रेरी (Unix) को लिंक करना 
cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  shared_library = "libmylib.so",
)
3. शेयर की गई लाइब्रेरी को इंटरफ़ेस लाइब्रेरी (Windows) से लिंक करना 
cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is a 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

इस टारगेट के लिए एक खास नाम.
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

पहले से कंपाइल की गई एक शेयर की गई लाइब्रेरी. Bazel पक्का करता है कि रनटाइम के दौरान यह उस बाइनरी के लिए उपलब्ध रहे जो इस पर निर्भर है.

अनुमति वाली फ़ाइल टाइप: .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 में मौजूद फ़ाइलों और deps में लाइब्रेरी को शामिल करने वाले cc_* नियमों में से srcs फ़ाइलों से सीधे तौर पर शामिल किया जा सकता है. 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.hbar.h
foo.ccfoo.h bar.h
bar.hBar-impl.h baz.h
बार-impl.hबार.h baz.h
bar.ccbar.h bar-impl.h baz.h
baz.hbaz-impl.h
baz-impl.hbaz.h
baz.ccbaz.h baz-impl.h

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

फ़िलहाल, Bazel, सीधे तौर पर और ट्रांज़िट स्थिति वाले पेजों में अंतर नहीं कर सकता. इसलिए, यह गड़बड़ी के उन मामलों का पता नहीं लगा सकता जिनमें फ़ाइल में गैर-कानूनी तरीके से ऐसा हेडर शामिल हो जिसे सिर्फ़ ट्रांज़िट के दौरान शामिल करने की अनुमति हो. उदाहरण के लिए, अगर ऊपर दिए गए foo.cc उदाहरण में सीधे तौर पर baz.h शामिल है, तो Bazel शिकायत नहीं करेगा. यह गैर-कानूनी होगा, क्योंकि foo सीधे तौर पर baz पर निर्भर नहीं है. फ़िलहाल, ऐसे मामले में कोई गड़बड़ी नहीं होती. हालांकि, आने वाले समय में गड़बड़ी की जांच करने की सुविधा जोड़ी जा सकती है.

तर्क

एट्रिब्यूट
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 में, सीधे तौर पर हेडर शामिल किए जा सकते हैं.

सभी #included फ़ाइलें, इस नियम के srcs एट्रिब्यूट या रेफ़र किए गए cc_library() के hdrs एट्रिब्यूट में शामिल होनी चाहिए. सुझाई गई स्टाइल, किसी लाइब्रेरी से जुड़े हेडर के लिए है, जिन्हें उस लाइब्रेरी के hdrs एट्रिब्यूट में शामिल किया जाना चाहिए. साथ ही, इस नियम के सोर्स से जुड़े बाकी हेडर को srcs में शामिल किया जाना चाहिए. ज़्यादा जानकारी के लिए, "हेडर शामिल करने की जांच" देखें.

अगर किसी नियम का नाम srcs में है, तो यह नियम अपने-आप उस नियम पर निर्भर करता है. अगर नाम वाले नियम की outs, C या C++ सोर्स फ़ाइलें हैं, तो उन्हें इस नियम के तहत इकट्ठा किया जाता है. अगर वे लाइब्रेरी फ़ाइलें हैं, तो उन्हें आपस में लिंक किया जाता है.

srcs फ़ाइल टाइप की अनुमति है:

  • C और C++ सोर्स फ़ाइलें: .c, .cc, .cpp, .cxx, .c++, .C
  • C और C++ हेडर फ़ाइलें: .h, .hh, .hpp, .hxx, .inc, .inl, .H
  • C प्रीप्रोसेसर के साथ असेंबलर: .S
  • संग्रह: .a, .pic.a
  • "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo
  • शेयर की गई लाइब्रेरी, जिसका वर्शन या वर्शन हटाया गया: .so, .so.version
  • ऑब्जेक्ट फ़ाइल: .o, .pic.o

...और उन फ़ाइलों को बनाने वाले किसी भी नियम के बारे में बताता है. अलग-अलग एक्सटेंशन, जीसीसी कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.

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

कंपाइल लाइन में जोड़ने के लिए डिफ़ाइन की सूची. यह नीति, "Make" वैरिएबल के रिप्लेसमेंट और बर्न शेल टोकनाइज़ेशन पर निर्भर करती है. हर स्ट्रिंग, जिसमें सिर्फ़ एक बॉर्न शेल टोकन होना चाहिए उसे -D से पहले जोड़ा जाता है. साथ ही, इस टारगेट के साथ-साथ, इस पर निर्भर हर नियम के साथ कंपाइल कमांड लाइन में जोड़ा जाता है. सावधानी बरतें, क्योंकि इसके बहुत बुरे नतीजे हो सकते हैं. अगर आपको नहीं पता कि एमपीएन सही है या नहीं, तो local_defines में वैल्यू जोड़ें.
implementation_deps

List of labels; optional

ऐसी दूसरी लाइब्रेरी की सूची जिन पर लाइब्रेरी टारगेट की जाती है. deps के उलट, इन लाइब्रेरी के हेडर और शामिल करने वाले पाथ (और इनके सभी ट्रांज़िटिव डिप) का इस्तेमाल सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है. इस लाइब्रेरी पर निर्भर लाइब्रेरी का इस्तेमाल नहीं किया जाता. implementation_deps के साथ तय की गई लाइब्रेरी, अब भी इस लाइब्रेरी पर निर्भर बाइनरी टारगेट में लिंक हैं.

फ़िलहाल, इसका इस्तेमाल cc_libraries तक सीमित है. साथ ही, इसे --experimental_cc_implementation_deps फ़्लैग की मदद से सुरक्षित रखा गया है.
include_prefix

String; optional

इस नियम के हेडर के पाथ में जोड़ा जाने वाला प्रीफ़िक्स.

अगर यह सेट हो जाता है, तो इस नियम के hdrs एट्रिब्यूट में मौजूद हेडर को ऐक्सेस किया जा सकता है. यह वैल्यू, डेटा स्टोर करने की जगह (रिपॉज़िटरी-रिलेटिव पाथ) से पहले जोड़ी गई इस एट्रिब्यूट की वैल्यू होती है.

इस प्रीफ़िक्स को जोड़ने से पहले, strip_include_prefix एट्रिब्यूट में मौजूद प्रीफ़िक्स को हटा दिया जाता है.

includes

List of strings; optional

कंपाइल लाइन में जोड़ने के लिए, शामिल की जाने वाली डायरेक्ट्री की सूची.

यह विकल्प "वैरिएबल बनाएं" पर निर्भर करता है. हर स्ट्रिंग को -isystem से पहले जोड़ा जाता है और COPTS में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: वे नियम नहीं जिन पर निर्भर करता है!) सावधानी बरतें, क्योंकि इसके कई गंभीर नतीजे हो सकते हैं. संदेह होने पर, "-I" फ़्लैग को COPTS में जोड़ें.

हेडर को srcs या hdrs में जोड़ना ज़रूरी है. ऐसा न होने पर, कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) होने के दौरान, वे डिपेंडेंट नियमों के लिए उपलब्ध नहीं होंगे.

linkopts

List of strings; optional

इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. यह विकल्प "Make" वैरिएबल के बदले, बॉर्न शेल टोकनाइज़ेशन, और लेबल एक्सपैंशन पर निर्भर करता है. इस एट्रिब्यूट की हर स्ट्रिंग को बाइनरी टारगेट को जोड़ने से पहले, 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 से लिंक करने को कहा जाता है. ऐसा हो सकता है कि कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकें. ठीक वैसे ही, ऐसी लाइब्रेरी जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं होती. इसलिए, एक्ज़ीक्यूटेबल फ़ॉर्मैट अब भी डाइनैमिक तरीके से लिंक किया जाएगा, इसलिए ज़्यादातर स्टैटिक होगा.

एक्ज़ीक्यूटेबल लिंक को लिंक करने के तीन अलग-अलग तरीके हैं:

  • पूरी तरह से_स्टैटिक लिंक की सुविधा के साथ आंकड़े. इस सुविधा में सब कुछ स्टैटिक रूप से लिंक होता है; जैसे, "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

कंपाइल लाइन में जोड़ने के लिए डिफ़ाइन की सूची. यह नीति, "Make" वैरिएबल के रिप्लेसमेंट और बर्न शेल टोकनाइज़ेशन पर निर्भर करती है. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए उसे -D के साथ जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, लेकिन डिपेंडेंट के साथ नहीं.
nocopts

String; optional

C++ कंपाइलेशन कमांड से मैच करने के विकल्प हटाएं. "बनाएं" वैरिएबल के विकल्प पर निर्भर करता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर इंटरप्रेट किया जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले पहले से मौजूद सभी COPTS (इसमें नियम के 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++ कोड जनरेट करना है.

fdo_prefetch_hints 

fdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

ऐसे एफ़डीओ प्रीफ़ेच संकेत प्रोफ़ाइल के बारे में बताता है जो फ़ाइल फ़ोल्डर में या किसी खास पाथ पर होती है. उदाहरण:

fdo_prefetch_hints(
    name = "hints",
    profile = "//path/to/hints:profile.afdo",
)

fdo_profile(
  name = "hints_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

तर्क

एट्रिब्यूट
name

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 फ़ाइल में, इनमें से कोई एक एक्सटेंशन हो सकता है: इंडेक्स नहीं की गई LLVM प्रोफ़ाइल के लिए .profraw, इंडेक्स की गई LLVM प्रोफ़ाइल के लिए .profdata. ऐसा .zip जिसमें LLVM Profraw प्रोफ़ाइल होती है. इसके अलावा, AutoFDO प्रोफ़ाइल के लिए .afdo का इस्तेमाल किया जा सकता है.
profile

Label; optional

एफ़डीओ प्रोफ़ाइल का लेबल या उसे जनरेट करने वाले नियम का लेबल. FDO फ़ाइल में, इनमें से कोई एक एक्सटेंशन हो सकता है: इंडेक्स नहीं की गई LLVM प्रोफ़ाइल के लिए .profraw, इंडेक्स की गई LLVM प्रोफ़ाइल के लिए .profdata. ऐसा .zip जिसमें LLVM Profraw प्रोफ़ाइल होती है, .afdo AutoFDO प्रोफ़ाइल के लिए, .xfdo, XBinary प्रोफ़ाइल के लिए हो सकता है. यह लेबल fdo_absolute_path_profile नियम को भी दिखा सकता है.
proto_profile

Label; optional

प्रोटोबफ़ प्रोफ़ाइल का लेबल.

propeller_optimize 

propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

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

तर्क

एट्रिब्यूट
name

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 में, सीधे तौर पर हेडर शामिल किए जा सकते हैं.

सभी #included फ़ाइलें, इस नियम के srcs एट्रिब्यूट या रेफ़र किए गए cc_library() के hdrs एट्रिब्यूट में शामिल होनी चाहिए. सुझाई गई स्टाइल, किसी लाइब्रेरी से जुड़े हेडर के लिए है, जिन्हें उस लाइब्रेरी के hdrs एट्रिब्यूट में शामिल किया जाना चाहिए. साथ ही, इस नियम के सोर्स से जुड़े बाकी हेडर को srcs में शामिल किया जाना चाहिए. ज़्यादा जानकारी के लिए, "हेडर शामिल करने की जांच" देखें.

अगर किसी नियम का नाम srcs में है, तो यह नियम अपने-आप उस नियम पर निर्भर करता है. अगर नाम वाले नियम की outs, C या C++ सोर्स फ़ाइलें हैं, तो उन्हें इस नियम के तहत इकट्ठा किया जाता है. अगर वे लाइब्रेरी फ़ाइलें हैं, तो उन्हें आपस में लिंक किया जाता है.

srcs फ़ाइल टाइप की अनुमति है:

  • C और C++ सोर्स फ़ाइलें: .c, .cc, .cpp, .cxx, .c++, .C
  • C और C++ हेडर फ़ाइलें: .h, .hh, .hpp, .hxx, .inc, .inl, .H
  • C प्रीप्रोसेसर के साथ असेंबलर: .S
  • संग्रह: .a, .pic.a
  • "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo
  • शेयर की गई लाइब्रेरी, जिसका वर्शन या वर्शन हटाया गया: .so, .so.version
  • ऑब्जेक्ट फ़ाइल: .o, .pic.o

...और उन फ़ाइलों को बनाने वाले किसी भी नियम के बारे में बताता है. अलग-अलग एक्सटेंशन, जीसीसी कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.

additional_linker_inputs

List of labels; optional

इन फ़ाइलों को C++ लिंकर कमांड को भेजें.

उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलें यहां दी जा सकती हैं, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके.

copts

List of strings; optional

C++ कंपाइलेशन कमांड में इन विकल्पों को जोड़ें. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है.

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

अगर पैकेज, सुविधा no_copts_tokenization का एलान करता है, तो बॉर्न शेल टोकन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "मेक" वैरिएबल शामिल होता है.

defines

List of strings; optional

कंपाइल लाइन में जोड़ने के लिए डिफ़ाइन की सूची. यह नीति, "Make" वैरिएबल के रिप्लेसमेंट और बर्न शेल टोकनाइज़ेशन पर निर्भर करती है. हर स्ट्रिंग, जिसमें सिर्फ़ एक बॉर्न शेल टोकन होना चाहिए उसे -D से पहले जोड़ा जाता है. साथ ही, इस टारगेट के साथ-साथ, इस पर निर्भर हर नियम के साथ कंपाइल कमांड लाइन में जोड़ा जाता है. सावधानी बरतें, क्योंकि इसके बहुत बुरे नतीजे हो सकते हैं. अगर आपको नहीं पता कि एमपीएन सही है या नहीं, तो local_defines में वैल्यू जोड़ें.
includes

List of strings; optional

कंपाइल लाइन में जोड़ने के लिए, शामिल की जाने वाली डायरेक्ट्री की सूची.

यह विकल्प "वैरिएबल बनाएं" पर निर्भर करता है. हर स्ट्रिंग को -isystem से पहले जोड़ा जाता है और COPTS में जोड़ा जाता है. COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: वे नियम नहीं जिन पर निर्भर करता है!) सावधानी बरतें, क्योंकि इसके कई गंभीर नतीजे हो सकते हैं. संदेह होने पर, "-I" फ़्लैग को COPTS में जोड़ें.

हेडर को srcs या hdrs में जोड़ना ज़रूरी है. ऐसा न होने पर, कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) होने के दौरान, वे डिपेंडेंट नियमों के लिए उपलब्ध नहीं होंगे.

linkopts

List of strings; optional

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

इस सूची का हर वह एलिमेंट जो $ या - से शुरू नहीं होता है उसे deps में टारगेट का लेबल माना जाता है. टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या deps में इसका एलान नहीं किया गया है, तो गड़बड़ी की रिपोर्ट की जाती है.

linkstatic

Boolean; optional; default is False

cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: नीचे देखें.

डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू और बाकी के लिए बंद रहता है.

अगर यह नीति चालू है और यह बाइनरी या टेस्ट है, तो इस विकल्प की मदद से बिल्ड टूल को उपयोगकर्ता लाइब्रेरी के लिए .so के बजाय, .a से लिंक करने को कहा जाता है. ऐसा हो सकता है कि कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकें. ठीक वैसे ही, ऐसी लाइब्रेरी जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं होती. इसलिए, एक्ज़ीक्यूटेबल फ़ॉर्मैट अब भी डाइनैमिक तरीके से लिंक किया जाएगा, इसलिए ज़्यादातर स्टैटिक होगा.

एक्ज़ीक्यूटेबल लिंक को लिंक करने के तीन अलग-अलग तरीके हैं:

  • पूरी तरह से_स्टैटिक लिंक की सुविधा के साथ आंकड़े. इस सुविधा में सब कुछ स्टैटिक रूप से लिंक होता है; जैसे, "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

कंपाइल लाइन में जोड़ने के लिए डिफ़ाइन की सूची. यह नीति, "Make" वैरिएबल के रिप्लेसमेंट और बर्न शेल टोकनाइज़ेशन पर निर्भर करती है. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए उसे -D के साथ जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है, लेकिन डिपेंडेंट के साथ नहीं.
malloc

Label; optional; default is @bazel_tools//tools/cpp:malloc

यह Malloc पर डिफ़ॉल्ट डिपेंडेंसी को ओवरराइड करता है.

डिफ़ॉल्ट रूप से, C++ बाइनरी को //tools/cpp:malloc से लिंक किया जाता है. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी, libc मैलक का इस्तेमाल करके खत्म होती है. इस लेबल में cc_library होना चाहिए. अगर कंपाइलेशन बिना C++ नियम के है, तो इस विकल्प से कोई असर नहीं पड़ता. अगर linkshared=True दिया गया है, तो इस एट्रिब्यूट की वैल्यू को नज़रअंदाज़ कर दिया जाता है.

nocopts

String; optional

C++ कंपाइलेशन कमांड से मैच करने के विकल्प हटाएं. "बनाएं" वैरिएबल के विकल्प पर निर्भर करता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर इंटरप्रेट किया जाता है. इस रेगुलर एक्सप्रेशन से मेल खाने वाले पहले से मौजूद सभी COPTS (इसमें नियम के 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++ टूलचेन कॉन्फ़िगरेशन और टूलचेन चुनने से जुड़े दस्तावेज़ों की पूरी जानकारी के लिए, यह पेज भी देखें.

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

तर्क

एट्रिब्यूट
name

Name; required

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

Label; required

सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. इन आर्टफ़ैक्ट को नियमों_cc से जुड़ी सभी कार्रवाइयों में इनपुट के तौर पर जोड़ा जाएगा. इनमें वे कार्रवाइयां शामिल नहीं हैं जो यहां दिए गए एट्रिब्यूट में मौजूद आर्टफ़ैक्ट के ज़्यादा सटीक सेट का इस्तेमाल करती हैं. Bazel मानता है कि all_files, आर्टफ़ैक्ट देने वाले अन्य सभी एट्रिब्यूट का सुपरसेट है.जैसे, लिंकस्टैंप कंपाइलेशन में फ़ाइलों को कंपाइल और लिंक करने, दोनों की ज़रूरत होती है. इसलिए, इसमें 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 एट्रिब्यूट का इस्तेमाल करें. Starlark पर CROSSTOOL के माइग्रेट होने के बाद, यह कार्रवाई नहीं की जाएगी. इसे #7075 तक हटा दिया जाएगा.

सेट होने पर, इसका इस्तेमाल Crosstool_config.toolchain चुनने के लिए किया जाएगा. इसे --cpu Bazel विकल्प के मुकाबले प्राथमिकता दी जाएगी.
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 एट्रिब्यूट का इस्तेमाल करें. Starlark पर CROSSTOOL के डेटा को माइग्रेट करने के बाद, यह अनुरोध भेजा जाएगा. इसे #7075 तक हटा दिया जाएगा.

सेट होने पर, इसका इस्तेमाल Crosstool_config.toolchain चुनने के लिए किया जाएगा. इसे --cpu Bazel विकल्प के मुकाबले प्राथमिकता दी जाएगी.
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

'सही' पर सेट करें, ताकि कोई ट्रांज़िशन (डिफ़ॉल्ट रूप से, टारगेट प्लैटफ़ॉर्म) के बजाय, exec प्लैटफ़ॉर्म के लिए cc_toolchain में सभी फ़ाइल इनपुट बनाए जा सकें.
libc_top

Label; optional

libc के लिए आर्टफ़ैक्ट का कलेक्शन है, जिसे कार्रवाइयों को कंपाइल/लिंक करने के लिए इनपुट के तौर पर पास किया गया है.
linker_files

Label; required

लिंक करने की कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
module_map

Label; optional

मॉड्यूलर बिल्ड के लिए इस्तेमाल किया जाने वाला मॉड्यूल मैप आर्टफ़ैक्ट.
objcopy_files

Label; required

ऑब्जेकॉपी कार्रवाइयों के लिए ज़रूरी सभी 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 को इससे जुड़े Crosstool_config.toolchain से मैच करने के लिए इस्तेमाल किया जाने वाला आइडेंटिफ़ायर.

जब तक समस्या #5380 ठीक नहीं हो जाती, तब तक cc_toolchain को CROSSTOOL.toolchain से जोड़ने का यही तरीका सुझाया गया है. इसे toolchain_config एट्रिब्यूट (#5380) से बदल दिया जाएगा.

cc_toolchain_suite 

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

C++ टूलचेन के कलेक्शन के बारे में बताता है.

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

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

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

तर्क

एट्रिब्यूट
name

Name; required

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

Dictionary mapping strings to labels; required; nonconfigurable

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

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