C / C++ नियम

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

नियम

cc_बाइनरी

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

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

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

तर्क

विशेषताएं
name

Name; required

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

deps

List of labels; optional

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

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

srcs

List of labels; optional

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

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

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

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

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

ऐसा srcs फ़ाइल टाइप इस्तेमाल किया जा सकता है जिसे अनुमति दी गई है:

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

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

additional_linker_inputs

List of labels; optional

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

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

copts

List of strings; optional

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

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

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

defines

List of strings; optional

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

List of strings; optional

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

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

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

linkopts

List of strings; optional

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

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

linkshared

Boolean; optional; nonconfigurable; default is False

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

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

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

linkstatic

Boolean; optional; default is True

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

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

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

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

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

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

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

local_defines

List of strings; optional

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

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

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

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

nocopts

String; optional

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

Integer; optional; default is -1

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

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

win_def_file

Label; optional

लिंक करने के लिए पास की जाने वाली Windows DEF फ़ाइल.

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

cc_Import

cc_import(name, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)

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

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

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

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

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

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

# second will link to mylib.dll through mylib.lib
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)

तर्क

विशेषताएं
name

Name; required

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

hdrs

List of labels; optional

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

Boolean; optional; default is False

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

अगर Windows पर हमेशा लिंक करने की सुविधा बनाम Windows 2017 काम नहीं करती है, तो ऐसा पहले से मालूम समस्या की वजह से हो सकता है. कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें.

interface_library

Label; optional

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

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

shared_library

Label; optional

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

इन फ़ाइल टाइप को अनुमति दी गई है: .so, .dll या .dylib

static_library

Label; optional

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

इन फ़ाइल टाइप को अनुमति दी गई है: .a, .pic.a या .lib

system_provided

Boolean; optional; default is False

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

cc_library

