सामान्य नियम

नियम

• उपनाम
• 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 फ़ंक्शन कॉल को सेव करने के लिए, बदलाव के नाम वाले नियम का भी इस्तेमाल किया जा सकता है.

उपनाम वाले नियम के लिए, दिखने की जानकारी अलग से दी जाती है. दूसरे सभी मामलों में, यह बताए गए नियम की तरह काम करता है (उदाहरण के लिए, उपनाम पर सिर्फ़ टेस्ट करने के लिए इस्तेमाल होने वाले तरीके को अनदेखा किया जाता है; इसके बजाय, रेफ़र किए गए नियम की सिर्फ़ पुष्टि करने की सुविधा का इस्तेमाल किया जाता है) की तरह:

• अगर कमांड लाइन में टेस्ट के उपनाम का इस्तेमाल किया जाता है, तो टेस्ट नहीं चलते. रेफ़रंस किए गए टेस्ट को चलाने वाले किसी उपनाम को तय करने के लिए, 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)

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

उदाहरण

यह पैटर्न, --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 को सेट करता है (साफ़ तौर पर कमांड लाइन पर या सीधे तौर पर .baazrc फ़ाइलों से):

  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, कॉन्फ़िगरेशन की मौजूदा स्थिति से मैच करते हैं, तो क्या होता है, यह जानने के लिए चुनें देखें.
• ऐसे फ़्लैग जिनमें शॉर्टहैंड फ़ॉर्म का इस्तेमाल किया जा सकता है (जैसे, --compilation_mode बनाम -c), उनके लिए values की परिभाषाओं में पूरा फ़ॉर्म इस्तेमाल करना ज़रूरी है. ये किसी भी फ़ॉर्म का इस्तेमाल करके, बोले जाने वाले वाक्यों का अपने-आप मिलान करते हैं.
• अगर किसी फ़्लैग में एक से ज़्यादा वैल्यू होती हैं (जैसे कि --copt=-Da --copt=-Db या सूची के तौर पर स्टारलार्क फ़्लैग), तो 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(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",
    ],
)

तर्क

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/..."] का इस्तेमाल नहीं किया जा सकता.

डिटरमिनिस्टिक आउटपुट लागू करने के लिए, जेनक्वेरी के आउटपुट को लेक्सिकोग्राफ़िक तरीके से क्रम में लगाया जाता है. हालांकि, --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 कमांड का इस्तेमाल करके, एक या उससे ज़्यादा फ़ाइलें जनरेट करता है.

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

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

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

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

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

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

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

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

यह जान-बूझकर बनाया गया है कि जेन नियम किसी deps एट्रिब्यूट की जानकारी नहीं देता है: अन्य बिल्ट-इन नियम, नियमों के बीच पास की गई भाषा पर आधारित मेटा जानकारी का इस्तेमाल करते हैं, ताकि यह अपने-आप तय हो सके कि डिपेंडेंट नियमों को कैसे मैनेज किया जाए. हालांकि, जेन रूल के लिए इस तरह का ऑटोमेशन मुमकिन नहीं है. 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 के कमांड में पास नहीं किए जाते. हालांकि, Basel (लेकिन Blaze नहीं) को उपयोगकर्ता के PATH एनवायरमेंट वैरिएबल की वैल्यू से गुज़रना होता है. PATH की वैल्यू में कोई बदलाव करने पर, Bazel अगले बिल्ड पर कमांड को फिर से चलाएगा.

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

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

सामान्य सलाह

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

तर्क

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 के अंदरूनी इस्तेमाल के लिए है.

तर्क

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

तर्क