सामान्य परिभाषाएं

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

इस सेक्शन में, कई फ़ंक्शन या नियम बनाने के लिए इस्तेमाल होने वाले अलग-अलग शब्दों और कॉन्सेप्ट के बारे में बताया गया है.

सामग्री

Bourne शेल टोकनाइज़ेशन

कुछ नियमों के कुछ स्ट्रिंग एट्रिब्यूट को, Bourne shell के टोकनाइज़ेशन नियमों के मुताबिक कई शब्दों में बांटा जाता है: बिना कोटेशन वाले स्पेस, अलग-अलग शब्दों को अलग करते हैं. साथ ही, टोकनाइज़ेशन को रोकने के लिए, सिंगल- और डबल-कोटेशन वर्ण और बैकस्लैश का इस्तेमाल किया जाता है.

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

"Make" वैरिएबल एक्सपैंशन और Bourne शेल के ज़रिए टोकनाइज़ किए गए एट्रिब्यूट का इस्तेमाल, आम तौर पर कंपाइलर और अन्य टूल को मनमुताबिक विकल्प देने के लिए किया जाता है. ऐसे एट्रिब्यूट के उदाहरण के तौर पर, cc_library.copts और java_library.javacopts को देखा जा सकता है. इन सबस्टिट्यूशन की मदद से, किसी एक स्ट्रिंग वैरिएबल को कॉन्फ़िगरेशन के हिसाब से, विकल्प के शब्दों की सूची में बदला जा सकता है.

लेबल का दायरा बढ़ाना

कुछ ही नियमों के कुछ स्ट्रिंग एट्रिब्यूट पर लेबल का दायरा बढ़ाया जा सकता है: अगर उन स्ट्रिंग में //mypkg:target जैसी किसी सबस्ट्रिंग के तौर पर मान्य लेबल है और वह लेबल, मौजूदा नियम के लिए ज़रूरी शर्त है, तो उसे टारगेट //mypkg:target के ज़रिए दिखाई गई फ़ाइल के पाथनेम में बड़ा किया जाता है.

उदाहरण के तौर पर दिए गए एट्रिब्यूट में genrule.cmd और cc_binary.linkopts शामिल हैं. हर मामले में जानकारी काफ़ी अलग-अलग हो सकती है. जैसे: रिलेटिव लेबल को बड़ा किया जाता है या नहीं; एक से ज़्यादा फ़ाइलों में बड़े होने वाले लेबल को कैसे माना जाता है वगैरह. ज़्यादा जानकारी के लिए, नियम एट्रिब्यूट के दस्तावेज़ देखें.

ज़्यादातर बिल्ड नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट

इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जिन्हें कई बिल्ड नियमों से तय किया जाता है, लेकिन सभी से नहीं.

एट्रिब्यूट ब्यौरा
data

लेबल की सूची; डिफ़ॉल्ट [] है

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

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

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

deps

लेबल की सूची; डिफ़ॉल्ट [] है

इस टारगेट के लिए डिपेंडेंसी. आम तौर पर, इसमें सिर्फ़ नियम के टारगेट शामिल होने चाहिए. (हालांकि, कुछ नियमों के तहत फ़ाइलों को सीधे deps में लिस्ट किया जा सकता है, लेकिन जहां तक हो सके, ऐसा नहीं करना चाहिए.)

भाषा के हिसाब से बने नियमों से, आम तौर पर सूची में शामिल उन टारगेट पर पाबंदी लगती है जिनमें खास प्रोवाइडर शामिल होते हैं.

deps का इस्तेमाल करके, किसी टारगेट के किसी दूसरे टारगेट पर निर्भर होने का मतलब, नियम के टाइप पर निर्भर करता है. नियम के हिसाब से बने दस्तावेज़ में इस बारे में ज़्यादा जानकारी दी गई है. सोर्स कोड को प्रोसेस करने वाले नियमों के लिए, आम तौर पर deps, srcs में कोड की डिपेंडेंसी की जानकारी देता है.

