C / C++ नियम

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

नियम

• cc_binary
• cc_import
• cc_library
• cc_proto_library
• cc_shared_library
• fdo_prefetch_hints
• fdo_profile
• memprof_profile
• propeller_optimize
• cc_test
• cc_toolchain
• cc_toolchain_suite

cc_binary

नियम का सोर्स देखें

cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, nocopts, output_licenses, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. ये cc_library या objc_library टारगेट हो सकते हैं.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट बनाने के लिए प्रोसेस की गई C और C++ फ़ाइलों की सूची. ये C/C++ सोर्स और हेडर फ़ाइलें होती हैं, जो या तो जनरेट नहीं की जाती हैं (सामान्य सोर्स कोड) या जनरेट की जाती हैं. सभी .cc, .c, और .cpp फ़ाइलों को इकट्ठा किया जाएगा. ये जनरेट की गई फ़ाइलें हो सकती हैं: अगर कोई नाम वाली फ़ाइल किसी दूसरे नियम के outs में है, तो यह नियम अपने-आप उस दूसरे नियम पर निर्भर हो जाएगा. .h फ़ाइल को कंपाइल नहीं किया जाएगा, लेकिन वह इस नियम में मौजूद सोर्स से शामिल किए जाने के लिए उपलब्ध होगी. .cc और .h, दोनों फ़ाइलों में सीधे तौर पर, इन srcs में मौजूद हेडर या deps आर्ग्युमेंट में दिए गए किसी भी नियम के hdrs में शामिल हेडर शामिल हो सकते हैं. सभी #included फ़ाइलों का उल्लेख, इस नियम के srcs एट्रिब्यूट या बताए गए cc_library() के hdrs एट्रिब्यूट में किया जाना चाहिए. हमारा सुझाव है कि लाइब्रेरी से जुड़े हेडर को उस लाइब्रेरी के hdrs एट्रिब्यूट में शामिल करें और इस नियम के सोर्स से जुड़े बाकी सभी हेडर को srcs में शामिल करें. ज़्यादा जानकारी के लिए, "हेडलाइन में शामिल करने की जांच" देखें. अगर किसी नियम का नाम srcs में है, तो यह नियम अपने-आप उस नियम के हिसाब से निर्भर करता है. अगर नाम वाले नियम के outs, C या C++ वाली सोर्स फ़ाइलें हैं, तो उन्हें इस नियम में कॉम्पाइल किया जाता है; अगर वे लाइब्रेरी फ़ाइलें हैं, तो उन्हें लिंक किया जाता है. अनुमति वाले srcs फ़ाइल टाइप: C और C++ सोर्स फ़ाइलें: .c, .cc, .cpp, .cxx, .c++, .C C और C++ हेडर फ़ाइलें: .h, .hh, .hpp, .hxx, .inc, .inl, .H C प्रीप्रोसेसर वाला असेंबलर: .S संग्रह: .a, .pic.a "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo शेयर की गई लाइब्रेरी, जिसका वर्शन या वर्शन नहीं है: .so, .so.version ऑब्जेक्ट फ़ाइल: .o, .pic.o ...और उन फ़ाइलों को बनाने वाले किसी भी नियम के बारे में बताया है. अलग-अलग एक्सटेंशन, gcc कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, यहां इकट्ठा की गई Windows .res फ़ाइलें दी जा सकती हैं.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है इन विकल्पों को C++ कंपाइलेशन कमांड में जोड़ें. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. बाइनरी टारगेट को कंपाइल करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में COPTS में जोड़ दिया जाता है. फ़्लैग सिर्फ़ इस टारगेट को कंपाइल करने के लिए लागू होते हैं, न कि उसकी डिपेंडेंसी के लिए. इसलिए, दूसरी जगह शामिल हेडर फ़ाइलों के बारे में सावधान रहें. सभी पाथ, फ़ाइल फ़ोल्डर के हिसाब से होने चाहिए, न कि मौजूदा पैकेज से. अगर पैकेज, सुविधा no_copts_tokenization के बारे में जानकारी देता है, तो बॉर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल मौजूद होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए, को -D से पहले जोड़ा जाता है. इसके बाद, स्ट्रिंग को इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है. साथ ही, स्ट्रिंग पर निर्भर हर नियम में भी इसे जोड़ा जाता है. बहुत सावधान रहें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. जब भी आपको पता न हो कि वैल्यू कहां दी गई हैं, तब local_defines में वैल्यू जोड़ें.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ी जाने वाली शामिल डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. हर स्ट्रिंग, -isystem से पहले जोड़ी जाती है और COPTS में जोड़ दी जाती है. COPTS के उलट, ये फ़्लैग इस नियम और उस पर निर्भर हर नियम के लिए जोड़े जाते हैं. (ध्यान दें: वे नियम नहीं हैं जिन पर यह निर्भर करता है!) बहुत सावधान रहें, क्योंकि इससे कई चीज़ों पर असर पड़ सकता है. जब भी आपको पता न हो कि COPTS में "-I" फ़्लैग जोड़ें. हेडर को src या hdrs में जोड़ना ज़रूरी है. ऐसा न होने पर, कंपाइलेशन के सैंडबॉक्स में होने पर वे डिपेंडेंट नियमों के लिए उपलब्ध नहीं होंगे (डिफ़ॉल्ट).
link_extra_lib	लेबल; डिफ़ॉल्ट "@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 से लिंक करने के लिए कहता है. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकती हैं. इनमें ऐसी लाइब्रेरी भी शामिल हैं जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे के तौर पर मिलने वाला एक्ज़ीक्यूटेबल अब भी डाइनैमिक लिंक होगा. इसलिए, सिर्फ़ ज़्यादातर स्टैटिक तरीके से ही लिंक होगा. किसी एक्ज़ीक्यूटेबल को लिंक करने के वास्तव में तीन अलग-अलग तरीके हैं: fully_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	लेबल की सूची; डिफ़ॉल्ट [] है पहले से कंपाइल की गई इस लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची, जिसे डिपेंडेंट नियमों में शामिल सोर्स से सीधे तौर पर शामिल किया जाएगा.
alwayslink	बूलियन; डिफ़ॉल्ट False है अगर 1 है, तो सी++ की इस पहले से संकलित लाइब्रेरी पर सीधे या किसी अन्य तरीके से निर्भर रहने वाली कोई भी बाइनरी, स्टैटिक लाइब्रेरी में संग्रहित सभी ऑब्जेक्ट फ़ाइलों को लिंक करेगी. भले ही, उनमें से कुछ में बाइनरी के रेफ़रंस वाले कोई सिंबल न हो. यह तब काम आता है, जब साफ़ तौर पर आपके कोड को बाइनरी में कोड के ज़रिए कॉल न किया गया हो. उदाहरण के लिए, जब आपका कोड किसी सेवा से मिलने वाले कॉलबैक के लिए रजिस्टर होता है. अगर 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)

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

