सामान्य नियम

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की रिपोर्ट करें सोर्स देखें नाइटली · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

नियम

• दूसरा ईमेल पता
• config_setting
• फ़ाइलग्रुप
• जेनक्वेरी
• जेनरुल
• 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-ness को के बजाय कुछ छोटे अपवादों के साथ) का उपयोग किया जाता है:

• अगर कमांड लाइन में उपनाम का इस्तेमाल किया जाता है, तो जांच नहीं की जाती हैं. उपनाम तय करने के लिए जो रेफ़रेंस टेस्ट करता है, test_suite का इस्तेमाल करें नियम, जिसके tests में एक ही टारगेट हो एट्रिब्यूट की वैल्यू सबमिट करें.
• एनवायरमेंट ग्रुप तय करते समय, environment नियमों के लिए उपनाम नहीं होते हैं समर्थित हैं. ये --target_environment कमांड लाइन में काम नहीं करते विकल्प भी है.

उदाहरण

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
actual	लेबल; आवश्यक वह टारगेट जिससे यह उपनाम दिखाता है. इसके लिए कोई नियम होना ज़रूरी नहीं है. यह एक इनपुट भी हो सकता है फ़ाइल से लिए जाते हैं.

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

  config_setting(
      name = "my_custom_flag_is_set",
      flag_values = { "//custom_flags:foo": "1" },
  )
  

नीचे दिए गए उदाहरण ऐसे किसी भी बिल्ड से मेल खाते हैं जो x86_64 आर्किटेक्चर और glibc वाले प्लैटफ़ॉर्म को टारगेट करता है यह मानते हुए कि लेबल के साथ constraint_value मौजूद है, वर्शन 2.25 //example:glibc_2_25. ध्यान दें कि अगर कोई प्लैटफ़ॉर्म एक से ज़्यादा कीवर्ड को परिभाषित करता है, तो वैल्यू को इन दोनों से ज़्यादा रखें.

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  

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

नोट

• एक से ज़्यादा विज्ञापन जोड़ने पर क्या होगा, यह जानने के लिए चुनें पर जाएं 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"] का उत्पादन करते हैं. फ़्लैग की परिभाषाएं देखें और सटीक अनुमान लगाने के लिए, शर्तों को ध्यान से देखें.