ज़्यादातर मामलों में, deps डिपेंडेंसी का इस्तेमाल करके, एक मॉड्यूल को उसी प्रोग्रामिंग भाषा में लिखे गए और अलग से कॉम्पाइल किए गए दूसरे मॉड्यूल में तय किए गए सिंबल का इस्तेमाल करने की अनुमति दी जाती है. कई मामलों में, अलग-अलग भाषाओं की डिपेंडेंसी की भी अनुमति होती है: उदाहरण के लिए, java_library टारगेट, cc_library टारगेट में मौजूद C++ कोड पर निर्भर हो सकता है. इसके लिए, deps एट्रिब्यूट में cc_library को शामिल करें. ज़्यादा जानकारी के लिए, डिपेंडेंसी की परिभाषा देखें.

licenses

स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट ["none"] है

इस टारगेट के लिए इस्तेमाल किए जाने वाले लाइसेंस टाइप की स्ट्रिंग की सूची. यह लाइसेंस देने वाले ऐसे एपीआई का हिस्सा है जिसका इस्तेमाल अब Bazel नहीं करता. इसका इस्तेमाल न करें.

srcs

लेबल की सूची; डिफ़ॉल्ट [] है

इस नियम के तहत प्रोसेस की गई या शामिल की गई फ़ाइलें. आम तौर पर, फ़ाइलों को सीधे सूची में शामिल किया जाता है. हालांकि, उनके डिफ़ॉल्ट आउटपुट को शामिल करने के लिए, filegroup या genrule जैसे नियम टारगेट को सूची में शामिल किया जा सकता है.

भाषा के हिसाब से बने नियमों के मुताबिक, सूची में शामिल फ़ाइलों के लिए खास फ़ाइल एक्सटेंशन होना ज़रूरी होता है.

सभी बिल्ड नियमों के लिए सामान्य एट्रिब्यूट

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

एट्रिब्यूट ब्यौरा
compatible_with

लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट तौर पर []

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

यह Bazel के कंस्ट्रेंट सिस्टम का हिस्सा है. इससे उपयोगकर्ता यह तय कर सकते हैं कि कौनसे टारगेट एक-दूसरे पर निर्भर हो सकते हैं और कौनसे नहीं. उदाहरण के लिए, बाहर से डिप्लॉय की जा सकने वाली बिनेरी, कंपनी के गोपनीय कोड वाली लाइब्रेरी पर निर्भर नहीं होनी चाहिए. ज़्यादा जानकारी के लिए, ConstraintSemantics देखें.

deprecation

स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट None है

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

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

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

अगर कोई पुराना टारगेट, किसी दूसरे पुराने टारगेट पर निर्भर करता है, तो कोई चेतावनी मैसेज नहीं भेजा जाता.

जब लोग इसका इस्तेमाल करना बंद कर दें, तब टारगेट को हटाया जा सकता है.

distribs

स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट [] है

इस खास टारगेट के लिए, डिस्ट्रिब्यूशन के तरीके की उन स्ट्रिंग की सूची जिनका इस्तेमाल किया जाना है. यह लाइसेंस देने वाले ऐसे एपीआई का हिस्सा है जिसका इस्तेमाल अब Bazel नहीं करता. इसका इस्तेमाल न करें.

exec_compatible_with

लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट तौर पर []

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

exec_properties

स्ट्रिंग की डिक्शनरी; डिफ़ॉल्ट तौर पर {}

स्ट्रिंग की एक डिक्शनरी, जिसे इस टारगेट के लिए चुने गए प्लैटफ़ॉर्म के exec_properties में जोड़ा जाएगा. प्लैटफ़ॉर्म के नियम का exec_properties देखें.

अगर कोई कुंजी, प्लैटफ़ॉर्म और टारगेट-लेवल, दोनों प्रॉपर्टी में मौजूद है, तो वैल्यू टारगेट से ली जाएगी.
features

feature स्ट्रिंग की सूची; डिफ़ॉल्ट [] है

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

इस features एट्रिब्यूट को पैकेज लेवल के features एट्रिब्यूट के साथ जोड़ा जाता है. उदाहरण के लिए, अगर पैकेज लेवल पर सुविधाएं ["a", "b"] चालू हैं और टारगेट के features एट्रिब्यूट में ["-a", "c"] शामिल हैं, तो नियम के लिए चालू की गई सुविधाएं "b" और "c" होंगी. उदाहरण देखें.

restricted_to

लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट तौर पर []

डिफ़ॉल्ट तौर पर काम करने वाले एनवायरमेंट के बदले, इस टारगेट को इन एनवायरमेंट के लिए बनाया जा सकता है.

