सामान्य नियम

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
किसी समस्या की शिकायत करें सोर्स देखें

नियम

उपनाम

नियम का सोर्स देखें
alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

alias नियम से एक और नाम बनता है. इसे नियम कहा जा सकता है.

एलियासिंग सिर्फ़ "सामान्य" टारगेट के लिए काम करती है. खास तौर पर, package_group और test_suite को उपनाम नहीं दिया जा सकता.

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

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

उदाहरण

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

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

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए यूनीक नाम.

actual

Label; required

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

कॉन्फ़िगरेशन सेटिंग

नियम का सोर्स देखें
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 टॉप-लेवल के कमांड लाइन फ़्लैग से मेल न खाता हो, लेकिन वह अब भी कुछ बिल्ड टारगेट से मेल खा सकता है.

नोट

  • अगर एक से ज़्यादा 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" } में पहले वाले वैल्यू के बजाय --copt वैल्यू दी जाती है. हालांकि, --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 के लिए, कम से कम एक सेट करना ज़रूरी है.

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए यूनीक नाम.

constraint_values

List of labels; optional; nonconfigurable

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

अगर दो config_setting एक ही select में मेल खाते हैं, तो इस एट्रिब्यूट को यह नहीं माना जाता कि कोई config_setting, किसी दूसरे प्रॉडक्ट की विशेषज्ञता है या नहीं. दूसरे शब्दों में, एक config_setting किसी प्लैटफ़ॉर्म से ज़्यादा मज़बूत नहीं हो सकता.

define_values

Dictionary: String -> String; optional; nonconfigurable

यह values की तरह है, लेकिन खास तौर पर --define फ़्लैग के लिए.

--define खास है, क्योंकि इसके सिंटैक्स (--define KEY=VAL) का मतलब है कि KEY=VAL value Bazel फ़्लैग के नज़रिये से है.

इसका मतलब है कि:

            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

Dictionary: label -> String; optional; nonconfigurable

यह values की तरह है, लेकिन उपयोगकर्ता के तय किए गए बिल्ड फ़्लैग के लिए.

यह एक खास एट्रिब्यूट है, क्योंकि उपयोगकर्ता के फ़्लैग किए गए फ़्लैग का इस्तेमाल लेबल के तौर पर किया जाता है. हालांकि, पहले से मौजूद फ़्लैग को आर्बिट्ररी स्ट्रिंग के तौर पर इस्तेमाल किया जाता है.

values

Dictionary: String -> String; optional; nonconfigurable

इस नियम से मेल खाने वाली कॉन्फ़िगरेशन वैल्यू का सेट (इसे बिल्ड फ़्लैग के तौर पर दिखाया जाता है)

यह नियम, कॉन्फ़िगर किए गए टारगेट का कॉन्फ़िगरेशन इनहेरिट करता है. यह select स्टेटमेंट में इसका रेफ़रंस देता है. अगर इसे डिक्शनरी में किसी भी एंट्री के लिए, अनुमानित वैल्यू से मैच किया जाता है, तो उसे "बेज़ल" शुरू होने का नाम माना जाता है. उदाहरण के लिए, values = {"compilation_mode": "opt"}, टारगेट के लिए कॉन्फ़िगर किए गए नियमों पर bazel build --compilation_mode=opt ... और bazel build -c opt ... शुरू करने के अनुरोधों से मेल खाता हो.

सुविधा के लिए, कॉन्फ़िगरेशन वैल्यू को बिल्ड फ़्लैग (पिछले "--" के बिना) के तौर पर बताया जाता है. हालांकि, इस बात का ध्यान रखें कि दोनों एक जैसे नहीं हैं. इसकी वजह यह है कि टारगेट एक ही बिल्ड में कई कॉन्फ़िगरेशन में बनाए जा सकते हैं. उदाहरण के लिए, होस्ट कॉन्फ़िगरेशन का "सीपीयू" --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

Name; required

इस टारगेट के लिए यूनीक नाम.

srcs

List of labels; optional

ऐसे टारगेट की सूची जो फ़ाइल ग्रुप के सदस्य हैं.

srcs एट्रिब्यूट की वैल्यू के लिए, ग्लोब एक्सप्रेशन का इस्तेमाल करना आम बात है.

data

List of labels; optional

रनटाइम के समय इस नियम के लिए ज़रूरी फ़ाइलों की सूची.

