सामान्य नियम

नियम

• उपनाम
• config_setting
• filegroup
• genquery
• genrule
• test_suite

उपनाम

alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

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

• अगर कमांड लाइन में टेस्ट के उपनाम का इस्तेमाल किया जाता है, तो टेस्ट नहीं चलते. रेफ़रंस वाले टेस्ट को चलाने वाले किसी उपनाम को तय करने के लिए, test_suite नियम का इस्तेमाल करें. इसके लिए, tests एट्रिब्यूट में एक टारगेट होना चाहिए.
• एनवायरमेंट ग्रुप तय करते समय, 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 सेट करने वाले किसी भी बिल्ड से मेल खाता है. ऐसा, कमांड-लाइन पर साफ़ तौर पर या .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" } पहले से मैच करता है, लेकिन दूसरे से नहीं. हालांकि, --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, 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 स्टेटमेंट में इसका रेफ़रंस देता है. अगर डिक्शनरी में मौजूद हर एंट्री के लिए, उसका कॉन्फ़िगरेशन एंट्री की उम्मीद की गई वैल्यू से मैच करता है, तो इसे Bazel के इस्तेमाल से "मैच" माना जाता है. उदाहरण के लिए, values = {"compilation_mode": "opt"}, टारगेट के हिसाब से कॉन्फ़िगर किए गए नियमों पर, bazel build --compilation_mode=opt ... और bazel build -c opt ... के साथ मेल खाता है. सुविधा के लिए, कॉन्फ़िगरेशन वैल्यू को बिल्ड फ़्लैग के तौर पर बताया जाता है. हालांकि, इनमें पहले "--" नहीं होता. ध्यान रखें कि ये दोनों एक जैसे नहीं हैं. ऐसा इसलिए होता है, क्योंकि एक ही बिल्ड में कई कॉन्फ़िगरेशन में टारगेट बनाए जा सकते हैं. उदाहरण के लिए, होस्ट कॉन्फ़िगरेशन का "cpu", --cpu की वैल्यू से नहीं, बल्कि --host_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 का इस्तेमाल करने का सुझाव दिया जाता है. दूसरा तरीका सही नहीं है, क्योंकि बिल्ड सिस्टम के पास डायरेक्ट्री के नीचे मौजूद सभी फ़ाइलों के बारे में पूरी जानकारी नहीं होती. इसलिए, हो सकता है कि इन फ़ाइलों में बदलाव होने पर, वह फिर से बिल्ड न करे. glob के साथ इस्तेमाल करने पर, filegroup यह पक्का कर सकता है कि सभी फ़ाइलें, बिल्ड सिस्टम के लिए साफ़ तौर पर जानी जाती हैं.

उदाहरण

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

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

इसके अलावा, testdata डायरेक्ट्री को grovel करने के लिए, glob का इस्तेमाल करें:

filegroup(
    name = "exported_testdata",
    srcs = glob([
        "testdata/*.dat",
        "testdata/logs/**/*.log",
    ]),
)

इन परिभाषाओं का इस्तेमाल करने के लिए, किसी भी नियम के लेबल के साथ filegroup का रेफ़रंस दें:

cc_library(
    name = "my_library",
    srcs = ["foo.cc"],
    data = [
        "//my_package:exported_testdata",
        "//my_package:mygroup",
    ],
)

तर्क

विशेषताएं
name	Name; required इस टारगेट के लिए यूनीक नाम.
srcs	List of labels; optional फ़ाइल ग्रुप के सदस्यों की सूची. आम तौर पर, srcs एट्रिब्यूट की वैल्यू के लिए, glob एक्सप्रेशन के नतीजे का इस्तेमाल किया जाता है.
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(), Blaze क्वेरी भाषा में बताई गई क्वेरी को चलाता है और नतीजे को फ़ाइल में डालता है.

बिल्ड को एक जैसा बनाए रखने के लिए, क्वेरी को सिर्फ़ scope एट्रिब्यूट में बताए गए टारगेट के ट्रांसिशन क्लोज़र पर जाने की अनुमति है. अगर strict की वैल्यू तय नहीं की गई है या 'सही' है, तो इस नियम का उल्लंघन करने वाली क्वेरी को लागू नहीं किया जा सकेगा. अगर strict की वैल्यू 'गलत' है, तो दायरे से बाहर के टारगेट को चेतावनी के साथ स्किप कर दिया जाएगा. ऐसा न हो, इसके लिए सबसे आसान तरीका यह है कि स्कोप में वही लेबल डालें जो क्वेरी एक्सप्रेशन में हैं.

