सामान्य नियम

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

नियम

• उपनाम
• config_setting
• filegroup
• genquery
• genrule
• starlark_doc_extract
• test_suite

उपनाम

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

alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

alias नियम से, नियम का एक और नाम बनता है.

बदली गई वैल्यू का इस्तेमाल सिर्फ़ "सामान्य" टारगेट के लिए किया जा सकता है. खास तौर पर, package_group और test_suite के लिए कोई दूसरा नाम नहीं दिया जा सकता.

बड़ी रिपॉज़िटरी में, किसी टारगेट का नाम बदलने के लिए कई फ़ाइलों में बदलाव करना पड़ता है. ऐसे में, किसी टारगेट का दूसरा नाम देना मददगार हो सकता है. अगर आपको एक से ज़्यादा टारगेट के लिए उस लॉजिक का फिर से इस्तेमाल करना है, तो select फ़ंक्शन कॉल को सेव करने के लिए, बदलाव के नाम वाले नियम का भी इस्तेमाल किया जा सकता है.

उपनाम वाले नियम के लिए, दिखने की जानकारी अलग से दी जाती है. बाकी सभी मामलों में, यह उस नियम की तरह काम करता है जिसका रेफ़रंस दिया गया है. उदाहरण के लिए, उपनाम पर testonly को अनदेखा किया जाता है. इसके बजाय, रेफ़र किए गए नियम के testonly-ness का इस्तेमाल किया जाता है. हालांकि, इसमें कुछ छोटे अपवाद हैं:

• अगर कमांड लाइन में टेस्ट के उपनाम का इस्तेमाल किया जाता है, तो टेस्ट नहीं चलते. रेफ़रंस किए गए टेस्ट को चलाने वाले किसी उपनाम को तय करने के लिए, test_suite नियम का इस्तेमाल करें. इसके लिए, tests एट्रिब्यूट में एक टारगेट होना चाहिए.
• एनवायरमेंट ग्रुप तय करते समय, environment नियमों के लिए उपनाम इस्तेमाल नहीं किए जा सकते. ये --target_environment कमांड लाइन के विकल्प में भी काम नहीं करते.

उदाहरण

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
actual	लेबल; ज़रूरी है वह टारगेट जिससे यह उपनाम जुड़ा है. यह ज़रूरी नहीं है कि यह कोई नियम हो, यह इनपुट फ़ाइल भी हो सकती है.

config_setting

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

config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)

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

उदाहरण

यह पैटर्न, --compilation_mode=opt या -c opt सेट करने वाले किसी भी बिल्ड से मेल खाता है. ऐसा, कमांड-लाइन पर साफ़ तौर पर या .bazelrc फ़ाइलों से अपने-आप हो सकता है:

  config_setting(
      name = "simple",
      values = {"compilation_mode": "opt"}
  )
  

यह ARM को टारगेट करने वाले किसी भी बिल्ड से मैच करता है और कस्टम डिफ़ाइन FOO=bar (उदाहरण के लिए, bazel build --cpu=arm --define FOO=bar ...) लागू करता है:

  config_setting(
      name = "two_conditions",
      values = {
          "cpu": "arm",
          "define": "FOO=bar"
      }
  )
  

यह पैटर्न, ऐसे किसी भी बिल्ड से मैच करता है जो उपयोगकर्ता के तय किए गए फ़्लैग --//custom_flags:foo=1 को सेट करता है. ऐसा, कमांड लाइन पर साफ़ तौर पर या .bazelrc फ़ाइलों से अपने-आप किया जा सकता है:

  config_setting(
      name = "my_custom_flag_is_set",
      flag_values = { "//custom_flags:foo": "1" },
  )
  

यह x86_64 आर्किटेक्चर और glibc के वर्शन 2.25 वाले प्लैटफ़ॉर्म को टारगेट करने वाले किसी भी बिल्ड से मैच करता है. ऐसा तब होता है, जब लेबल //example:glibc_2_25 वाला constraint_value मौजूद हो. ध्यान दें कि अगर कोई प्लैटफ़ॉर्म इन दोनों के अलावा, और भी सीमाओं की वैल्यू तय करता है, तब भी वह मैच करता है.

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  

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

नोट

• अगर एक से ज़्यादा config_setting, कॉन्फ़िगरेशन की मौजूदा स्थिति से मैच करते हैं, तो क्या होगा, यह जानने के लिए चुनें देखें.
• ऐसे फ़्लैग जिनमें शॉर्टहैंड फ़ॉर्म का इस्तेमाल किया जा सकता है (जैसे, --compilation_mode बनाम -c), उनके लिए values की परिभाषाओं में पूरा फ़ॉर्म इस्तेमाल करना ज़रूरी है. ये किसी भी फ़ॉर्म का इस्तेमाल करके, अपने-आप ट्रिगर होने वाले अनुरोधों से मैच होते हैं.
• अगर कोई फ़्लैग एक से ज़्यादा वैल्यू लेता है, जैसे कि --copt=-Da --copt=-Db या सूची टाइप वाला Starlark फ़्लैग, तो values = { "flag": "a" } तब मैच होता है, जब "a" असल सूची में कहीं भी मौजूद हो.

  values = { "myflag": "a,b" } भी इसी तरह काम करता है: यह --myflag=a --myflag=b, --myflag=a --myflag=b --myflag=c, --myflag=a,b, और --myflag=c,b,a से मैच करता है. अलग-अलग फ़्लैग के लिए, सटीक सेमेटिक्स अलग-अलग होते हैं. उदाहरण के लिए, --copt एक ही उदाहरण में एक से ज़्यादा वैल्यू के साथ काम नहीं करता: --copt=a,b से ["a,b"] मिलता है, जबकि --copt=a --copt=b से ["a", "b"] मिलता है. इसलिए, values = { "copt": "a,b" } पहले से मैच करता है, लेकिन दूसरे से नहीं. हालांकि, --ios_multi_cpus (Apple के नियमों के लिए) ऐसा करता है: -ios_multi_cpus=a,b और ios_multi_cpus=a --ios_multi_cpus=b , दोनों ["a", "b"] देते हैं. फ़्लैग की परिभाषाएं देखें और अपनी शर्तों को ध्यान से जांचें, ताकि सही उम्मीदों की पुष्टि की जा सके.