• अगर आपको ऐसी स्थितियां तय करनी हैं जिन्हें बिल्ट-इन बिल्ड फ़्लैग से मॉडल नहीं किया गया है, तो स्टारलार्क के बनाए हुए झंडे. --define का भी इस्तेमाल किया जा सकता है, लेकिन इससे कम ऑफ़र मिलते हैं सहायता ली जाती है और इसका सुझाव नहीं दिया जाता. यहां जाएं: ज़्यादा चर्चा के लिए यहां जाएं.
• अलग-अलग पैकेज में, एक जैसी config_setting परिभाषाएं दोहराने से बचें. इसके बजाय, कैननिकल पैकेज में बताए गए सामान्य config_setting का रेफ़रंस दें.
• values define_values, और constraint_values एक ही config_setting में किसी भी कॉम्बिनेशन में इस्तेमाल किया जा सकता है, लेकिन कम से कम एक का इस्तेमाल करना ज़रूरी है किसी भी दिए गए config_setting के लिए सेट हो.

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
constraint_values	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से [] है constraint_values का कम से कम सेट, जिसे टारगेट प्लैटफ़ॉर्म को तय करना ज़रूरी है ताकि इस config_setting से मेल खा सके. (निष्पादक प्लैटफ़ॉर्म माना जाता है.) प्लैटफ़ॉर्म ने जिन अतिरिक्त कंस्ट्रेंट वैल्यू को शामिल नहीं किया है उन्हें अनदेखा कर दिया जाता है. यहां जाएं: ज़्यादा जानकारी के लिए, कॉन्फ़िगर किए जा सकने वाले बिल्ड एट्रिब्यूट. जब दो config_setting एक ही हों select, तय करने के लिए इस एट्रिब्यूट का इस्तेमाल नहीं किया जाता है क्या config_setting में से कोई एक, किसी अन्य की विशेषज्ञता है. अन्य शब्द, एक config_setting किसी प्लेटफ़ॉर्म से दूसरे से ज़्यादा मेल नहीं खा सकता.
define_values	शब्दकोश: स्ट्रिंग -> String; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से {} है values की तरह है, लेकिन खास तौर पर, --define फ़्लैग के लिए. --define खास है, क्योंकि इसका सिंटैक्स (--define KEY=VAL) का मतलब है कि बेज़ल फ़्लैग के नज़रिए से KEY=VAL एक वैल्यू है. इसका मतलब है कि: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है काम नहीं करता क्योंकि एक ही कुंजी (define) शब्दकोश. इस एट्रिब्यूट की मदद से यह सवाल हल किया जा सकता है: config_setting( name = "a_and_b", define_values = { "a": "1", "b": "2", }) अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है bazel build //foo --define a=1 --define b=2 से सही ढंग से मेल खाता है. --define अब भी यहां दिख सकते हैं सामान्य फ़्लैग सिंटैक्स के साथ values, और इस एट्रिब्यूट के साथ तब तक मिक्स किए जा सकते हैं, जब तक डिक्शनरी की कुंजियां अलग-अलग रहती हैं.
flag_values	शब्दकोश: label -> String; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से {} है values की तरह है, लेकिन के लिए उपयोगकर्ता के तय किए गए बिल्ड फ़्लैग शामिल किए जाएंगे. यह एक अलग एट्रिब्यूट है, क्योंकि उपयोगकर्ता के तय किए हुए फ़्लैग, लेबल के तौर पर रेफ़र किए जाते हैं बिल्ट-इन फ़्लैग को आर्बिट्रेरी स्ट्रिंग के तौर पर बताया जाता है.
values	शब्दकोश: स्ट्रिंग -> String; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से {} है इस नियम से मेल खाने वाली कॉन्फ़िगरेशन वैल्यू का सेट (इसे बिल्ड फ़्लैग के तौर पर दिखाया जाता है) यह नियम, कॉन्फ़िगर किए गए उस टारगेट के कॉन्फ़िगरेशन को इनहेरिट करता है जो इसका रेफ़रंस select स्टेटमेंट में देता है. माना जाता है कि "मिलते-जुलते वीडियो" Basel का अनुरोध करना, अगर, शब्दकोश में प्रत्येक प्रविष्टि के लिए, उसका कॉन्फ़िगरेशन, एंट्री की अनुमानित वैल्यू से मेल खाता है. उदाहरण के लिए values = {"compilation_mode": "opt"} शुरू करने की प्रक्रिया से मेल खाता है bazel build --compilation_mode=opt ... और टारगेट के लिए कॉन्फ़िगर किए गए नियमों के लिए bazel build -c opt .... सुविधा के लिए, कॉन्फ़िगरेशन वैल्यू को बिल्ड फ़्लैग के तौर पर दिखाया जाता है. इनके बिना पिछले "--"). लेकिन ध्यान रखें कि दोनों एक ही नहीं होते. यह ऐसा इसलिए है, क्योंकि टारगेट एक ही कैंपेन में कई कॉन्फ़िगरेशन में बनाए जा सकते हैं बिल्ड. उदाहरण के लिए, किसी exec कॉन्फ़िगरेशन का "cpu" इसके मान से मेल खाता है --host_cpu, --cpu नहीं. इसलिए, अलग-अलग मामलों में वही config_setting, एक ही बात को अलग तरह से मैच कर सकता है जो उनका इस्तेमाल करने वाले नियम के कॉन्फ़िगरेशन पर निर्भर करता है. अगर कमांड लाइन पर फ़्लैग साफ़ तौर पर सेट नहीं किया गया है, तो इसके डिफ़ॉल्ट मान का इस्तेमाल किया जाता है. अगर डिक्शनरी में कोई कुंजी एक से ज़्यादा बार दिखती है, तो सिर्फ़ आखिरी इंस्टेंस का इस्तेमाल किया जाता है. अगर कुंजी किसी ऐसे फ़्लैग का संदर्भ देती है जिसे कमांड लाइन पर कई बार सेट किया जा सकता है (जैसे, bazel build --copt=foo --copt=bar --copt=baz ...), तो मैच तब होता है जब इनमें से कोई भी सेटिंग मेल खाती हैं.

फ़ाइलग्रुप

