C / C++ नियम

नियम

cc_binary 

cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, includes, licenses, 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

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 या इनमें सूचीबद्ध किसी भी नियम के hdrs में deps तर्क को बदल दिया गया है.

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

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

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

defines

List of strings; optional

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

List of strings; optional

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

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

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

linkopts

List of strings; optional

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

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

  • पूरी तरह से static_link सुविधा के साथ आंकड़े, जिसमें सब कुछ स्थिर रूप से जुड़ा होता है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm".
    इस मोड को इसमें fully_static_link तय करके चालू किया जाता है features एट्रिब्यूट.
  • आंकड़े, जिसमें सभी उपयोगकर्ता लाइब्रेरी स्थिर रूप से लिंक की जाती हैं (अगर वर्शन उपलब्ध है), लेकिन सिस्टम लाइब्रेरी (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

List of strings; optional

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

Label; optional

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

अनुमति वाले फ़ाइल टाइप: .ifso, .tbd, .lib, .so या .dylib

shared_library

Label; optional

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

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

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

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

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

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

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

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

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

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

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

फ़ाइल शामिल हैशामिल करने की अनुमति है
foo.hbar.h
foo.ccफ़ू.ह बार.ह
bar.hBar-impl.h baz.h
बार-इंप्लि.एचबार.ह बाज़.एच
bar.ccबार.ह बार-इंप्ल.ह बाज़.एच
baz.hबाज़-इंप्ल॰एच
बाज़-इंप्ल॰एचbaz.h
baz.ccबाज़.ह बाज़-इंप्ल.एच

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

माफ़ करें, फ़िलहाल Basel को डायरेक्ट और ट्रांज़िट के बीच फ़र्क़ नहीं पड़ता शामिल नहीं किया जा सकता, इसलिए यह ऐसे गड़बड़ी मामलों का पता नहीं लगा सकता जहां किसी फ़ाइल में गैर-कानूनी रूप से हेडर होना चाहिए, जिसे सिर्फ़ ट्रांज़िट के दौरान शामिल करने की अनुमति हो. उदाहरण के लिए, अगर ऊपर दिए गए उदाहरण में, सीधे तौर पर 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 या इनमें सूचीबद्ध किसी भी नियम के hdrs में deps तर्क को बदल दिया गया है.

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

Boolean; optional; default is False

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

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

List of strings; optional

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

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

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

defines

List of strings; optional

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

List of labels; optional

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

फ़िलहाल, इसका इस्तेमाल cc_लाइब्रेरी तक सीमित किया गया है और उसे फ़्लैग किया गया है --experimental_cc_implementation_deps.
include_prefix

String; optional

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

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

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

includes

List of strings; optional

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

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

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

linkopts

List of strings; optional

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

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

linkstamp

Label; optional

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

Boolean; optional; default is False

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

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

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

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

  • पूरी तरह से static_link सुविधा के साथ आंकड़े, जिसमें सब कुछ स्थिर रूप से जुड़ा होता है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm".
    इस मोड को इसमें fully_static_link तय करके चालू किया जाता है features एट्रिब्यूट.
  • आंकड़े, जिसमें सभी उपयोगकर्ता लाइब्रेरी स्थिर रूप से लिंक की जाती हैं (अगर वर्शन उपलब्ध है), लेकिन सिस्टम लाइब्रेरी (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

List of strings; optional

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

String; optional

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

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

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_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

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

Label; optional

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

Label; optional

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

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

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 या इनमें सूचीबद्ध किसी भी नियम के hdrs में deps तर्क को बदल दिया गया है.

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

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

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

defines

List of strings; optional

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

List of strings; optional

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

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

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

linkopts

List of strings; optional

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

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

linkstatic

Boolean; optional; default is False

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

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

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

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

  • पूरी तरह से static_link सुविधा के साथ आंकड़े, जिसमें सब कुछ स्थिर रूप से जुड़ा होता है; उदाहरण के लिए, "gcc -static foo.o libbar.a libbaz.a -lm".
    इस मोड को इसमें fully_static_link तय करके चालू किया जाता है features एट्रिब्यूट.
  • आंकड़े, जिसमें सभी उपयोगकर्ता लाइब्रेरी स्थिर रूप से लिंक की जाती हैं (अगर वर्शन उपलब्ध है), लेकिन सिस्टम लाइब्रेरी (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

List of strings; optional

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

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

तर्क

विशेषताएं
name

Name; required

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

Label; required

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

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

Label; optional

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

Label; optional

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

String; optional; nonconfigurable

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

इसे सेट करने पर, इसका इस्तेमाल Crosstool_config.toolchain को चुनने के लिए किया जाएगा. इसमें समय लगेगा --cpu Basel विकल्प पर प्राथमिकता.
compiler_files

Label; required

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

Label; optional

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

Label; optional

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

String; optional; nonconfigurable

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

इसे सेट करने पर, इसका इस्तेमाल Crosstool_config.toolchain को चुनने के लिए किया जाएगा. इसमें समय लगेगा --cpu Basel विकल्प पर प्राथमिकता.
dwp_files

Label; required

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

Label; optional

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

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

Boolean; optional; default is True

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

Label; optional

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

Label; required

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

Label; optional

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

Label; required

objकॉपी की कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन होना चाहिए.
static_runtime_lib

Label; optional

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

इसका इस्तेमाल तब किया जाएगा, जब '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 का मिलान संबंधित प्रॉडक्ट से करने के लिए इस्तेमाल किया जाने वाला आइडेंटिफ़ायर crosstool_config.toolchain.

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

cc_toolchain_suite 

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

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

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

  • C++ के सभी ज़रूरी टूलचेन इकट्ठा करना.
  • --cpu और --compiler विकल्पों के आधार पर एक टूलचेन चुनना को भेजा गया.

इसे भी देखें पेज पढ़ें.

तर्क

विशेषताएं
name

Name; required

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

Dictionary mapping strings to labels; required; nonconfigurable

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

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