data एट्रिब्यूट में मौजूद टारगेट को, इस filegroup नियम के runfiles में जोड़ा जाएगा. जब किसी दूसरे नियम के data एट्रिब्यूट में filegroup को रेफ़र किया जाता है, तो उसके runfiles को उस नियम के runfiles में जोड़ा जाता है. डेटा फ़ाइलों पर निर्भर करने और उनके इस्तेमाल के बारे में ज़्यादा जानकारी के लिए डेटा डिपेंडेंसी सेक्शन और data का सामान्य दस्तावेज़ देखें.

output_group

String; optional

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

"आउटपुट ग्रुप", टारगेट के आउटपुट आर्टफ़ैक्ट की कैटगरी है. इसे नियम के लागू होने में बताया जाता है.

Genquery

नियम का सोर्स देखें
genquery(name, deps, data, compatible_with, 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/..."] की अनुमति नहीं है).

खोज क्वेरी का आउटपुट, --order_output=full का इस्तेमाल करके ऑर्डर किया जाता है, ताकि डेटरमिस्टिक आउटपुट लागू किया जा सके.

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

उदाहरण

इस उदाहरण में, फ़ाइल के लिए तय किए गए टारगेट के ट्रांज़िट समय में लेबल की सूची बनाई गई है.

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

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए यूनीक नाम.

expression

String; required

चलाया जाने वाली क्वेरी. BUILD फ़ाइलों में कमांड लाइन और अन्य जगहों के उलट, यहां दिए गए लेबल, फ़ाइल फ़ोल्डर की रूट डायरेक्ट्री के हिसाब से दिखाए जाते हैं. उदाहरण के लिए, फ़ाइल a/BUILD में एट्रिब्यूट में मौजूद :b लेबल, टारगेट //:b का रेफ़रंस देगा.
opts

List of strings; optional

वे विकल्प जो क्वेरी इंजन को पास किए जाते हैं. ये कमांड लाइन के विकल्प हैं, जिन्हें bazel query को भेजा जा सकता है. यहां कुछ क्वेरी विकल्पों की अनुमति नहीं है: --keep_going, --query_file, --universe_scope, --order_results, और --order_output. यहां नहीं दिए गए विकल्पों की डिफ़ॉल्ट वैल्यू bazel query की कमांड लाइन की तरह ही होंगी.
scope

null; required

क्वेरी का दायरा. क्वेरी को इन टारगेट को, कुछ समय के लिए बंद करने के बाद, टारगेट को छूने की अनुमति नहीं है.
strict

Boolean; optional; default is True

अगर सही है, तो उन क्वेरी को नहीं बनाया जा सकेगा जिनकी क्वेरी, उनके दायरे को कुछ समय के लिए बंद करने से बचें. गलत होने पर, Bazel एक चेतावनी प्रिंट करेगा. साथ ही, उस क्वेरी पाथ को छोड़कर, जो उसे दायरे से बाहर रखते हुए क्वेरी के बाकी हिस्से को पूरा करेगा.

Genrule

नियम का सोर्स देखें
genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exec_tools, 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 का इस्तेमाल करें.

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

क्रॉस-कंपाइलेशन विचार

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

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

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

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

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

खास मामले

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

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

जनरेशन का माहौल

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

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

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

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

सामान्य सलाह

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

उदाहरण

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

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

इस उदाहरण में, filegroup और दूसरे genrule के आउटपुट का इस्तेमाल करने का तरीका बताया गया है. ध्यान दें कि $(location) के लिए अश्लील डायरेक्टिव इस्तेमाल करने के बजाय, $(SRCS) का इस्तेमाल भी किया जा सकता है. इस उदाहरण में, ऊपर दिए गए तरीके का इस्तेमाल करके, Google पर कॉन्टेंट को दिखाने का अनुरोध किया गया है.

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

Name; required

इस टारगेट के लिए यूनीक नाम.


अन्य नियम के srcs या deps सेक्शन में, नाम से इस नियम के बारे में बताया जा सकता है. अगर नियम में सोर्स फ़ाइलें जनरेट की जाती हैं, तो आपको srcs एट्रिब्यूट का इस्तेमाल करना चाहिए.
srcs

List of labels; optional

इस नियम के लिए इनपुट की सूची, जैसे कि प्रोसेस करने के लिए सोर्स फ़ाइलें.

यह एट्रिब्यूट, cmd में लागू होने वाले टूल की सूची बनाने के लिए सही नहीं है. इसके बजाय, tools एट्रिब्यूट का इस्तेमाल करें.

बिल्ड सिस्टम यह पक्का करता है कि इन ज़रूरी शर्तों को genrule कमांड चलाने से पहले बनाया जाए. इन्हें उसी कॉन्फ़िगरेशन का इस्तेमाल करके बनाया जाता है जिसमें मूल रूप से अनुरोध किया गया हो. इन ज़रूरी शर्तों की फ़ाइलों के नाम, $(SRCS) में स्पेस से अलग की गई सूची के तौर पर कमांड के लिए उपलब्ध हैं. इसके अलावा, $(location //x:y) का इस्तेमाल करके, किसी एक srcs टारगेट //x:y का पाथ भी पाया जा सकता है. इसके अलावा, अगर $< में सिर्फ़ यही एंट्री है, तो srcs का इस्तेमाल किया जा सकता है.

outs

List of filenames; required; nonconfigurable

इस नियम से जनरेट की गई फ़ाइलों की सूची.

आउटपुट फ़ाइलों को पैकेज सीमाओं को पार नहीं करना चाहिए. आउटपुट फ़ाइल नामों को पैकेज से संबंधित समझा जाता है.

अगर executable फ़्लैग सेट है, तो outs में ठीक एक लेबल होना चाहिए.

genrule निर्देश से हर आउटपुट फ़ाइल को पहले से तय जगह पर बनाने की उम्मीद की जाती है. जगह की जानकारी, cmd में सही नियम "मेक" वैरिएबल ($@, $(OUTS), $(@D) या $(RULEDIR)) या $(location) के विकल्प का इस्तेमाल करके मिली है.

cmd

String; optional

चलने वाला कमांड. $(location) और "बनाएं" वैरिएबल के विकल्प के हिसाब से.
  1. पहले $(location) को लागू किया जाता है. इसे $(location label) और $(locations label) की सभी घटनाओं (और इससे मिलते-जुलते वैरिएबल execpath, execpaths, rootpath, और rootpaths का इस्तेमाल करके बनाए गए) की जगह लागू किया जाता है.
  2. इसके बाद, "बनाएं" वैरिएबल को बड़ा किया जाता है. ध्यान दें कि $(JAVA), $(JAVAC), और $(JAVABASE) के लिए तय किए गए वैरिएबल, होस्ट कॉन्फ़िगरेशन में ही बड़े किए जाते हैं. इसलिए, बिल्ड चरण के तौर पर चलने वाले Java इनोवेशन, शेयर की गई लाइब्रेरी और अन्य डिपेंडेंसी को सही तरीके से लोड कर सकते हैं.
  3. आखिर में, कमांड को Bash Shell का इस्तेमाल करके एक्ज़ीक्यूट किया जाता है. अगर इसका एग्ज़िट कोड शून्य नहीं है, तो यह माना जाएगा कि कमांड फ़ेल हो गया है.
cmd_bash, cmd_ps, और cmd_bat का फ़ॉलबैक. अगर इनमें से कोई भी लागू नहीं होता है, तो.

अगर कमांड लाइन की लंबाई, प्लैटफ़ॉर्म के लिए तय सीमा (Linux/macOS पर 64K, Windows पर 8K) से ज़्यादा है, तो genrule, स्क्रिप्ट को कमांड लिखेगा और उस स्क्रिप्ट को काम करने देगा. यह सभी cmd एट्रिब्यूट पर लागू होता है (cmd, cmd_bash, cmd_ps, cmd_bat).

cmd_bash

String; optional

चलाने के लिए Bash आदेश.

इस एट्रिब्यूट की प्राथमिकता, cmd से ज़्यादा है. निर्देश को बड़ा करके, cmd एट्रिब्यूट की तरह ही चलाया जाता है.

cmd_bat

String; optional

Windows पर चलाने के लिए एक बैच कमांड.

इस एट्रिब्यूट की प्राथमिकता, cmd और cmd_bash से ज़्यादा है. निर्देश, cmd एट्रिब्यूट की तरह ही काम करता है. इसमें अंतर भी इस अंतर पर लागू होते हैं:

  • यह एट्रिब्यूट सिर्फ़ Windows पर लागू होता है.
  • यह निर्देश, नीचे दिए गए डिफ़ॉल्ट आर्ग्युमेंट के साथ cmd.exe /c पर चलता है:
    • /S - पहले और आखिरी कोट को निकालें और बाकी सब कुछ पहले जैसा ही करें.
    • /E:ON - एक्सटेंडेड कमांड सेट को चालू करें.
    • /V:ON - देरी से वैरिएबल बढ़ाने की सुविधा चालू करें
    • /D - ऑटोरन रजिस्ट्री एंट्री को नज़रअंदाज़ करें.
  • $(location) और "बनाएं" वैरिएबल को बदलने के बाद, पाथ को Windows स्टाइल के पाथ (बैकस्लैश के साथ) के लिए बढ़ा दिया जाएगा.
cmd_ps

String; optional

Windows पर चलने के लिए Powershell आदेश.

इस एट्रिब्यूट की प्राथमिकता cmd, cmd_bash, और cmd_bat से ज़्यादा है. यह निर्देश, cmd एट्रिब्यूट की तरह ही काम करता है. इसमें ये अंतर शामिल हैं:

  • यह एट्रिब्यूट सिर्फ़ Windows पर लागू होता है.
  • निर्देश, powershell.exe /c के साथ चलता है.

PowerShell को इस्तेमाल करना आसान बनाने और गड़बड़ी की आशंका को कम करने के लिए, हम genरूल में PowerShell निर्देश लागू करने से पहले, इन कमांड को चालू करके एनवायरमेंट को सेट अप करते हैं.

  • Set-ExecutionPolicy -Scope CurrentUser RemoteSigned - बिना साइन वाली स्क्रिप्ट चलाने की अनुमति दें.
  • $errorActionPreference='Stop' - अगर ; से अलग किए गए एक से ज़्यादा निर्देशों का इस्तेमाल होता है, तो PowerShell CmdAllow नहीं हो पाने पर कार्रवाई तुरंत बंद हो जाती है. हालांकि, यह बाहरी निर्देश के लिए काम नहीं करता है.
  • $PSDefaultParameterValues['*:Encoding'] = 'utf8' - डिफ़ॉल्ट एन्कोडिंग को utf-16 से utf-8 में बदलें.
exec_tools

List of labels; optional

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

ब्लेज़ टीम exec_tools सिमेंटिक का इस्तेमाल करने के लिए, tools के सभी इस्तेमाल को माइग्रेट कर रही है. उपयोगकर्ताओं को exec_tools को tools पसंद करने की सलाह दी जाती है. इनकी वजह से कोई समस्या नहीं होती. फ़ंक्शनल माइग्रेशन पूरा होने के बाद, हम exec_tools का नाम बदलकर tools कर सकते हैं. ऐसा होने से पहले, आपको समर्थन नहीं होने या रोके जाने की चेतावनी मिलेगी.

executable

Boolean; optional; nonconfigurable; default is False

आउटपुट को एक्ज़ीक्यूटेबल होने का एलान करें.

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

जनरेट किए गए एक्ज़ीक्यूटेबल के लिए, डेटा डिपेंडेंसी का एलान नहीं किया जा सकता.

local

Boolean; optional; default is False

अगर इसे 'सही है' पर सेट किया जाता है, तो इस विकल्प की वजह से, genrule "लोकल" रणनीति का इस्तेमाल करता है. इसका मतलब है कि साइट को कोई दूसरी जगह से नहीं चलाना होगा, किसी सैंडबॉक्स का इस्तेमाल नहीं करना होगा, और न लगातार इस्तेमाल करने वाले वर्कर मिलेंगे.

यह टैग के रूप में 'स्थानीय' देने के बराबर है (tags=["local"]).

message

String; optional

एक प्रोग्रेस मैसेज.

यह चरण पूरा होने पर, एक प्रोग्रेस मैसेज प्रिंट किया जाएगा. डिफ़ॉल्ट रूप से, यह मैसेज "आउटपुट" (या कुछ ऐसा ही होता है) जनरेट करता है, लेकिन आप उससे ज़्यादा सटीक जानकारी दे सकते हैं. अपने cmd निर्देश में echo या किसी दूसरे प्रिंट स्टेटमेंट के बजाय, इस एट्रिब्यूट का इस्तेमाल करें. ऐसा करने से, बिल्ड टूल यह कंट्रोल कर पाता है कि इस तरह के प्रोग्रेस मैसेज प्रिंट किए जाएं या नहीं.

output_licenses

Licence type; optional

common attributes देखें
output_to_bindir

Boolean; optional; nonconfigurable; default is False

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो आउटपुट फ़ाइलों को genfiles डायरेक्ट्री के बजाय, bin डायरेक्ट्री में लिखा जाता है.

tools

List of labels; optional

इस नियम के लिए, टूल डिपेंडेंसी की सूची. ज़्यादा जानकारी के लिए डिपेंडेंसी की परिभाषा देखें.

बिल्ड सिस्टम यह पक्का करता है कि जनरेट करने के निर्देश से पहले, इन शर्तों को बनाया जाए. इन्हें host कॉन्फ़िगरेशन का इस्तेमाल करके बनाया जाता है. ऐसा इसलिए होता है, क्योंकि इन टूल को बिल्ड के हिस्से के तौर पर इस्तेमाल किया जाता है. $(location //x:y) का इस्तेमाल करके, किसी खास tools टारगेट //x:y का पाथ पाया जा सकता है.

cmd से लागू किए जाने वाले *_binary या टूल को इस सूची में दिखना चाहिए, न कि srcs में, ताकि यह पक्का किया जा सके कि वे सही कॉन्फ़िगरेशन में बनाए गए हैं.

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 जैसे शुरू करने के लिए, ब्लेज़ पहले, //some/test:suite टारगेट में शामिल किए गए सभी टेस्ट टारगेट की गणना करता है (इसे "test_suite एक्सपैंशन" कहते हैं). इसके बाद, ब्लेज़ उन टारगेट को बनाता है और उनकी जांच करता है.

उदाहरण

मौजूदा पैकेज में सभी छोटे टेस्ट चलाने के लिए एक टेस्ट सुइट.

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

Name; required

इस टारगेट के लिए यूनीक नाम.

tags

List of strings; optional; nonconfigurable

टेक्स्ट टैग की सूची, जैसे कि "छोटा" या "डेटाबेस" या "-फ़्लैकी". टैग कोई भी मान्य स्ट्रिंग हो सकते हैं.

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

इसके अलावा, पॉज़िटिव टैग को और अच्छे तरीके से दिखाने के लिए, टैग "+" वर्ण से भी शुरू हो सकते हैं. इनका आकलन, टैग के टेक्स्ट के हिस्से के तौर पर नहीं किया जाएगा. इससे, सिर्फ़ सकारात्मक और नेगेटिव, अंतर समझने में मदद मिलती है.

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

manual टैग कीवर्ड को, ऊपर दिए गए तरीके से अलग माना जाता है. ऐसा "test_suite एक्सपैंशन" में, blaze test कमांड से किया जाता है और इसमें वाइल्डकार्ड टारगेट पैटर्न का इस्तेमाल किया जाता है. वहां, "मैन्युअल" के तौर पर टैग किए गए test_suite टारगेट, फ़िल्टर किए जाते हैं (और इसलिए, वे बड़े नहीं होते). यह तरीका blaze build और blaze test के वाइल्डकार्ड टारगेट पैटर्न को मैनेज करने के तरीके से मेल खाता है. ध्यान दें कि यह blaze query 'tests(E)' के काम करने के तरीके से अलग है, क्योंकि सुइट को tests क्वेरी फ़ंक्शन की मदद से हमेशा बड़ा किया जाता है, चाहे manual टैग कोई भी हो.

ध्यान दें कि जांच के लिए, size के टैग को एक टैग माना जाता है.

अगर आपको एक ऐसे test_suite की ज़रूरत है जिसमें खास तरह के सभी टैग वाले टेस्ट शामिल हों, जैसे कि सभी छोटे और मीडियम टेस्ट, तो आपको तीन test_suite नियम बनाने होंगे: एक छोटे टेस्ट के लिए, दूसरा सभी मीडियम टेस्ट के लिए, और दूसरा पिछले दो टेस्ट के लिए.

tests

List of labels; optional; nonconfigurable

टेस्ट सुइट और किसी भी भाषा के टेस्ट टारगेट की सूची.

*_test कोई भी हो, चाहे जो भी हो. हालांकि, कोई भी *_binary टारगेट स्वीकार नहीं किया जाता, भले ही वे टेस्ट करने के लिए क्यों न किए गए हों. बताए गए tags के हिसाब से फ़िल्टर करने की सुविधा, सिर्फ़ उन जांचों के लिए की जाती है जो इस एट्रिब्यूट में सीधे तौर पर सूची में शामिल हैं. अगर इस एट्रिब्यूट में test_suite शामिल हैं, तो उनके अंदर की जांच इस test_suite के हिसाब से फ़िल्टर नहीं की जाएगी. ऐसा माना जाता है कि इन्हें पहले ही फ़िल्टर कर दिया गया है.

अगर tests एट्रिब्यूट तय नहीं है या खाली है, तो यह नियम डिफ़ॉल्ट रूप से मौजूदा BUILD फ़ाइल में टेस्ट के उन सभी नियमों को शामिल करेगा जिन्हें manual के तौर पर टैग नहीं किया गया है. ये नियम अब भी tag फ़िल्टर करने के अधीन हैं.