नियम का सोर्स देखें

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

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
srcs	लेबल की सूची; डिफ़ॉल्ट रूप से [] है उन टारगेट की सूची जो फ़ाइल ग्रुप के सदस्य हैं. किसी समस्या के लिए ग्लोब एक्सप्रेशन के नतीजे का इस्तेमाल करना आम बात है srcs एट्रिब्यूट की वैल्यू.
data	लेबल की सूची; डिफ़ॉल्ट रूप से [] है रनटाइम के दौरान इस नियम के तहत ज़रूरी फ़ाइलों की सूची. data एट्रिब्यूट में दिए गए टारगेट इस filegroup नियम में से runfiles. जब filegroup का संदर्भ इसकी data विशेषता में दिया गया है एक और नियम है, जिसका runfiles runfiles में जोड़ दिया जाएगा का पालन करें. डेटा डिपेंडेंसी देखना अनुभाग और सामान्य दस्तावेज़ डेटा फ़ाइलों पर निर्भर रहने और उन्हें इस्तेमाल करने के तरीके के बारे में ज़्यादा जानने के लिए, data पर जाएं.
output_group	String; "" डिफ़ॉल्ट है वह आउटपुट ग्रुप जिससे सोर्स से आर्टफ़ैक्ट इकट्ठा करना है. अगर यह एट्रिब्यूट तय किया गया है, तो डिपेंडेंसी के तय किए गए आउटपुट ग्रुप के आर्टफ़ैक्ट एक्सपोर्ट किए जाएंगे पर क्लिक करें. "आउटपुट ग्रुप" टारगेट के आउटपुट आर्टफ़ैक्ट की एक कैटगरी है, जिसे नियम लागू करना.

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/..."] अनुमति नहीं है).

डिटरमिनिस्टिक आउटपुट लागू करने के लिए, जेनक्वेरी के आउटपुट को लेक्सिकोग्राफ़िक रूप से व्यवस्थित किया जाता है, अपवाद के साथ --output=graph|minrank|maxrank या जब somepath का इस्तेमाल टॉप-लेवल फ़ंक्शन के तौर पर किया जाता है.

आउटपुट फ़ाइल का नाम ही नियम का नाम होता है.

उदाहरण

यह उदाहरण, फ़ाइल के लिए निर्दिष्ट लक्ष्य.

genquery(
    name = "kiwi-deps",
    expression = "deps(//kiwi:kiwi_lib)",
    scope = ["//kiwi:kiwi_lib"],
)

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
compressed_output	बूलियन; False डिफ़ॉल्ट है अगर True है, तो क्वेरी आउटपुट को GZIP फ़ाइल फ़ॉर्मैट में लिखा जाता है. इस सेटिंग का इस्तेमाल किया जा सकता है का इस्तेमाल करें. बेज़ल यह क्वेरी आउटपुट को 2^20 बाइट से ज़्यादा, अंदरूनी तौर पर कंप्रेस करता है, भले ही इस सेटिंग का मान है, इसलिए इसे True पर सेट करने से हीप. हालांकि, यह आउटपुट फ़ाइल लिखते समय Basel को डिकंप्रेशन करने से नहीं रोकता है, इसमें ज़्यादा मेमोरी खर्च हो सकती है.
expression	String; आवश्यक एक्ज़ीक्यूट की जाने वाली क्वेरी. BUILD फ़ाइलों में कमांड लाइन और अन्य जगहों से उलट, यहां मौजूद लेबल का समाधान, फ़ाइल फ़ोल्डर की रूट डायरेक्ट्री के हिसाब से किया जाता है. उदाहरण के लिए, a/BUILD फ़ाइल में इस एट्रिब्यूट में मौजूद :b लेबल, टारगेट //:b.
opts	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है क्वेरी इंजन को भेजे जाने वाले विकल्प. ये कमांड लाइन के हिसाब से होते हैं विकल्प हैं, जिन्हें bazel query को भेजा जा सकता है. क्वेरी के कुछ विकल्पों की अनुमति नहीं है यहां: --keep_going, --query_file, --universe_scope, --order_results और --order_output. विकल्प यहां नहीं दिए गए हैं इनके डिफ़ॉल्ट मान ठीक वैसे ही होंगे जैसे bazel query की कमांड लाइन पर होते हैं.
scope	लेबल की सूची; आवश्यक क्वेरी का स्कोप. क्वेरी को ट्रांज़िटिव से बाहर के टारगेट को छूने की अनुमति नहीं है इन लक्ष्यों को बंद करने में मदद करे.
strict	बूलियन; True डिफ़ॉल्ट है अगर सही है, तो ऐसे टारगेट जिनके लिए क्वेरी के जवाब देने से जुड़ी क्वेरी के स्कोप की वजह से अस्थायी तौर पर बंद होने से बचा जा सकता है बिल्ड. गलत होने पर, Basel एक चेतावनी प्रिंट करेगा और उस क्वेरी पाथ को छोड़ देगा जो क्वेरी पाथ के बाहर ले गई थी स्कोप का इस्तेमाल करके, बाकी क्वेरी को पूरा करते हैं.