यह Bazel के कंस्ट्रेंट सिस्टम का हिस्सा है. ज़्यादा जानकारी के लिए, compatible_with पर जाएं.

tags

स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट [] है

टैग का इस्तेमाल किसी भी नियम पर किया जा सकता है. टेस्ट और test_suite नियमों पर मौजूद टैग, टेस्ट की कैटगरी तय करने के लिए काम के होते हैं. टेस्ट के दायरे से बाहर के टारगेट पर मौजूद टैग का इस्तेमाल, genrule और Starlark ऐक्शन के सैंडबॉक्स किए गए तरीके से लागू होने को कंट्रोल करने के लिए किया जाता है. साथ ही, इनका इस्तेमाल, लोगों और/या बाहरी टूल के ज़रिए पार्स करने के लिए भी किया जाता है.

अगर Bazel को किसी भी टेस्ट के tags एट्रिब्यूट या genrule टारगेट में ये कीवर्ड मिलते हैं, तो वह अपने सैंडबॉक्सिंग कोड के व्यवहार में बदलाव करता है. इसके अलावा, किसी भी Starlark ऐक्शन के लिए execution_requirements की कुंजियों में भी ये कीवर्ड मिल सकते हैं.

  • no-sandbox कीवर्ड का इस्तेमाल करने पर, ऐक्शन या जांच को कभी भी सैंडबॉक्स नहीं किया जाता. हालांकि, इसे अब भी कैश मेमोरी में सेव किया जा सकता है या रिमोट तौर पर चलाया जा सकता है. इनमें से किसी एक या दोनों को रोकने के लिए, no-cache या no-remote का इस्तेमाल करें.
  • no-cache कीवर्ड की वजह से, कार्रवाई या जांच कभी भी रिमोट या लोकल तौर पर कैश मेमोरी में सेव नहीं होती
  • no-remote-cache कीवर्ड की वजह से, कार्रवाई या जांच को कभी भी रिमोट तौर पर कैश मेमोरी में सेव नहीं किया जाता. हालांकि, इसे लोकल तौर पर कैश मेमोरी में सेव किया जा सकता है. साथ ही, इसे रिमोट तौर पर भी चलाया जा सकता है. ध्यान दें: इस टैग के लिए, डिस्क-कैश को लोकल कैश माना जाता है, जबकि HTTP और gRPC कैश को रिमोट कैश माना जाता है. अगर लोकल डिस्क कैश और रिमोट कैश (कॉम्बिनेट कैश) का इस्तेमाल किया जाता है, तो इसे रिमोट कैश माना जाता है और इसे तब तक पूरी तरह से बंद कर दिया जाता है, जब तक --incompatible_remote_results_ignore_disk सेट नहीं किया जाता. ऐसा होने पर, लोकल कॉम्पोनेंट का इस्तेमाल किया जाएगा.
  • no-remote-exec कीवर्ड की वजह से, कार्रवाई या जांच कभी भी रिमोट तौर पर पूरी नहीं की जाती. हालांकि, इसे रिमोट तौर पर कैश मेमोरी में सेव किया जा सकता है.
  • no-remote कीवर्ड, कार्रवाई या जांच को रिमोट तौर पर लागू होने या रिमोट तौर पर कैश मेमोरी में सेव होने से रोकता है. यह no-remote-cache और no-remote-exec, दोनों का इस्तेमाल करने के बराबर है.
  • no-remote-cache-upload कीवर्ड, स्पैन के रिमोट कैश मेमोरी में अपलोड करने की सुविधा को बंद कर देता है. यह रिमोट तरीके से प्रोग्राम चलाने की सुविधा बंद नहीं करता.
  • local कीवर्ड, कार्रवाई या जांच को रिमोट तौर पर कैश मेमोरी में सेव होने, रिमोट तौर पर लागू होने या सैंडबॉक्स में चलने से रोकता है. जनरेट किए गए नियमों और टेस्ट के लिए, नियम को local = True एट्रिब्यूट के साथ मार्क करने का असर एक जैसा होता है.
  • requires-network कीवर्ड, सैंडबॉक्स में मौजूद बाहरी नेटवर्क को ऐक्सेस करने की अनुमति देता है. इस टैग का असर सिर्फ़ तब होता है, जब सैंडबॉक्सिंग की सुविधा चालू हो.
  • block-network कीवर्ड, सैंडबॉक्स में मौजूद बाहरी नेटवर्क का ऐक्सेस ब्लॉक करता है. इस मामले में, सिर्फ़ localhost के साथ कम्यूनिकेशन की अनुमति है. इस टैग का असर सिर्फ़ तब होता है, जब सैंडबॉक्सिंग की सुविधा चालू हो.
  • requires-fakeroot, जांच या कार्रवाई को uid और gid 0 (यानी, रूट उपयोगकर्ता) के तौर पर चलाता है. यह सुविधा सिर्फ़ Linux पर काम करती है. इस टैग को --sandbox_fake_username कमांड-लाइन विकल्प के बजाय प्राथमिकता दी जाती है.