बिल्ड में इस्तेमाल की जाने वाली सभी हेडर फ़ाइलों को 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.h	bar.h
foo.cc	foo.h bar.h
bar.h	Bar-impl.h baz.h
bar-impl.h	बार.ह बाज़.एच
bar.cc	बार.ह बार-इंप्ल.ह बाज़.एच
baz.h	baz-impl.h
baz-impl.h	baz.h
baz.cc	baz.h baz-impl.h

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

बिना किसी भेदभाव के सभी को शामिल करने की जांच से जुड़े नियम लागू करने के लिए, 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 ...और उन फ़ाइलों को बनाने वाले किसी भी नियम के बारे में बताया है. अलग-अलग एक्सटेंशन, जीसीसी के नियमों के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
hdrs	लेबल की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची, ताकि सोर्स उन्हें सीधे तौर पर, डिपेंडेंट नियमों में शामिल कर सकें. लाइब्रेरी के इंटरफ़ेस की जानकारी देने वाली हेडर फ़ाइलों का एलान करने के लिए, इस जगह का सुझाव दिया जाता है. इन हेडर को इस नियम या इससे जुड़े नियमों में, सोर्स के ज़रिए शामिल करने के लिए उपलब्ध कराया जाएगा. जिन हेडर को इस लाइब्रेरी के क्लाइंट को शामिल नहीं करना है उन्हें srcs एट्रिब्यूट में शामिल किया जाना चाहिए. भले ही, उन्हें पब्लिश किए गए हेडर में शामिल किया गया हो. ज़्यादा जानकारी के लिए, "हेडलाइन में शामिल करने की जांच" देखें.
additional_compiler_inputs	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी कोई भी अतिरिक्त फ़ाइल जिसे आपको कंपाइलर कमांड लाइन में पास करना है. उदाहरण के लिए, सैनिटाइज़र की सूची को नज़रअंदाज़ करना. इसके बाद, यहां दी गई फ़ाइलों को $(location) फ़ंक्शन के साथ कॉप्ट में इस्तेमाल किया जा सकता है.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, यहां इकट्ठा की गई Windows .res फ़ाइलें दी जा सकती हैं.
alwayslink	बूलियन; डिफ़ॉल्ट False है अगर 1 है, तो इस C++ लाइब्रेरी पर निर्भर कोई भी बाइनरी (सीधे तौर पर या किसी दूसरे तरीके से) srcs में मौजूद फ़ाइलों के लिए सभी ऑब्जेक्ट फ़ाइलों को लिंक कर देगी. भले ही, कुछ में बाइनरी के रेफ़रंस वाला कोई सिंबल मौजूद न हो. यह तब काम आता है, जब साफ़ तौर पर आपके कोड को बाइनरी में कोड के ज़रिए कॉल न किया गया हो. उदाहरण के लिए, जब आपका कोड किसी सेवा से मिलने वाले कॉलबैक के लिए रजिस्टर होता है. अगर Windows पर VS 2017 के साथ alwayslink काम नहीं करता है, तो इसकी वजह जानी-पहचानी समस्या है. कृपया अपने 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" फ़्लैग जोड़ें. हेडर को srcs या hdrs में जोड़ना ज़रूरी है. ऐसा न करने पर, कंपाइलेशन को सैंडबॉक्स में डालने पर (डिफ़ॉल्ट रूप से), वे हेडर उन नियमों के लिए उपलब्ध नहीं होंगे जिन पर वे निर्भर हैं.
linkopts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है इन फ़्लैग को C++ लिंकर कमांड में जोड़ें. "Make" वैरिएबल के बदले, Bourne शेल टोकनाइज़ेशन और लेबल एक्सपैंशन का इस्तेमाल किया जा सकता है. इस एट्रिब्यूट की हर स्ट्रिंग को बाइनरी टारगेट को लिंक करने से पहले, LINKOPTS में जोड़ा जाता है. इस सूची के हर उस एलिमेंट को deps में टारगेट का लेबल माना जाता है जो $ या - से शुरू नहीं होता. उस टारगेट से जनरेट की गई फ़ाइलों की सूची, लिंकर के विकल्पों में जोड़ दी जाती है. अगर लेबल अमान्य है या deps में एलान नहीं किया गया है, तो गड़बड़ी की सूचना दी जाती है.
linkstamp	लेबल; डिफ़ॉल्ट None है यह तय की गई C++ सोर्स फ़ाइल को साथ-साथ फ़ाइनल बाइनरी में इकट्ठा और लिंक करता है. बाइनरी में टाइमस्टैंप की जानकारी डालने के लिए, यह तरकीब ज़रूरी है. अगर हम सोर्स फ़ाइल को सामान्य तरीके से ऑब्जेक्ट फ़ाइल में कंपाइल करते हैं, तो टाइमस्टैंप गलत होगा. लिंकस्टैम्प कंपाइलर में कंपाइलर फ़्लैग का कोई खास सेट शामिल नहीं हो सकता. इसलिए, यह किसी खास हेडर, कंपाइलर विकल्प या अन्य बिल्ड वैरिएबल पर निर्भर नहीं होना चाहिए. इस विकल्प की ज़रूरत सिर्फ़ base पैकेज में होनी चाहिए.
linkstatic	बूलियन; डिफ़ॉल्ट तौर पर False cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह सुविधा चालू है और यह एक बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को जब भी मुमकिन हो, उपयोगकर्ता लाइब्रेरी के लिए .so के बजाय .a से लिंक करने के लिए कहता है. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकती हैं. इनमें ऐसी लाइब्रेरी भी शामिल हैं जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे के तौर पर मिलने वाला एक्ज़ीक्यूटेबल अब भी डाइनैमिक लिंक होगा. इसलिए, सिर्फ़ ज़्यादातर स्टैटिक तरीके से ही लिंक होगा. किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं: fully_static_link सुविधा के साथ स्टैटिक, जिसमें सब कुछ स्टैटिक तौर पर लिंक किया गया है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm". इस मोड को चालू करने के लिए, features एट्रिब्यूट में fully_static_link डालें. STATIC, जिसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है, जैसे कि "gcc foo.o libfoo.a libbaz.a -lm". इस मोड को चालू करने के लिए, linkstatic=True डालें. डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाती हैं (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "gcc foo.o libfoo.so libbaz.so -lm". यह मोड, linkstatic=False की जानकारी देकर चालू किया जाता है. linkstatic एट्रिब्यूट का इस्तेमाल, cc_library() नियम के लिए करने पर, इसका मतलब अलग होता है. C++ लाइब्रेरी के लिए, linkstatic=True बताता है कि सिर्फ़ स्टैटिक लिंक करने की अनुमति है, इसलिए कोई .so जनरेट नहीं किया जाएगा. linkstatic=False स्टैटिक लाइब्रेरी को बनने से नहीं रोकता है. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने के काम को कंट्रोल करना है. अगर linkstatic=False, तो बिल्ड टूल *.runfiles एरिया में डिपेंडेंट, शेयर की गई लाइब्रेरी के लिए सिमलिंक बनाएगा.
local_defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए, परिभाषाओं की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए, कमपाइल करने की कमांड लाइन में जोड़ा जाता है, लेकिन इसके डिपेंडेंट में नहीं. हर स्ट्रिंग में एक ही Bourne शेल टोकन होना चाहिए.
nocopts	स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है C++ कंपाइलेशन कमांड से मैच करने के विकल्प हटाएं. "Make" वैरिएबल के विकल्प पर निर्भर करता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस रेगुलर एक्सप्रेशन से मैच करने वाले, पहले से मौजूद COPTS (इसमें नियम के copts एट्रिब्यूट में साफ़ तौर पर बताई गई वैल्यू भी शामिल हैं) को COPTS से हटा दिया जाएगा, ताकि इस नियम को इकट्ठा किया जा सके. इस एट्रिब्यूट की ज़रूरत बहुत कम पड़ती है.
strip_include_prefix	स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है इस नियम के हेडर के पाथ से स्ट्रिप किया जाने वाला प्रीफ़िक्स. अगर नीति को सेट किया जाता है, तो इस नियम के hdrs एट्रिब्यूट में मौजूद हेडर को अपने पाथ से ऐक्सेस किया जा सकेगा. साथ ही, इस प्रीफ़िक्स को काटकर बनाए गए हेडर को अपने पाथ से ऐक्सेस किया जा सकेगा. अगर यह कोई रिलेटिव पाथ है, तो इसे पैकेज के हिसाब से रिलेटिव पाथ माना जाता है. अगर यह ऐब्सलूट पाथ है, तो इसे रिपॉज़िटरी से रिलेटिव पाथ माना जाता है. include_prefix एट्रिब्यूट में प्रीफ़िक्स, इस प्रीफ़िक्स को हटाने के बाद जोड़ा जाता है.
textual_hdrs	लेबल की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी से पब्लिश की गई हेडर फ़ाइलों की सूची, ताकि सोर्स, टेक्स्ट के तौर पर इन नियमों में शामिल कर सकें. इस सेक्शन में उन हेडर फ़ाइलों के बारे में बताया जाता है जिन्हें अपने-आप कंपाइल नहीं किया जा सकता. इसका मतलब है कि मान्य कोड बनाने के लिए, उन्हें हमेशा दूसरी सोर्स फ़ाइलों में टेक्स्ट के तौर पर शामिल करना ज़रूरी होता है.
win_def_file	लेबल; डिफ़ॉल्ट None है लिंकर को भेजी जाने वाली Windows DEF फ़ाइल. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब Windows टारगेट प्लैटफ़ॉर्म हो. इसका इस्तेमाल, शेयर की गई लाइब्रेरी को लिंक करते समय सिंबल एक्सपोर्ट करने के लिए किया जा सकता है.