सामान्य

नियम का सोर्स देखें

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_* नियमों के अनुसार, क्योंकि सभी लिफ़्टिंग पहले ही पूरी की जा चुकी हैं आपके लिए.

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

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

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

इस बारे में ज़्यादा जानकारी के लिए इस्तेमाल के लिए गाइड देखें क्रॉस-कंपाइलेशन.

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

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

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

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

खास मामले

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

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

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

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

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

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

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

सामान्य सलाह

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

उदाहरण

इस उदाहरण से foo.h जनरेट हुई है. कोई सोर्स उपलब्ध नहीं है, क्योंकि कमांड नहीं ली जाती इनपुट दें. "बाइनरी" कमांड से रन करने पर, जेनुलेशन के पैकेज में पर्ल स्क्रिप्ट होती है.

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.h"],
    cmd = "./$(location create_foo.pl) > \"$@\"",
    tools = ["create_foo.pl"],
)

नीचे दिए गए उदाहरण में, filegroup का इस्तेमाल करने का तरीका बताया गया है और एक और genrule के आउटपुट पा सकते हैं. ध्यान दें कि इसके बजाय $(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) > $@",
)

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. आप इस नियम को अन्य BUILD का srcs या deps सेक्शन नियम. अगर यह नियम सोर्स फ़ाइलें जनरेट करता है, तो आपको srcs एट्रिब्यूट की वैल्यू सबमिट करें.
srcs	लेबल की सूची; डिफ़ॉल्ट रूप से [] है इस नियम के लिए इनपुट की सूची, जैसे कि प्रोसेस की जाने वाली सोर्स फ़ाइलें. यह एट्रिब्यूट, उन टूल की सूची बनाने के लिए सही नहीं है जिन्हें cmd लागू करता है; इस्तेमाल तो tools एट्रिब्यूट का इस्तेमाल किया जा सकता है. बिल्ड सिस्टम यह पक्का करता है कि जेनरूल का इस्तेमाल करने से पहले, इन ज़रूरी शर्तों को पूरा किया जाए निर्देश दें; इन्हें मूल बिल्ड अनुरोध वाले कॉन्फ़िगरेशन का ही इस्तेमाल करके बनाया जाता है. कॉन्टेंट बनाने इन पूर्वापेक्षाओं की फ़ाइलों के नाम आदेश के लिए $(SRCS) में स्पेस से अलग की गई सूची; इसका मतलब है कि srcs टारगेट //x:y को $(location //x:y) या $< का इस्तेमाल करके हासिल किया जा सकता है, बशर्ते इसमें सिर्फ़ यही एक एंट्री हो srcs.
outs	फ़ाइल नामों की सूची; कॉन्फ़िगर नहीं किया जा सकता; आवश्यक इस नियम के तहत जनरेट की गई फ़ाइलों की सूची. आउटपुट फ़ाइलों को पैकेज की सीमाएं पार नहीं करनी चाहिए. आउटपुट फ़ाइल नामों को पैकेज के हिसाब से समझा जाता है. अगर executable फ़्लैग सेट है, तो outs में सिर्फ़ एक फ़्लैग होना चाहिए लेबल. जेनरूल कमांड से हर आउटपुट फ़ाइल को पहले से तय जगह पर बनाया जाता है. जन नियम के हिसाब से "बनाएं" का इस्तेमाल करके, cmd में जगह उपलब्ध है वैरिएबल ($@, $(OUTS), $(@D) या $(RULEDIR)) या का इस्तेमाल करके $(location) विकल्प.
cmd	String; "" डिफ़ॉल्ट है चलाने के लिए निर्देश. $(location) और "बनाएं" पर निर्भर करता है वैरिएबल की जगह बदलें. $(location label) और $(locations label) (और मिलते-जुलते) सभी इंस्टेंस को बदलते हुए पहला $(location) विकल्प लागू किया गया है संबंधित वैरिएबल execpath, execpaths का इस्तेमाल करके कंस्ट्रक्शन, rootpath और rootpaths). इसके बाद, "बनाएं" वैरिएबल को बड़ा किया जाता है. ध्यान दें कि पहले से तय वैरिएबल $(JAVA), $(JAVAC) और $(JAVABASE) exec कॉन्फ़िगरेशन के तहत बड़ा हो जाता है, ताकि Java का इस्तेमाल शुरू किया जा सके जो बिल्ड चरण के तौर पर चलते हैं, वे शेयर की गई लाइब्रेरी और दूसरी निर्भरता. आखिर में, इससे बनने वाले निर्देश को बैश शेल का इस्तेमाल करके एक्ज़ीक्यूट किया जाता है. अगर उसका एग्ज़िट कोड यह है गैर-शून्य के लिए आदेश को विफल माना जाता है. यह cmd_bash, cmd_ps, और cmd_bat का फ़ॉलबैक है, विकल्प मिलते हैं. अगर कमांड लाइन की लंबाई, प्लैटफ़ॉर्म की सीमा से ज़्यादा है (Linux/macOS पर 64K, Windows पर 8K), तो genral किसी स्क्रिप्ट में कमांड लिखेगा और उस स्क्रिप्ट को काम करने के लिए एक्ज़ीक्यूट करेगा. यह सभी cmd एट्रिब्यूट (cmd, cmd_bash, cmd_ps, cmd_bat).
cmd_bash	String; "" डिफ़ॉल्ट है चलाने के लिए Bash निर्देश. इस एट्रिब्यूट की प्राथमिकता cmd से ज़्यादा है. निर्देश को बड़ा किया जाता है और ठीक उसी तरह काम करता है जैसे cmd एट्रिब्यूट में होता है.
cmd_bat	String; "" डिफ़ॉल्ट है Windows पर चलाने के लिए बैच कमांड. इस एट्रिब्यूट की प्राथमिकता cmd और cmd_bash से ज़्यादा है. यह निर्देश, cmd एट्रिब्यूट की तरह ही काम करता है. क्या अंतर है: यह एट्रिब्यूट सिर्फ़ Windows पर लागू होता है. यह निर्देश cmd.exe /c के साथ इन डिफ़ॉल्ट आर्ग्युमेंट के साथ चलता है: /S - पहले और आखिरी कोटेशन को हटाएं और बाकी सभी को पहले जैसा करें. /E:ON - एक्सटेंडेड कमांड सेट चालू करें. /V:ON - देर से वैरिएबल का एक्सपैंशन चालू करें /D - AutoRun रजिस्ट्री एंट्री को अनदेखा करें. $(location) के बाद और "बनाएं" वैरिएबल के विकल्प को छोड़कर, पाथ Windows स्टाइल पाथ तक बढ़ाया गया (बैकस्लैश के साथ).
cmd_ps	String; "" डिफ़ॉल्ट है Windows पर चलाने के लिए Powershell निर्देश. इस एट्रिब्यूट की प्राथमिकता cmd, cmd_bash, और cmd_bat. यह निर्देश cmd की तरह ही काम करता है एट्रिब्यूट की वैल्यू में बदलाव करें, क्योंकि इनके बीच ये अंतर होते हैं: यह एट्रिब्यूट सिर्फ़ Windows पर लागू होता है. निर्देश powershell.exe /c के साथ चलता है. PowerShell को इस्तेमाल करना आसान बनाने और गड़बड़ियों को कम करने के लिए, हम ये काम करते हैं: कमांड को भी सेट अप करने की ज़रूरत होती है. Set-ExecutionPolicy -Scope CurrentUser RemoteSigned - चलने की अनुमति दें साइन नहीं की गई स्क्रिप्ट. $errorActionPreference='Stop' - कई निर्देश होने पर इन्हें ; से अलग किया जाता है. अगर PowerShell CmdLet फ़ेल होता है, तो कार्रवाई तुरंत बंद हो जाती है, लेकिन यह बाहरी कमांड के लिए काम नहीं करता है. $PSDefaultParameterValues['*:Encoding'] = 'utf8' - डिफ़ॉल्ट वैल्यू बदलें utf-16 से utf-8 में एन्कोड करने का तरीका.
executable	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से False है आउटपुट को एक्ज़ीक्यूटेबल के तौर पर बताएं. इस फ़्लैग को 'सही' पर सेट करने का मतलब है कि आउटपुट एक एक्ज़ीक्यूटेबल फ़ाइल है और उसे run निर्देश. इस मामले में, जेन नियम से सिर्फ़ एक आउटपुट मिलना चाहिए. अगर यह एट्रिब्यूट सेट किया जाता है, तो run फ़ाइल को एक्ज़ीक्यूट करने की कोशिश करेगा, भले ही कॉन्टेंट भी शामिल है. जनरेट की गई एक्ज़ीक्यूटेबल के लिए डेटा डिपेंडेंसी का एलान नहीं किया जा सकता.
local	बूलियन; False डिफ़ॉल्ट है अगर इस नीति को 'सही है' पर सेट किया जाता है, तो यह विकल्प इस genrule को "स्थानीय" का इस्तेमाल करके चलने के लिए मजबूर करता है रणनीति का मतलब है, न तो दूर से एक्ज़ीक्यूशन करना, न सैंडबॉक्सिंग करना, और न ही स्थायी कर्मचारी. यह 'स्थानीय' वैल्यू देने के बराबर है टैग (tags=["local"]) के तौर पर डालें.
message	String; "" डिफ़ॉल्ट है प्रोग्रेस की जानकारी देने वाला मैसेज. बिल्ड का यह चरण पूरा होते ही, प्रोग्रेस का मैसेज प्रिंट किया जाएगा. डिफ़ॉल्ट रूप से, मैसेज "आउटपुट जनरेट हो रहा है" है (या ऐसी ही कुछ अजीब चीज़ें) लेकिन आप हमारे ज़्यादा सटीक है. echo या दूसरे प्रिंट के बजाय इस एट्रिब्यूट का इस्तेमाल करें आपके cmd कमांड में स्टेटमेंट का इस्तेमाल किया जाता है. इससे बिल्ड टूल को यह कंट्रोल करने में मदद मिलती है कि क्या ऐसे प्रगति संदेश प्रिंट किए जाएंगे या नहीं.
output_licenses	लाइसेंस का टाइप; ["none"] डिफ़ॉल्ट है common attributes देखें
output_to_bindir	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से False है अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो इस विकल्प की वजह से आउटपुट फ़ाइलें bin में लिखी जाएंगी genfiles डायरेक्ट्री के बजाय डायरेक्ट्री का इस्तेमाल करें.
tools	लेबल की सूची; डिफ़ॉल्ट रूप से [] है इस नियम के लिए, टूल डिपेंडेंसी की सूची. इसकी परिभाषा देखें डिपेंडेंसी सबमिट करें. बिल्ड सिस्टम यह पक्का करता है कि gen बचाने के लिए निर्देश चलाने से पहले, इन ज़रूरी शर्तों को पूरा किया जाए; इन्हें exec का इस्तेमाल करके बनाया जाता है कॉन्फ़िगरेशन में बदलाव नहीं किया जा सकता, क्योंकि इन टूल को बिल्ड के हिस्से के तौर पर एक्ज़ीक्यूट किया जाता है. इसका पाथ अलग-अलग tools टारगेट //x:y को, इसका इस्तेमाल करके हासिल किया जा सकता है $(location //x:y). cmd से चलाने के लिए, कोई भी *_binary या टूल इसमें दिखना चाहिए सूची में होनी चाहिए, srcs में नहीं. इससे यह पक्का किया जा सकेगा कि उन्हें सही कॉन्फ़िगरेशन में बनाया गया है.

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 बाइनरी प्रोटो है, जैसा कि बताया गया है इंच stardoc_output.proto के लेवल को हाइलाइट कर सकते हैं.