• अगर आपको ऐसी शर्तें तय करनी हैं जो पहले से मौजूद बिल्ड फ़्लैग के हिसाब से नहीं हैं, तो Starlark के हिसाब से तय किए गए फ़्लैग का इस्तेमाल करें. --define का इस्तेमाल भी किया जा सकता है. हालांकि, इससे कम मदद मिलती है और इसका सुझाव नहीं दिया जाता. ज़्यादा जानकारी के लिए, यहां देखें.
• अलग-अलग पैकेज में एक जैसी config_setting परिभाषाओं को दोहराने से बचें. इसके बजाय, किसी कैननिकल पैकेज में बताए गए सामान्य config_setting का रेफ़रंस दें.
• values, define_values, और constraint_values का इस्तेमाल, एक ही config_setting में किसी भी कॉम्बिनेशन में किया जा सकता है. हालांकि, किसी भी config_setting के लिए कम से कम एक को सेट करना ज़रूरी है.

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
constraint_values	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट तौर पर [] constraint_values का कम से कम वह सेट जिसे टारगेट प्लैटफ़ॉर्म को बताना होगा, ताकि वह इस config_setting से मैच कर सके. (कार्रवाई करने वाले प्लैटफ़ॉर्म को यहां शामिल नहीं किया जाता.) प्लैटफ़ॉर्म पर मौजूद अन्य पाबंदियों की वैल्यू को अनदेखा कर दिया जाता है. ज़्यादा जानकारी के लिए, कॉन्फ़िगर किए जा सकने वाले बिल्ड एट्रिब्यूट देखें. अगर दो config_setting एक ही select से मैच करते हैं, तो यह तय करने के लिए कि इनमें से कोई एक config_setting, दूसरे की विशेषता है या नहीं, इस एट्रिब्यूट को ध्यान में नहीं रखा जाता. दूसरे शब्दों में, एक config_setting किसी प्लैटफ़ॉर्म से दूसरे प्लैटफ़ॉर्म से ज़्यादा मैच नहीं कर सकता.
define_values	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; nonconfigurable; डिफ़ॉल्ट {} है यह values जैसा ही है, लेकिन खास तौर पर --define फ़्लैग के लिए. --define खास है, क्योंकि इसके सिंटैक्स (--define KEY=VAL) का मतलब है कि KEY=VAL, Bazel फ़्लैग के हिसाब से वैल्यू है. इसका मतलब है कि: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) काम नहीं करता, क्योंकि डिक्शनरी में एक ही बटन (define) दो बार दिखता है. इस एट्रिब्यूट की मदद से, इस समस्या को हल किया जा सकता है: config_setting( name = "a_and_b", define_values = { "a": "1", "b": "2", }) bazel build //foo --define a=1 --define b=2 से सही तरीके से मेल खाता हो. --define अब भी सामान्य फ़्लैग सिंटैक्स के साथ, values में दिख सकता है. साथ ही, जब तक डिक्शनरी की कुंजियां अलग-अलग रहती हैं, तब तक इस एट्रिब्यूट के साथ इसे आसानी से मिलाया जा सकता है.
flag_values	डिक्शनरी: label -> स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट {} है यह values जैसा ही है, लेकिन यह उपयोगकर्ता के तय किए गए बिल्ड फ़्लैग के लिए है. यह एक अलग एट्रिब्यूट है, क्योंकि उपयोगकर्ता के तय किए गए फ़्लैग को लेबल के तौर पर रेफ़र किया जाता है, जबकि पहले से मौजूद फ़्लैग को मनमुताबिक स्ट्रिंग के तौर पर रेफ़र किया जाता है.
values	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; nonconfigurable; डिफ़ॉल्ट {} है इस नियम से मैच करने वाली कॉन्फ़िगरेशन वैल्यू का सेट (बिल्ड फ़्लैग के तौर पर दिखाया गया) यह नियम, कॉन्फ़िगर किए गए उस टारगेट का कॉन्फ़िगरेशन इनहेरिट करता है जो select स्टेटमेंट में इसका रेफ़रंस देता है. अगर डिक्शनरी में मौजूद हर एंट्री के लिए, उसका कॉन्फ़िगरेशन एंट्री की उम्मीद की गई वैल्यू से मैच करता है, तो इसे Bazel के इस्तेमाल से "मैच" माना जाता है. उदाहरण के लिए, values = {"compilation_mode": "opt"}, टारगेट के हिसाब से कॉन्फ़िगर किए गए नियमों पर, bazel build --compilation_mode=opt ... और bazel build -c opt ... के साथ मेल खाता है. सुविधा के लिए, कॉन्फ़िगरेशन वैल्यू को बिल्ड फ़्लैग के तौर पर बताया जाता है. हालांकि, इनमें पहले "--" नहीं होता. ध्यान रखें कि ये दोनों एक जैसे नहीं हैं. ऐसा इसलिए होता है, क्योंकि एक ही बिल्ड में कई कॉन्फ़िगरेशन में टारगेट बनाए जा सकते हैं. उदाहरण के लिए, exec कॉन्फ़िगरेशन का "cpu", --cpu की वैल्यू से नहीं, बल्कि --host_cpu की वैल्यू से मैच करता है. इसलिए, एक ही config_setting के अलग-अलग इंस्टेंस, एक ही कॉल को अलग-अलग तरीके से मैच कर सकते हैं. यह इस बात पर निर्भर करता है कि उनका इस्तेमाल करने वाले नियम का कॉन्फ़िगरेशन क्या है. अगर कमांड लाइन पर कोई फ़्लैग साफ़ तौर पर सेट नहीं किया गया है, तो उसकी डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है. अगर कोई कीवर्ड डिक्शनरी में कई बार दिखता है, तो सिर्फ़ आखिरी इंस्टेंस का इस्तेमाल किया जाता है. अगर कोई कुंजी किसी ऐसे फ़्लैग का रेफ़रंस देती है जिसे कमांड लाइन पर कई बार सेट किया जा सकता है (उदाहरण के लिए, bazel build --copt=foo --copt=bar --copt=baz ...), तो मैच तब होता है, जब उनमें से कोई भी सेटिंग मैच करती है.

फ़ाइल ग्रुप

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

filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

टारगेट के कलेक्शन को कोई आसान नाम देने के लिए, filegroup का इस्तेमाल करें. इसके बाद, इनका रेफ़रंस दूसरे नियमों से लिया जा सकता है.

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

उदाहरण

दो सोर्स फ़ाइलों वाला filegroup बनाने के लिए,

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "some/subdirectory/another_file.txt",
    ],
)

इसके अलावा, testdata डायरेक्ट्री को grovel करने के लिए, glob का इस्तेमाल करें:

filegroup(
    name = "exported_testdata",
    srcs = glob([
        "testdata/*.dat",
        "testdata/logs/**/*.log",
    ]),
)

इन परिभाषाओं का इस्तेमाल करने के लिए, किसी भी नियम के लेबल के साथ filegroup का रेफ़रंस दें:

cc_library(
    name = "my_library",
    srcs = ["foo.cc"],
    data = [
        "//my_package:exported_testdata",
        "//my_package:mygroup",
    ],
)

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है फ़ाइल ग्रुप के सदस्यों की सूची. आम तौर पर, srcs एट्रिब्यूट की वैल्यू के लिए, glob एक्सप्रेशन के नतीजे का इस्तेमाल किया जाता है.
data	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम के दौरान, इस नियम के लिए ज़रूरी फ़ाइलों की सूची. data एट्रिब्यूट में नाम वाले टारगेट, इस filegroup नियम के runfiles में जोड़ दिए जाएंगे. जब किसी दूसरे नियम के data एट्रिब्यूट में filegroup का रेफ़रंस दिया जाता है, तो उस नियम के runfiles में runfiles जोड़ दिया जाएगा. डेटा फ़ाइलों पर निर्भर रहने और उनका इस्तेमाल करने के तरीके के बारे में ज़्यादा जानने के लिए, डेटा डिपेंडेंसी सेक्शन और data का सामान्य दस्तावेज़ देखें.
output_group	स्ट्रिंग; डिफ़ॉल्ट रूप से "" वह आउटपुट ग्रुप जिससे सोर्स से आर्टफ़ैक्ट इकट्ठा करने हैं. अगर इस एट्रिब्यूट की वैल्यू दी गई है, तो डिफ़ॉल्ट आउटपुट ग्रुप के बजाय, डिपेंडेंसी के तय किए गए आउटपुट ग्रुप के आर्टफ़ैक्ट एक्सपोर्ट किए जाएंगे. "आउटपुट ग्रुप", किसी टारगेट के आउटपुट आर्टफ़ैक्ट की कैटगरी होती है. इसे नियम के लागू होने के दौरान तय किया जाता है.

genquery

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

genquery(name, deps, data, compatible_with, compressed_output, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)

genquery(), Blaze क्वेरी भाषा में बताई गई क्वेरी को चलाता है और नतीजे को फ़ाइल में डालता है.

बिल्ड को एक जैसा बनाए रखने के लिए, क्वेरी को सिर्फ़ scope एट्रिब्यूट में बताए गए टारगेट के ट्रांसिशन क्लोज़र पर जाने की अनुमति है. अगर strict की वैल्यू तय नहीं की गई है या 'सही' है, तो इस नियम का उल्लंघन करने वाली क्वेरी को लागू नहीं किया जा सकेगा. अगर strict की वैल्यू 'गलत' है, तो दायरे से बाहर के टारगेट को चेतावनी के साथ स्किप कर दिया जाएगा. ऐसा न हो, इसके लिए सबसे आसान तरीका यह है कि स्कोप में वही लेबल डालें जो क्वेरी एक्सप्रेशन में हैं.

यहां और कमांड लाइन पर इस्तेमाल की जा सकने वाली क्वेरी में सिर्फ़ एक अंतर है. यहां ऐसी क्वेरी इस्तेमाल नहीं की जा सकतीं जिनमें वाइल्डकार्ड टारगेट स्पेसिफ़िकेशन (उदाहरण के लिए, //pkg:* या //pkg:all) शामिल हों. इसकी दो वजहें हैं: पहला, genquery को स्कोप तय करना होता है, ताकि क्वेरी के ट्रांज़िशन क्लोज़र के बाहर के टारगेट को उसके आउटपुट पर असर न डालने दिया जा सके.दूसरा, BUILD फ़ाइलें वाइल्डकार्ड डिपेंडेंसी के साथ काम नहीं करती हैं. उदाहरण के लिए, deps=["//a/..."] का इस्तेमाल नहीं किया जा सकता.

genquery के आउटपुट को, तय नतीजे देने के लिए, वर्णमाला के क्रम में लगाया जाता है. ऐसा --output=graph|minrank|maxrank के अलावा, तब भी किया जाता है, जब somepath का इस्तेमाल टॉप-लेवल फ़ंक्शन के तौर पर किया जाता है.

आउटपुट फ़ाइल का नाम, नियम का नाम होता है.

उदाहरण

इस उदाहरण में, किसी फ़ाइल में दिए गए टारगेट के ट्रांज़िशन क्लोज़र में लेबल की सूची लिखी गई है.

genquery(
    name = "kiwi-deps",
    expression = "deps(//kiwi:kiwi_lib)",
    scope = ["//kiwi:kiwi_lib"],
)

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
compressed_output	बूलियन; डिफ़ॉल्ट तौर पर False अगर True है, तो क्वेरी का आउटपुट GZIP फ़ाइल फ़ॉर्मैट में लिखा जाता है. इस सेटिंग का इस्तेमाल, क्वेरी के आउटपुट के बड़े होने पर, Bazel के मेमोरी इस्तेमाल में होने वाली बढ़ोतरी से बचने के लिए किया जा सकता है. Bazel पहले से ही, 2^20 बाइट से ज़्यादा के क्वेरी आउटपुट को अंदरूनी तौर पर कंप्रेस कर देता है. भले ही, इस सेटिंग की वैल्यू कुछ भी हो. इसलिए, हो सकता है कि इसे True पर सेट करने से, सेव किए गए ढेर का साइज़ कम न हो. हालांकि, इससे Bazel को आउटपुट फ़ाइल लिखते समय डिकंप्रेसन को छोड़ने की अनुमति मिलती है, जो मेमोरी का ज़्यादा इस्तेमाल कर सकती है.
expression	स्ट्रिंग; ज़रूरी है वह क्वेरी जिसे लागू करना है. BUILD फ़ाइलों में कमांड लाइन और अन्य जगहों के मुकाबले, यहां लेबल को वर्कस्पेस की रूट डायरेक्ट्री के हिसाब से हल किया जाता है. उदाहरण के लिए, फ़ाइल a/BUILD में इस एट्रिब्यूट में मौजूद लेबल :b, टारगेट //:b का रेफ़रंस देगा.
opts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] क्वेरी इंजन को दिए जाने वाले विकल्प. ये कमांड-लाइन के उन विकल्पों से जुड़े होते हैं जिन्हें bazel query में पास किया जा सकता है. यहां कुछ क्वेरी विकल्पों की अनुमति नहीं है: --keep_going, --query_file, --universe_scope, --order_results, और --order_output. यहां बताए गए विकल्पों के लिए, डिफ़ॉल्ट वैल्यू वही होंगी जो bazel query की कमांड लाइन में होती हैं.
scope	लेबल की सूची; ज़रूरी है क्वेरी का दायरा. क्वेरी को इन टारगेट के ट्रांज़िशन के क्लोज़र के बाहर के टारगेट को छूने की अनुमति नहीं है.
strict	बूलियन; डिफ़ॉल्ट तौर पर True अगर यह सही है, तो जिन टारगेट की क्वेरी उनके दायरे के ट्रांज़िशन क्लोज़र से बाहर निकलती हैं वे बिल्ड नहीं हो पाएंगी. अगर यह फ़ील्ड गलत है, तो Bazel एक चेतावनी प्रिंट करेगा और बाकी क्वेरी को पूरा करते समय, क्वेरी के उस पाथ को छोड़ देगा जिसकी वजह से वह स्कोप से बाहर निकल गया था.