आम तौर पर, टेस्ट पर मौजूद टैग का इस्तेमाल, डीबग और रिलीज़ की प्रोसेस में किसी टेस्ट की भूमिका के बारे में जानकारी देने के लिए किया जाता है. आम तौर पर, टैग C++ और Python के लिए सबसे ज़्यादा काम के होते हैं टेस्ट, जिनमें रनटाइम एनोटेशन की सुविधा नहीं होती. टैग और साइज़ एलिमेंट का इस्तेमाल करने से, कोडबेस की जांच करने की नीति के आधार पर, टेस्ट के सुइट को आसानी से इकट्ठा किया जा सकता है.

अगर Bazel को टेस्ट के नियम के tags एट्रिब्यूट में ये कीवर्ड मिलते हैं, तो वह टेस्ट के चलने के तरीके में बदलाव करता है:

  • exclusive, टेस्ट को "एक्सक्लूज़िव" मोड में चलाने के लिए मजबूर करेगा. इससे यह पक्का किया जा सकेगा कि एक ही समय पर कोई दूसरा टेस्ट न चल रहा हो. सभी बिल्ड ऐक्टिविटी और नॉन-एक्सक्लूज़िव टेस्ट पूरे होने के बाद, ऐसे टेस्ट सीरियल फ़ैशन में चलाए जाएंगे. इस तरह के टेस्ट के लिए, रिमोट से टेस्ट चलाने की सुविधा बंद होती है. इसकी वजह यह है कि Bazel के पास रिमोट मशीन पर चल रहे प्रोसेस को कंट्रोल करने की सुविधा नहीं होती.
  • अगर exclusive-if-local को लोकल तौर पर चलाया जाता है, तो यह टेस्ट को "एक्सक्लूज़िव" मोड में चलाने के लिए मजबूर करेगा. हालांकि, अगर इसे रिमोट तौर पर चलाया जाता है, तो यह टेस्ट को पैरलल मोड में चलाएगा.
  • manual कीवर्ड, टारगेट पैटर्न वाइल्डकार्ड (..., :*, :all वगैरह) और test_suite नियमों के टारगेट को एक्सपैंशन से बाहर रखेगा. ये ऐसे नियम होते हैं जो build, test, और coverage कमांड के लिए, टॉप-लेवल टारगेट के सेट का हिसाब लगाते समय, टेस्ट को साफ़ तौर पर शामिल नहीं करते. इससे, query कमांड के साथ-साथ, अन्य संदर्भों में टारगेट वाइल्डकार्ड या टेस्ट सुइट के एक्सपैंशन पर कोई असर नहीं पड़ता. ध्यान दें कि manual का मतलब यह नहीं है कि किसी टारगेट को, लगातार बिल्ड/टेस्ट करने वाले सिस्टम से अपने-आप बिल्ड/रन नहीं किया जाना चाहिए. उदाहरण के लिए, हो सकता है कि किसी टारगेट को bazel test ... से बाहर रखा जाए, क्योंकि इसके लिए खास Bazel फ़्लैग की ज़रूरत होती है. हालांकि, उसे सही तरीके से कॉन्फ़िगर किए गए, सबमिट करने से पहले या लगातार टेस्ट चलाने की प्रोसेस में शामिल किया जा सकता है.
  • external कीवर्ड, बिना किसी शर्त के जांच को ज़बरदस्ती लागू करेगा, भले ही --cache_test_results की वैल्यू कुछ भी हो.
