C / C++ नियम

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

नियम

cc_binary

नियम का सोर्स देखें 
cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, nocopts, output_licenses, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

इंप्लिसिट आउटपुट टारगेट

  • name.stripped (सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो): बाइनरी का ऐसा वर्शन जिसमें कुछ सुविधाएं हटाई गई हों. डीबग सिंबल हटाने के लिए, strip -g को बाइनरी पर चलाया जाता है. कमांड लाइन पर, --stripopt=-foo का इस्तेमाल करके स्ट्रिप के अन्य विकल्प दिए जा सकते हैं. यह आउटपुट सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो.
  • name.dwp (सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो): अगर Fission चालू है, तो यह डिबग करने के लिए जानकारी देने वाला पैकेज है. यह रिमोट तौर पर डिप्लॉय की गई बाइनरी को डिबग करने के लिए सही है. अगर ऐसा नहीं है, तो एक खाली फ़ाइल.

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

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

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

बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची.

ये cc_library या objc_library टारगेट हो सकते हैं.
srcs

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

टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें होती हैं. ये जनरेट नहीं की गई (सामान्य सोर्स कोड) या जनरेट की गई हो सकती हैं.

.cc, .c, और .cpp की सभी फ़ाइलें कंपाइल कर दी जाएंगी. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर कोई फ़ाइल किसी दूसरे नियम के outs में है, तो यह नियम अपने-आप उस दूसरे नियम पर निर्भर करेगा.

.h फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, इस नियम में सोर्स के ज़रिए इसे शामिल किया जा सकता है. .cc और .h, दोनों फ़ाइलों में इन srcs में दिए गए हेडर या deps आर्ग्युमेंट में दिए गए किसी भी नियम के hdrs में, हेडर सीधे तौर पर शामिल किए जा सकते हैं.

सभी #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

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

additional_linker_inputs

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

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

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

copts

स्ट्रिंग की सूची; डिफ़ॉल्ट [] है

C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.

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

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

defines

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

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

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

लेबल; डिफ़ॉल्ट "@bazel_tools//tools/cpp:link_extra_lib" है

अतिरिक्त लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल करना.

डिफ़ॉल्ट रूप से, C++ बाइनरी //tools/cpp:link_extra_lib से लिंक होती हैं, जो डिफ़ॉल्ट रूप से लेबल फ़्लैग //tools/cpp:link_extra_libs पर निर्भर करती हैं. फ़्लैग सेट किए बिना, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग को सेट करने पर, वैकल्पिक डिपेंडेंसी को लिंक किया जा सकता है. जैसे, कमज़ोर सिंबल के लिए बदलाव, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के बदले, malloc या --custom_malloc का इस्तेमाल करें). इस एट्रिब्यूट को None पर सेट करने से, यह सुविधा बंद हो जाती है.

linkopts

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

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

linkshared

बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट False है

शेयर की जा सकने वाली लाइब्रेरी बनाएं. इस एट्रिब्यूट को चालू करने के लिए, अपने नियम में linkshared=True शामिल करें. डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है.

इस फ़्लैग के मौजूद होने का मतलब है कि -shared फ़्लैग के साथ gcc को लिंक किया जाता है. साथ ही, इससे मिलने वाली शेयर की गई लाइब्रेरी, Java प्रोग्राम जैसे लोड करने के लिए सही है. हालांकि, इसे कभी भी बिल्ड के मकसद से, डिपेंडेंट बाइनरी से लिंक नहीं किया जाएगा. ऐसा इसलिए माना जाता है, क्योंकि cc_binary नियम के साथ बनाई गई शेयर की गई लाइब्रेरी, सिर्फ़ अन्य प्रोग्राम के ज़रिए मैन्युअल रूप से लोड की जाती हैं. इसलिए, इसे cc_library नियम के विकल्प के तौर पर नहीं माना जाना चाहिए. हमारा सुझाव है कि बड़े पैमाने पर डेटा मैनेज करने के लिए, इस तरीके का इस्तेमाल न करें. इसके बजाय, java_library को cc_library नियमों पर निर्भर रहने दें.

linkopts=['-static'] और linkshared=True, दोनों को तय करने पर, आपको एक ऐसी यूनिट मिलती है जिसमें सभी एलिमेंट मौजूद होते हैं. अगर आपने linkstatic=True और linkshared=True, दोनों का इस्तेमाल किया है, तो आपको एक ऐसी यूनिट मिलेगी जिसमें ज़्यादातर चीज़ें मौजूद होंगी.

linkstatic

बूलियन; डिफ़ॉल्ट तौर पर True

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

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

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

किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं:

  • पूरी तरह से static_link सुविधा के साथ स्टैटआईसी, जिसमें हर चीज़ स्टैटिक रूप से लिंक की गई है; जैसे कि "gcc -static foo.o libbar.a libbaz.a -lm".
    इस मोड को features एट्रिब्यूट में fully_static_link तय करके चालू किया जाता है.
  • STATIC, जिसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है, जैसे कि "gcc foo.o libfoo.a libbaz.a -lm".
    इस मोड को चालू करने के लिए, linkstatic=True डालें.
  • डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाती हैं (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "gcc foo.o libfoo.so libbaz.so -lm".
    यह मोड, linkstatic=False की जानकारी देकर चालू किया जाता है.

अगर linkstatic एट्रिब्यूट का मतलब cc_library() नियम में इस्तेमाल किया गया है, तो उसका अलग मतलब होता है. C++ लाइब्रेरी के लिए, linkstatic=True बताता है कि सिर्फ़ स्टैटिक लिंक करने की अनुमति है, इसलिए कोई .so जनरेट नहीं किया जाएगा. linkstatic=False स्टैटिक लाइब्रेरी को बनने से नहीं रोकता है. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है.

अगर linkstatic=False, तो बिल्ड टूल *.runfiles एरिया में डिपेंडेंट, शेयर की गई लाइब्रेरी के लिए सिमलिंक बनाएगा.

local_defines

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

लेबल; डिफ़ॉल्ट "@bazel_tools//tools/cpp:malloc" है

malloc पर डिफ़ॉल्ट डिपेंडेंसी को बदलें.

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

nocopts

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

C++ कंपाइलेशन कमांड से मैच करने वाले विकल्प हटाएं. "Make" वैरिएबल के बदले इस्तेमाल किया जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस रेगुलर एक्सप्रेशन से मैच करने वाले सभी मौजूदा COPTS (इसमें नियम के copts एट्रिब्यूट में साफ़ तौर पर बताई गई वैल्यू भी शामिल हैं) को इस नियम को कॉम्पाइल करने के लिए, COPTS से हटा दिया जाएगा. इस एट्रिब्यूट की ज़रूरत शायद ही कभी पड़े.
stamp

पूर्णांक; डिफ़ॉल्ट -1 है

बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. जितने तरह के प्लेसमेंट हो सकते हैं उनकी जानकारी यहां दी गई है:
  • stamp = 1: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. ऐसा --nostamp बिल्ड में भी करें. इस सेटिंग का इस्तेमाल नहीं किया जाना चाहिए, क्योंकि इससे बिटरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल नहीं किया जा सकता.
  • stamp = 0: बिल्ड की जानकारी को हमेशा कॉन्सटैंट वैल्यू से बदलें. इससे बिल्ड के अच्छे नतीजों को कैश मेमोरी में सेव किया जाता है.
  • stamp = -1: बाइल्ड की जानकारी को एम्बेड करने की सुविधा, --[no]stamp फ़्लैग से कंट्रोल की जाती है.

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

लेबल; डिफ़ॉल्ट None है

लिंकर को भेजी जाने वाली Windows DEF फ़ाइल.

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

cc_import

नियम का सोर्स देखें 
cc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)

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

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

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  # If alwayslink is turned on,
  # libmylib.a will be forcely linked into any binary that depends on it.
  # alwayslink = 1,
)
2. शेयर की गई लाइब्रेरी (Unix) को लिंक करना 
cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  shared_library = "libmylib.so",
)
3. इंटरफ़ेस लाइब्रेरी (Windows) के साथ शेयर की गई लाइब्रेरी को लिंक करना 
cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is an import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll will be available for runtime
  shared_library = "mylib.dll",
)
4. शेयर की गई लाइब्रेरी को system_provided=True (Windows) से लिंक करना 
cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is an import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll is provided by system environment, for example it can be found in PATH.
  # This indicates that Bazel is not responsible for making mylib.dll available.
  system_provided = 1,
)
5. स्टैटिक या शेयर की गई लाइब्रेरी
से लिंक करना Unix पर: 
cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  shared_library = "libmylib.so",
)

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

# second will link to libmylib.so
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)
Windows पर: 
cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.lib", # A normal static library
  interface_library = "mylib.lib", # An import library for mylib.dll
  shared_library = "mylib.dll",
)

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

# second will link to mylib.dll through mylib.lib
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)
cc_import में 'शामिल करें' एट्रिब्यूट का इस्तेमाल किया जा सकता है. उदाहरण के लिए: 
  cc_import(
  name = "curl_lib",
  hdrs = glob(["vendor/curl/include/curl/*.h"]),
  includes = [ "vendor/curl/include" ],
  shared_library = "vendor/curl/lib/.libs/libcurl.dylib",
)

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

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

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

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

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

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

बूलियन; डिफ़ॉल्ट तौर पर False

अगर 1 है, तो C++ पहले से कंपाइल की गई लाइब्रेरी पर निर्भर (सीधे तौर पर या किसी दूसरे तरीके से) वाली बाइनरी, स्टैटिक लाइब्रेरी में संग्रहित सभी ऑब्जेक्ट फ़ाइलों से लिंक हो जाएगी. भले ही, कुछ में बाइनरी से रेफ़र किया गया कोई सिंबल मौजूद न हो. यह तब काम आता है, जब आपके कोड को बाइनरी में कोड से साफ़ तौर पर कॉल न किया गया हो. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिलने वाला कॉलबैक पाने के लिए रजिस्टर करता है.

अगर Windows पर VS 2017 के साथ alwayslink काम नहीं करता है, तो इसकी वजह जानी-पहचानी समस्या है. कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें.
interface_library

लेबल; डिफ़ॉल्ट None है

शेयर की गई लाइब्रेरी को लिंक करने के लिए, एक इंटरफ़ेस लाइब्रेरी.

इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: .ifso, .tbd, .lib, .so या .dylib

shared_library

लेबल; डिफ़ॉल्ट None है

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

इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: .so, .dll या .dylib

static_library

लेबल; डिफ़ॉल्ट None है

पहले से कंपाइल की गई एक स्टैटिक लाइब्रेरी.

इस्तेमाल किए जा सकने वाले फ़ाइल टाइप: .a, .pic.a या .lib

system_provided

बूलियन; डिफ़ॉल्ट False है

अगर 1 है, तो इसका मतलब है कि रनटाइम के दौरान ज़रूरी शेयर की गई लाइब्रेरी, सिस्टम से मिलती है. इस मामले में, interface_library की वैल्यू दी जानी चाहिए और shared_library खाली होना चाहिए.

