सामान्य नियम

नियम

• उपनाम
• 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)

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

उदाहरण

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

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

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

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

टेस्ट चलाने के लिए, genrule का इस्तेमाल न करें. टेस्ट और टेस्ट के नतीजों के लिए, कैश मेमोरी से जुड़ी नीतियां और एनवायरमेंट वैरिएबल के साथ-साथ कुछ खास छूट भी दी जाती हैं. आम तौर पर, टेस्ट को बिल्ड पूरा होने के बाद और टारगेट आर्किटेक्चर पर चलाया जाना चाहिए. वहीं, जनरेट किए गए नियमों को बिल्ड के दौरान और एक्सेक्यूट आर्किटेक्चर पर चलाया जाता है. ये दोनों अलग-अलग हो सकते हैं. अगर आपको सामान्य मकसद के लिए जांच करने का नियम चाहिए, तो 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++ कंपाइलर सुइट के किसी टूल का इस्तेमाल करने के लिए, बिल्ड सिस्टम इस्तेमाल करने के लिए वैरिएबल का एक सेट उपलब्ध कराता है. ज़्यादा जानकारी के लिए, "बनाएं" वैरिएबल देखें.

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

तर्क

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

तर्क