यहां और कमांड लाइन पर इस्तेमाल की जा सकने वाली क्वेरी में सिर्फ़ एक अंतर है. यहां ऐसी क्वेरी इस्तेमाल नहीं की जा सकतीं जिनमें वाइल्डकार्ड टारगेट स्पेसिफ़िकेशन (उदाहरण के लिए, //pkg:* या //pkg:all) शामिल हों. इसकी दो वजहें हैं: पहला, genquery को स्कोप तय करना होता है, ताकि क्वेरी के ट्रांज़िशन क्लोज़र से बाहर के टारगेट को उसके आउटपुट पर असर न डालने दिया जा सके.दूसरा, BUILD फ़ाइलें वाइल्डकार्ड डिपेंडेंसी के साथ काम नहीं करती हैं. उदाहरण के लिए, deps=["//a/..."] का इस्तेमाल नहीं किया जा सकता.

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

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

उदाहरण

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

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

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

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

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

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

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

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

खास मामले

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

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

Genrule एनवायरमेंट

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

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

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

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

सामान्य सलाह

• पक्का करें कि genrule से चलाए जाने वाले टूल, डिटरमिनिस्टिक और हर्मेटिक हों. उन्हें अपने आउटपुट में टाइमस्टैंप नहीं लिखने चाहिए. साथ ही, उन्हें सेट और मैप के लिए स्थिर क्रम का इस्तेमाल करना चाहिए. इसके अलावा, आउटपुट में सिर्फ़ रिलेटिव फ़ाइल पाथ लिखने चाहिए, न कि एब्सोलूट पाथ. इस नियम का पालन न करने पर, बिल्ड का व्यवहार अनचाहा हो सकता है (Bazel उस genrule को फिर से नहीं बनाता जिसे आपने सोचा था कि वह बनाएगा) और कैश मेमोरी की परफ़ॉर्मेंस खराब हो सकती है.
• आउटपुट, टूल, और सोर्स के लिए, $(location) का ज़्यादा से ज़्यादा इस्तेमाल करें. अलग-अलग कॉन्फ़िगरेशन के लिए आउटपुट फ़ाइलों को अलग-अलग रखने की वजह से, genrules, हार्ड कोड और/या एब्सोलूट पाथ पर निर्भर नहीं हो सकता.
• अगर एक ही या काफ़ी मिलते-जुलते genrules का इस्तेमाल कई जगहों पर किया जाता है, तो एक सामान्य Starlark मैक्रो लिखें. अगर genrule जटिल है, तो उसे स्क्रिप्ट में या Starlark नियम के तौर पर लागू करें. इससे कोड को पढ़ने और टेस्ट करने में आसानी होती है.
• पक्का करें कि बाहर निकलने का कोड, genrule के काम करने या न करने के बारे में सही जानकारी देता हो.
• जानकारी देने वाले मैसेज, स्टैंडआउट या स्टैंडर्ड गड़बड़ी वाले आउटपुट में न लिखें. डीबग करने के लिए यह मददगार है, लेकिन यह आसानी से ग़ैर-ज़रूरी जानकारी बन सकता है. सही genrule में ग़ैर-ज़रूरी जानकारी नहीं होनी चाहिए. दूसरी ओर, काम न करने वाले genrule से, गड़बड़ी के अच्छे मैसेज मिलने चाहिए.
• $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x).
• सिंबल लिंक और डायरेक्ट्री बनाने से बचें. Bazel, genrules के बनाए गए डायरेक्ट्री/लिंक के स्ट्रक्चर को कॉपी नहीं करता. साथ ही, डायरेक्ट्री की डिपेंडेंसी की जांच करने की उसकी सुविधा सही नहीं है.
• दूसरे नियमों में genrule का रेफ़रंस देते समय, genrule के लेबल या अलग-अलग आउटपुट फ़ाइलों के लेबल का इस्तेमाल किया जा सकता है. कभी-कभी एक तरीका ज़्यादा पढ़ने लायक होता है और कभी-कभी दूसरा: किसी नियम का इस्तेमाल करने वाले srcs में आउटपुट को नाम से रेफ़र करने से, अनजाने में जनरेट किए गए नियम के अन्य आउटपुट को चुनने से बचा जा सकता है. हालांकि, अगर जनरेट किए गए नियम से कई आउटपुट जनरेट होते हैं, तो यह तरीका मुश्किल हो सकता है.

उदाहरण

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

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

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

genrule(
    name = "concat_all_files",
    srcs = [
        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
        "//other:gen",   # a genrule with a single output ==> $(location)
    ],
    outs = ["concatenated.txt"],
    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)

तर्क