genrule

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

genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

genrule, उपयोगकर्ता के तय किए गए Bash कमांड का इस्तेमाल करके, एक या उससे ज़्यादा फ़ाइलें जनरेट करता है.

जनरल नियम, सामान्य बिल्ड नियम होते हैं. इनका इस्तेमाल तब किया जा सकता है, जब टास्क के लिए कोई खास नियम न हो. उदाहरण के लिए, Bash का एक लाइन वाला कोड चलाया जा सकता है. हालांकि, अगर आपको C++ फ़ाइलों को कंपाइल करना है, तो cc_* के मौजूदा नियमों का पालन करें, क्योंकि आपके लिए पहले से ही सभी ज़रूरी काम कर लिए गए हैं.

ध्यान दें कि genrule को कमांड आर्ग्युमेंट को समझने के लिए, शेल की ज़रूरत होती है. PATH पर मौजूद किसी भी प्रोग्राम का रेफ़रंस देना भी आसान है. हालांकि, इससे कमांड को हेरमेटिक नहीं बनाया जा सकता और हो सकता है कि उसे दोबारा इस्तेमाल न किया जा सके. अगर आपको सिर्फ़ एक टूल चलाना है, तो इसके बजाय run_binary का इस्तेमाल करें.

टेस्ट चलाने के लिए, genrule का इस्तेमाल न करें. टेस्ट और टेस्ट के नतीजों के लिए, कैश मेमोरी से जुड़ी नीतियां और एनवायरमेंट वैरिएबल के साथ-साथ कुछ खास छूट भी दी जाती हैं. आम तौर पर, टेस्ट को बिल्ड पूरा होने के बाद और टारगेट आर्किटेक्चर पर चलाया जाना चाहिए. वहीं, genrules को बिल्ड के दौरान और exec आर्किटेक्चर पर चलाया जाता है. ये दोनों अलग-अलग हो सकते हैं. अगर आपको सामान्य मकसद के लिए जांच करने का नियम चाहिए, तो sh_test का इस्तेमाल करें.

क्रॉस-कंपाइलेशन से जुड़ी बातें

क्रॉस-कंपाइलेशन के बारे में ज़्यादा जानकारी के लिए, उपयोगकर्ता मैन्युअल देखें.

genrules, बिल्ड के दौरान चलते हैं. हालांकि, उनके आउटपुट का इस्तेमाल अक्सर बिल्ड के बाद, डिप्लॉयमेंट या जांच के लिए किया जाता है. माइक्रोकंट्रोलर के लिए C कोड को कंपाइल करने के उदाहरण पर विचार करें: कंपाइलर, C के सोर्स फ़ाइलों को स्वीकार करता है और माइक्रोकंट्रोलर पर चलने वाला कोड जनरेट करता है. जनरेट किया गया कोड, उस सीपीयू पर नहीं चल सकता जिसका इस्तेमाल उसे बनाने के लिए किया गया था. हालांकि, सोर्स से कॉम्पाइल किए जाने पर, सी कंपाइलर को उस पर चलना होगा.

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

genrules के लिए, बिल्ड सिस्टम यह पक्का करता है कि डिपेंडेंसी सही तरीके से बनाई गई हों: srcs को टारगेट कॉन्फ़िगरेशन के लिए (ज़रूरत पड़ने पर) बनाया जाता है, tools को exec कॉन्फ़िगरेशन के लिए बनाया जाता है, और आउटपुट को टारगेट कॉन्फ़िगरेशन के लिए माना जाता है. यह "Make" वैरिएबल भी उपलब्ध कराता है, जिन्हें genrule कमांड, संबंधित टूल को पास कर सकते हैं.

genrule में deps एट्रिब्यूट का इस्तेमाल नहीं किया जाता है. ऐसा जान-बूझकर किया जाता है: पहले से मौजूद अन्य नियम, भाषा पर निर्भर मेटा जानकारी का इस्तेमाल करते हैं. यह जानकारी, नियमों के बीच भेजी जाती है, ताकि यह अपने-आप तय किया जा सके कि भाषा पर निर्भर नियमों को कैसे मैनेज किया जाए. हालांकि, genrule के लिए इस लेवल का ऑटोमेशन नहीं किया जा सकता. Genrules पूरी तरह से फ़ाइल और रनफ़ाइल के लेवल पर काम करते हैं.

खास मामले

Exec-exec कंपाइलेशन: कुछ मामलों में, बिल्ड सिस्टम को genrules को इस तरह चलाना पड़ता है कि बिल्ड के दौरान भी आउटपुट को चलाया जा सके. उदाहरण के लिए, अगर कोई genrule कोई कस्टम कंपाइलर बनाता है और उसका इस्तेमाल किसी दूसरे genrule में किया जाता है, तो पहले genrule को exec कॉन्फ़िगरेशन के लिए अपना आउटपुट देना होगा. ऐसा इसलिए, क्योंकि दूसरे genrule में कंपाइलर यहीं चलेगा. इस मामले में, बिल्ड सिस्टम अपने-आप सही काम करता है: यह टारगेट कॉन्फ़िगरेशन के बजाय, एक्सीक्यूट कॉन्फ़िगरेशन के लिए पहले genrule के srcs और outs को बनाता है. ज़्यादा जानकारी के लिए, उपयोगकर्ता मैन्युअल देखें.

JDK और C++ टूल: JDK या C++ कंपाइलर सुइट के किसी टूल का इस्तेमाल करने के लिए, बिल्ड सिस्टम इस्तेमाल करने के लिए वैरिएबल का एक सेट उपलब्ध कराता है. ज़्यादा जानकारी के लिए, "Make" वैरिएबल देखें.

Genrule एनवायरमेंट

genrule कमांड को Bash शेल से चलाया जाता है. यह शेल, set -e -o pipefail का इस्तेमाल करके, किसी कमांड या पाइपलाइन के काम न करने पर, काम न करने के लिए कॉन्फ़िगर किया जाता है.