टेस्ट टारगेट से जुड़े टैग के बारे में ज़्यादा जानकारी के लिए, टेस्ट एनसाइक्लोपीडिया में टैग के लिए इस्तेमाल होने वाले नियम देखें.
target_compatible_with

लेबल की सूची; डिफ़ॉल्ट [] है

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

ऐसे टारगेट जिन्हें काम न करने वाले टारगेट पर ट्रांज़िशन के तौर पर निर्भर किया जाता है उन्हें भी काम न करने वाले टारगेट माना जाता है. इन्हें बनाने और टेस्ट करने के लिए भी स्किप किया जाता है.

खाली सूची (जो डिफ़ॉल्ट रूप से होती है) का मतलब है कि टारगेट सभी प्लैटफ़ॉर्म के साथ काम करता है.

Workspace के नियम के अलावा, बाकी सभी नियमों में यह एट्रिब्यूट इस्तेमाल किया जा सकता है. कुछ नियमों पर इस एट्रिब्यूट का कोई असर नहीं पड़ता. उदाहरण के लिए, किसी cc_toolchain के लिए target_compatible_with तय करना काम का नहीं है.

काम न करने वाले टारगेट को स्किप करने के बारे में ज़्यादा जानने के लिए, प्लैटफ़ॉर्म पेज देखें.

testonly

बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से False है. हालांकि, टेस्ट और टेस्ट सुइट टारगेट के लिए यह False नहीं है

अगर True है, तो सिर्फ़ टेस्ट के लिए बने टारगेट (जैसे, टेस्ट) ही इस टारगेट पर निर्भर हो सकते हैं.

इसी तरह, testonly से अलग किसी नियम को testonly वाले किसी नियम पर निर्भर करने की अनुमति नहीं है.

टेस्ट (*_test नियम) और टेस्ट सुइट (test_suite नियम), डिफ़ॉल्ट रूप से testonly होते हैं.

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

testonly, रन टाइम के बजाय बिल्ड टाइम पर लागू होता है. साथ ही, यह डिपेंडेंसी ट्री में तेज़ी से फैलता है. इसलिए, इसे सावधानी से लागू किया जाना चाहिए. उदाहरण के लिए, यूनिट टेस्ट के लिए काम के स्टब और फ़ेक, इंटिग्रेशन टेस्ट के लिए भी काम के हो सकते हैं. इनमें वे बाइनरी शामिल होती हैं जिन्हें प्रोडक्शन में रिलीज़ किया जाएगा. इसलिए, इन्हें सिर्फ़ टेस्ट के लिए मार्क नहीं किया जाना चाहिए. इसके उलट, ऐसे नियम जिन्हें लिंक करना भी खतरनाक है, उन्हें 'सिर्फ़ टेस्ट के लिए' के तौर पर मार्क किया जाना चाहिए. ऐसा इसलिए, क्योंकि ये नियम बिना शर्त सामान्य व्यवहार को बदल देते हैं.

toolchains

लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट तौर पर []

उन टारगेट का सेट जिनके Make वैरिएबल को इस टारगेट को ऐक्सेस करने की अनुमति है. ये टारगेट, TemplateVariableInfo देने वाले नियमों के इंस्टेंस होते हैं या Bazel में बने टूलचेन टाइप के लिए खास टारगेट होते हैं. इनमें ये शामिल हैं:

  • @bazel_tools//tools/cpp:current_cc_toolchain
  • @bazel_tools//tools/jdk:current_java_runtime

ध्यान दें कि यह टूलचेन रिज़ॉल्यूशन के कॉन्सेप्ट से अलग है. इसका इस्तेमाल, प्लैटफ़ॉर्म पर निर्भर कॉन्फ़िगरेशन के लिए, नियम लागू करने के लिए किया जाता है. इस एट्रिब्यूट का इस्तेमाल करके यह तय नहीं किया जा सकता कि टारगेट किस cc_toolchain या java_toolchain का इस्तेमाल करेगा.

visibility

लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से, पैकेज में बताए गए default_visibility का इस्तेमाल किया जाता है. अगर पैकेज में default_visibility नहीं बताया गया है, तो "//visibility:private" का इस्तेमाल किया जाता है

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

सभी टेस्ट नियमों (*_test) के लिए सामान्य एट्रिब्यूट

इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जो सभी टेस्ट नियमों के लिए सामान्य हैं.

एट्रिब्यूट ब्यौरा
args

