BazelCon 2022, 16 नवंबर से 17 नवंबर तक न्यूयॉर्क में और ऑनलाइन उपलब्ध है.
आज ही रजिस्टर करें!

सामान्य नियम

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

नियम

उपनाम

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

config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)

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

उदाहरण

यह मिलान ऐसे किसी भी बिल्ड से मेल खाता है जो --compilation_mode=opt या -c opt को सेट करता है (या तो साफ़ तौर पर कमांड लाइन पर या सीधे तौर पर .bazenrc फ़ाइलों से):

  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 को सेट करता है. इसका मतलब है कि कमांड लाइन पर या इंप्लिसिट तरीके से .bazenrc पर मौजूद फ़ाइलों से ऐसा किया गया है:

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

ये ऐसे किसी भी बिल्ड से मेल खाते हैं जो x86_64 आर्किटेक्चर और glibc वर्शन 2.25 वाले प्लैटफ़ॉर्म को टारगेट करता हो. ऐसा मानते हैं कि constraint_value लेबल //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 या सूची के टाइप वाले स्टारलैक फ़्लैग) हैं, तो 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

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, बेज़ेल फ़्लैग के हिसाब से एक वैल्यू है.

इसका मतलब है:

            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 ... को टारगेट के लिए कॉन्फ़िगर किए गए नियमों से मेल खाता है.

वहीं, सुविधा की मदद से, कॉन्फ़िगरेशन के वैल्यू को बिल्ड फ़्लैग के तौर पर बताया जाता है. इसके लिए, "--" से पहले का इस्तेमाल नहीं किया जाता. हालांकि, ध्यान रखें कि दोनों एक जैसे नहीं होते. ऐसा इसलिए है, क्योंकि एक ही बिल्ड में कई कॉन्फ़िगरेशन में टारगेट बनाए जा सकते हैं. उदाहरण के लिए, होस्ट कॉन्फ़िगरेशन's "cpu&quat; --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 में जोड़े जाएंगे. जब filegroup को किसी दूसरे नियम के data एट्रिब्यूट में बताया जाता है, तो उस नियम के runfiles में runfiles को जोड़ा जाएगा. डेटा फ़ाइलों पर निर्भर रहने और उनका इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, डेटा डिपेंडेंसी सेक्शन और सामान्य दस्तावेज़ data देखें.

output_group

String; optional

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

& वह आउटपुट आउटपुट की टारगेट कैटगरी की कैटगरी है जिसे नियम और #39; को लागू करने में बताया गया है.

जनरेट करें

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

तय किए गए आउटपुट को लागू करने के लिए, genquery' के आउटपुट को --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

List of labels; required

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

Boolean; optional; default is True

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

जनरेट

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

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

क्रॉस-कंपाइलेशन के बारे में खास बातें

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

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

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

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

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

खास मामले

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

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

पर्यावरण सुरक्षा

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

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

एक 'नियम' निर्देश से, नेटवर्क को ऐक्सेस नहीं किया जा सकता. हालांकि, उस प्रोसेस को जोड़ने के लिए ऐसा किया जाता है जो निर्देश (बच्चे) ही हों.

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

सामान्य सलाह

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

उदाहरण

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

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

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

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

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


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

List of labels; optional

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

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

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

outs

List of filenames; required; nonconfigurable

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

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

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

cmd

String; optional

चलाने का निर्देश. $(location) और &kot;make&कोटेशन वैरिएबल के तहत.
  1. पहले $(location) सब्स्टीट्यूशन लागू किया गया, जिसमें $(location label) और $(locations label) के सभी इंस्टेंस को बदला गया है.
  2. ध्यान दें कि इस बदलाव में outs शामिल नहीं है. आउटपुट फ़ाइलें हमेशा अनुमानित जगह पर जनरेट की जाती हैं. यह $(@D), $@, $(OUTS) या $(RULEDIR) या $(location output_name) के ज़रिए उपलब्ध होती है. नीचे देखें.

  3. इसके बाद, "मेक&कोटेशन वैरिएबल को बड़ा किया जाता है. ध्यान दें कि $(JAVA), $(JAVAC), और $(JAVABASE) पहले से तय वैरिएबल, होस्ट कॉन्फ़िगरेशन के तहत बड़े होते हैं. इसलिए, बिल्ड स्टेप के तौर पर चलने वाले Java के शुरू करने पर, शेयर की गई लाइब्रेरी और अन्य डिपेंडेंसी सही तरीके से लोड हो सकती हैं.
  4. आखिर में, कमांड, बैश शेल का इस्तेमाल करके लागू किया जाता है. अगर एग्ज़िट कोड शून्य नहीं है, तो निर्देश को पूरा नहीं माना जा सकता.

यह निर्देश, *_binary टारगेट को रेफ़र कर सकता है; इसके लिए लेबल का इस्तेमाल किया जाना चाहिए. cmd वैरिएबल में ये वैरिएबल उपलब्ध हैं:

  • "मेक&कोटेशन; वैरिएबल
  • & कोटेशन</बनाएं>; ऐसे वैरिएबल जो बिल्ड टूल के पहले से तय होते हैं. कृपया हार्डकोड की गई वैल्यू के बजाय, इन वैरिएबल का इस्तेमाल करें. इस्तेमाल की जा सकने वाली वैल्यू की सूची के लिए, इस दस्तावेज़ में पहले से तय किए गए &कोटेशन बनाएं वैरिएबल देखें.

अगर cmd_bash, cmd_ps, और cmd_bat लागू नहीं होते हैं, तो यह उनका फ़ॉलबैक है.

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

cmd_bash

String; optional

रन करने के लिए बैश निर्देश.

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

cmd_bat

String; optional

Windows पर चलाने के लिए बैच निर्देश.

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

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

String; optional

Windows पर चलाने के लिए PowerShell निर्देश.

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

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

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

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

List of labels; optional

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

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

executable

Boolean; optional; nonconfigurable; default is False

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

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

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

local

Boolean; optional; default is False

अगर इसे 1 पर सेट किया जाता है, तो यह विकल्प हर कार्रवाई के लिएgenrule &&tt>local&kot; रणनीति का इस्तेमाल करता है. इसका मतलब है कि इसे रिमोट तरीके से करने, सैंडबॉक्स करने, और लगातार काम करने वाले लोगों को शामिल करने की ज़रूरत नहीं होती.

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

message

String; optional

प्रगति का मैसेज.

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

output_licenses

Licence type; optional

common attributes देखें
output_to_bindir

Boolean; optional; nonconfigurable; default is False

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

tools

List of labels; optional

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

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

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

जांच_सुइट

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" का एक सुइट टैग टेस्ट के's "छोटे" साइज़ से मेल खाता है. बाकी सभी टैग को पॉज़िटिव टैग माना जाता है.

इसके अलावा, सकारात्मक टैग को और साफ़ तौर पर दिखाने के लिए टैग, &&kot;+&ott; वर्ण से भी शुरू हो सकते हैं. इसका आकलन टैग के टेक्स्ट के हिस्से के तौर पर नहीं किया जाएगा. इससे, पेजों पर मिलने वाले सकारात्मक और नेगेटिव टिप्पणियों को आसानी से पढ़ने लायक बनाया जा सकता है.

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

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

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

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

tests

List of labels; optional; nonconfigurable

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

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

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