BazelCon 2022, 16 नवंबर से 17 नवंबर तक न्यूयॉर्क में और ऑनलाइन उपलब्ध है.
आज ही रजिस्टर करें!

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 (सिर्फ़ तब अनुरोध किया गया, जब साफ़ तौर पर अनुरोध किया गया हो): अगर Fision चालू है: डीबग की जानकारी देने वाली पैकेज फ़ाइल, जो रिमोट तरीके से डिप्लॉय की गई बाइनरी को डीबग करने के लिए सही है. दूसरा तरीका: एक खाली फ़ाइल.

तर्क

एट्रिब्यूट
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 के एट्रिब्यूट में शामिल किया जाना है. साथ ही, इन नियमों का इस्तेमाल इस नियम और #39; के सोर्स से जुड़े हुए बाकी हेडर को srcs में शामिल करने के लिए किया जाता है. ज़्यादा जानकारी के लिए &quat;हेडर शामिल करने की जांच" देखें.

अगर कोई नियम' का नाम srcs में है, तो यह नियम अपने-आप उस पर निर्भर हो जाता है. अगर नाम वाले नियम outs# या 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

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

additional_linker_inputs

List of labels; optional

इन फ़ाइलों को C++ लिंकर निर्देश के पास भेजें.

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

copts

List of strings; optional

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

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

अगर पैकेज में, सुविधा no_copts_tokenization के बारे में जानकारी दी गई है, तो बोर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही &kot;Make&quat; वैरिएबल होता है.

defines

List of strings; optional

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

List of strings; optional

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

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

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

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=1 और linkshared=True, दोनों के बारे में बताते हैं, तो आपको एक ही, ज़्यादातर शामिल की गई यूनिट मिलेगी.

linkstatic

Boolean; optional; default is True

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

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

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

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

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

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

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

local_defines

List of strings; optional

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

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

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

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

nocopts

String; optional

C++ कंपाइलेशन निर्देश से मिलान के विकल्प हटाएं. "Make&कोटेशन वैरिएबल के तहत. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस नियम को कंपाइल करने के लिए, पहले से मौजूद इस रेगुलर एक्सप्रेशन (इसमें नियम और #39;s ऑप्ट-आउट एट्रिब्यूट में दी गई वैल्यू भी शामिल है) से 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 पर VS 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, include_prefix, includes, interface_deps, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

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

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

cc_library नियमों के लिए, hdrs में मौजूद हेडर, लाइब्रेरी का सार्वजनिक इंटरफ़ेस शामिल करते हैं. साथ ही, इन्हें लाइब्रेरी की hdrs और srcs, दोनों में सीधे शामिल किया जा सकता है. साथ ही, cc_* में मौजूद 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.h बार.h
Bar.hBar- पक्का.बज़.h
बार-इंप्रेशनBar.h baz.h
बारBar.h Bar-ंट.h baz.h
baz.hbaz-impl.h
baz-impl.hbaz.h
baz.ccbaz.h baz-Impact.h

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

फ़िलहाल, बेज़ेल सीधे तौर पर होने वाले और ट्रांज़िट समय के बीच शामिल नहीं किए जा सकते. इसलिए, यह गड़बड़ी के ऐसे मामलों का पता नहीं लगा सकता जहां किसी फ़ाइल में गैरकानूनी तरीके से एक हेडर को सीधे शामिल करने की अनुमति होती है. उदाहरण के लिए, अगर ऊपर दिए गए उदाहरण में 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 के एट्रिब्यूट में शामिल किया जाना है. साथ ही, इन नियमों का इस्तेमाल इस नियम और #39; के सोर्स से जुड़े हुए बाकी हेडर को srcs में शामिल करने के लिए किया जाता है. ज़्यादा जानकारी के लिए &quat;हेडर शामिल करने की जांच" देखें.

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

इन srcs फ़ाइल टाइप की अनुमति है:

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

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

hdrs

List of labels; optional

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

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

Boolean; optional; default is False

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

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

copts

List of strings; optional

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

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

अगर पैकेज में, सुविधा no_copts_tokenization के बारे में जानकारी दी गई है, तो बोर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही &kot;Make&quat; वैरिएबल होता है.

defines

List of strings; optional

कंपाइल लाइन में जोड़ने के लिए जानकारी की सूची. &kot;Make&कोटेशन वैरिएबल और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. हर स्ट्रिंग, जिसमें एक बोर्न शेल टोकन होना चाहिए, को -D के साथ जोड़ा जाता है. साथ ही, इसे इस टारगेट में कंपाइल करने के लिए कमांड लाइन में जोड़ा जाता है. साथ ही, इस पर निर्भर करने वाले हर नियम को जोड़ा जाता है. सावधान रहें, क्योंकि इसका बहुत दूर तक असर पड़ सकता है. संदेह होने पर, local_defines में वैल्यू तय करें.
include_prefix

String; optional

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

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

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

includes

List of strings; optional

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

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

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

interface_deps

