BaselCon 2024 का रजिस्ट्रेशन अब शुरू हो गया है!

इस पेज का अनुवाद Cloud Translation API से किया गया है.

सामान्य नियम

नियम

दूसरा ईमेल पता
config_setting
फ़ाइलग्रुप
जेनक्वेरी
जेनरुल
test_suite

उपनाम

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

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

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

अन्य नियम के तहत, 'किसको दिखे' सेटिंग का अपना एलान होता है. अन्य सभी मामलों में, यह जैसा कि इस नियम में बताया गया है (उदाहरण के लिए, उपनाम पर सिर्फ़ टेस्ट को नज़रअंदाज़ किया जाता है, सिर्फ़ 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 (या तो साफ़ तौर पर कमांड लाइन पर या सीधे तौर पर .baZZrc फ़ाइलों से):

  config_setting(
      name = "simple",
      values = {"compilation_mode": "opt"}
  )

नीचे दिए गए उदाहरण ऐसे किसी भी बिल्ड से मेल खाते हैं जो ARM को टारगेट करता है और कस्टम डेफ़िनिशन को लागू करता है FOO=bar (उदाहरण के लिए, bazel build --cpu=arm --define FOO=bar ...):

  config_setting(
      name = "two_conditions",
      values = {
          "cpu": "arm",
          "define": "FOO=bar"
      }
  )

नीचे दी गई चीज़ें ऐसे किसी भी बिल्ड से मेल खाती हैं जो सेट की जाती है उपयोगकर्ता के हिसाब से तय किया गया फ़्लैग --//custom_flags:foo=1 (या तो साफ़ तौर पर कमांड लाइन पर या सीधे तौर पर .bagelrc फ़ाइलें):

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

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

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

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

नोट

एक से ज़्यादा विज्ञापन जोड़ने पर क्या होगा, यह जानने के लिए चुनें पर जाएं config_setting का कॉन्फ़िगरेशन, कॉन्फ़िगरेशन की मौजूदा स्थिति से होता है.
उन फ़्लैग के लिए जिनमें शॉर्टहैंड फ़ॉर्म काम करते हैं (जैसे कि --compilation_mode बनाम -c), values परिभाषाओं में फ़ुल फ़ॉर्म का इस्तेमाल किया जाना चाहिए. ये अपने-आप दोनों में से किसी भी फ़ॉर्म का इस्तेमाल करके, बोले जाने वाले वाक्यों का मिलान करना होगा.
अगर किसी फ़्लैग में एक से ज़्यादा वैल्यू (जैसे, --copt=-Da --copt=-Db या सूची का टाइप) इस्तेमाल की जाती हैं Starlark फ़्लैग), values = { "flag": "a" } मेल खाता है, अगर "a" हो असली सूची में कहीं भी मौजूद रहेगा.
values = { "myflag": "a,b" } इसी तरह से काम करता है: यह --myflag=a --myflag=b, --myflag=a --myflag=b --myflag=c, --myflag=a,b और --myflag=c,b,a. सटीक सिमैंटिक अलग-अलग होते हैं फ़्लैग. उदाहरण के लिए, --copt फ़ंक्शन में एक से ज़्यादा वैल्यू को इस्तेमाल नहीं किया जा सकता उदाहरण: --copt=a,b, ["a,b"] देता है, जबकि --copt=a --copt=b, ["a", "b"] देता है (इसलिए values = { "copt": "a,b" }), पूर्व से मेल खाता है, लेकिन बाद वाले से नहीं). लेकिन --ios_multi_cpus (Apple के नियमों के लिए) ऐसा करता है: -ios_multi_cpus=a,b और ios_multi_cpus=a --ios_multi_cpus=b दोनों ["a", "b"] का उत्पादन करते हैं. फ़्लैग की परिभाषाएं देखें और सटीक अनुमान लगाने के लिए, शर्तों को ध्यान से देखें.
अगर आपको ऐसी स्थितियां तय करनी हैं जिन्हें बिल्ट-इन बिल्ड फ़्लैग से मॉडल नहीं किया गया है, तो स्टारलार्क के बनाए हुए झंडे. --define का भी इस्तेमाल किया जा सकता है, लेकिन इससे कम ऑफ़र मिलते हैं सहायता ली जाती है और इसका सुझाव नहीं दिया जाता. यहां जाएं: ज़्यादा चर्चा के लिए यहां जाएं.
अलग-अलग पैकेज में, एक जैसी config_setting परिभाषाएं दोहराने से बचें. इसके बजाय, कैननिकल पैकेज में बताए गए सामान्य config_setting का रेफ़रंस दें.
values define_values, और constraint_values एक ही config_setting में किसी भी कॉम्बिनेशन में इस्तेमाल किया जा सकता है, लेकिन कम से कम एक का इस्तेमाल करना ज़रूरी है किसी भी दिए गए config_setting के लिए सेट हो.