बिल्ड टूल, बैश कमांड को ऐसे प्रोसेस एनवायरमेंट में चलाता है जिसमें सिर्फ़ मुख्य वैरिएबल तय किए जाते हैं. जैसे, PATH, PWD, TMPDIR वगैरह. यह पक्का करने के लिए कि बिल्ड फिर से बनाए जा सकें, उपयोगकर्ता के शेल एनवायरमेंट में तय किए गए ज़्यादातर वैरिएबल, genrule के निर्देश में पास नहीं किए जाते. हालांकि, Bazel (न कि Blaze) उपयोगकर्ता के PATH एनवायरमेंट वैरिएबल की वैल्यू को पास करता है. PATH की वैल्यू में कोई बदलाव करने पर, Bazel अगले बिल्ड पर कमांड को फिर से चलाएगा.

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

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

सामान्य सलाह

• पक्का करें कि genrule से चलाए जाने वाले टूल, डिटरमिनिस्टिक और हर्मेटिक हों. उन्हें अपने आउटपुट में टाइमस्टैंप नहीं लिखने चाहिए. साथ ही, उन्हें सेट और मैप के लिए स्थिर क्रम का इस्तेमाल करना चाहिए. इसके अलावा, आउटपुट में सिर्फ़ रिलेटिव फ़ाइल पाथ लिखने चाहिए, न कि एब्सोलूट पाथ. इस नियम का पालन न करने पर, बिल्ड का व्यवहार अनचाहा हो सकता है (Bazel उस genrule को फिर से नहीं बनाता जिसे आपने सोचा था कि वह बनाएगा) और कैश मेमोरी की परफ़ॉर्मेंस खराब हो सकती है.
• आउटपुट, टूल, और सोर्स के लिए, $(location) का ज़्यादा से ज़्यादा इस्तेमाल करें. अलग-अलग कॉन्फ़िगरेशन के लिए आउटपुट फ़ाइलों को अलग-अलग रखने की वजह से, genrules, हार्ड कोड और/या एब्सोलूट पाथ पर निर्भर नहीं हो सकता.
• अगर एक ही या काफ़ी मिलते-जुलते genrules का इस्तेमाल कई जगहों पर किया जाता है, तो एक सामान्य Starlark मैक्रो लिखें. अगर genrule जटिल है, तो उसे स्क्रिप्ट में या Starlark नियम के तौर पर लागू करें. इससे कोड को पढ़ने और टेस्ट करने में आसानी होती है.
• पक्का करें कि बाहर निकलने का कोड, genrule के काम करने या न करने के बारे में सही जानकारी देता हो.
• जानकारी देने वाले मैसेज, स्टैंडआउट या स्टैंडर्ड गड़बड़ी वाले आउटपुट में न लिखें. डीबग करने के लिए यह मददगार है, लेकिन यह आसानी से ग़ैर-ज़रूरी जानकारी बन सकता है. सही genrule में कोई ग़ैर-ज़रूरी जानकारी नहीं होनी चाहिए. दूसरी ओर, काम न करने वाले genrule से, गड़बड़ी के अच्छे मैसेज मिलने चाहिए.
• $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x).
• सिंबल लिंक और डायरेक्ट्री बनाने से बचें. Bazel, genrules की मदद से बनाई गई डायरेक्ट्री/लिंक के स्ट्रक्चर को कॉपी नहीं करता. साथ ही, डायरेक्ट्री की डिपेंडेंसी की जांच करने की उसकी सुविधा सही नहीं है.
• दूसरे नियमों में genrule का रेफ़रंस देते समय, genrule के लेबल या अलग-अलग आउटपुट फ़ाइलों के लेबल का इस्तेमाल किया जा सकता है. कभी-कभी एक तरीका ज़्यादा पढ़ने लायक होता है और कभी-कभी दूसरा: किसी नियम का इस्तेमाल करने वाले srcs में आउटपुट को नाम से रेफ़र करने से, अनजाने में जनरेट किए गए नियम के अन्य आउटपुट को चुनने से बचा जा सकता है. हालांकि, अगर जनरेट किए गए नियम से कई आउटपुट जनरेट होते हैं, तो यह तरीका मुश्किल हो सकता है.

उदाहरण

यह उदाहरण foo.h जनरेट करता है. कोई सोर्स नहीं है, क्योंकि कमांड में कोई इनपुट नहीं दिया जाता. कमांड से चलने वाली "बाइनरी", genrule वाले पैकेज में मौजूद एक पर्ल स्क्रिप्ट होती है.

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.h"],
    cmd = "./$(location create_foo.pl) > \"$@\"",
    tools = ["create_foo.pl"],
)

यहां दिए गए उदाहरण में, filegroup और किसी दूसरे genrule के आउटपुट का इस्तेमाल करने का तरीका बताया गया है. ध्यान दें कि साफ़ तौर पर बताए गए $(location) निर्देशों के बजाय, $(SRCS) का इस्तेमाल करने पर भी यह काम करेगा. इस उदाहरण में, उदाहरण के तौर पर $(location) का इस्तेमाल किया गया है.