cc_proto_library

नियम का सोर्स देखें

cc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

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

deps फ़ंक्शन, proto_library के नियमों पर ले जाने वाला होना चाहिए.

उदाहरण:

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

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

proto_library(
    name = "foo_proto",
)

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है C++ कोड जनरेट करने के लिए, proto_library के नियमों की सूची.

cc_shared_library

नियम का सोर्स देखें

cc_shared_library(name, deps, additional_linker_inputs, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, win_def_file)

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

उदाहरण

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

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

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

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

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

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

गड़बड़ियां

Two shared libraries in dependencies export the same symbols.

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

Two shared libraries in dependencies link the same library statically

ऐसा तब होगा, जब दो अलग-अलग 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:__subpackages__, foo/BUILD में मौजूद किसी भी टारगेट या foo/ के नीचे मौजूद किसी भी अन्य पैकेज, जैसे कि foo/bar/BUILD को ध्यान में रखने के लिए
shared_lib_name	स्ट्रिंग; डिफ़ॉल्ट रूप से "" डिफ़ॉल्ट रूप से, cc_shared_library, टारगेट के नाम और प्लैटफ़ॉर्म के आधार पर, शेयर की गई लाइब्रेरी की आउटपुट फ़ाइल के लिए किसी नाम का इस्तेमाल करेगा. इसमें एक्सटेंशन और कभी-कभी प्रीफ़िक्स भी शामिल होता है. कभी-कभी हो सकता है कि आपको डिफ़ॉल्ट नाम न पड़े. उदाहरण के लिए, Python के लिए C++ शेयर की गई लाइब्रेरी लोड करते समय, डिफ़ॉल्ट lib* प्रीफ़िक्स की ज़रूरत नहीं होती. ऐसे में, अपनी पसंद के मुताबिक नाम चुनने के लिए इस एट्रिब्यूट का इस्तेमाल किया जा सकता है.
user_link_flags	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] ऐसे अन्य फ़्लैग जिन्हें शायद आप लिंकर को भेजना चाहें. उदाहरण के लिए, 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 है एफ़डीओ प्रोफ़ाइल का लेबल या उसे जनरेट करने वाला नियम. FDO फ़ाइल में इनमें से कोई एक एक्सटेंशन हो सकता है: इंडेक्स नहीं की गई LLVM प्रोफ़ाइल के लिए .profraw, इंडेक्स की गई LLVM प्रोफ़ाइल के लिए .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()s के hdrs एट्रिब्यूट में किया जाना चाहिए. हमारा सुझाव है कि लाइब्रेरी से जुड़े हेडर को उस लाइब्रेरी के hdrs एट्रिब्यूट में शामिल करें और इस नियम के सोर्स से जुड़े बाकी सभी हेडर को srcs में शामिल करें. ज़्यादा जानकारी के लिए, "हेडलाइन में शामिल करने की जांच" देखें. अगर किसी नियम का नाम srcs में है, तो यह नियम अपने-आप उस नियम के हिसाब से निर्भर करता है. अगर नाम वाले नियम की outs, C या C++ सोर्स फ़ाइलें हैं, तो उन्हें इस नियम में कंपाइल किया जाता है. अगर वे लाइब्रेरी फ़ाइलें हैं, तो उनमें लिंक किया जाता है. अनुमति वाले srcs फ़ाइल टाइप: C और C++ सोर्स फ़ाइलें: .c, .cc, .cpp, .cxx, .c++, .C C और C++ हेडर फ़ाइलें: .h, .hh, .hpp, .hxx, .inc, .inl, .H C प्रीप्रोसेसर वाला असेंबलर: .S संग्रह: .a, .pic.a "हमेशा लिंक करें" लाइब्रेरी: .lo, .pic.lo शेयर की गई लाइब्रेरी, जिसका वर्शन या वर्शन नहीं है: .so, .so.version ऑब्जेक्ट फ़ाइल: .o, .pic.o ...और उन फ़ाइलों को जनरेट करने वाले नियम. अलग-अलग एक्सटेंशन, gcc कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं.
additional_linker_inputs	लेबल की सूची; डिफ़ॉल्ट [] है इन फ़ाइलों को C++ लिंकर कमांड में पास करें. उदाहरण के लिए, बाइनरी टारगेट में एम्बेड करने के लिए, यहां इकट्ठा की गई Windows .res फ़ाइलें दी जा सकती हैं.
copts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है C++ कंपाइलेशन कमांड में ये विकल्प जोड़ें. यह "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. बाइनरी टारगेट को कंपाइल करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में COPTS में जोड़ दिया जाता है. फ़्लैग सिर्फ़ इस टारगेट को इकट्ठा करने के लिए लागू होते हैं, इनकी डिपेंडेंसी के लिए नहीं. इसलिए, कहीं और शामिल की गई हेडर फ़ाइलों को लेकर सावधान रहें. सभी पाथ, फ़ाइल फ़ोल्डर से जुड़े होने चाहिए, न कि मौजूदा पैकेज से. अगर पैकेज में सुविधा no_copts_tokenization का एलान किया गया है, तो Bourne शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक "Make" वैरिएबल होता है.
defines	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग के आगे -D जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए, कमपाइल करने की कमांड लाइन में जोड़ा जाता है. साथ ही, इस पर निर्भर हर नियम में भी इसे जोड़ा जाता है. हर स्ट्रिंग में एक ही Bourne shell टोकन होना चाहिए. बहुत सावधान रहें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. अगर आपको नहीं पता कि जीटीआईएन सही है या नहीं, तो इसके बजाय, local_defines में वैल्यू जोड़ें.
includes	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़े जाने वाले डाइरों को शामिल करने की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. हर स्ट्रिंग को -isystem से शुरू किया जाता है और COPTS में जोड़ा जाता है. COPTS के उलट, इन फ़्लैग को इस नियम और इस पर निर्भर हर नियम के लिए जोड़ा जाता है. (ध्यान दें: उन नियमों के बारे में नहीं जिन पर यह निर्भर करता है!) बहुत सावधान रहें, क्योंकि इसके दूर तक पहुंचने वाले प्रभाव हो सकते हैं. अगर आपको कोई संदेह है, तो COPTS में "-I" फ़्लैग जोड़ें. हेडर को srcs या hdrs में जोड़ना ज़रूरी है. ऐसा न करने पर, कंपाइलेशन को सैंडबॉक्स में डालने पर (डिफ़ॉल्ट रूप से), वे हेडर उन नियमों के लिए उपलब्ध नहीं होंगे जिन पर वे निर्भर हैं.
link_extra_lib	लेबल; डिफ़ॉल्ट "@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" वैरिएबल के बदले, Bourne शेल टोकनाइज़ेशन और लेबल एक्सपैंशन का इस्तेमाल किया जा सकता है. बाइनरी टारगेट को लिंक करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को LINKOPTS में जोड़ा जाता है. इस सूची के हर उस एलिमेंट को deps में टारगेट का लेबल माना जाता है जो $ या - से शुरू नहीं होता. उस टारगेट से जनरेट होने वाली फ़ाइलों की सूची को लिंकर के विकल्पों में जोड़ दिया जाता है. अगर लेबल अमान्य है या उसके बारे में deps में एलान नहीं किया गया है, तो एक गड़बड़ी की शिकायत की जाती है.
linkstatic	बूलियन; डिफ़ॉल्ट False है cc_binary और cc_test के लिए: बाइनरी को स्टैटिक मोड में लिंक करें. cc_library.linkstatic के लिए: नीचे देखें. डिफ़ॉल्ट रूप से, यह विकल्प cc_binary के लिए चालू होता है और बाकी के लिए बंद होता है. अगर यह सुविधा चालू है और यह एक बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को जब भी मुमकिन हो, उपयोगकर्ता लाइब्रेरी के लिए .so के बजाय .a से लिंक करने के लिए कहता है. कुछ सिस्टम लाइब्रेरी अब भी डाइनैमिक तौर पर लिंक की जा सकती हैं. इनमें ऐसी लाइब्रेरी भी शामिल हैं जिनके लिए कोई स्टैटिक लाइब्रेरी नहीं है. इसलिए, नतीजे के तौर पर मिलने वाला एक्ज़ीक्यूटेबल अब भी डाइनैमिक लिंक होगा. इसलिए, सिर्फ़ ज़्यादातर स्टैटिक तरीके से ही लिंक होगा. किसी एक्सीक्यूटेबल को लिंक करने के तीन तरीके हैं: fully_static_link सुविधा के साथ स्टैटिक, जिसमें सब कुछ स्टैटिक तौर पर लिंक किया गया है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm". इस मोड को चालू करने के लिए, features एट्रिब्यूट में fully_static_link डालें. STATIC, जिसमें सभी उपयोगकर्ता लाइब्रेरी को स्टैटिक तौर पर लिंक किया जाता है (अगर स्टैटिक वर्शन उपलब्ध है). हालांकि, सिस्टम लाइब्रेरी (C/C++ रनटाइम लाइब्रेरी को छोड़कर) को डाइनैमिक तौर पर लिंक किया जाता है, जैसे कि "gcc foo.o libfoo.a libbaz.a -lm". इस मोड को चालू करने के लिए, linkstatic=True डालें. डाइनैमिक, जिसमें सभी लाइब्रेरी डाइनैमिक रूप से लिंक की जाती हैं (अगर डाइनैमिक वर्शन उपलब्ध है), जैसे कि "gcc foo.o libfoo.so libbaz.so -lm". इस मोड को linkstatic=False तय करके चालू किया जाता है. अगर linkstatic एट्रिब्यूट का मतलब cc_library() नियम में इस्तेमाल किया गया है, तो उसका अलग मतलब होता है. C++ लाइब्रेरी के लिए, linkstatic=True बताता है कि सिर्फ़ स्टैटिक लिंक करने की अनुमति है, इसलिए कोई .so जनरेट नहीं किया जाएगा. linkstatic=False स्टैटिक लाइब्रेरी को बनने से नहीं रोकता है. इस एट्रिब्यूट का मकसद, डाइनैमिक लाइब्रेरी बनाने की प्रोसेस को कंट्रोल करना है. अगर linkstatic=False, तो बिल्ड टूल *.runfiles एरिया में डिपेंडेंट, शेयर की गई लाइब्रेरी के लिए सिमलिंक बनाएगा.
local_defines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] कंपाइल लाइन में जोड़ने के लिए डेफ़िनिशन की सूची. "Make" वैरिएबल के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. हर स्ट्रिंग, जिसमें एक बॉर्न शेल टोकन होना चाहिए, को -D से पहले जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ी जाती है, लेकिन इससे जुड़े डिपेंडेंट्स के साथ नहीं.
malloc	लेबल; डिफ़ॉल्ट "@bazel_tools//tools/cpp:malloc" है मॉलोक पर डिफ़ॉल्ट डिपेंडेंसी बदलें. डिफ़ॉल्ट रूप से, C++ बाइनरी //tools/cpp:malloc से लिंक होती हैं. यह एक खाली लाइब्रेरी है, इसलिए बाइनरी libc मैलडॉक का इस्तेमाल करके खत्म होती है. यह लेबल, किसी cc_library से जुड़ा होना चाहिए. अगर कंपाइलेशन, C++ के अलावा किसी दूसरे नियम के लिए है, तो इस विकल्प का कोई असर नहीं पड़ता. अगर linkshared=True दिया गया है, तो इस एट्रिब्यूट की वैल्यू को नज़रअंदाज़ किया जाता है.
nocopts	स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है C++ कंपाइलेशन कमांड से मैच करने वाले विकल्प हटाएं. "Make" वैरिएबल के बदले इस्तेमाल किया जा सकता है. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस रेगुलर एक्सप्रेशन से मैच करने वाले, पहले से मौजूद COPTS (इसमें नियम के copts एट्रिब्यूट में साफ़ तौर पर बताई गई वैल्यू भी शामिल हैं) को COPTS से हटा दिया जाएगा, ताकि इस नियम को इकट्ठा किया जा सके. इस एट्रिब्यूट की ज़रूरत शायद ही कभी पड़े.
stamp	पूर्णांक; डिफ़ॉल्ट 0 है बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. जितने तरह के प्लेसमेंट हो सकते हैं उनकी जानकारी यहां दी गई है: stamp = 1: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. ऐसा --nostamp बिल्ड में भी करें. इस सेटिंग का इस्तेमाल नहीं किया जाना चाहिए, क्योंकि इससे बिटरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल नहीं किया जा सकता. stamp = 0: बिल्ड की जानकारी को हमेशा कॉन्सटैंट वैल्यू से बदलें. इससे, बिल्ड के नतीजे को कैश मेमोरी में सेव करने की सुविधा मिलती है. stamp = -1: बिल्ड की जानकारी को एम्बेड करने को --[no]stamp फ़्लैग से कंट्रोल किया जाता है. स्टैंप की गई बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो जाए.
win_def_file	लेबल; डिफ़ॉल्ट None है Windows DEF फ़ाइल, जिसे लिंकर को पास करना है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब Windows टारगेट प्लैटफ़ॉर्म हो. इसका इस्तेमाल, शेयर की गई लाइब्रेरी को लिंक करते समय सिंबल एक्सपोर्ट करने के लिए किया जा सकता है.

