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

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

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

defines

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

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

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

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

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

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

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

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

  • default_static_link सुविधा के साथ StatIC, जिसमें सब कुछ स्टैटिक रूप से लिंक किया जाता है; उदाहरण के लिए, "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

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

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

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

मॉलक पर डिफ़ॉल्ट डिपेंडेंसी को ओवरराइड करें.

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

nocopts

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

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

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

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

इन फ़ाइल टाइप की अनुमति है: .ifso, .tbd, .lib, .so या .dylib

shared_library

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

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

इन फ़ाइल टाइप की अनुमति है: .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)

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

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

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

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

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

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

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

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

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

फ़ाइल शामिल हैशामिल करने की अनुमति है
foo.hbar.h
foo.ccfoo.h bar.h
bar.hBar-impl.h baz.h
बार-impl.hBar.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 में मौजूद किसी भी हेडर फ़ाइल को ट्रांज़िटिव deps बंद होने पर, किसी भी cc_library में ट्रांज़िशन के लिए शामिल किया जा सकता है. इस मामले में, foo.cc को कंपाइल करते समय कंपाइलर baz.h और baz-impl.h पढ़ सकता है. हालांकि, foo.cc में #include "baz.h" नहीं होना चाहिए. इसकी अनुमति के लिए, baz को foo के deps में जोड़ना ज़रूरी है.

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

तर्क

विशेषताएं
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 कन्वेंशन के हिसाब से अलग-अलग प्रोग्रामिंग भाषाओं को दिखाया जाता है.

hdrs

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

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

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

additional_compiler_inputs

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

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

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

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

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

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

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

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

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

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

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

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

defines

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

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

linkopts

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

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

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

linkstamp

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

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

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

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

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

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

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

  • default_static_link सुविधा के साथ StatIC, जिसमें सब कुछ स्टैटिक रूप से लिंक किया जाता है; उदाहरण के लिए, "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

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

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

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

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

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

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

cc_shared_library

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

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

उदाहरण

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

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

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

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

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

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

गड़बड़ियां

Two shared libraries in dependencies export the same symbols.

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

ऐसा तब होता है, जब दो अलग-अलग 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 में लिंक किया जाएगा. "LINKABLE_MORE_THAN_ONCE" को cc_library.tags में जोड़कर या `cc_library` को, शेयर की गई किसी लाइब्रेरी के एक्सपोर्ट के तौर पर शामिल करके, इस समस्या से बचा जा सकता है, ताकि किसी एक को अन्य लाइब्रेरी का dynamic_dep बनाया जा सके.

additional_linker_inputs

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

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

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

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

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

exports_filter

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

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

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

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

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

foo/BUILD में किसी भी टारगेट के लिए //foo:__package__

foo/BUILD या इससे नीचे के किसी भी पैकेज के लिए //foo:__subpackages__. जैसे- 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 हो. इसका इस्तेमाल, शेयर की गई लाइब्रेरी को लिंक करने के दौरान सिंबल एक्सपोर्ट करने के लिए किया जा सकता है.

fdo_prefetch_hints

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

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

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

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

तर्क

विशेषताएं
name

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

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

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

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

fdo_profile

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

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

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

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

तर्क

विशेषताएं
name

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

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

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

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

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

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

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

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

memprof_profile

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

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

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

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

तर्क

विशेषताएं
name

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

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

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

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

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

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

propeller_optimize

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

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

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

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

तर्क

विशेषताएं
name

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

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

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

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

cc_test

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

तर्क

विशेषताएं
name

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

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

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

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

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

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

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

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

.h फ़ाइल को कंपाइल नहीं किया जाएगा, लेकिन उसे इस नियम में शामिल सोर्स के ज़रिए शामिल करने के लिए उपलब्ध कराया जाएगा. .cc और .h दोनों फ़ाइलों में, इन srcs में या 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++ कंपाइलेशन कमांड में जोड़ें. यह "वैरिएबल बनाएं" से बदल सकते हैं और बॉर्न शेल टोकनाइज़ेशन लागू हो सकता है.

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

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

defines

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

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

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

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

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

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

लेबल; "@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++ लिंकर कमांड में जोड़ें. "बनाएं" वैरिएबल के सब्सिटिट्यूशन, बॉर्न शेल टोकनाइज़ेशन, और लेबल एक्सपैंशन पर निर्भर करता है. इस एट्रिब्यूट की हर स्ट्रिंग को बाइनरी टारगेट को लिंक करने से पहले, LINKOPTS में जोड़ा जाता है.

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

linkstatic

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

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

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

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

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

  • default_static_link सुविधा के साथ StatIC, जिसमें सब कुछ स्टैटिक रूप से लिंक किया जाता है; उदाहरण के लिए, "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

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

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

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

मॉलक पर डिफ़ॉल्ट डिपेंडेंसी को ओवरराइड करें.

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

nocopts

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

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

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

तर्क

विशेषताएं
name

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

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

लेबल; आवश्यक

cc_toolchain के सभी आर्टफ़ैक्ट का कलेक्शन. इन आर्टफ़ैक्ट को रूल_सीसी से जुड़ी सभी कार्रवाइयों में इनपुट के तौर पर जोड़ा जाएगा. उन कार्रवाइयों को छोड़कर जो नीचे दिए गए एट्रिब्यूट से आर्टफ़ैक्ट के ज़्यादा सटीक सेट का इस्तेमाल करती हैं. 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 है

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

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

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

लेबल; आवश्यक

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

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

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

लेबल; आवश्यक

ऑब्जेकॉपी कार्रवाइयों के लिए ज़रूरी सभी 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",
            },
          )