सामान्य नियम

नियम

• उपनाम
• config_setting
• filegroup
• genquery
• जेनरुल
• 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 को सेट करती है (साफ़ तौर पर कमांड लाइन पर या सीधे तौर पर .baZZrc फ़ाइलों से):

  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 या सूची के तौर पर स्टारलार्क फ़्लैग), तो 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(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 का इस्तेमाल करें.

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

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

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

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

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

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

खास मामले

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

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

जेनरुल एनवायरमेंट

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

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

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

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

सामान्य सलाह

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

तर्क