cc_toolchain

नियम का सोर्स देखें

cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, visibility)

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

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

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

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

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

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
all_files	लेबल; ज़रूरी है cc_toolchain के सभी आर्टफ़ैक्ट का कलेक्शन. इन आर्टफ़ैक्ट को, Terms_cc से जुड़ी सभी कार्रवाइयों में इनपुट के तौर पर जोड़ दिया जाएगा. इनमें वे कार्रवाइयां शामिल नहीं हैं जो नीचे दिए गए एट्रिब्यूट में से, ज़्यादा सटीक आर्टफ़ैक्ट के सेट का इस्तेमाल करती हैं. Bazel मानता है कि all_files, आर्टफ़ैक्ट उपलब्ध कराने वाले सभी अन्य एट्रिब्यूट का सुपरसेट है. उदाहरण के लिए, लिंकस्टैंप कंपाइलेशन के लिए, इकट्ठा करने और लिंक करने, दोनों तरह की फ़ाइलों की ज़रूरत होती है. इसलिए, इसमें all_files का इस्तेमाल किया जाता है. cc_toolchain.files में यही होता है. C++ टूलचेन का इस्तेमाल करने वाले सभी Starlark नियमों में इसका इस्तेमाल किया जाता है.
ar_files	लेबल; डिफ़ॉल्ट None है संग्रहित करने की कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन चाहिए.
as_files	लेबल; डिफ़ॉल्ट None है असेंबल करने की कार्रवाइयों के लिए सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन ज़रूरी है.
compiler_files	लेबल; ज़रूरी है कंपाइल करने की कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
compiler_files_without_includes	लेबल; डिफ़ॉल्ट None है cc_toolchain के सभी आर्टफ़ैक्ट का कलेक्शन, जो संकलन की कार्रवाइयों के लिए ज़रूरी होते हैं. ऐसा तब होता है, जब इनपुट डिस्कवरी की सुविधा काम करती हो. फ़िलहाल, यह सुविधा सिर्फ़ Google के लिए उपलब्ध है.
coverage_files	लेबल; डिफ़ॉल्ट None है कवरेज से जुड़ी कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. अगर इसके बारे में नहीं बताया गया है, तो all_files इस्तेमाल किए जाते हैं.
dwp_files	लेबल; ज़रूरी है dwp कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
dynamic_runtime_lib	लेबल; डिफ़ॉल्ट None है C++ रनटाइम लाइब्रेरी (उदाहरण के लिए, libstdc++.so) के लिए डाइनैमिक लाइब्रेरी आर्टफ़ैक्ट. इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू हो और हम डिपेंडेंसी को डाइनैमिक तौर पर लिंक कर रहे हों.
exec_transition_for_inputs	बूलियन; डिफ़ॉल्ट तौर पर True exec प्लैटफ़ॉर्म के लिए, cc_toolchain में सभी फ़ाइल इनपुट बनाने के लिए 'सही है' पर सेट करें. ऐसा करने से, कोई ट्रांज़िशन नहीं होगा. उदाहरण के लिए, डिफ़ॉल्ट रूप से टारगेट प्लैटफ़ॉर्म.
libc_top	लेबल; डिफ़ॉल्ट None है libc के आर्टफ़ैक्ट का कलेक्शन, जिसे कंपाइल/लिंक करने की कार्रवाइयों के इनपुट के तौर पर पास किया जाता है.
linker_files	लेबल; ज़रूरी है कार्रवाइयों को लिंक करने के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
module_map	लेबल; डिफ़ॉल्ट None है मॉड्यूलर बिल्ड के लिए इस्तेमाल किया जाने वाला मॉड्यूल मैप आर्टफ़ैक्ट.
objcopy_files	लेबल; ज़रूरी है objcopy ऐक्शन के लिए ज़रूरी सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
static_runtime_lib	लेबल; डिफ़ॉल्ट None है C++ रनटाइम लाइब्रेरी के लिए स्टैटिक लाइब्रेरी आर्टफ़ैक्ट (उदाहरण के लिए, libstdc++.a). इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू हो और हम डिपेंडेंसी को स्टैटिक तौर पर लिंक कर रहे हों.
strip_files	लेबल; ज़रूरी है स्ट्रिप से जुड़ी कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन.
supports_header_parsing	बूलियन; डिफ़ॉल्ट False है जब cc_toolchain, हेडर पार्स करने की कार्रवाइयों के साथ काम करता है, तो इसे 'सही है' पर सेट करें.
supports_param_files	बूलियन; डिफ़ॉल्ट तौर पर True जब cc_toolchain, ऐक्शन को लिंक करने के लिए पैरामीटर फ़ाइलों का इस्तेमाल करने की सुविधा देता है, तो इसे 'सही है' पर सेट करें.
toolchain_config	लेबल; ज़रूरी है cc_toolchain_config_info देने वाले नियम का लेबल.
toolchain_identifier	स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट रूप से "" पर सेट है इस cc_toolchain को इससे जुड़े क्रॉस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++ के सभी ज़रूरी टूलचेन इकट्ठा करना.
• 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", }, )