List of labels; optional

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

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

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

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

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

local_defines

List of strings; optional

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

String; optional

C++ कंपाइलेशन निर्देश से मिलान के विकल्प हटाएं. "Make&कोटेशन वैरिएबल के तहत. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस नियम को कंपाइल करने के लिए, पहले से मौजूद इस रेगुलर एक्सप्रेशन (इसमें नियम और #39;s ऑप्ट-आउट एट्रिब्यूट में दी गई वैल्यू भी शामिल है) से COPTS को हटा दिया जाएगा. इस एट्रिब्यूट की ज़रूरत कभी-कभी ही होनी चाहिए.
strip_include_prefix

String; optional

इस नियम के हेडर के पाथ से स्ट्रिप प्रीफ़िक्स.

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

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

इस प्रीफ़िक्स को हटाने के बाद, 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_fetch_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

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

Label; optional

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

propelle_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 या deps तर्क में दिए गए किसी भी नियम के hdrs में मौजूद हेडर शामिल हो सकते हैं.

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

अगर कोई नियम' का नाम srcs में है, तो यह नियम अपने-आप उस पर निर्भर हो जाता है. अगर नाम वाले नियम outs# या 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

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

additional_linker_inputs

List of labels; optional

इन फ़ाइलों को C++ लिंकर निर्देश के पास भेजें.

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

copts

List of strings; optional

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

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

अगर पैकेज में, सुविधा no_copts_tokenization के बारे में जानकारी दी गई है, तो बोर्न शेल टोकनाइज़ेशन सिर्फ़ उन स्ट्रिंग पर लागू होता है जिनमें एक ही &kot;Make&quat; वैरिएबल होता है.

defines

List of strings; optional

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

List of strings; optional

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

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

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

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

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

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

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

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

local_defines

List of strings; optional

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

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

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

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

nocopts

String; optional

C++ कंपाइलेशन निर्देश से मिलान के विकल्प हटाएं. "Make&कोटेशन वैरिएबल के तहत. इस एट्रिब्यूट की वैल्यू को रेगुलर एक्सप्रेशन के तौर पर समझा जाता है. इस नियम को कंपाइल करने के लिए, पहले से मौजूद इस रेगुलर एक्सप्रेशन (इसमें नियम और #39;s ऑप्ट-आउट एट्रिब्यूट में दी गई वैल्यू भी शामिल है) से 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++ टूलचेन कॉन्फ़िगरेशन और टूलचेन दस्तावेज़ों के लिए, इस पेज को भी देखें.

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

तर्क

एट्रिब्यूट
name

Name; required

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

all_files

Label; required

cc_toolchain से जुड़ी सभी कलाकृतियों का संग्रह. इन आर्टफ़ैक्ट को, rules_cc से जुड़ी सभी कार्रवाइयों के लिए इनपुट के तौर पर जोड़ा जाएगा. हालांकि, इसमें वे कार्रवाइयां शामिल नहीं हैं जो नीचे दी गई विशेषताओं में से ज़्यादा सटीक आर्टफ़ैक्ट का इस्तेमाल कर रही हैं. बेज़ेल यह मानकर चलता है कि 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 एट्रिब्यूट का इस्तेमाल करें. CROSSTool को Starlark पर माइग्रेट करने के बाद, यह ग़ैर-ज़रूरी नहीं होगा. इसे #7075 से हटा दिया जाएगा.

सेट होने पर, इसका इस्तेमाल crosstool_config.toolchain चुनने के लिए किया जाएगा. इसे --cpu Bazer के विकल्प के ऊपर प्राथमिकता दी जाएगी.

compiler_files

Label; required

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

फ़िलहाल, सिर्फ़ lto_backend कार्रवाइयों के लिए इस्तेमाल की जाती है. रेगुलर कंपाइल कार्रवाइयां, all_files (#6927) का इस्तेमाल करती हैं.

compiler_files_without_includes

Label; optional

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

Label; optional

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

String; optional; nonconfigurable

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

सेट होने पर, इसका इस्तेमाल crosstool_config.toolchain चुनने के लिए किया जाएगा. इसे --cpu Bazer के विकल्प के ऊपर प्राथमिकता दी जाएगी.

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

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

Label; optional

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

Label; required

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

Label; optional

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

Label; required

objcopy कार्रवाई के लिए, 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 से मिलते-जुलते क्रॉसtool_config.toolchain के साथ पहचानकर्ता का इस्तेमाल किया जाता है.

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

cc_toolchain_suite

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

C++ टूलचेन के संग्रह को दिखाता है.

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

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

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

तर्क

एट्रिब्यूट
name

Name; required

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

toolchains

Dictionary mapping strings to labels; required; nonconfigurable

&cc_toolchain</t> "<cpu>" --cpu का इस्तेमाल सिर्फ़ तब होगा, जब बेज़ेल को --cpu भेजा जाएगा. साथ ही, &&tt;cpu>|<compiler>&kot; तब इस्तेमाल किया जाएगा, जब --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",
            },
          )