cc_library(name, deps, srcs, data, hdrs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

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

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

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

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

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

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

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

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

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

फ़ाइल शामिल हैशामिल किए जाने की अनुमति है
फ़ूBar.h
foo.ccfoo.h बार
Bar.hBar-impl.h baz.h
Bar-impl.hBar.h baz.h
Bar.ccBar.h Bar-impl.h baz.h
CANNOT TRANSLATEbaz-impl.h
baz-impl.hCANNOT TRANSLATE
baz.ccbaz.h baz-impl.h

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

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

तर्क

विशेषताएं
name

Name; required

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

deps

List of labels; optional

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

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

srcs

List of labels; optional

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

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

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

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

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

ऐसा srcs फ़ाइल टाइप इस्तेमाल किया जा सकता है जिसे अनुमति दी गई है:

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

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

hdrs

List of labels; optional

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

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

Boolean; optional; default is False

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

अगर Windows पर हमेशा लिंक करने की सुविधा बनाम Windows 2017 काम नहीं करती है, तो ऐसा पहले से मालूम समस्या की वजह से हो सकता है. कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें.

copts

List of strings; optional

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

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

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

defines

List of strings; optional

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

List of labels; optional

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

अभी इस सुविधा का इस्तेमाल, cc_library (सीमित संख्या) तक सीमित है और फ़्लैग --experimental_cc_implementation_deps इसे सुरक्षित करता है.

include_prefix

String; optional

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

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

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

includes

List of strings; optional

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

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

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

linkopts

List of strings; optional

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

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

linkstamp

Label; optional

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

Boolean; optional; default is False

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

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

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

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

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

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

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

local_defines

List of strings; optional

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

String; optional

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

String; optional

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

सेट होने पर, इस नियम के hdrs एट्रिब्यूट के हेडर, प्रीफ़िक्स के कट-ऑफ़ होने पर ही अपने पाथ पर ऐक्सेस किए जा सकते हैं.

अगर यह एक रिलेटिव पाथ है, तो इसे पैकेज-रिलेटिव के तौर पर लिया जाता है. अगर यह सटीक है, तो इसे रिपॉज़िटरी-रिलेटिव पाथ के तौर पर समझा जाता है.

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

textual_hdrs

List of labels; optional

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

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

win_def_file

Label; optional

लिंक करने के लिए पास की जाने वाली Windows DEF फ़ाइल.

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

cc_proto_library

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

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

deps में proto_library नियम होने चाहिए.

उदाहरण:

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

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

proto_library(
    name = "foo_proto",
)

तर्क

विशेषताएं
name

Name; required

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

deps

List of labels; optional

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

CANNOT TRANSLATE

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

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

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

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

तर्क

विशेषताएं
name

Name; required

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

profile

Label; optional

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

fdo_profile

fdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

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

तर्क

विशेषताएं
name

Name; required

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

absolute_path_profile

String; optional

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

Label; optional

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

Label; optional

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

परफ़ॉर्मर_ऑप्टिमाइज़

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

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

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

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

तर्क

विशेषताएं
name

Name; required

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

ld_profile

Label; optional

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

cc_test

cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, includes, licenses, linkopts, linkstatic, local, local_defines, malloc, nocopts, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

तर्क

विशेषताएं
name

Name; required

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

deps

List of labels; optional

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

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

srcs

List of labels; optional

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

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

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

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

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

ऐसा srcs फ़ाइल टाइप इस्तेमाल किया जा सकता है जिसे अनुमति दी गई है:

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

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

additional_linker_inputs

List of labels; optional

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

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

copts

List of strings; optional

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

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

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

defines

List of strings; optional

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

List of strings; optional

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

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

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

linkopts

List of strings; optional

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

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

linkstatic

Boolean; optional; default is False

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

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

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

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

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

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

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

local_defines

List of strings; optional

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

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

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

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

nocopts

String; optional

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

Integer; optional; default is 0

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

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

win_def_file

Label; optional

लिंक करने के लिए पास की जाने वाली Windows DEF फ़ाइल.

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

cc_toolchain

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

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

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

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

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

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

तर्क

विशेषताएं
name

Name; required

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

all_files

Label; required

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

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

ar_files

Label; optional

संग्रहित की गई कार्रवाइयों के लिए, cc_toolchain की सभी कलाकृतियों का संग्रह.

as_files

Label; optional

असेंबली की कार्रवाइयों के लिए ज़रूरी cc_toolchain की सभी कलाकृतियों का संग्रह.

compiler

String; optional; nonconfigurable

समर्थन नहीं होना या रुकना. इसके बजाय, toolchain_identifier एट्रिब्यूट का इस्तेमाल करें. CROSSटूल पर स्टारलार्क के माइग्रेशन के बाद यह नूप होगा और #7075 से हटा दिया जाएगा.

सेट होने पर, इसका इस्तेमाल क्रॉसटूल_कॉन्फ़िगरेशन.टूलचेन चुनने के लिए किया जाएगा. इसे -- cpu Bazel के विकल्प की जगह प्राथमिकता दी जाएगी.

compiler_files

Label; required

कंपाइल कार्रवाइयों के लिए, सभी cc_toolchain कलाकृतियों का संग्रह.
compiler_files_without_includes

Label; optional

इनपुट की सुविधा उपलब्ध होने पर, ऐक्शन की कंपाइल करने के लिए सभी cc_toolchain आर्टफ़ैक्ट इकट्ठा करना (फ़िलहाल, सिर्फ़ Google के लिए).
coverage_files

Label; optional

कवरेज से जुड़ी कार्रवाइयों के लिए, cc_toolchain से जुड़ी सभी आर्टफ़ैक्ट इकट्ठा करना ज़रूरी है. अगर बताया न गया हो, तो all_files का इस्तेमाल किया जाएगा.
cpu

String; optional; nonconfigurable

समर्थन नहीं होना या रुकना. इसके बजाय, Toolchain_identifier एट्रिब्यूट का इस्तेमाल करें. CROSSTool माइग्रेशन के लिए स्टारलैक के बाद, यह एक नूप होगा और #7075 से हटा दिया जाएगा.

सेट होने पर, इसका इस्तेमाल क्रॉसटूल_कॉन्फ़िगरेशन.टूलचेन चुनने के लिए किया जाएगा. इसे -- cpu Bazel के विकल्प की जगह प्राथमिकता दी जाएगी.

dwp_files

Label; required

dwp की कार्रवाइयों के लिए, सभी cc_toolchain कलाकृतियों का संग्रह.
dynamic_runtime_lib

Label; optional

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

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

exec_transition_for_inputs

Boolean; optional; default is True

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

Label; optional

लिंक करने वाली कार्रवाइयों को कंपाइल करने या जोड़ने के लिए, इन्हें लाइब्रेरी में शेयर किया गया है.
linker_files

Label; required

लिंक करने की कार्रवाइयों के लिए, सभी cc_toolchain कलाकृतियों का संग्रह.
module_map

Label; optional

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

Label; required

cc_toolchain से जुड़े सभी आर्टफ़ैक्ट का संग्रह, जिसे objcopy के लिए ज़रूरी है.
static_runtime_lib

Label; optional

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

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

strip_files

Label; required

स्ट्रिप कार्रवाइयों के लिए ज़रूरी सभी cc_toolchain कलाकृतियों का संग्रह.
supports_header_parsing

Boolean; optional; default is False

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

Boolean; optional; default is True

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

Label; required

cc_toolchain_config_info को उपलब्ध कराने वाले नियम का लेबल.
toolchain_identifier

String; optional; nonconfigurable

इस cc_toolchain से मिलते-जुलते क्रॉसटूल_कॉन्फ़िगरेशन.टूलचेन के साथ मेल खाने के लिए पहचानकर्ता का इस्तेमाल करें.

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

cc_toolchain_suite

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

C++ टूलचेन के संग्रह का प्रतिनिधित्व करता है.

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

  • काम के सभी C++ टूलचेन इकट्ठा करना.
  • --cpu से लेकर --compiler तक के विकल्पों के हिसाब से, एक टूल चेन को चुना गया. इसके लिए, उन्होंने बैज़ेल में पास किया.

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

तर्क

विशेषताएं
name

Name; required

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

toolchains

Dictionary mapping strings to labels; required; nonconfigurable

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

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