genrule(
    name = "concat_all_files",
    srcs = [
        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
        "//other:gen",   # a genrule with a single output ==> $(location)
    ],
    outs = ["concatenated.txt"],
    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम. BUILD के अन्य नियमों के srcs या deps सेक्शन में, इस नियम को नाम से रेफ़र किया जा सकता है. अगर नियम सोर्स फ़ाइलें जनरेट करता है, तो आपको srcs एट्रिब्यूट का इस्तेमाल करना चाहिए.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है इस नियम के लिए इनपुट की सूची, जैसे कि प्रोसेस करने के लिए सोर्स फ़ाइलें. यह एट्रिब्यूट, cmd से चलाए जाने वाले टूल की सूची बनाने के लिए सही नहीं है. इसके बजाय, tools एट्रिब्यूट का इस्तेमाल करें. बिल्ड सिस्टम यह पक्का करता है कि genrule कमांड को चलाने से पहले, ये ज़रूरी शर्तें पूरी कर ली गई हों. इन्हें उसी कॉन्फ़िगरेशन का इस्तेमाल करके बनाया जाता है जिसका इस्तेमाल ओरिजनल बिल्ड रिक्वेस्ट के लिए किया गया था. $(SRCS) में, इन ज़रूरी शर्तों की फ़ाइलों के नाम, स्पेस से अलग की गई सूची के तौर पर कमांड के लिए उपलब्ध होते हैं. इसके अलावा, किसी एक srcs टारगेट //x:y का पाथ, $(location //x:y) का इस्तेमाल करके या $< का इस्तेमाल करके पाया जा सकता है. हालांकि, ऐसा तब ही किया जा सकता है, जब srcs में सिर्फ़ एक एंट्री हो.
outs	फ़ाइल नामों की सूची; कॉन्फ़िगर नहीं की जा सकती; ज़रूरी है इस नियम से जनरेट हुई फ़ाइलों की सूची. आउटपुट फ़ाइलें, पैकेज की सीमाओं से ज़्यादा नहीं होनी चाहिए. आउटपुट फ़ाइलों के नामों को पैकेज के हिसाब से समझा जाता है. अगर executable फ़्लैग सेट है, तो outs में सिर्फ़ एक लेबल होना चाहिए. genrule कमांड से, हर आउटपुट फ़ाइल को पहले से तय की गई जगह पर बनाया जाना चाहिए. जगह की जानकारी, cmd में उपलब्ध है. इसके लिए, genrule के हिसाब से "Make" वैरिएबल ($@, $(OUTS), $(@D) या $(RULEDIR)) का इस्तेमाल करें या $(location) सबस्टिट्यूशन का इस्तेमाल करें.
cmd	स्ट्रिंग; डिफ़ॉल्ट रूप से "" चलाया जाने वाला निर्देश. $(location) और "Make" वैरिएबल के बदले जाने के अधीन है. सबसे पहले $(location) का विकल्प लागू किया जाता है. इससे $(location label) और $(locations label) के सभी उदाहरणों को बदल दिया जाता है. साथ ही, इससे मिलते-जुलते वैरिएबल execpath, execpaths, rootpath, और rootpaths का इस्तेमाल करके बनाए गए मिलते-जुलते कॉन्स्ट्रक्शन भी बदल जाते हैं. इसके बाद, "Make" वैरिएबल को बड़ा किया जाता है. ध्यान दें कि पहले से तय वैरिएबल $(JAVA), $(JAVAC), और $(JAVABASE), exec कॉन्फ़िगरेशन के तहत बड़े हो जाते हैं. इसलिए, बिल्ड चरण के हिस्से के तौर पर चलने वाले Java invocatio, शेयर की गई लाइब्रेरी और अन्य डिपेंडेंसी को सही तरीके से लोड कर सकते हैं. आखिर में, Bash शेल का इस्तेमाल करके, नतीजा देने वाला कमांड चलाया जाता है. अगर इसका बाहर निकलने का कोड, शून्य से ज़्यादा है, तो माना जाता है कि निर्देश पूरा नहीं हुआ. अगर cmd_bash, cmd_ps, और cmd_bat में से कोई भी लागू नहीं होता है, तो यह cmd_bash, cmd_ps, और cmd_bat के लिए फ़ॉलबैक है. अगर कमांड लाइन की लंबाई, प्लैटफ़ॉर्म की तय सीमा (Linux/macOS पर 64K, Windows पर 8K) से ज़्यादा है, तो genrule कमांड को स्क्रिप्ट में लिखेगा और उस स्क्रिप्ट को चलाएगा. यह सभी cmd एट्रिब्यूट (cmd, cmd_bash, cmd_ps, cmd_bat) पर लागू होता है.
cmd_bash	स्ट्रिंग; डिफ़ॉल्ट रूप से "" चलाया जाने वाला Bash कमांड. इस एट्रिब्यूट की प्राथमिकता, cmd से ज़्यादा है. यह कमांड बड़ा हो जाता है और cmd एट्रिब्यूट की तरह ही काम करता है.
cmd_bat	स्ट्रिंग; डिफ़ॉल्ट रूप से "" Windows पर चलाने के लिए बैच कमांड. इस एट्रिब्यूट की प्राथमिकता, cmd और cmd_bash से ज़्यादा है. यह कमांड, cmd एट्रिब्यूट की तरह ही काम करता है. हालांकि, इनमें ये अंतर हैं: यह एट्रिब्यूट सिर्फ़ Windows पर लागू होता है. यह कमांड cmd.exe /c के साथ इन डिफ़ॉल्ट आर्ग्युमेंट के साथ चलता है: /S - पहले और आखिरी कोट को हटाएं और बाकी सभी को वैसे ही लागू करें. /E:ON - बेहतर कमांड सेट चालू करें. /V:ON - वैरिएबल के दायरे को बाद में बढ़ाने की सुविधा चालू करना /D - AutoRun रजिस्ट्री एंट्री को अनदेखा करें. $(location) और "Make" वैरिएबल के बदले जाने के बाद, पाथ को बैकस्लैश के साथ Windows स्टाइल पाथ में बड़ा किया जाएगा.
cmd_ps	स्ट्रिंग; डिफ़ॉल्ट रूप से "" Windows पर चलाने के लिए Powershell कमांड. इस एट्रिब्यूट की प्राथमिकता, cmd, cmd_bash, और cmd_bat से ज़्यादा है. यह कमांड, cmd एट्रिब्यूट की तरह ही काम करता है. हालांकि, इनमें अंतर है: यह एट्रिब्यूट सिर्फ़ Windows पर लागू होता है. यह निर्देश powershell.exe /c के साथ चलता है. Powershell को इस्तेमाल करना आसान बनाने और उसमें गड़बड़ी होने की संभावना कम करने के लिए, हम genrule में Powershell कमांड को लागू करने से पहले, एनवायरमेंट सेट अप करने के लिए ये कमांड चलाते हैं. Set-ExecutionPolicy -Scope CurrentUser RemoteSigned - बिना हस्ताक्षर वाली स्क्रिप्ट को चलाने की अनुमति दें. $errorActionPreference='Stop' - अगर ; से अलग किए गए कई निर्देश हैं, तो Powershell CmdLet के काम न करने पर, कार्रवाई तुरंत बंद हो जाती है. हालांकि, यह बाहरी निर्देश के लिए काम नहीं करता. $PSDefaultParameterValues['*:Encoding'] = 'utf8' - डिफ़ॉल्ट एन्कोडिंग को UTF-16 से UTF-8 में बदलें.
executable	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट False है आउटपुट को एक्ज़ीक्यूटेबल के तौर पर घोषित करें. इस फ़्लैग को 'सही है' पर सेट करने का मतलब है कि आउटपुट एक एक्ज़ीक्यूटेबल फ़ाइल है और इसे run कमांड का इस्तेमाल करके चलाया जा सकता है. इस मामले में, genrule से सिर्फ़ एक आउटपुट जनरेट होना चाहिए. अगर यह एट्रिब्यूट सेट है, तो run फ़ाइल को चलाने की कोशिश करेगा, फिर चाहे उसमें कोई कॉन्टेंट हो या नहीं. जनरेट किए गए एक्सीक्यूटेबल के लिए, डेटा डिपेंडेंसी का एलान नहीं किया जा सकता.
local	बूलियन; डिफ़ॉल्ट तौर पर False अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो यह genrule को "स्थानीय" रणनीति का इस्तेमाल करके चलाने के लिए मजबूर करता है. इसका मतलब है कि रिमोट से कोई प्रोसेस नहीं की जाएगी, सैंडबॉक्सिंग नहीं होगी, और न ही लगातार काम करने वाले वर्कर्स का इस्तेमाल किया जाएगा. यह टैग (tags=["local"]) के तौर पर 'local' देने के बराबर है.
message	स्ट्रिंग; डिफ़ॉल्ट रूप से "" प्रोग्रेस का मैसेज. प्रोग्रेस मैसेज, जो बिल्ड के इस चरण को पूरा करने पर प्रिंट किया जाएगा. डिफ़ॉल्ट रूप से, मैसेज "आउटपुट जनरेट हो रहा है" (या कोई ऐसा ही सामान्य मैसेज) होता है. हालांकि, आपके पास ज़्यादा जानकारी देने वाला मैसेज देने का विकल्प होता है. अपने cmd कमांड में echo या प्रिंट करने के अन्य स्टेटमेंट के बजाय, इस एट्रिब्यूट का इस्तेमाल करें. इससे, बिल्ड टूल यह कंट्रोल कर सकता है कि प्रगति के ऐसे मैसेज प्रिंट किए जाएं या नहीं.
output_licenses	लाइसेंस का टाइप; डिफ़ॉल्ट रूप से ["none"] पर सेट होता है common attributes देखें
output_to_bindir	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट False है अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो आउटपुट फ़ाइलें genfiles डायरेक्ट्री के बजाय bin डायरेक्ट्री में सेव हो जाती हैं.
tools	लेबल की सूची; डिफ़ॉल्ट [] है इस नियम के लिए, टूल की डिपेंडेंसी की सूची. ज़्यादा जानकारी के लिए, डिपेंडेंसी की परिभाषा देखें. बिल्ड सिस्टम यह पक्का करता है कि genrule कमांड चलाने से पहले, ये ज़रूरी शर्तें पूरी हो गई हों; इन्हें exec कॉन्फ़िगरेशन का इस्तेमाल करके बनाया जाता है, क्योंकि इन टूल को बिल्ड के हिस्से के तौर पर चलाया जाता है. किसी एक tools टारगेट //x:y का पाथ, $(location //x:y) का इस्तेमाल करके पाया जा सकता है. cmd से चलाया जाने वाला कोई भी *_binary या टूल, इस सूची में दिखना चाहिए, न कि srcs में. इससे यह पक्का किया जा सकेगा कि उन्हें सही कॉन्फ़िगरेशन में बनाया गया है.

starlark_doc_extract

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

starlark_doc_extract(name, deps, src, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, render_main_repo_name, restricted_to, symbol_names, tags, target_compatible_with, testonly, visibility)

starlark_doc_extract(), किसी .bzl या .scl फ़ाइल में तय किए गए या फिर से एक्सपोर्ट किए गए नियमों, फ़ंक्शन (मैक्रो शामिल हैं), पहलुओं, और प्रोवाइडर के दस्तावेज़ों को निकालता है. इस नियम का आउटपुट, ModuleInfo बाइनरी प्रोटो है, जैसा कि Bazel सोर्स ट्री में stardoc_output.proto में बताया गया है.

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

• name.binaryproto (डिफ़ॉल्ट आउटपुट): एक ModuleInfo बाइनरी प्रोटो.
• name.textproto (सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो): name.binaryproto का टेक्स्ट प्रोटो वर्शन.

चेतावनी: इस नियम के आउटपुट फ़ॉर्मैट के स्थिर होने की कोई गारंटी नहीं है. इसका मकसद मुख्य रूप से, Stardoc के अंदरूनी इस्तेमाल के लिए है.

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है Starlark फ़ाइलों को रैप करने वाले टारगेट की सूची, जिन्हें load() ने src से load() किया है. आम तौर पर, इन टारगेट को bzl_library टारगेट होना चाहिए, लेकिन starlark_doc_extract नियम ऐसा नहीं करता. साथ ही, वह ऐसे किसी भी टारगेट को स्वीकार करता है जो अपने DefaultInfo में Starlark फ़ाइलें उपलब्ध कराता है. ध्यान दें कि रैप की गई Starlark फ़ाइलें, सोर्स ट्री में मौजूद फ़ाइलें होनी चाहिए. Bazel, load() जनरेट की गई फ़ाइलों को रैप नहीं कर सकता.
src	लेबल; ज़रूरी है वह Starlark फ़ाइल जिससे दस्तावेज़ निकालना है. ध्यान दें कि यह सोर्स ट्री में मौजूद फ़ाइल होनी चाहिए. Bazel, load() जनरेट की गई फ़ाइलों को इस्तेमाल नहीं कर सकता.
render_main_repo_name	बूलियन; डिफ़ॉल्ट तौर पर False अगर यह सही है, तो रिपॉज़िटरी कॉम्पोनेंट के साथ, रिलीज़ किए गए दस्तावेज़ में मुख्य रिपॉज़िटरी में लेबल रेंडर करें (दूसरे शब्दों में, //foo:bar.bzl को @main_repo_name//foo:bar.bzl के तौर पर रिलीज़ किया जाएगा). मुख्य रिपॉज़िटरी के लिए इस्तेमाल किया जाने वाला नाम, मुख्य रिपॉज़िटरी की MODULE.bazel फ़ाइल में मौजूद module(name = ...) से लिया जाता है. हालांकि, अगर Bzlmod चालू है, तो यह नाम मुख्य रिपॉज़िटरी की WORKSPACE फ़ाइल में मौजूद workspace(name = ...) से लिया जाता है. इस एट्रिब्यूट को False पर सेट किया जाना चाहिए, जब सिर्फ़ एक ही रिपॉज़िटरी में इस्तेमाल की जाने वाली Starlark फ़ाइलों के लिए दस्तावेज़ जनरेट किए जा रहे हों. साथ ही, इस एट्रिब्यूट को True पर सेट किया जाना चाहिए, जब दूसरी रिपॉज़िटरी से इस्तेमाल की जाने वाली Starlark फ़ाइलों के लिए दस्तावेज़ जनरेट किए जा रहे हों.
symbol_names	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] एक्सपोर्ट किए गए फ़ंक्शन, नियमों, प्रोवाइडर या पहलुओं (या उन स्ट्रक्चर में जो नेस्ट किए गए हैं) के लिए, दस्तावेज़ निकालने के लिए ज़रूरी नामों की वैकल्पिक सूची. यहां, क्वालीफ़ाइड नाम का मतलब उस नाम से है जिसके तहत मॉड्यूल के उपयोगकर्ता के लिए इकाई उपलब्ध कराई जाती है. इसमें ऐसे सभी स्ट्रक्चर शामिल हैं जिनमें नेमस्पेस के लिए इकाई को नेस्ट किया गया है. starlark_doc_extract किसी इकाई के लिए दस्तावेज़ सिर्फ़ तब दिखाता है, जब इकाई के क्वालीफ़ाइड नाम का हर कॉम्पोनेंट सार्वजनिक हो (दूसरे शब्दों में, क्वालीफ़ाइड नाम के हर कॉम्पोनेंट का पहला वर्ण, "_" नहीं, बल्कि वर्णमाला का होना चाहिए); और symbol_names सूची या तो खाली हो (जो डिफ़ॉल्ट रूप से होता है), या इकाई का क्वालिफ़ाइड नाम या उस स्ट्रक्चर का क्वालिफ़ाइड नाम जिसमें इकाई को नेस्ट किया गया है, symbol_names सूची में शामिल है.

test_suite

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

test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)