cc_library

नियम का सोर्स देखें 
cc_library(name, deps, srcs, data, hdrs, additional_compiler_inputs, additional_linker_inputs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

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

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

cc_library नियमों के लिए, hdrs में मौजूद हेडर में लाइब्रेरी का सार्वजनिक इंटरफ़ेस होता है. साथ ही, इन्हें लाइब्रेरी के hdrs और srcs में मौजूद फ़ाइलों से सीधे तौर पर शामिल किया जा सकता है. इसके अलावा, cc_* नियमों के hdrs और srcs में मौजूद फ़ाइलों से भी इन्हें शामिल किया जा सकता है. ये नियम, अपने deps में लाइब्रेरी की सूची देते हैं. srcs के हेडर, सिर्फ़ लाइब्रेरी के hdrs और srcs की फ़ाइलों से ही शामिल किए जाने चाहिए. यह तय करते समय कि हेडर को hdrs में रखना है या srcs में, आपको यह पूछना चाहिए कि इस लाइब्रेरी के उपभोक्ताओं को इसे सीधे शामिल करने की सुविधा देनी है या नहीं. यह फ़ैसला, प्रोग्रामिंग भाषाओं में public और private के बीच विज़िबिलिटी तय करने के फ़ैसले जैसा ही है.

cc_binary और cc_test नियमों का एक्सपोर्ट किया गया इंटरफ़ेस नहीं होता. इसलिए, इनमें hdrs एट्रिब्यूट भी नहीं होता. बाइनरी या टेस्ट से जुड़े सभी हेडर, srcs में शामिल होने चाहिए.

इन नियमों को दिखाने के लिए, यह उदाहरण देखें. 

cc_binary(
    name = "foo",
    srcs = [
        "foo.cc",
        "foo.h",
    ],
    deps = [":bar"],
)

cc_library(
    name = "bar",
    srcs = [
        "bar.cc",
        "bar-impl.h",
    ],
    hdrs = ["bar.h"],
    deps = [":baz"],
)

cc_library(
    name = "baz",
    srcs = [
        "baz.cc",
        "baz-impl.h",
    ],
    hdrs = ["baz.h"],
)

इस उदाहरण में, सीधे तौर पर शामिल किए जा सकने वाले एलिमेंट की सूची नीचे दी गई टेबल में दी गई है. उदाहरण के लिए, foo.cc में foo.h और bar.h को सीधे तौर पर शामिल किया जा सकता है, लेकिन baz.h को नहीं.

फ़ाइल शामिल करनाशामिल किए जा सकने वाले आइटम
foo.hbar.h
foo.ccfoo.h bar.h
bar.hBar-impl.h baz.h
bar-impl.hbar.h baz.h
bar.ccबार.ह बार-इंप्ल.ह बाज़.एच
baz.hbaz-impl.h
baz-impl.hbaz.h
baz.ccbaz.h baz-impl.h

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

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

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

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

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

बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची.

ये cc_library या objc_library टारगेट हो सकते हैं.
srcs

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

टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें होती हैं. ये जनरेट नहीं की गई (सामान्य सोर्स कोड) या जनरेट की गई हो सकती हैं.

.cc, .c, और .cpp की सभी फ़ाइलें कंपाइल कर दी जाएंगी. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर कोई फ़ाइल किसी दूसरे नियम के outs में है, तो यह नियम अपने-आप उस दूसरे नियम पर निर्भर करेगा.

.h फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, इस नियम में सोर्स के ज़रिए इसे शामिल किया जा सकता है. .cc और .h, दोनों फ़ाइलों में इन srcs में दिए गए हेडर या deps आर्ग्युमेंट में दिए गए किसी भी नियम के hdrs में, हेडर सीधे तौर पर शामिल किए जा सकते हैं.

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

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

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

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

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

hdrs

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

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

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

additional_compiler_inputs

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

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

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

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

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

बूलियन; डिफ़ॉल्ट तौर पर False

अगर 1 है, तो सीधे या किसी अन्य तरीके से इस C++ लाइब्रेरी पर निर्भर रहने वाली कोई भी बाइनरी, srcs में दी गई फ़ाइलों की सभी ऑब्जेक्ट फ़ाइलों को लिंक करेगी. भले ही, कुछ फ़ाइलों में बाइनरी का रेफ़रंस देने वाला कोई सिंबल न हो. यह तब काम आता है, जब आपके कोड को बाइनरी में कोड से साफ़ तौर पर कॉल न किया गया हो. उदाहरण के लिए, अगर आपका कोड किसी सेवा से मिलने वाला कॉलबैक पाने के लिए रजिस्टर करता है.

अगर Windows पर VS 2017 के साथ alwayslink काम नहीं करता है, तो इसकी वजह जानी-पहचानी समस्या है. कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें.
copts

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.

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

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

defines

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

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

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

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

स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है

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

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

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

includes

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

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

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

linkopts

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

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

linkstamp

लेबल; डिफ़ॉल्ट None है

यह तय की गई C++ सोर्स फ़ाइल को साथ-साथ फ़ाइनल बाइनरी में इकट्ठा और लिंक करता है. बाइनरी में टाइमस्टैंप की जानकारी डालने के लिए, यह तरकीब ज़रूरी है. अगर हम सोर्स फ़ाइल को सामान्य तरीके से ऑब्जेक्ट फ़ाइल में कंपाइल करते हैं, तो टाइमस्टैंप गलत होगा. लिंकस्टैम्प कंपाइलर में कंपाइलर फ़्लैग का कोई खास सेट शामिल नहीं हो सकता. इसलिए, यह किसी खास हेडर, कंपाइलर विकल्प या अन्य बिल्ड वैरिएबल पर निर्भर नहीं होना चाहिए. इस विकल्प की ज़रूरत सिर्फ़ base पैकेज में होनी चाहिए.
linkstatic

बूलियन; डिफ़ॉल्ट तौर पर False

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

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

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

किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं:

  • fully_static_link सुविधा के साथ स्टैटिक, जिसमें सब कुछ स्टैटिक तौर पर लिंक किया गया है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm".
    इस मोड को चालू करने के लिए, features एट्रिब्यूट में fully_static_link डालें.
  • STATIC, जिसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है, जैसे कि "gcc foo.o libfoo.a libbaz.a -lm".
    इस मोड को चालू करने के लिए, linkstatic=True डालें.
  • डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाती हैं (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "gcc foo.o libfoo.so libbaz.so -lm".
    यह मोड, linkstatic=False की जानकारी देकर चालू किया जाता है.

linkstatic एट्रिब्यूट का इस्तेमाल, cc_library() नियम के लिए करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, linkstatic=True से पता चलता है कि सिर्फ़ स्टैटिक लिंकिंग की अनुमति है. इसलिए, कोई .so नहीं जनरेट होगा. linkstatic=False से, स्टैटिक लाइब्रेरी बनने से नहीं रोका जाता. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है.

अगर linkstatic=False, तो बिल्ड टूल *.runfiles एरिया में डिपेंडेंट, शेयर की गई लाइब्रेरी के लिए सिमलिंक बनाएगा.

local_defines

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है

C++ कंपाइलेशन कमांड से मैच करने वाले विकल्प हटाएं. "Make" वैरिएबल के बदले इस्तेमाल किया जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस रेगुलर एक्सप्रेशन से मैच करने वाले सभी मौजूदा COPTS (इसमें नियम के copts एट्रिब्यूट में साफ़ तौर पर बताई गई वैल्यू भी शामिल हैं) को इस नियम को कॉम्पाइल करने के लिए, COPTS से हटा दिया जाएगा. इस एट्रिब्यूट की ज़रूरत शायद ही कभी पड़े.
strip_include_prefix

स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है

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

सेट होने पर, इस नियम के hdrs एट्रिब्यूट में मौजूद हेडर को उनके पाथ पर ऐक्सेस किया जा सकता है.

अगर यह रिलेटिव पाथ है, तो इसे पैकेज के हिसाब से लिया जाता है. अगर यह ऐब्सलूट पाथ है, तो इसे रिपॉज़िटरी से रिलेटिव पाथ माना जाता है.

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

textual_hdrs

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

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

यह हेडर फ़ाइलों के बारे में जानकारी देने की जगह है, जिन्हें खुद से कंपाइल नहीं किया जा सकता. इसका मतलब है कि उन्हें दूसरी सोर्स फ़ाइलों में टेक्स्ट के तौर पर हमेशा शामिल करना होगा, ताकि मान्य कोड बनाया जा सके.
win_def_file

लेबल; डिफ़ॉल्ट None है

लिंकर को भेजी जाने वाली Windows DEF फ़ाइल.

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

cc_proto_library

नियम का सोर्स देखें 
cc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

cc_proto_library, .proto फ़ाइलों से C++ कोड जनरेट करता है.

deps, proto_library नियमों पर ले जाना चाहिए.

उदाहरण: 

cc_library(
    name = "lib",
    deps = [":foo_cc_proto"],
)

cc_proto_library(
    name = "foo_cc_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
)

तर्क

विशेषताएं
name

नाम; ज़रूरी है

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

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

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

cc_shared_library

नियम का सोर्स देखें 
cc_shared_library(name, deps, additional_linker_inputs, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, win_def_file)

इससे शेयर की जा सकने वाली लाइब्रेरी बनती है.

उदाहरण

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

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

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

cc_shared_library की हर डायरेक्ट डिपेंडेंसी को एक्सपोर्ट किया गया माना जाता है. इसलिए, विश्लेषण के दौरान Basel यह मान लेता है कि foo को foo_shared एक्सपोर्ट कर रहा है. baz को foo_shared ने एक्सपोर्ट नहीं किया है. exports_filter के साथ मैच होने वाले हर टारगेट को भी एक्सपोर्ट किया जाता है.

उदाहरण में दिया गया हर cc_library, ज़्यादा से ज़्यादा एक cc_shared_library में दिखना चाहिए. अगर हमें baz को भी bar_shared से लिंक करना है, तो हमें baz में tags = ["LINKABLE_MORE_THAN_ONCE"] जोड़ना होगा.

shared_lib_name एट्रिब्यूट की वजह से, bar_shared से जनरेट की गई फ़ाइल का नाम bar.so होगा, न कि libbar.so, जो कि Linux पर डिफ़ॉल्ट रूप से होता है.

गड़बड़ियां

Two shared libraries in dependencies export the same symbols.

ऐसा तब होगा, जब दो अलग-अलग cc_shared_library डिपेंडेंसी के साथ कोई टारगेट बनाया जा रहा हो, जो एक ही टारगेट को एक्सपोर्ट करता हो. इस समस्या को ठीक करने के लिए, आपको cc_shared_library डिपेंडेंसी में से किसी एक में लाइब्रेरी को एक्सपोर्ट होने से रोकना होगा.

ऐसा तब होगा, जब दो अलग-अलग cc_shared_library डिपेंडेंसी के साथ नया cc_shared_library बनाया जा रहा हो, जो एक ही टारगेट को स्टैटिक तौर पर लिंक करते हों. एक्सपोर्ट करने से जुड़ी गड़बड़ी से मिलती-जुलती.

इस समस्या को ठीक करने का एक तरीका यह है कि लाइब्रेरी को किसी cc_shared_library डिपेंडेंसी से लिंक करना बंद कर दिया जाए. साथ ही, जिस व्यक्ति ने अब भी लाइब्रेरी को लिंक किया है उसे लाइब्रेरी एक्सपोर्ट करनी होगी, ताकि जिसने लाइब्रेरी को अनलिंक किया है वह सिंबल देख सके. टारगेट को एक्सपोर्ट करने वाली तीसरी लाइब्रेरी का इस्तेमाल करना भी एक तरीका है. तीसरा तरीका यह है कि समस्या वाले cc_library को LINKABLE_MORE_THAN_ONCE के साथ टैग करें. हालांकि, ऐसा बहुत कम किया जाना चाहिए. साथ ही, आपको यह पक्का करना होगा कि cc_library को एक से ज़्यादा बार लिंक करना वाकई सुरक्षित है.

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

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

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

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

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

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

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

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

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

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

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

टॉप लेवल लाइब्रेरी, जिन्हें पूरी तरह से संग्रहित करने के बाद, शेयर की गई लाइब्रेरी में स्टैटिक तौर पर लिंक किया जाएगा.

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

विश्लेषण के दौरान, नियम लागू करने की प्रोसेस में deps में मौजूद किसी भी टारगेट को शेयर की गई लाइब्रेरी से एक्सपोर्ट किया गया टारगेट माना जाएगा. ऐसा इसलिए किया जाता है, ताकि एक से ज़्यादा cc_shared_libraries एक ही टारगेट को एक्सपोर्ट करने पर गड़बड़ियां दिखें. नियम लागू करने की प्रोसेस में, लिंकर को यह जानकारी नहीं दी जाती कि शेयर किए गए ऑब्जेक्ट से कौनसे सिंबल एक्सपोर्ट किए जाने चाहिए. उपयोगकर्ता को सोर्स कोड में लिंकर स्क्रिप्ट या दिखने की जानकारी के एलान की मदद से, इस बात का ध्यान रखना चाहिए.

जब एक ही लाइब्रेरी को एक से ज़्यादा cc_shared_library में स्टैटिक तौर पर लिंक किया जाता है, तो लागू करने पर गड़बड़ियां भी ट्रिगर होंगी. cc_library.tags में "LINKABLE_MORE_THAN_ONCE" जोड़कर या शेयर की गई किसी लाइब्रेरी के एक्सपोर्ट के तौर पर, `cc_library` को सूची में शामिल करके, इस गड़बड़ी से बचा जा सकता है. इससे, एक को दूसरे का dynamic_dep बनाया जा सकता है.

additional_linker_inputs

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

ऐसी अन्य फ़ाइलें जिन्हें आपको लिंकर को पास करना है. उदाहरण के लिए, लिंकर स्क्रिप्ट. इस फ़ाइल के बारे में जानकारी रखने के लिए, आपको लिंकर के लिए ज़रूरी फ़्लैग को अलग से भेजना होगा. ऐसा करने के लिए, user_link_flags एट्रिब्यूट का इस्तेमाल करें.
dynamic_deps

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

ये cc_shared_library की अन्य डिपेंडेंसी हैं, जिन पर मौजूदा टारगेट निर्भर करता है.

cc_shared_library लागू करने के लिए, dynamic_deps की सूची का इस्तेमाल किया जाएगा.इसमें ट्रांज़िटिव dynamic_deps (यानी मौजूदा टारगेट के dynamic_deps का dynamic_deps) भी शामिल है. इससे यह तय किया जा सकेगा कि ट्रांज़िटिव deps में मौजूद किस cc_libraries को लिंक नहीं किया जाना चाहिए, क्योंकि उन्हें पहले से ही किसी दूसरे cc_shared_library से उपलब्ध कराया गया है.

exports_filter

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

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

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

इस सिंटैक्स का इस्तेमाल किया जा सकता है:

//foo:__package__, foo/BUILD में किसी भी टारगेट को ध्यान में रखते हुए

//foo:__subpackages__, foo/BUILD में मौजूद किसी भी टारगेट या foo/ के नीचे मौजूद किसी भी अन्य पैकेज, जैसे कि foo/bar/BUILD को ध्यान में रखने के लिए
shared_lib_name

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

डिफ़ॉल्ट रूप से, cc_shared_library, टारगेट के नाम और प्लैटफ़ॉर्म के आधार पर, शेयर की गई लाइब्रेरी की आउटपुट फ़ाइल के लिए किसी नाम का इस्तेमाल करेगा. इसमें एक्सटेंशन और कभी-कभी प्रीफ़िक्स भी शामिल होता है. कभी-कभी, आपको डिफ़ॉल्ट नाम नहीं चाहिए. उदाहरण के लिए, Python के लिए C++ शेयर की गई लाइब्रेरी लोड करते समय, अक्सर डिफ़ॉल्ट lib* प्रीफ़िक्स का इस्तेमाल नहीं किया जाता. ऐसे में, कस्टम नाम चुनने के लिए इस एट्रिब्यूट का इस्तेमाल किया जा सकता है.

स्ट्रिंग की सूची; डिफ़ॉल्ट [] है

ऐसे अन्य फ़्लैग जिन्हें शायद आप लिंकर को भेजना चाहें. उदाहरण के लिए, additional_linker_inputs के ज़रिए पास की गई लिंकर स्क्रिप्ट के बारे में लिंकर को बताने के लिए, इनका इस्तेमाल किया जा सकता है: 
         cc_shared_library(
            name = "foo_shared",
            additional_linker_inputs = select({
              "//src/conditions:linux": [
                ":foo.lds",
                ":additional_script.txt",
              ],
              "//conditions:default": []}),
            user_link_flags = select({
              "//src/conditions:linux": [
                "-Wl,-rpath,kittens",
                "-Wl,--version-script=$(location :foo.lds)",
                "-Wl,--script=$(location :additional_script.txt)",
              ],
              "//conditions:default": []}),
              ...
         )
win_def_file

लेबल; डिफ़ॉल्ट None है

लिंकर को भेजी जाने वाली Windows DEF फ़ाइल.

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

cc_static_library

नियम का सोर्स देखें 
cc_static_library(name, deps, tags)
 टारगेट और उनकी ट्रांज़िशन डिपेंडेंसी की सूची से स्टैटिक लाइब्रेरी बनाता है.

नतीजे के तौर पर मिलने वाली स्टैटिक लाइब्रेरी में, deps में दिए गए टारगेट की ऑब्जेक्ट फ़ाइलें होती हैं. साथ ही, उनकी ट्रांज़िटिव डिपेंडेंसी भी होती है. इस लाइब्रेरी में, PIC ऑब्जेक्ट को प्राथमिकता दी जाती है.

आउटपुट ग्रुप

linkdeps

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

linkopts

एक टेक्स्ट फ़ाइल, जिसमें deps में दिए गए टारगेट की सभी ट्रांज़िशन डिपेंडेंसी के लिए, उपयोगकर्ता से मिला linkopts शामिल होता है.

डुप्लीकेट सिंबल

डिफ़ॉल्ट रूप से, cc_static_library नियम यह जांच करता है कि बनाई गई स्टैटिक लाइब्रेरी में कोई डुप्लीकेट सिंबल न हो. अगर ऐसा होता है, तो गड़बड़ी का मैसेज दिखता है और बिल्ड पूरा नहीं होता. इस मैसेज में, डुप्लीकेट सिंबल और उनमें मौजूद ऑब्जेक्ट फ़ाइलों की सूची होती है.

इस जांच को हर टारगेट या हर पैकेज के लिए बंद किया जा सकता है. इसके लिए, features = ["-symbol_check"] सेट करें या --features=-symbol_check की मदद से, इसे पूरी तरह बंद करें.

symbol_check के लिए टूलचेन सहायता

Basel के साथ शिप किए गए C++ टूलचेन अपने-आप कॉन्फ़िगर होने वाले सभी प्लैटफ़ॉर्म पर symbol_check की सुविधा के साथ काम करते हैं. कस्टम टूलचेन इसके लिए, दो में से किसी एक तरीके से मदद कर सकती है:

  • ACTION_NAMES.validate_static_library कार्रवाई को लागू करना और इसे symbol_check सुविधा की मदद से चालू करना. ऐक्शन में सेट किए गए टूल को दो आर्ग्युमेंट के साथ शुरू किया जाता है. पहला आर्ग्युमेंट, डुप्लीकेट सिंबल की जांच करने के लिए स्टैटिक लाइब्रेरी है और दूसरा आर्ग्युमेंट, उस फ़ाइल का पाथ है जिसे जांच पूरी होने पर बनाया जाना चाहिए.
  • symbol_check सुविधा की मदद से, संग्रह करने वाले टूल के फ़्लैग जोड़े जाते हैं. इनकी वजह से, डुप्लीकेट सिंबल पर स्टैटिक लाइब्रेरी बनाने की कार्रवाई पूरी नहीं हो पाती.

तर्क

विशेषताएं
name

नाम; ज़रूरी है

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

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

स्टैटिक लाइब्रेरी में जोड़ने के लिए टारगेट की सूची. इसमें उनकी सभी ट्रांज़िशन डिपेंडेंसी भी शामिल हैं.

जिन डिपेंडेंसी में कोई ऑब्जेक्ट फ़ाइल नहीं होती उन्हें स्टैटिक लाइब्रेरी में शामिल नहीं किया जाता. हालांकि, उनके लेबल को linkdeps आउटपुट ग्रुप की ओर से दी गई फ़ाइल में इकट्ठा किया जाता है.

fdo_prefetch_hints

नियम का सोर्स देखें 
fdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

यह FDO प्रीफ़ेच के सुझावों वाली प्रोफ़ाइल दिखाती है, जो वर्कस्पेस में या किसी तय किए गए सटीक पाथ पर मौजूद होती है. उदाहरण:

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

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

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

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

लेबल; डिफ़ॉल्ट None है

संकेत की प्रोफ़ाइल का लेबल. हिंट फ़ाइल का एक्सटेंशन .afdo होता है यह लेबल, fdo_absolute_path_profile नियम पर भी ले जा सकता है.

fdo_profile

नियम का सोर्स देखें 
fdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)

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

fdo_profile(
    name = "fdo",
    profile = "//path/to/fdo:profile.zip",
)

fdo_profile(
  name = "fdo_abs",
  absolute_path_profile = "/absolute/path/profile.zip",
)

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

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

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

एफ़डीओ प्रोफ़ाइल का ऐब्सलूट पाथ. FDO फ़ाइल में सिर्फ़ .afdo एक्सटेंशन हो सकता है.
profile

लेबल; डिफ़ॉल्ट None है

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

लेबल; डिफ़ॉल्ट None है

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

memprof_profile

नियम का सोर्स देखें 
memprof_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

यह MEMPROF प्रोफ़ाइल दिखाता है, जो वर्कस्पेस में या किसी तय किए गए एब्सोल्यूट पाथ में मौजूद होती है. उदाहरण:

memprof_profile(
    name = "memprof",
    profile = "//path/to/memprof:profile.afdo",
)

memprof_profile(
  name = "memprof_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

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

स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है

MEMPROF प्रोफ़ाइल का ऐब्सलूट पाथ. फ़ाइल में सिर्फ़ .profdata या .zip एक्सटेंशन हो सकता है. साथ ही, ZIP फ़ाइल में memprof.profdata फ़ाइल होनी चाहिए.
profile

लेबल; डिफ़ॉल्ट None है

MEMPROF प्रोफ़ाइल का लेबल. प्रोफ़ाइल में .profdata एक्सटेंशन (इंडेक्स की गई/सिंबल वाली memprof प्रोफ़ाइल के लिए) या .zip एक्सटेंशन होना चाहिए. यह एक्सटेंशन, ऐसी zip फ़ाइल के लिए होता है जिसमें memprof.profdata फ़ाइल शामिल हो. लेबल, fdo_absolute_path_profile नियम पर भी ले जा सकता है.

propeller_optimize

नियम का सोर्स देखें 
propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

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

तर्क

विशेषताएं
name

नाम; ज़रूरी है

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

लेबल; डिफ़ॉल्ट None है

लिंक करने की कार्रवाई में दी गई प्रोफ़ाइल का लेबल. इस फ़ाइल का .txt एक्सटेंशन हो.

cc_test

नियम का सोर्स देखें 
cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, includes, licenses, link_extra_lib, linkopts, linkstatic, local, local_defines, malloc, nocopts, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

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

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

बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची.

ये cc_library या objc_library टारगेट हो सकते हैं.
srcs

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

टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें होती हैं. ये जनरेट नहीं की गई (सामान्य सोर्स कोड) या जनरेट की गई हो सकती हैं.

.cc, .c, और .cpp की सभी फ़ाइलें कंपाइल कर दी जाएंगी. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर कोई फ़ाइल किसी दूसरे नियम के outs में है, तो यह नियम अपने-आप उस दूसरे नियम पर निर्भर करेगा.

.h फ़ाइल को कंपाइल नहीं किया जाएगा. हालांकि, इस नियम में सोर्स के ज़रिए इसे शामिल किया जा सकता है. .cc और .h, दोनों फ़ाइलों में इन srcs में दिए गए हेडर या deps आर्ग्युमेंट में दिए गए किसी भी नियम के hdrs में, हेडर सीधे तौर पर शामिल किए जा सकते हैं.

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

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

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

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

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

additional_linker_inputs

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

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

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

copts

स्ट्रिंग की सूची; डिफ़ॉल्ट [] है

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

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

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

defines

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

स्ट्रिंग की सूची; डिफ़ॉल्ट [] है

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

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

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

लेबल; डिफ़ॉल्ट "@bazel_tools//tools/cpp:link_extra_lib" है

अतिरिक्त लाइब्रेरी को लिंक करने की सुविधा को कंट्रोल करना.

डिफ़ॉल्ट रूप से, C++ बाइनरी //tools/cpp:link_extra_lib से लिंक होती हैं, जो डिफ़ॉल्ट रूप से लेबल फ़्लैग //tools/cpp:link_extra_libs पर निर्भर करती हैं. फ़्लैग सेट किए बिना, यह लाइब्रेरी डिफ़ॉल्ट रूप से खाली होती है. लेबल फ़्लैग को सेट करने पर, वैकल्पिक डिपेंडेंसी को लिंक किया जा सकता है. जैसे, कमज़ोर सिंबल के लिए बदलाव, शेयर की गई लाइब्रेरी फ़ंक्शन के लिए इंटरसेप्टर या खास रनटाइम लाइब्रेरी (malloc के बदले, malloc या --custom_malloc का इस्तेमाल करें). इस एट्रिब्यूट को None पर सेट करने से, यह सुविधा बंद हो जाती है.

linkopts

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

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

linkstatic

बूलियन; डिफ़ॉल्ट तौर पर False

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

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

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

किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं:

  • पूरी तरह से static_link सुविधा के साथ स्टैटआईसी, जिसमें हर चीज़ स्टैटिक रूप से लिंक की गई है; जैसे कि "gcc -static foo.o libbar.a libbaz.a -lm".
    इस मोड को features एट्रिब्यूट में fully_static_link तय करके चालू किया जाता है.
  • STATIC, जिसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है, जैसे कि "gcc foo.o libfoo.a libbaz.a -lm".
    इस मोड को चालू करने के लिए, linkstatic=True डालें.
  • डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाती हैं (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "gcc foo.o libfoo.so libbaz.so -lm".
    यह मोड, linkstatic=False की जानकारी देकर चालू किया जाता है.

linkstatic एट्रिब्यूट का इस्तेमाल, cc_library() नियम के लिए करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, linkstatic=True बताता है कि सिर्फ़ स्टैटिक लिंक करने की अनुमति है, इसलिए कोई .so जनरेट नहीं किया जाएगा. linkstatic=False स्टैटिक लाइब्रेरी को बनने से नहीं रोकता है. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है.

अगर linkstatic=False, तो बिल्ड टूल *.runfiles एरिया में डिपेंडेंट, शेयर की गई लाइब्रेरी के लिए सिमलिंक बनाएगा.

local_defines

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए, कमपाइल करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए.
malloc

लेबल; डिफ़ॉल्ट "@bazel_tools//tools/cpp:malloc" है

मॉलोक पर डिफ़ॉल्ट डिपेंडेंसी बदलें.

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

nocopts

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

C++ कंपाइलेशन कमांड से मैच करने वाले विकल्प हटाएं. "Make" वैरिएबल के बदले इस्तेमाल किया जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन माना जाता है. इस रेगुलर एक्सप्रेशन से मैच करने वाले सभी मौजूदा COPTS (इसमें नियम के copts एट्रिब्यूट में साफ़ तौर पर बताई गई वैल्यू भी शामिल हैं) को इस नियम को कॉम्पाइल करने के लिए, COPTS से हटा दिया जाएगा. इस एट्रिब्यूट की ज़रूरत शायद ही कभी पड़े.
stamp

पूर्णांक; डिफ़ॉल्ट वैल्यू 0 है

बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. वैल्यू, इनमें से कोई हो सकती है:
  • stamp = 1: बिल्ड की जानकारी को हमेशा बाइनरी में ही स्टैंप करें, भले ही --nostamp बिल्ड में ही क्यों न हो. इस सेटिंग का इस्तेमाल नहीं किया जाना चाहिए, क्योंकि इससे बिटरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल नहीं किया जा सकता.
  • stamp = 0: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे, बिल्ड के नतीजे को कैश मेमोरी में सेव करने की सुविधा मिलती है.
  • stamp = -1: बाइल्ड की जानकारी को एम्बेड करने की सुविधा, --[no]stamp फ़्लैग से कंट्रोल की जाती है.

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

लेबल; डिफ़ॉल्ट None है

Windows DEF फ़ाइल, जिसे लिंकर को पास करना है.

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

cc_toolchain

नियम का सोर्स देखें 
cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, visibility)

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

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

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

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

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

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

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

लेबल; ज़रूरी है

cc_toolchain के सभी आर्टफ़ैक्ट का कलेक्शन. इन आर्टफ़ैक्ट को, सभी rules_cc से जुड़ी कार्रवाइयों में इनपुट के तौर पर जोड़ा जाएगा. हालांकि, उन कार्रवाइयों को छोड़कर जो यहां दिए गए एट्रिब्यूट से, आर्टफ़ैक्ट के ज़्यादा सटीक सेट का इस्तेमाल कर रही हैं. Bazel मानता है कि all_files, आर्टफ़ैक्ट उपलब्ध कराने वाले सभी अन्य एट्रिब्यूट का सुपरसेट है. उदाहरण के लिए, लिंकस्टैंप कंपाइलेशन के लिए, इकट्ठा करने और लिंक करने, दोनों तरह की फ़ाइलों की ज़रूरत होती है. इसलिए, इसमें all_files का इस्तेमाल किया जाता है.

cc_toolchain.files में यही कॉन्टेंट होता है. इसका इस्तेमाल, C++ टूलचेन का इस्तेमाल करने वाले सभी Starlark नियमों में किया जाता है.
ar_files

लेबल; डिफ़ॉल्ट None है

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

लेबल; डिफ़ॉल्ट None है

असेंबली ऐक्शन के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
compiler_files

लेबल; ज़रूरी है

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

लेबल; डिफ़ॉल्ट None है

cc_toolchain के सभी आर्टफ़ैक्ट का कलेक्शन, जो संकलन की कार्रवाइयों के लिए ज़रूरी होते हैं. ऐसा तब होता है, जब इनपुट डिस्कवरी की सुविधा काम करती हो. फ़िलहाल, यह सुविधा सिर्फ़ Google के लिए उपलब्ध है.
coverage_files

लेबल; डिफ़ॉल्ट None है

कवरेज ऐक्शन के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. अगर यह जानकारी नहीं दी गई है, तो all_files का इस्तेमाल किया जाता है.
dwp_files

लेबल; ज़रूरी है

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

लेबल; डिफ़ॉल्ट None है

C++ रनटाइम लाइब्रेरी (उदाहरण के लिए, libstdc++.so) के लिए डाइनैमिक लाइब्रेरी आर्टफ़ैक्ट.

इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू हो और हम डाइनैमिक तौर पर डिपेंडेंसी लिंक कर रहे हों.
exec_transition_for_inputs

बूलियन; डिफ़ॉल्ट तौर पर True

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

लेबल; डिफ़ॉल्ट None है

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

लेबल; ज़रूरी है

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

लेबल; डिफ़ॉल्ट None है

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

लेबल; ज़रूरी है

objcopy ऐक्शन के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
static_runtime_lib

लेबल; डिफ़ॉल्ट None है

C++ रनटाइम लाइब्रेरी (उदाहरण के लिए, libstdc++.a) के लिए स्टैटिक लाइब्रेरी आर्टफ़ैक्ट.

इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू हो और हम डिपेंडेंसी को स्टैटिक तौर पर लिंक कर रहे हों.
strip_files

लेबल; ज़रूरी है

स्ट्रिप से जुड़ी कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
supports_header_parsing

बूलियन; डिफ़ॉल्ट तौर पर False

जब cc_toolchain, हेडर पार्स करने की कार्रवाइयों के साथ काम करता है, तो इसे 'सही है' पर सेट करें.
supports_param_files

बूलियन; डिफ़ॉल्ट True है

जब cc_toolchain से लिंक करने की कार्रवाइयों के लिए पैरामीटर फ़ाइलों का इस्तेमाल करने की सुविधा होती है, तो 'सही' पर सेट करें.
toolchain_config

लेबल; ज़रूरी है

cc_toolchain_config_info देने वाले नियम का लेबल.
toolchain_identifier

स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट "" है

इस 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++ के सभी ज़रूरी टूलचेन इकट्ठा करना.
  • Bazel को दिए गए --cpu और --compiler विकल्पों के आधार पर, एक टूलचेन चुनना.

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

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

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

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

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