स्ट्रिंग की सूची; $(location) और "Make variable" के बदले, और Bourne shell tokenization के हिसाब से बदली जा सकती है; डिफ़ॉल्ट [] है

कमांड लाइन आर्ग्युमेंट, जिन्हें bazel test के साथ चलाए जाने पर Bazel, टारगेट को पास करता है.

ये आर्ग्युमेंट, bazel test कमांड लाइन पर बताई गई किसी भी --test_arg वैल्यू से पहले पास किए जाते हैं.

env

स्ट्रिंग की डिक्शनरी; वैल्यू में $(location) और "Make variable" के बदले वैल्यू डाली जा सकती है; डिफ़ॉल्ट वैल्यू [] है

bazel test से टेस्ट को चलाने पर, सेट करने के लिए अन्य एनवायरमेंट वैरिएबल तय करता है.

यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि cc_test, py_test, और sh_test. यह Starlark से तय किए गए टेस्ट नियमों पर लागू नहीं होता. अपने Starlark नियमों के लिए, "env" एट्रिब्यूट जोड़ा जा सकता है. साथ ही, इसका इस्तेमाल करके TestEnvironment प्रोवाइडर को पॉप्युलेट किया जा सकता है.

env_inherit

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

bazel test से टेस्ट को चलाने पर, बाहरी एनवायरमेंट से इनहेरिट करने के लिए, अन्य एनवायरमेंट वैरिएबल तय करता है.

यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि cc_test, py_test, और sh_test. यह Starlark से तय किए गए टेस्ट नियमों पर लागू नहीं होता.

size

स्ट्रिंग "enormous", "large", "medium" या "small"; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट "medium" है

इससे टेस्ट टारगेट के "भारी होने" की जानकारी मिलती है: इसे चलाने के लिए कितना समय/संसाधन चाहिए.

यूनिट टेस्ट को "छोटा", इंटिग्रेशन टेस्ट को "मीडियम", और एंड-टू-एंड टेस्ट को "बड़ा" या "बहुत बड़ा" माना जाता है. Bazel, डिफ़ॉल्ट टाइम आउट तय करने के लिए साइज़ का इस्तेमाल करता है. इसे timeout एट्रिब्यूट का इस्तेमाल करके बदला जा सकता है. टाइम आउट, BUILD टारगेट में मौजूद सभी टेस्ट के लिए होता है, न कि हर अलग-अलग टेस्ट के लिए. जब टेस्ट को लोकल तौर पर चलाया जाता है, तो size का इस्तेमाल शेड्यूल करने के लिए भी किया जाता है: Bazel, --local_{ram,cpu}_resources का सम्मान करने की कोशिश करता है और एक ही समय पर कई भारी टेस्ट चलाकर, लोकल मशीन को ज़्यादा लोड नहीं डालता.

टेस्ट साइज़, इन डिफ़ॉल्ट टाइम आउट और स्थानीय संसाधन के सबसे ज़्यादा इस्तेमाल के अनुमान से मेल खाते हैं:

साइज़ रैम (एमबी में) सीपीयू (सीपीयू कोर में) डिफ़ॉल्ट टाइम आउट
छोटा 20 1 छोटा (1 मिनट)
मध्यम 100 1 सामान्य (5 मिनट)
बड़ा 300 1 लंबा (15 मिनट)
बहुत बड़ा 800 1 हमेशा के लिए (60 मिनट)

टेस्ट को स्पैन करते समय, एनवायरमेंट वैरिएबल TEST_SIZE को इस एट्रिब्यूट की वैल्यू पर सेट किया जाएगा.
timeout

स्ट्रिंग "short", "moderate", "long" या "eternal"; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट वैल्यू, जांच के size एट्रिब्यूट से ली जाती है

जांच पूरी होने में कितना समय लगेगा.

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

टाइम आउट की वैल्यू समयावधि
छोटा 1 मिनट
मध्यम 5 मिनट
लंबा 15 मिनट
अनंत 60 मिनट

ऊपर बताए गए समय के अलावा, --test_timeout bazel फ़्लैग की मदद से जांच के टाइम आउट को बदला जा सकता है. उदाहरण के लिए, मैन्युअल तरीके से उन स्थितियों में चलाने के लिए जिनके बारे में पता है कि वे धीमी हैं. --test_timeout वैल्यू, सेकंड में दी गई हैं. उदाहरण के लिए, --test_timeout=120, जांच के लिए दो मिनट का टाइम आउट सेट करेगा.

