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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 .

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

कॉन्टेंट

• Bourne shell टोकनाइज़ेशन
• लेबल एक्सपैंशन
• ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट
• बिल्ड के सभी नियमों के लिए सामान्य एट्रिब्यूट
• सभी टेस्ट नियमों (*_test) के लिए सामान्य एट्रिब्यूट
• सभी बाइनरी नियमों (*_binary) के लिए सामान्य एट्रिब्यूट
• कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट
• इंप्लिसिट आउटपुट टारगेट

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	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट तौर पर [] इस टारगेट के साथ काम करने वाले एनवायरमेंट के साथ-साथ, एनवायरमेंट की सूची भी बनाई जा सकती है. यह Baज़ल के कंस्ट्रेंट सिस्टम का हिस्सा है. इससे उपयोगकर्ता यह तय कर पाते हैं कि कौनसे टारगेट एक-दूसरे पर निर्भर हो सकते हैं और कौनसे नहीं. उदाहरण के लिए, बाहर से डिप्लॉय की जा सकने वाली बिनेरी, कंपनी के गोपनीय कोड वाली लाइब्रेरी पर निर्भर नहीं होनी चाहिए. ज़्यादा जानकारी के लिए, 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	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट तौर पर [] डिफ़ॉल्ट तौर पर काम करने वाले एनवायरमेंट के बदले, इस टारगेट को इन एनवायरमेंट के लिए बनाया जा सकता है. यह बेज़ल के कंस्ट्रेंट सिस्टम का हिस्सा है. ज़्यादा जानकारी के लिए, compatible_with पर जाएं.
tags	स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट [] है टैग का इस्तेमाल किसी भी नियम के लिए किया जा सकता है. जांच के लिए सेट किए गए टैग और test_suite नियम, टेस्ट को कैटगरी में बांटने में मददगार होते हैं. नॉन-टेस्ट टारगेट के टैग का इस्तेमाल, genrules और 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 ... से बाहर रखना ज़रूरी हो, क्योंकि इसके लिए खास बेज़ल फ़्लैग की ज़रूरत होती है. हालांकि, इसे फिर भी अच्छी तरह से कॉन्फ़िगर किए गए प्री-सबमिट या लगातार टेस्ट रन में शामिल किया जाना चाहिए. external कीवर्ड, बिना किसी शर्त के जांच को ज़बरदस्ती लागू करेगा, भले ही --cache_test_results की वैल्यू कुछ भी हो. टेस्ट टारगेट से जुड़े टैग के बारे में ज़्यादा जानकारी के लिए, टेस्ट एनसाइक्लोपीडिया में टैग के लिए इस्तेमाल होने वाले नियम देखें.
target_compatible_with	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट प्लैटफ़ॉर्म में मौजूद उन constraint_value की सूची जिनके मौजूद होने पर ही, इस टारगेट को काम करने वाला माना जाएगा. यह पाबंदी, नियम के टाइप से पहले से सेट की गई पाबंदियों के अलावा है. अगर टारगेट प्लैटफ़ॉर्म, सूची में दी गई सभी शर्तों को पूरा नहीं करता है, तो टारगेट को काम नहीं करता माना जाता है. टारगेट पैटर्न को बड़ा करने पर (उदाहरण के लिए, //..., :all), काम न करने वाले टारगेट को बिल्ड और टेस्ट करने से छोड़ दिया जाता है. कमांड लाइन पर साफ़ तौर पर बताए जाने पर, काम न करने वाले टारगेट की वजह से Bazel गड़बड़ी की जानकारी देता है और बिल्ड या टेस्ट पूरा नहीं हो पाता. जो टारगेट एक समय के लिए काम न करने वाले टारगेट पर निर्भर रहते हैं उन्हें असंगत माना जाता है. इन्हें बनाने और टेस्ट करने के लिए भी छोड़ दिया जाता है. खाली सूची (जो डिफ़ॉल्ट रूप से होती है) का मतलब है कि टारगेट सभी प्लैटफ़ॉर्म के साथ काम करता है. Workspace के नियम के अलावा, बाकी सभी नियमों में यह एट्रिब्यूट इस्तेमाल किया जा सकता है. कुछ नियमों पर इस एट्रिब्यूट का कोई असर नहीं पड़ता. उदाहरण के लिए, किसी cc_toolchain के लिए target_compatible_with तय करना काम का नहीं है. काम न करने वाले टारगेट को स्किप करने के बारे में ज़्यादा जानने के लिए, प्लैटफ़ॉर्म पेज देखें.
testonly	बूलियन; कॉन्फ़िगर नहीं किया जा सकता. जांच और टेस्ट सुइट के टारगेट को छोड़कर, डिफ़ॉल्ट तौर पर False है अगर True, तो सिर्फ़ टेस्ट करने के लिए टारगेट (जैसे कि टेस्ट) इस टारगेट पर निर्भर हो सकते हैं. बराबर है, ऐसे नियम जो testonly नहीं है उसे ऐसे किसी भी नियम पर निर्भर करने की अनुमति नहीं है जो testonly है. टेस्ट (*_test नियम) और टेस्ट सुइट (test_suite नियम), डिफ़ॉल्ट रूप से 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 या "//visibility:private" टारगेट पर मौजूद visibility एट्रिब्यूट से यह तय होता है कि टारगेट का इस्तेमाल अन्य पैकेज में किया जा सकता है या नहीं. प्रॉडक्ट दिखने के बारे में जानने के लिए, दस्तावेज़ देखें.

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

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

एट्रिब्यूट	ब्यौरा
args	स्ट्रिंग की सूची; $(location) और "Make variable" के बदले, और Bourne shell tokenization के हिसाब से बदली जा सकती है; डिफ़ॉल्ट [] है कमांड लाइन आर्ग्युमेंट, जिन्हें bazel test के साथ चलाए जाने पर Bazel, टारगेट को पास करता है. ये आर्ग्युमेंट, bazel test कमांड लाइन पर बताई गई किसी भी --test_arg वैल्यू से पहले पास किए जाते हैं.
env	स्ट्रिंग की डिक्शनरी; वैल्यू $(location) और "वैरिएबल बनाएं" के विकल्प पर निर्भर करती हैं. वैल्यू, डिफ़ॉल्ट तौर पर [] पर निर्भर करती है 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 एट्रिब्यूट का इस्तेमाल करके बदला जा सकता है. टाइम आउट, बिल्ड टारगेट में मौजूद सभी टेस्ट के लिए है, न कि हर टेस्ट के लिए. जब स्थानीय तौर पर टेस्ट किया जाता है, तब size का इस्तेमाल शेड्यूल करने के लिए भी किया जाता है: Basel, --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 बेज़ल फ़्लैग से बदला जा सकता है. उदाहरण के लिए, मैन्युअल रूप से चलने वाली ऐसी स्थितियों के लिए जिन्हें धीमा माना जाता है. --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" दिया गया है.

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

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

एट्रिब्यूट	ब्यौरा
args	स्ट्रिंग की सूची; $(location) और "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन के तहत आने वाली स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर [] है कमांड लाइन आर्ग्युमेंट, जिन्हें Baज़ल से टारगेट को पास किया जाएगा, जब उसे run कमांड से या टेस्ट के तौर पर एक्ज़ीक्यूट किया जाएगा. ये आर्ग्युमेंट, bazel run या bazel test कमांड लाइन पर बताए गए आर्ग्युमेंट से पहले पास किए जाते हैं. ध्यान दें: टारगेट को Baज़र के बाहर से चलाने पर, आर्ग्युमेंट पास नहीं होते (उदाहरण के लिए, bazel-bin/ में बाइनरी को मैन्युअल तरीके से एक्ज़ीक्यूट करना).
env	स्ट्रिंग की डिक्शनरी. वैल्यू $(location) और "वैरिएबल बनाएं" के विकल्प पर निर्भर करती हैं. वैल्यू, डिफ़ॉल्ट रूप से {} पर निर्भर करती है bazel run से टारगेट को लागू करने पर, सेट करने के लिए अन्य एनवायरमेंट वैरिएबल तय करता है. यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि cc_binary, py_binary, और sh_binary. यह Starlark से तय किए गए, लागू किए जा सकने वाले नियमों पर लागू नहीं होता. ध्यान दें: Bazel के बाहर टारगेट को चलाने पर, एनवायरमेंट वैरिएबल सेट नहीं होते. उदाहरण के लिए, bazel-bin/ में बाइनरी को मैन्युअल तरीके से चलाकर.
output_licenses	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है उन आउटपुट फ़ाइलों के लाइसेंस जिन्हें यह बाइनरी जनरेट करती है. यह उस लाइसेंसिंग एपीआई का हिस्सा है जो अब सेवा में नहीं है. अब Basel का इस्तेमाल नहीं किया जाता है. इसका इस्तेमाल न करें.

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

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

इस उदाहरण में, अलग-अलग टारगेट आर्किटेक्चर के लिए अलग-अलग सोर्स के बारे में बताया गया है. 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++ में, इंप्लिसिट आउटपुट का इस्तेमाल बंद कर दिया गया है. जहां भी हो सके, दूसरी भाषाओं में इसका इस्तेमाल न करें. फ़िलहाल, हमने इन सुविधाओं को बंद करने का कोई तरीका तय नहीं किया है. हालांकि, इन्हें भी बंद कर दिया जाएगा.

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

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

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

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