test_suite, टेस्ट के ऐसे सेट की जानकारी देता है जिन्हें लोगों के लिए "काम का" माना जाता है. इससे प्रोजेक्ट को टेस्ट के सेट तय करने की अनुमति मिलती है. जैसे, "चेक इन करने से पहले आपको ये टेस्ट करने होंगे", "हमारे प्रोजेक्ट के स्ट्रेस टेस्ट" या "सभी छोटे टेस्ट." blaze test कमांड इस तरह के व्यवस्थित क्रम का पालन करता है: blaze test //some/test:suite जैसे किसी इनवोकेशन के लिए, Blaze सबसे पहले उन सभी टेस्ट टारगेट की सूची बनाता है जिन्हें //some/test:suite टारगेट ने ट्रांज़िटिव तौर पर शामिल किया है (हम इसे "test_suite एक्सपैंशन" कहते हैं). इसके बाद, Blaze उन टारगेट को बनाता है और उनकी जांच करता है.

उदाहरण

मौजूदा पैकेज में सभी छोटे टेस्ट चलाने के लिए टेस्ट सुइट.

test_suite(
    name = "small_tests",
    tags = ["small"],
)

टेस्ट का ऐसा सुइट जो टेस्ट का कोई खास सेट चलाता है:

test_suite(
    name = "smoke_tests",
    tests = [
        "system_unittest",
        "public_api_unittest",
    ],
)

