सामान्य नियम

नियम

• दूसरा ईमेल पता
• config_setting
• फ़ाइलग्रुप
• 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 (या तो साफ़ तौर पर कमांड लाइन पर या सीधे तौर पर .bagelrc फ़ाइलें):

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

उदाहरण

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

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "some/subdirectory/another_file.txt",
    ],
)

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

बिल्ड को एक जैसा बनाए रखने के लिए, क्वेरी को सिर्फ़ 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 का इस्तेमाल करें.

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

क्रॉस-कंपाइलेशन के बारे में ध्यान देने वाली बातें

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

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

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

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

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

खास मामले

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

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

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

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

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

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

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

सामान्य सलाह

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

उदाहरण

यह उदाहरण 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 (डिफ़ॉल्ट आउटपुट): 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 एक्सपैंशन" कहते हैं). इसके बाद, 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"],
)

तर्क