सामान्य नियम

नियम

• alias
• config_setting
• filegroup
• genquery
• genrule
• starlark_doc_extract
• test_suite

उपनाम

alias(name, actual, aspect_hints, compatible_with, deprecation, features, package_metadata, 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",
)

तर्क

config_setting

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

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

उदाहरण

नीचे दिया गया पैटर्न, --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"
      }
  )
  

नीचे दिया गया पैटर्न, user-defined flag सेट करने वाले किसी भी बिल्ड से मेल खाता है. --//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, मौजूदा कॉन्फ़िगरेशन की स्थिति से मेल खाते हैं, तब क्या होता है, इसके लिए select देखें.
• शॉर्टहैंड फ़ॉर्मैट वाले फ़्लैग (जैसे, --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 के लिए कम से कम एक वैल्यू सेट करनी होगी.

तर्क

            config_setting(
                name = "a_and_b",
                values = {
                    "define": "a=1",
                    "define": "b=2",
                })
          

            config_setting(
                name = "a_and_b",
                define_values = {
                    "a": "1",
                    "b": "2",
                })
          

filegroup

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

filegroup का इस्तेमाल करके, एक ही लेबल के तहत टारगेट के सेट के आउटपुट इकट्ठा करें.

filegroup, कमांड लाइन पर या किसी अन्य नियम के एट्रिब्यूट में टारगेट की सूची बनाने का विकल्प नहीं है. ऐसा इसलिए, क्योंकि टारगेट में उनके आउटपुट के अलावा कई अन्य प्रॉपर्टी होती हैं. इन्हें एक ही तरीके से इकट्ठा नहीं किया जाता. हालांकि, यह अब भी कई मामलों में काम आता है. उदाहरण के लिए, genrule के srcs एट्रिब्यूट में या *_binary नियम के data एट्रिब्यूट में.

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

उदाहरण

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

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "//a/library:target",
        "//a/binary:target",
    ],
)

इसके अलावा, testdata डायरेक्ट्री को पूरी तरह से क्रॉल करने के लिए, 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",
    ],
)

तर्क

genquery

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

genquery(), Bazel क्वेरी लैंग्वेज में दी गई क्वेरी को चलाता है और नतीजे को किसी फ़ाइल में डंप करता है.

क्वेरी को एक जैसा बनाए रखने के लिए, इसे सिर्फ़ 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"],
)

तर्क

genrule

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

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

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

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

हर कार्रवाई की तरह, genrules से बनाई गई कार्रवाई को अपनी वर्किंग डायरेक्ट्री के बारे में कुछ भी नहीं मानना चाहिए. Bazel सिर्फ़ यह गारंटी देता है कि उनके बताए गए इनपुट, उस पाथ पर उपलब्ध होंगे जो $(location) उनके लेबल के लिए दिखाता है. उदाहरण के लिए, अगर कार्रवाई सैंडबॉक्स या रिमोट में की जाती है, तो सैंडबॉक्स या रिमोट एक्ज़ीक्यूशन के लागू होने से वर्किंग डायरेक्ट्री तय होगी. अगर इसे सीधे तौर पर (standalone रणनीति का इस्तेमाल करके) चलाया जाता है, तो वर्किंग डायरेक्ट्री, एक्ज़ीक्यूशन रूट होगी. इसका मतलब है कि यह bazel info execution_root का नतीजा होगी.

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

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

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

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

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

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

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

खास मामले

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

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

Genrule Environment

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

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

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

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

सामान्य सलाह

• यह पक्का करें कि जनरूल से चलने वाले टूल, डिटरमिनिस्टिक और हर्मेटिक हों. उन्हें अपने आउटपुट में टाइमस्टैंप नहीं लिखने चाहिए. साथ ही, उन्हें सेट और मैप के लिए स्टेबल ऑर्डरिंग का इस्तेमाल करना चाहिए. इसके अलावा, उन्हें आउटपुट में सिर्फ़ मिलते-जुलते फ़ाइल पाथ लिखने चाहिए, पूरे पाथ नहीं. इस नियम का पालन न करने पर, बिल्ड में अनचाहे बदलाव हो सकते हैं. जैसे, Bazel उस genrule को फिर से नहीं बनाएगा जिसे आपको फिर से बनाना था. साथ ही, इससे कैश मेमोरी की परफ़ॉर्मेंस भी खराब हो सकती है.
• आउटपुट, टूल, और सोर्स के लिए, $(location) का ज़्यादा से ज़्यादा इस्तेमाल करें. अलग-अलग कॉन्फ़िगरेशन के लिए आउटपुट फ़ाइलों को अलग-अलग करने की वजह से, genrules, हार्ड-कोड किए गए और/या पूरे पाथ पर भरोसा नहीं कर सकते.
• अगर एक ही तरह के या मिलते-जुलते कई जनरूल का इस्तेमाल अलग-अलग जगहों पर किया जाता है, तो एक सामान्य Starlark मैक्रो लिखें. अगर genrule जटिल है, तो उसे किसी स्क्रिप्ट में या Starlark नियम के तौर पर लागू करें. इससे कोड को पढ़ना और टेस्ट करना आसान हो जाता है.
• पक्का करें कि एक्ज़िट कोड से, यह सही तरीके से पता चलता हो कि genrule सफल हुआ है या नहीं.
• stdout या stderr पर सूचना देने वाले मैसेज न लिखें. यह डीबग करने के लिए मददगार है. हालांकि, इससे आसानी से नॉइज़ जनरेट हो सकती है. 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 में नाम के हिसाब से आउटपुट का रेफ़रंस देने से, genrule के अन्य आउटपुट को गलती से चुनने से बचा जा सकेगा. हालांकि, अगर genrule कई आउटपुट जनरेट करता है, तो यह तरीका मुश्किल हो सकता है.

उदाहरण

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

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

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

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) > $@",
)

तर्क

starlark_doc_extract

starlark_doc_extract(name, deps, src, data, allow_unused_doc_comments, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, licenses, package_metadata, 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 (डिफ़ॉल्ट आउटपुट): A ModuleInfo बाइनरी प्रोटो.
• name.textproto (सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो): name.binaryproto का टेक्स्ट प्रोटो वर्शन.

तर्क

test_suite

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

test_suite, टेस्ट का एक ऐसा सेट होता है जिसे इंसानों के लिए "काम का" माना जाता है. इससे प्रोजेक्ट, टेस्ट के सेट तय कर सकते हैं. जैसे, "चेकइन से पहले किए जाने वाले टेस्ट", "हमारे प्रोजेक्ट के स्ट्रेस टेस्ट" या "सभी छोटे टेस्ट." bazel test कमांड, इस तरह के संगठन का पालन करती है: bazel test //some/test:suite जैसे इनवोकेशन के लिए, Bazel सबसे पहले //some/test:suite टारगेट में ट्रांज़िटिव तरीके से शामिल किए गए सभी टेस्ट टारगेट की गिनती करता है. इसे "test_suite एक्सपैंशन" कहा जाता है. इसके बाद, Bazel उन टारगेट को बनाता है और उनकी जांच करता है.

उदाहरण

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

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"],
)

तर्क