टेस्ट को स्पैन करने पर, एनवायरमेंट वैरिएबल TEST_TIMEOUT को टेस्ट टाइम आउट (सेकंड में) पर सेट कर दिया जाएगा.
flaky

बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट False है

टेस्ट को 'अमान्य' के तौर पर मार्क करता है.

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

shard_count

50 से कम या उसके बराबर कोई पूर्णांक, जो नकारात्मक न हो; डिफ़ॉल्ट तौर पर -1

इससे पता चलता है कि टेस्ट चलाने के लिए, एक साथ काम करने वाले कितने शर्ड इस्तेमाल करने हैं.

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

अगर टेस्ट को अलग-अलग ग्रुप में बांटने की सुविधा चालू है, तो टेस्ट को स्पैन करने के दौरान एनवायरमेंट वैरिएबल TEST_TOTAL_SHARDS को इस वैल्यू पर सेट कर दिया जाएगा.

टेस्ट रनर को टेस्ट के लिए, स्प्लिट करने के प्रोटोकॉल का इस्तेमाल करना होगा. अगर ऐसा नहीं होता है, तो हो सकता है कि यह हर टेस्ट को हर शर्ड में चलाए, जो आपके काम का नहीं है.

टास्क को अलग-अलग हिस्सों में बांटने के बारे में जानने के लिए, टेस्ट एनसाइक्लोपीडिया में टास्क को अलग-अलग हिस्सों में बांटना देखें.
local

बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट False है

सैंडबॉक्सिंग के बिना, टेस्ट को स्थानीय तौर पर चलाने के लिए मजबूर करता है.

इस विकल्प को 'सही' पर सेट करने का मतलब है कि टैग (tags=["local"]) के तौर पर "local" दिया गया है.

सभी बाइनरी नियमों (*_binary) के लिए सामान्य एट्रिब्यूट

इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जो सभी बाइनरी नियमों के लिए सामान्य हैं.

एट्रिब्यूट ब्यौरा
args

स्ट्रिंग की सूची; $(location) और "Make variable" के बदले, और Bourne shell tokenization के हिसाब से तय की जाती है; इसे कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट [] है

कमांड लाइन के ऐसे आर्ग्युमेंट जिन्हें run कमांड या टेस्ट के तौर पर लागू करने पर, Bazel टारगेट को पास करेगा. ये आर्ग्युमेंट, bazel run या bazel test कमांड लाइन पर बताए गए आर्ग्युमेंट से पहले पास किए जाते हैं.

ध्यान दें: Bazel के बाहर टारगेट को चलाने पर, आर्ग्युमेंट पास नहीं किए जाते. उदाहरण के लिए, bazel-bin/ में बाइनरी को मैन्युअल रूप से चलाकर.

env

स्ट्रिंग की डिक्शनरी; वैल्यू में $(location) और "Make variable" के बदले वैल्यू डाली जा सकती है; डिफ़ॉल्ट वैल्यू {} है

bazel run से टारगेट को लागू करने पर, सेट करने के लिए अतिरिक्त एनवायरमेंट वैरिएबल तय करता है.

यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि cc_binary, py_binary, और sh_binary. यह Starlark से तय किए गए, लागू किए जा सकने वाले नियमों पर लागू नहीं होता.

ध्यान दें: Bazel के बाहर टारगेट को चलाने पर, एनवायरमेंट वैरिएबल सेट नहीं होते. उदाहरण के लिए, bazel-bin/ में बाइनरी को मैन्युअल तरीके से चलाने पर.

output_licenses

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

इस बाइनरी से जनरेट होने वाली आउटपुट फ़ाइलों के लाइसेंस. यह लाइसेंस देने वाले ऐसे एपीआई का हिस्सा है जिसका इस्तेमाल अब Bazel नहीं करता. इसका इस्तेमाल न करें.

कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट

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

यहां दिए गए उदाहरण में, अलग-अलग टारगेट आर्किटेक्चर के लिए अलग-अलग सोर्स दिखाए गए हैं. bazel build :multiplatform_lib --cpu x86 को चलाने पर, x86_impl.cc का इस्तेमाल करके टारगेट बनाया जाएगा. वहीं, --cpu arm को बदलने पर, arm_impl.cc का इस्तेमाल किया जाएगा. 