विशेषताएं
name	Name; required इस टारगेट के लिए यूनीक नाम. BUILD के अन्य नियमों के 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 में उपलब्ध है. इसके लिए, genrule के हिसाब से "Make" वैरिएबल ($@, $(OUTS), $(@D) या $(RULEDIR)) का इस्तेमाल करें या $(location) सबस्टिट्यूशन का इस्तेमाल करें.
cmd	String; optional चलाया जाने वाला निर्देश. $(location) और "Make" वैरिएबल के बदले जाने के अधीन है. सबसे पहले $(location) का विकल्प लागू किया जाता है. इससे $(location label) और $(locations label) के सभी उदाहरणों को बदल दिया जाता है. साथ ही, इससे मिलते-जुलते वैरिएबल execpath, execpaths, rootpath, और rootpaths का इस्तेमाल करके बनाए गए मिलते-जुलते कॉन्स्ट्रक्शन भी बदल जाते हैं. इसके बाद, "Make" वैरिएबल को बड़ा किया जाता है. ध्यान दें कि पहले से तय वैरिएबल $(JAVA), $(JAVAC), और $(JAVABASE), होस्ट कॉन्फ़िगरेशन के तहत बड़े हो जाते हैं. इसलिए, बिल्ड चरण के हिस्से के तौर पर चलने वाले Java invocatio, शेयर की गई लाइब्रेरी और अन्य डिपेंडेंसी को सही तरीके से लोड कर सकते हैं. आखिर में, Bash शेल का इस्तेमाल करके, नतीजा देने वाला कमांड चलाया जाता है. अगर इसका बाहर निकलने का कोड, शून्य से ज़्यादा है, तो माना जाता है कि निर्देश पूरा नहीं हुआ. अगर cmd_bash, cmd_ps, और cmd_bat में से कोई भी लागू नहीं होता है, तो यह 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 - AutoRun रजिस्ट्री एंट्री को अनदेखा करें. $(location) और "Make" वैरिएबल के बदले जाने के बाद, पाथ को बैकस्लैश के साथ Windows स्टाइल पाथ में बड़ा किया जाएगा.
cmd_ps	String; optional Windows पर चलाने के लिए Powershell कमांड. इस एट्रिब्यूट की प्राथमिकता, cmd, cmd_bash, और cmd_bat से ज़्यादा है. यह कमांड, cmd एट्रिब्यूट की तरह ही काम करता है. हालांकि, इनमें अंतर है: यह एट्रिब्यूट सिर्फ़ Windows पर लागू होता है. यह निर्देश powershell.exe /c के साथ चलता है. Powershell को इस्तेमाल करना आसान बनाने और उसमें गड़बड़ी होने की संभावना कम करने के लिए, हम genrule में Powershell कमांड को लागू करने से पहले, एनवायरमेंट सेट अप करने के लिए ये कमांड चलाते हैं. Set-ExecutionPolicy -Scope CurrentUser RemoteSigned - बिना हस्ताक्षर वाली स्क्रिप्ट को चलाने की अनुमति दें. $errorActionPreference='Stop' - अगर ; से अलग किए गए एक से ज़्यादा निर्देश हैं, तो Powershell CmdLet के काम न करने पर, कार्रवाई तुरंत बंद हो जाती है. हालांकि, यह बाहरी निर्देश के लिए काम नहीं करता. $PSDefaultParameterValues['*:Encoding'] = 'utf8' - डिफ़ॉल्ट एन्कोडिंग को UTF-16 से UTF-8 में बदलें.
exec_tools	List of labels; optional इस नियम के लिए, टूल की डिपेंडेंसी की सूची. यह एट्रिब्यूट, बिल्कुल tools एट्रिब्यूट की तरह ही काम करता है. हालांकि, इन डिपेंडेंसी को होस्ट कॉन्फ़िगरेशन के बजाय, नियम के लागू होने के प्लैटफ़ॉर्म के लिए कॉन्फ़िगर किया जाएगा. इसका मतलब है कि exec_tools में मौजूद डिपेंडेंसी पर, tools में मौजूद डिपेंडेंसी जैसी सीमाएं लागू नहीं होती हैं. खास तौर पर, उन्हें अपनी ट्रांज़िशन डिपेंडेंसी के लिए, होस्ट कॉन्फ़िगरेशन का इस्तेमाल करने की ज़रूरत नहीं है. ज़्यादा जानकारी के लिए, tools देखें. Blaze टीम, exec_tools के सेमेटिक्स का इस्तेमाल करने के लिए, tools के सभी इस्तेमाल को माइग्रेट कर रही है. हम उपयोगकर्ताओं को exec_tools के बजाय tools का इस्तेमाल करने का सुझाव देते हैं, जहां इससे कोई समस्या न हो. फ़ंक्शनल माइग्रेशन पूरा होने के बाद, हम exec_tools का नाम बदलकर tools कर सकते हैं. ऐसा होने से पहले, आपको इस सुविधा के बंद होने की चेतावनी और माइग्रेट करने के निर्देश मिलेंगे.
executable	Boolean; optional; nonconfigurable; default is False आउटपुट को एक्ज़ीक्यूट किया जा सकने वाला घोषित करें. इस फ़्लैग को 'सही है' पर सेट करने का मतलब है कि आउटपुट एक एक्ज़ीक्यूटेबल फ़ाइल है और इसे run कमांड का इस्तेमाल करके चलाया जा सकता है. इस मामले में, genrule से सिर्फ़ एक आउटपुट जनरेट होना चाहिए. अगर यह एट्रिब्यूट सेट है, तो run फ़ाइल को चलाने की कोशिश करेगा, भले ही उसमें कोई कॉन्टेंट न हो. जनरेट किए गए एक्सीक्यूटेबल के लिए, डेटा डिपेंडेंसी का एलान नहीं किया जा सकता.
local	Boolean; optional; default is False अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो यह genrule को "स्थानीय" रणनीति का इस्तेमाल करके चलाने के लिए मजबूर करता है. इसका मतलब है कि रिमोट से कोई प्रोसेस नहीं की जाएगी, सैंडबॉक्सिंग नहीं होगी, और न ही लगातार काम करने वाले वर्कर्स का इस्तेमाल किया जाएगा. यह टैग (tags=["local"]) के तौर पर '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 इस नियम के लिए, टूल की डिपेंडेंसी की सूची. ज़्यादा जानकारी के लिए, डिपेंडेंसी की परिभाषा देखें. बिल्ड सिस्टम यह पक्का करता है कि genrule कमांड चलाने से पहले, ये ज़रूरी शर्तें पूरी हो गई हों. इन्हें होस्ट कॉन्फ़िगरेशन का इस्तेमाल करके बनाया जाता है, क्योंकि इन टूल को बिल्ड के हिस्से के तौर पर चलाया जाता है. किसी एक tools टारगेट //x:y का पाथ, $(location //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 जैसे किसी इनवोकेशन के लिए, 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	Name; required इस टारगेट के लिए यूनीक नाम.
tags	List of strings; optional; nonconfigurable टेक्स्ट टैग की सूची, जैसे कि "छोटा" या "डेटाबेस" या "-flaky". टैग कोई भी मान्य स्ट्रिंग हो सकती है. "-" वर्ण से शुरू होने वाले टैग को नेगेटिव टैग माना जाता है. इससे पहले मौजूद "-" वर्ण को टैग का हिस्सा नहीं माना जाता. इसलिए, "-small" वाला सुइट टैग, टेस्ट के "small" साइज़ से मैच करता है. बाकी सभी टैग को पॉज़िटिव टैग माना जाता है. इसके अलावा, पॉज़िटिव टैग को ज़्यादा साफ़ तौर पर दिखाने के लिए, टैग को "+" वर्ण से भी शुरू किया जा सकता है. इसका आकलन, टैग के टेक्स्ट के हिस्से के तौर पर नहीं किया जाएगा. इससे, पॉज़िटिव और नेगेटिव रेटिंग को आसानी से पढ़ा जा सकता है. टेस्ट सुइट में सिर्फ़ वे टेस्ट नियम शामिल किए जाएंगे जो सभी पॉज़िटिव टैग और किसी भी नेगेटिव टैग से मैच करते हैं. ध्यान दें कि इसका मतलब यह नहीं है कि फ़िल्टर किए गए टेस्ट पर निर्भरता के लिए, गड़बड़ी की जांच छोड़ दी जाती है.फ़िल्टर किए गए टेस्ट पर निर्भरता अब भी कानूनी होनी चाहिए. उदाहरण के लिए, उन्हें दिखने से जुड़ी पाबंदियों से ब्लॉक नहीं किया जाना चाहिए. manual टैग कीवर्ड को ऊपर दिए गए कीवर्ड से अलग माना जाता है. ऐसा, blaze test कमांड के ज़रिए किए गए "test_suite एक्सपैंशन" की वजह से होता है. यह कमांड, वाइल्डकार्ड वाले टारगेट पैटर्न वाले इनवोकेशन पर काम करता है. वहां, "मैन्युअल" के तौर पर टैग किए गए 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 फ़िल्टर लागू होता है.