मौजूदा पैकेज में सभी टेस्ट चलाने के लिए टेस्ट सुइट, जो काम के हैं.

test_suite(
    name = "non_flaky_test",
    tags = ["-flaky"],
)

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
tags	स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट [] है टेक्स्ट टैग की सूची, जैसे कि "छोटा" या "डेटाबेस" या "-flaky". टैग कोई भी मान्य स्ट्रिंग हो सकती है. "-" वर्ण से शुरू होने वाले टैग को नेगेटिव टैग माना जाता है. इससे पहले मौजूद "-" वर्ण को टैग का हिस्सा नहीं माना जाता. इसलिए, "-small" वाला सुइट टैग, टेस्ट के "small" साइज़ से मैच करता है. बाकी सभी टैग को पॉज़िटिव टैग माना जाता है. इसके अलावा, अगर आपको पॉज़िटिव टैग को ज़्यादा साफ़ तौर पर दिखाना है, तो टैग को "+" वर्ण से भी शुरू किया जा सकता है. इसका आकलन, टैग के टेक्स्ट के हिस्से के तौर पर नहीं किया जाएगा. इससे, पॉज़िटिव और नेगेटिव रेटिंग को आसानी से पढ़ा जा सकता है. टेस्ट सुइट में सिर्फ़ वे टेस्ट नियम शामिल किए जाएंगे जो सभी पॉज़िटिव टैग और किसी भी नेगेटिव टैग से मैच करते हैं. ध्यान दें कि इसका मतलब यह नहीं है कि फ़िल्टर किए गए टेस्ट पर निर्भरता के लिए, गड़बड़ी की जांच छोड़ दी जाती है.फ़िल्टर किए गए टेस्ट पर निर्भरता अब भी कानूनी होनी चाहिए. उदाहरण के लिए, उन्हें दिखने से जुड़ी पाबंदियों से ब्लॉक नहीं किया जाना चाहिए. manual टैग कीवर्ड को ऊपर दिए गए कीवर्ड से अलग माना जाता है. ऐसा, blaze test कमांड के ज़रिए किए गए "test_suite एक्सपैंशन" की वजह से होता है. यह कमांड, वाइल्डकार्ड वाले टारगेट पैटर्न वाले इनवोकेशन पर काम करता है. वहां, "मैन्युअल" के तौर पर टैग किए गए test_suite टारगेट फ़िल्टर कर दिए जाते हैं. इसलिए, इन्हें बड़ा नहीं किया जाता. यह व्यवहार, blaze build और blaze test के सामान्य तौर पर वाइल्डकार्ड टारगेट पैटर्न को हैंडल करने के तरीके से मेल खाता है. ध्यान दें कि यह blaze query 'tests(E)' के काम करने के तरीके से अलग है, क्योंकि सुइट को हमेशा tests क्वेरी फ़ंक्शन से बड़ा किया जाता है. भले ही, manual टैग कुछ भी हो. ध्यान दें कि फ़िल्टर करने के लिए, किसी टेस्ट के size को टैग माना जाता है. अगर आपको ऐसा test_suite चाहिए जिसमें एक-दूसरे से अलग टैग वाले टेस्ट शामिल हों (उदाहरण के लिए, सभी छोटे और मीडियम टेस्ट), तो आपको तीन test_suite नियम बनाने होंगे: एक सभी छोटे टेस्ट के लिए, एक सभी मीडियम टेस्ट के लिए, और एक जिसमें पहले दो शामिल हों.
tests	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट तौर पर [] किसी भी भाषा के टेस्ट सुइट और टेस्ट टारगेट की सूची. यहां किसी भी भाषा में *_test का इस्तेमाल किया जा सकता है. हालांकि, कोई भी *_binary टारगेट स्वीकार नहीं किया जाता, भले ही वे कोई टेस्ट चला रहे हों. बताए गए tags के हिसाब से फ़िल्टर करने की सुविधा, सिर्फ़ उन टेस्ट के लिए उपलब्ध है जो सीधे इस एट्रिब्यूट में सूची में शामिल हैं. अगर इस एट्रिब्यूट में test_suite शामिल हैं, तो उनमें मौजूद जांचों को इस test_suite से फ़िल्टर नहीं किया जाएगा. इन्हें पहले से फ़िल्टर माना जाता है. अगर tests एट्रिब्यूट की वैल्यू नहीं दी गई है या वह खाली है, तो डिफ़ॉल्ट रूप से, मौजूदा BUILD फ़ाइल में उन सभी टेस्ट नियमों को शामिल किया जाएगा जिन्हें manual के तौर पर टैग नहीं किया गया है. इन नियमों पर अब भी tag फ़िल्टर लागू होता है.