तर्क

विशेषताएं
`name`	`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` स्टेटमेंट में देता है. माना जाता है कि "मिलते-जुलते वीडियो" Basel का अनुरोध करना, अगर, शब्दकोश में प्रत्येक प्रविष्टि के लिए, उसका कॉन्फ़िगरेशन, एंट्री की अनुमानित वैल्यू से मेल खाता है. उदाहरण के लिए `values = {"compilation_mode": "opt"}` शुरू करने की प्रक्रिया से मेल खाता है `bazel build --compilation_mode=opt ...` और टारगेट के लिए कॉन्फ़िगर किए गए नियमों के लिए `bazel build -c opt ...`. सुविधा के लिए, कॉन्फ़िगरेशन वैल्यू को बिल्ड फ़्लैग के तौर पर दिखाया जाता है. इनके बिना पिछले `"--"`). लेकिन ध्यान रखें कि दोनों एक ही नहीं होते. यह ऐसा इसलिए है, क्योंकि टारगेट एक ही कैंपेन में कई कॉन्फ़िगरेशन में बनाए जा सकते हैं बिल्ड. उदाहरण के लिए, होस्ट कॉन्फ़िगरेशन का "cpu" इसके मान से मेल खाता है `--host_cpu`, `--cpu` नहीं. इसलिए, अलग-अलग मामलों में वही `config_setting`, एक ही बात को अलग तरह से मैच कर सकता है जो उनका इस्तेमाल करने वाले नियम के कॉन्फ़िगरेशन पर निर्भर करता है. अगर कमांड लाइन पर फ़्लैग साफ़ तौर पर सेट नहीं किया गया है, तो इसके डिफ़ॉल्ट मान का इस्तेमाल किया जाता है. अगर डिक्शनरी में कोई कुंजी एक से ज़्यादा बार दिखती है, तो सिर्फ़ आखिरी इंस्टेंस का इस्तेमाल किया जाता है. अगर कुंजी किसी ऐसे फ़्लैग का संदर्भ देती है जिसे कमांड लाइन पर कई बार सेट किया जा सकता है (जैसे, `bazel build --copt=foo --copt=bar --copt=baz ...`), तो मैच तब होता है जब इनमें से कोई भी सेटिंग मेल खाती हैं.

फ़ाइलग्रुप

filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

टारगेट के कलेक्शन को एक सुविधाजनक नाम देने के लिए, filegroup का इस्तेमाल करें. इसके बाद, इन नियमों का रेफ़रंस दूसरे नियमों में दिया जा सकता है.

सीधे डायरेक्ट्री का रेफ़रंस देने के बजाय, filegroup का इस्तेमाल करने का सुझाव दिया जाता है. बाद वाली क्वेरी ठीक नहीं होती, क्योंकि बिल्ड सिस्टम के पास सभी फ़ाइलों की पूरी जानकारी नहीं होती ताकि इन फ़ाइलों के बदलने पर यह दोबारा न बने. इसके साथ जोड़ने पर ग्लोब, filegroup यह पक्का कर सकता है कि सभी फ़ाइलें बिल्ड सिस्टम के लिए साफ़ तौर पर पता होता है.

उदाहरण

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

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

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

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

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

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

तर्क

विशेषताएं
`name`	`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` वह आउटपुट ग्रुप जिससे सोर्स से आर्टफ़ैक्ट इकट्ठा करना है. अगर यह एट्रिब्यूट तय किया गया है, तो डिपेंडेंसी के तय किए गए आउटपुट ग्रुप के आर्टफ़ैक्ट एक्सपोर्ट किए जाएंगे पर क्लिक करें. "आउटपुट ग्रुप" टारगेट के आउटपुट आर्टफ़ैक्ट की एक कैटगरी है, जिसे नियम लागू करना.

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

सामान्य

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 को target कॉन्फ़िगरेशन के लिए बनाया गया है (अगर ज़रूरी हो), tools को होस्ट कॉन्फ़िगरेशन के लिए बनाया गया है. साथ ही, आउटपुट को टारगेट कॉन्फ़िगरेशन के लिए सेट होनी चाहिए. यह "बनाएं" वाले वैरिएबल जनरेट करने के निर्देश से जुड़े टूल तक भेजे जा सकते हैं.

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

