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

defines

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

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

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

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

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

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

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

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

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

linkopts

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

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

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

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

डिफ़ॉल्ट रूप से, C++ बाइनरी //tools/cpp:malloc से लिंक होती हैं. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी libc मैलडॉक का इस्तेमाल करके खत्म होती है. यह लेबल किसी 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 है

पहले से कंपाइल की गई सिंगल शेयर लाइब्रेरी. 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, दोनों फ़ाइलों में सीधे शामिल किया जा सकता है. साथ ही, इन्हें 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.ccफ़ू.ह बार.ह
bar.hBar-impl.h baz.h
बार-इंप्लि.एचबार.ह बाज़.एच
bar.ccबार.ह बार-इंप्ल.ह बाज़.एच
baz.hbaz-impl.h
baz-impl.hbaz.h
baz.ccबाज़.ह बाज़-इंप्ल.एच

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

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

defines

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

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

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

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

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

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

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

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

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

local_defines

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

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

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

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 से लिंक करना चाहते, तो हमें tags = ["LINKABLE_MORE_THAN_ONCE"] को baz में जोड़ना होगा.

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

गड़बड़ियां

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/ जैसे कि foo/bar/BUILD से कम के किसी भी अन्य पैकेज को शामिल करने के लिए //foo:__subpackages__
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

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

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

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

एफ़डीओ प्रोफ़ाइल का लेबल या इसे जनरेट करने वाला नियम. एफ़डीओ फ़ाइल में, इनमें से कोई एक एक्सटेंशन हो सकता है: इंडेक्स नहीं की गई एलएलवीएम प्रोफ़ाइल के लिए .profraw, इंडेक्स की गई एलएलवीएम प्रोफ़ाइल के लिए .profdata, LLVM Profraw प्रोफ़ाइल वाला .zip, AutoFDO प्रोफ़ाइल के लिए .afdo, XBinary प्रोफ़ाइल के लिए .xfdo. यह लेबल किसी 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 .profdata फ़ाइल वाली ज़िप फ़ाइल के लिए एक.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 के बारे में जानकारी देता है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल मौजूद होता है.

defines

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

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

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

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

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

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

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

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

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

linkopts

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

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

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

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

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

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

तर्क

विशेषताएं
name

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

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

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

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

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

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

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

तर्क

विशेषताएं
name

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

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

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

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

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