इंप्लिसिट आउटपुट टारगेट

• name.binaryproto (डिफ़ॉल्ट आउटपुट): A ModuleInfo बाइनरी प्रोटो.
• name.textproto (सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो): टेक्स्ट name.binaryproto का प्रोटो वर्शन.

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

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट रूप से [] है Starlark फ़ाइलों को रैप किए जाने वाले टारगेट की सूची जो load()-ed से src. इन टारगेट का इस्तेमाल सामान्य इस्तेमाल के तहत किया जाना चाहिए bzl_library लक्षित करता है, लेकिन starlark_doc_extract नियम उसे लागू नहीं करता है और ऐसा कोई भी लक्ष्य जो अपने DefaultInfo में Starlark फ़ाइलें उपलब्ध कराता है. ध्यान दें कि रैप की गई Starlark फ़ाइलें, सोर्स ट्री में मौजूद होनी चाहिए; बेज़ल यह नहीं कर सकते load() फ़ाइलें जनरेट की गईं.
src	लेबल; आवश्यक एक Starlark फ़ाइल जिससे दस्तावेज़ एक्सट्रैक्ट करना है. ध्यान दें कि यह सोर्स ट्री में मौजूद फ़ाइल होनी चाहिए; बेज़ल load() नहीं कर सकते जनरेट की गई फ़ाइलें.
render_main_repo_name	बूलियन; False डिफ़ॉल्ट है अगर सही है, तो जारी किए गए दस्तावेज़ के मुख्य डेटा स्टोर करने की जगह में, रेपो कॉम्पोनेंट की मदद से लेबल रेंडर करें (दूसरे शब्दों में, //foo:bar.bzl को इसके तौर पर मिटाया जाएगा @main_repo_name//foo:bar.bzl). मुख्य डेटा स्टोर करने की जगह के लिए इस्तेमाल किया जाने वाला नाम, module(name = ...) से मिला है डेटा स्टोर करने की मुख्य जगह की MODULE.bazel फ़ाइल में (अगर Bzlmod चालू है) या डेटा स्टोर करने की मुख्य जगह की WORKSPACE फ़ाइल में workspace(name = ...). इसके लिए दस्तावेज़ जनरेट करते समय, इस एट्रिब्यूट को False पर सेट किया जाना चाहिए Starlark फ़ाइलें जिनका इस्तेमाल सिर्फ़ एक ही डेटा स्टोर करने की जगह में किया जाना चाहिए. इसके अलावा, Starlark की उन फ़ाइलों के लिए दस्तावेज़ जनरेट करते समय True जिनका मकसद डेटा स्टोर करने की अन्य जगहों से इस्तेमाल किया जाता है.
symbol_names	स्ट्रिंग की सूची; [] डिफ़ॉल्ट है एक्सपोर्ट किए गए फ़ंक्शन, नियमों, सेवा देने वाली कंपनियों या पहलुओं के क्वालिफ़ाइड नामों की वैकल्पिक सूची (या के लिए भी इस्तेमाल किया जा सकता है. यहां, विज्ञापन देने वाले लोग या कंपनियां नाम का मतलब उस नाम से है जिसके तहत कोई इकाई, मॉड्यूल के उपयोगकर्ता को उपलब्ध कराई जाती है, इसमें वे निर्देश शामिल हैं जिनमें इकाई को नेमस्पेसिंग के लिए नेस्ट किया गया है. starlark_doc_extract से किसी इकाई के दस्तावेज़ तभी मिलते हैं, जब और सिर्फ़ तभी इनका इस्तेमाल किया जाता हो इकाई के मान्य नाम का हर कॉम्पोनेंट सार्वजनिक है (दूसरे शब्दों में, पहले क्वालिफ़ाइड नाम के हर कॉम्पोनेंट का वर्ण, अक्षर और अंक में होता है, न कि "_"); और symbol_names सूची दोनों में से खाली है (जो डिफ़ॉल्ट है केस), या इकाई का योग्य नाम या किसी ऐसे निर्देश का योग्य नाम जिसमें इकाई नेस्ट किया गया है, यह symbol_names सूची में है.

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

तर्क

विशेषताएं
name	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
tags	स्ट्रिंग की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से [] है "छोटा" जैसे टेक्स्ट टैग की सूची या "डेटाबेस" या "-फ्लैकी". टैग कोई मान्य स्ट्रिंग हो सकती है. "-" से शुरू होने वाले टैग वर्ण को नेगेटिव टैग माना जाता है. कॉन्टेंट बनाने "-" से पहले वर्ण को टैग का हिस्सा नहीं माना जाता है, इसलिए सुइट टैग "-small" का परीक्षण के "छोटे" से मेल खाता है साइज़. अन्य सभी टैग का इस्तेमाल किया जाता है पॉज़िटिव टैग. इसके अलावा, सकारात्मक टैग को ज़्यादा साफ़ तौर पर दिखाने के लिए, टैग की शुरुआत भी "+" वर्ण का इस्तेमाल करें, जिसकी गणना टैग के टेक्स्ट के हिस्से के रूप में नहीं की जाएगी. यह सकारात्मक और नकारात्मक के बीच के अंतर को आसानी से पढ़ा जा सकता है. सिर्फ़ उन नियमों की जांच करें जो सभी पॉज़िटिव टैग से और नेगेटिव किसी भी से मेल नहीं खाते टैग, टेस्ट सुइट में शामिल कर दिए जाएंगे. ध्यान दें कि इसका मतलब यह नहीं कि उस गड़बड़ी की जांच की जाए के लिए, जिन टेस्ट को फ़िल्टर करके बाहर कर दिया गया है उन्हें छोड़ दिया गया है; स्किप की गई डिपेंडेंसी परीक्षण अब भी कानूनी होने चाहिए (उदाहरण के लिए, दिखाई देने की सीमाओं की वजह से ब्लॉक न किया गया हो). manual टैग कीवर्ड को ऊपर दिए गए कीवर्ड से अलग माना जाता है. "test_suite का विस्तार" शुरू करने के लिए blaze test कमांड से परफ़ॉर्म किया गया वाइल्डकार्ड को शामिल करना टारगेट पैटर्न. वहां test_suite लक्ष्य "मैन्युअल" टैग किए गए हैं उन्हें फ़िल्टर करके बाहर किया जाता है (इसलिए, बड़ा किया गया). यह व्यवहार blaze build और blaze test आम तौर पर, वाइल्डकार्ड टारगेट पैटर्न को हैंडल करता है. ध्यान दें कि यह यह blaze query 'tests(E)' के काम करने के तरीके से अलग है, क्योंकि सुइट इसे हमेशा tests क्वेरी फ़ंक्शन से बड़ा किया जाता है, भले ही manual टैग के साथ किया जा सकता है. ध्यान दें कि जांच के size को फ़िल्टर करने के लिए एक टैग माना जाता है. अगर आपको ऐसा test_suite चाहिए जिसमें म्युचुअली एक्सक्लूसिव टैग वाले टेस्ट शामिल हों (उदाहरण के लिए, सभी छोटे और मध्यम स्तर के टेस्ट), आपको तीन test_suite बनाने होंगे नियम: एक सभी छोटे परीक्षणों के लिए, एक सभी मध्यम परीक्षणों के लिए और एक जिसमें पिछले दो.
tests	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से [] है किसी भी भाषा के टेस्ट सुइट और टेस्ट टारगेट की सूची. भाषा के अलावा, यहां किसी भी *_test को स्वीकार किया जाता है. नहीं हालांकि, *_binary टारगेट को स्वीकार किया जाता है, भले ही वे टेस्ट करने के लिए हुए हों. बताए गए tags के हिसाब से फ़िल्टर करने की सुविधा, सीधे तौर पर यहां लिस्ट की गई जांचों के लिए ही काम करती है इस एट्रिब्यूट की वैल्यू सबमिट करें. अगर इस एट्रिब्यूट में test_suite शामिल हैं, तो इसके अंदर की गई जांच उन्हें इस test_suite से फ़िल्टर नहीं किया जाएगा (इन्हें फ़िल्टर किया गया है). अगर tests एट्रिब्यूट की वैल्यू नहीं बताई गई है या कोई वैल्यू नहीं दी गई है, तो नियम डिफ़ॉल्ट रूप से इसमें मौजूदा BUILD फ़ाइल में टेस्ट के वे सभी नियम शामिल हैं जिन्हें इसके तौर पर टैग नहीं किया गया है manual. ये नियम अब भी tag फ़िल्टर के तहत आते हैं.