खास मामले

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

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

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

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

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

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

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

सामान्य सलाह

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

उदाहरण

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

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

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

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

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम. आप इस नियम को अन्य `BUILD` का `srcs` या `deps` सेक्शन नियम. अगर यह नियम सोर्स फ़ाइलें जनरेट करता है, तो आपको `srcs` एट्रिब्यूट की वैल्यू सबमिट करें.
`srcs`	`List of labels; optional` इस नियम के लिए इनपुट की सूची, जैसे कि प्रोसेस की जाने वाली सोर्स फ़ाइलें. यह एट्रिब्यूट, उन टूल की सूची बनाने के लिए सही नहीं है जिन्हें `cmd` लागू करता है; इस्तेमाल तो `tools` एट्रिब्यूट का इस्तेमाल किया जा सकता है. बिल्ड सिस्टम यह पक्का करता है कि जेनरूल का इस्तेमाल करने से पहले, इन ज़रूरी शर्तों को पूरा किया जाए निर्देश दें; इन्हें मूल बिल्ड अनुरोध वाले कॉन्फ़िगरेशन का ही इस्तेमाल करके बनाया जाता है. कॉन्टेंट बनाने इन पूर्वापेक्षाओं की फ़ाइलों के नाम आदेश के लिए `$(SRCS)` में स्पेस से अलग की गई सूची; इसका मतलब है कि `srcs` टारगेट `//x:y` को `$(location //x:y)` या `$<` का इस्तेमाल करके हासिल किया जा सकता है, बशर्ते इसमें सिर्फ़ यही एक एंट्री हो `srcs`.
`outs`	`List of filenames; required; nonconfigurable` इस नियम के तहत जनरेट की गई फ़ाइलों की सूची. आउटपुट फ़ाइलों को पैकेज की सीमाएं पार नहीं करनी चाहिए. आउटपुट फ़ाइल नामों को पैकेज के हिसाब से समझा जाता है. अगर `executable` फ़्लैग सेट है, तो `outs` में सिर्फ़ एक फ़्लैग होना चाहिए लेबल. जेनरूल कमांड से हर आउटपुट फ़ाइल को पहले से तय जगह पर बनाया जाता है. जन नियम के हिसाब से "बनाएं" का इस्तेमाल करके, `cmd` में जगह उपलब्ध है वैरिएबल (`$@`, `$(OUTS)`, `$(@D)` या `$(RULEDIR)`) या का इस्तेमाल करके `$(location)` विकल्प.
`cmd`	`String; optional` चलाने के लिए निर्देश. `$(location)` और "बनाएं" पर निर्भर करता है वैरिएबल की जगह बदलें. `$(location label)` और `$(locations label)` (और मिलते-जुलते) सभी इंस्टेंस को बदलते हुए पहला `$(location)` विकल्प लागू किया गया है संबंधित वैरिएबल `execpath`, `execpaths` का इस्तेमाल करके कंस्ट्रक्शन, `rootpath` और `rootpaths`). इसके बाद, "बनाएं" वैरिएबल को बड़ा किया जाता है. ध्यान दें कि पहले से तय वैरिएबल `$(JAVA)`, `$(JAVAC)` और `$(JAVABASE)` होस्ट कॉन्फ़िगरेशन में बड़ा होता है. इसलिए, Java को शुरू करने की सुविधा मिलती है जो बिल्ड चरण के तौर पर चलते हैं, वे शेयर की गई लाइब्रेरी और दूसरी निर्भरता. आखिर में, इससे बनने वाले निर्देश को बैश शेल का इस्तेमाल करके एक्ज़ीक्यूट किया जाता है. अगर उसका एग्ज़िट कोड यह है गैर-शून्य के लिए आदेश को विफल माना जाता है. यह `cmd_bash`, `cmd_ps`, और `cmd_bat` का फ़ॉलबैक है, विकल्प मिलते हैं. अगर कमांड लाइन की लंबाई, प्लैटफ़ॉर्म की सीमा से ज़्यादा है (Linux/macOS पर 64K, Windows पर 8K), तो genral किसी स्क्रिप्ट में कमांड लिखेगा और उस स्क्रिप्ट को काम करने के लिए एक्ज़ीक्यूट करेगा. यह सभी 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) के बाद और "बनाएं" वैरिएबल के विकल्प को छोड़कर, पाथ Windows स्टाइल पाथ तक बढ़ाया गया (बैकस्लैश के साथ).
`cmd_ps`	`String; optional` Windows पर चलाने के लिए Powershell निर्देश. इस एट्रिब्यूट की प्राथमिकता `cmd`, `cmd_bash`, और `cmd_bat`. यह निर्देश `cmd` की तरह ही काम करता है एट्रिब्यूट की वैल्यू में बदलाव करें, क्योंकि इनके बीच ये अंतर होते हैं: यह एट्रिब्यूट सिर्फ़ Windows पर लागू होता है. निर्देश `powershell.exe /c` के साथ चलता है. PowerShell को इस्तेमाल करना आसान बनाने और गड़बड़ियों को कम करने के लिए, हम ये काम करते हैं: कमांड को भी सेट अप करने की ज़रूरत होती है. `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - चलने की अनुमति दें साइन नहीं की गई स्क्रिप्ट. `$errorActionPreference='Stop'` - कई निर्देश होने पर इन्हें `;` से अलग किया जाता है. अगर PowerShell CmdLet फ़ेल होता है, तो कार्रवाई तुरंत बंद हो जाती है, लेकिन यह बाहरी कमांड के लिए काम नहीं करता है. `$PSDefaultParameterValues['*:Encoding'] = 'utf8'` - डिफ़ॉल्ट वैल्यू बदलें utf-16 से utf-8 में एन्कोड करने का तरीका.
`exec_tools`	`List of labels; optional` इस नियम के लिए, टूल डिपेंडेंसी की सूची. यह बिलकुल इस तरह काम करता है: `tools` एट्रिब्यूट, इन डिपेंडेंसी को छोड़कर को होस्ट कॉन्फ़िगरेशन के बजाय, नियम के लागू करने वाले प्लैटफ़ॉर्म के लिए कॉन्फ़िगर किया जाएगा. इसका मतलब है कि `exec_tools` में डिपेंडेंसी `tools` में डिपेंडेंसी के तौर पर सीमाएं. खास तौर पर, इन चीज़ों की ज़रूरत नहीं अपनी खुद की ट्रांज़िटिव डिपेंडेंसी के लिए होस्ट कॉन्फ़िगरेशन का इस्तेमाल करता है. यहां जाएं: ज़्यादा जानकारी के लिए, `tools` पर जाएं. Blaze की टीम, `tools` के सभी इस्तेमाल को `exec_tools` पर माइग्रेट कर रही है सिमेंटिक्स. उपयोगकर्ताओं को `tools` के बजाय `exec_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` प्रोग्रेस की जानकारी देने वाला मैसेज. बिल्ड का यह चरण पूरा होते ही, प्रोग्रेस का मैसेज प्रिंट किया जाएगा. डिफ़ॉल्ट रूप से, मैसेज "आउटपुट जनरेट हो रहा है" है (या ऐसी ही कुछ अजीब चीज़ें) लेकिन आप हमारे ज़्यादा सटीक है. `echo` या दूसरे प्रिंट के बजाय इस एट्रिब्यूट का इस्तेमाल करें आपके `cmd` कमांड में स्टेटमेंट का इस्तेमाल किया जाता है. इससे बिल्ड टूल को यह कंट्रोल करने में मदद मिलती है कि क्या ऐसे प्रगति संदेश प्रिंट किए जाएंगे या नहीं.
`output_licenses`	`Licence type; optional` `common attributes` देखें
`output_to_bindir`	`Boolean; optional; nonconfigurable; default is False` अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो इस विकल्प की वजह से आउटपुट फ़ाइलें `bin` में लिखी जाएंगी `genfiles` डायरेक्ट्री के बजाय डायरेक्ट्री का इस्तेमाल करें.
`tools`	`List of labels; optional` इस नियम के लिए, टूल डिपेंडेंसी की सूची. इसकी परिभाषा देखें डिपेंडेंसी सबमिट करें. बिल्ड सिस्टम यह पक्का करता है कि gen बचाने के लिए निर्देश चलाने से पहले, इन ज़रूरी शर्तों को पूरा किया जाए; इन्हें होस्ट का इस्तेमाल करके बनाया जाता है कॉन्फ़िगरेशन में बदलाव नहीं किया जा सकता, क्योंकि इन टूल को बिल्ड के हिस्से के तौर पर एक्ज़ीक्यूट किया जाता है. इसका पाथ अलग-अलग `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

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

"-" से शुरू होने वाले टैग वर्ण को नेगेटिव टैग माना जाता है. कॉन्टेंट बनाने "-" से पहले वर्ण को टैग का हिस्सा नहीं माना जाता है, इसलिए सुइट टैग "-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 फ़िल्टर के तहत आते हैं.