cc_library(
    name = "multiplatform_lib",
    srcs = select({
        ":x86_mode": ["x86_impl.cc"],
        ":arm_mode": ["arm_impl.cc"]
    })
)
config_setting(
    name = "x86_mode",
    values = { "cpu": "x86" }
)
config_setting(
    name = "arm_mode",
    values = { "cpu": "arm" }
)

select() फ़ंक्शन, कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट के लिए, वैकल्पिक वैल्यू में से किसी एक को चुनता है. यह इस आधार पर चुना जाता है कि टारगेट का कॉन्फ़िगरेशन, config_setting या constraint_value की शर्तों को पूरा करता है या नहीं.

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

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

ज़्यादा जानकारी के लिए, कॉन्फ़िगर किए जा सकने वाले बिल्ड एट्रिब्यूट देखें.

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

C++ में, इंप्लिसिट आउटपुट का इस्तेमाल बंद कर दिया गया है. जहां भी हो सके, कृपया इसका इस्तेमाल दूसरी भाषाओं में न करें. फ़िलहाल, हमने इन सुविधाओं को बंद करने का कोई तरीका तय नहीं किया है. हालांकि, इन्हें भी बंद कर दिया जाएगा.

BUILD फ़ाइल में कोई बिल्ड नियम तय करने पर, पैकेज में नए नाम वाले नियम के टारगेट का साफ़ तौर पर एलान किया जाता है. कई बिल्ड नियम फ़ंक्शन में, एक या एक से ज़्यादा आउटपुट फ़ाइल टारगेट भी अनजाने में शामिल होते हैं. इनका कॉन्टेंट और मतलब, नियम के हिसाब से होता है. उदाहरण के लिए, जब किसी java_binary(name='foo', ...) नियम को साफ़ तौर पर बताया जाता है, तो उसी पैकेज के सदस्य के तौर पर, आउटपुट फ़ाइल टारगेट foo_deploy.jar को भी अनजाने में बताया जाता है. (यह खास टारगेट, डिप्लॉयमेंट के लिए सही, अपने-आप काम करने वाला Java संग्रह है.)

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

हर तरह के बिल्ड नियम के लिए, नियम के दस्तावेज़ में एक ऐसा खास सेक्शन होता है जिसमें उस तरह के नियम के एलान से जुड़े किसी भी इंप्लिसिट आउटपुट के नाम और कॉन्टेंट की जानकारी होती है.

बिल्ड सिस्टम के इस्तेमाल किए जाने वाले दो नेमस्पेस के बीच का अंतर, ज़रूरी है, लेकिन थोड़ा मुश्किल है: लेबल, टारगेट की पहचान करते हैं. ये नियम या फ़ाइलें हो सकती हैं. साथ ही, फ़ाइल टारगेट को सोर्स (या इनपुट) फ़ाइल टारगेट और डेरिव्ड (या आउटपुट) फ़ाइल टारगेट में बांटा जा सकता है. इन चीज़ों को BUILD फ़ाइलों में शामिल किया जा सकता है, कमांड-लाइन से बनाया जा सकता है या bazel query का इस्तेमाल करके जांचा जा सकता है. यह टारगेट नेमस्पेस है. हर फ़ाइल टारगेट, डिस्क पर मौजूद एक असल फ़ाइल ("फ़ाइल सिस्टम नेमस्पेस") से जुड़ा होता है. हर नियम टारगेट, डिस्क पर मौजूद शून्य, एक या उससे ज़्यादा असल फ़ाइलों से जुड़ा हो सकता है. डिस्क पर ऐसी फ़ाइलें हो सकती हैं जिनका कोई टारगेट न हो. उदाहरण के लिए, C++ कंपाइलेशन के दौरान बनाई गई .o ऑब्जेक्ट फ़ाइलों का रेफ़रंस, BUILD फ़ाइलों या कमांड-लाइन से नहीं दिया जा सकता. इस तरह, बिल्ड टूल अपने काम करने के तरीके की कुछ जानकारी छिपा सकता है. इस बारे में ज़्यादा जानकारी, BUILD कॉन्सेप्ट रेफ़रंस में दी गई है.