सामान्य नियम

नियम

• alias
• 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",
)

तर्क

config_setting

config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, 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, 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 डायरेक्ट्री को क्रॉल करने के लिए, 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, 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"],
)

तर्क

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 कमांड का इस्तेमाल करके एक या उससे ज़्यादा फ़ाइलें जनरेट करता है.

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

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

टेस्ट चलाने के लिए, genrule का इस्तेमाल न करें. जांच और जांच के नतीजों के लिए, खास छूट दी जाती है. इनमें कैश मेमोरी से जुड़ी नीतियां और एनवायरमेंट वैरिएबल शामिल हैं. आम तौर पर, टेस्ट को बिल्ड पूरा होने के बाद और टारगेट आर्किटेक्चर पर चलाना होता है. वहीं, जनरूल को बिल्ड के दौरान और एक्ज़ेक आर्किटेक्चर पर लागू किया जाता है. ये दोनों अलग-अलग हो सकते हैं. अगर आपको सामान्य मकसद के लिए टेस्टिंग का नियम बनाना है, तो 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, हार्ड-कोड किए गए और/या पूरे पाथ पर भरोसा नहीं कर सकते.
• अगर एक जैसे या मिलते-जुलते genrule का इस्तेमाल कई जगहों पर किया जाता है, तो एक सामान्य Starlark मैक्रो लिखें. अगर जनरूल जटिल है, तो उसे किसी स्क्रिप्ट में या 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, 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 (डिफ़ॉल्ट आउटपुट): A ModuleInfo बाइनरी प्रोटो.
• name.textproto (सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो): name.binaryproto का टेक्स्ट प्रोटो वर्शन.

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

तर्क

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 expansion" कहा जाता है. इसके बाद, 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"],
)

तर्क