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

समस्या की शिकायत करें सोर्स देखें Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

सामग्री

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

बॉर्न शेल टोकनाइज़ेशन

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

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

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

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

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

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

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

एट्रिब्यूट	ब्यौरा
aspect_hints	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है यह ऐसे लेबल की सूची है जो पहलू के लिए उपलब्ध है. खास तौर पर, इस नियम की रिवर्स डिपेंडेंसी से जुड़े पहलू. हालांकि, यह इस नियम के खुद के लागू करने के लिए उपलब्ध नहीं है. किसी खास भाषा के लिए बने नियमों के सेट से जुड़े दस्तावेज़ देखें. इससे आपको यह पता चलेगा कि किसी पहलू के बारे में दिए गए सुझाव का क्या असर होगा. किसी पहलू के बारे में जानकारी देने वाले सुझाव को टैग के बेहतर विकल्प के तौर पर देखा जा सकता है: टैग सिर्फ़ बूलियन स्थिति के बारे में बताता है. इसका मतलब है कि टैग, tags सूची में मौजूद है या नहीं. वहीं, किसी पहलू के बारे में जानकारी देने वाले सुझाव के प्रोवाइडर, स्ट्रक्चर्ड फ़ॉर्मैट में कोई भी जानकारी दे सकते हैं. असल में, पहलू के बारे में जानकारी देने वाले हिंट का इस्तेमाल, भाषा के हिसाब से बनाए गए अलग-अलग नियम सेट के बीच इंटरऑपरेबिलिटी के लिए किया जाता है. उदाहरण के लिए, मान लें कि आपके पास एक mylang_binary टारगेट है, जिसे otherlang_library टारगेट पर निर्भर रहना है. MyLang के हिसाब से लॉजिक का इस्तेमाल करने के लिए, OtherLang टारगेट के बारे में कुछ और जानकारी की ज़रूरत होती है. हालांकि, otherlang_libraryयह जानकारी नहीं देता, क्योंकि इसे MyLang के बारे में कुछ भी नहीं पता. एक समाधान यह हो सकता है कि MyLang के नियम सेट में एक mylang_hint नियम तय किया जाए. इसका इस्तेमाल, अतिरिक्त जानकारी को कोड में बदलने के लिए किया जा सकता है. उपयोगकर्ता, अपने otherlang_library के aspect_hints में हिंट जोड़ सकता है. साथ ही, mylang_binary, mylang_hint में MyLang के हिसाब से काम करने वाले किसी प्रोवाइडर से अतिरिक्त जानकारी इकट्ठा करने के लिए, किसी पहलू का इस्तेमाल कर सकता है. उदाहरण के लिए, rules_swift में swift_interop_hint और swift_overlay देखें. सबसे सही तरीके: aspect_hints में दिए गए टारगेट, हल्के-फुल्के और कम होने चाहिए. भाषा के हिसाब से लॉजिक को सिर्फ़ उन पहलुओं के बारे में जानकारी देनी चाहिए जिनके लिए, उस भाषा से जुड़े प्रोवाइडर उपलब्ध हैं. साथ ही, उसे अन्य पहलुओं के बारे में जानकारी को अनदेखा करना चाहिए.
compatible_with	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू [] है डिफ़ॉल्ट रूप से काम करने वाले एनवायरमेंट के अलावा, इस टारगेट को जिन एनवायरमेंट के लिए बनाया जा सकता है उनकी सूची. यह Bazel के कॉन्स्ट्रेंट सिस्टम का हिस्सा है. इससे उपयोगकर्ता यह तय कर सकते हैं कि कौनसे टारगेट एक-दूसरे पर निर्भर हो सकते हैं और कौनसे नहीं. उदाहरण के लिए, बाहरी तौर पर डिप्लॉय किए जा सकने वाले बाइनरी, कंपनी के सीक्रेट कोड वाली लाइब्रेरी पर निर्भर नहीं होने चाहिए. ज़्यादा जानकारी के लिए, ConstraintSemantics देखें.
deprecation	स्ट्रिंग; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू None है इस टारगेट से जुड़ी चेतावनी का मैसेज. आम तौर पर, इसका इस्तेमाल उपयोगकर्ताओं को यह सूचना देने के लिए किया जाता है कि कोई टारगेट पुराना हो गया है. इसके अलावा, इसका इस्तेमाल यह बताने के लिए भी किया जाता है कि किसी टारगेट को किसी दूसरे नियम ने बदल दिया है, वह किसी पैकेज के लिए निजी है या किसी वजह से उसे नुकसान पहुंचाने वाला माना जाता है. कुछ रेफ़रंस (जैसे, वेबपेज, गड़बड़ी का नंबर या माइग्रेशन के उदाहरण वाले सीएल) शामिल करना एक अच्छा विचार है, ताकि यह आसानी से पता लगाया जा सके कि मैसेज से बचने के लिए कौनसे बदलाव ज़रूरी हैं. अगर कोई नया टारगेट उपलब्ध है, जिसका इस्तेमाल पुराने टारगेट की जगह किया जा सकता है, तो पुराने टारगेट के सभी उपयोगकर्ताओं को माइग्रेट करना बेहतर होता है. इस एट्रिब्यूट से, चीज़ें बनाने के तरीके पर कोई असर नहीं पड़ता. हालांकि, इससे बिल्ड टूल के डाइग्नोस्टिक आउटपुट पर असर पड़ सकता है. जब किसी दूसरे पैकेज में मौजूद टारगेट, deprecation एट्रिब्यूट वाले नियम पर निर्भर होता है, तब बिल्ड टूल चेतावनी जारी करता है. इंट्रा-पैकेज डिपेंडेंसी को इस चेतावनी से छूट दी गई है, ताकि उदाहरण के लिए, बंद किए गए नियम के टेस्ट बनाने पर चेतावनी न मिले. अगर बंद किए गए किसी टारगेट के लिए, बंद किए गए किसी दूसरे टारगेट पर निर्भर रहना ज़रूरी है, तो चेतावनी वाला कोई मैसेज नहीं दिखाया जाता. जब लोग इसका इस्तेमाल करना बंद कर दें, तब टारगेट को हटाया जा सकता है.
exec_compatible_with	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू [] है constraint_values की सूची, जो इस टारगेट के डिफ़ॉल्ट एक्ज़ीक्यूशन ग्रुप के एक्ज़ीक्यूशन प्लैटफ़ॉर्म में मौजूद होनी चाहिए. यह नियम के टाइप के हिसाब से पहले से सेट की गई किसी भी सीमा के अलावा है. पाबंदियों का इस्तेमाल, उपलब्ध एक्ज़ीक्यूशन प्लैटफ़ॉर्म की सूची को सीमित करने के लिए किया जाता है. ज़्यादा जानकारी के लिए, टूलचेन रिज़ॉल्यूशन का ब्यौरा देखें. और एक्ज़ेक ग्रुप
exec_group_compatible_with	लेबल की सूचियों के लिए स्ट्रिंग का शब्दकोश; nonconfigurable; डिफ़ॉल्ट वैल्यू {} है यह एक्ज़ेक ग्रुप के नामों की डिक्शनरी है. इसमें constraint_values की सूचियां होती हैं. ये सूचियां, दिए गए एक्ज़ेक ग्रुप के लिए एक्ज़ीक्यूशन प्लैटफ़ॉर्म में मौजूद होनी चाहिए. यह एक्ज़ीक्यूटिव ग्रुप की परिभाषा पर पहले से सेट की गई किसी भी पाबंदी के अलावा है. पाबंदियों का इस्तेमाल, उपलब्ध एक्ज़ीक्यूशन प्लैटफ़ॉर्म की सूची को सीमित करने के लिए किया जाता है. ज़्यादा जानकारी के लिए, टूलचेन रिज़ॉल्यूशन का ब्यौरा देखें. और एक्ज़ेक ग्रुप
exec_properties	स्ट्रिंग का शब्दकोश; डिफ़ॉल्ट वैल्यू {} है स्ट्रिंग की एक डिक्शनरी, जिसे इस टारगेट के लिए चुने गए प्लैटफ़ॉर्म के exec_properties में जोड़ा जाएगा. प्लैटफ़ॉर्म के नियम का exec_properties देखें. अगर कोई कुंजी, प्लैटफ़ॉर्म और टारगेट-लेवल, दोनों प्रॉपर्टी में मौजूद है, तो वैल्यू को टारगेट से लिया जाएगा. कुंजी के नाम से पहले, एक्ज़ीक्यूशन ग्रुप का नाम और उसके बाद . लगाया जा सकता है. इससे कुंजियां सिर्फ़ उस एक्ज़ीक्यूशन ग्रुप पर लागू होंगी.
features	सुविधा स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है सुविधा एक स्ट्रिंग टैग होती है, जिसे किसी टारगेट पर चालू या बंद किया जा सकता है. किसी सुविधा का मतलब, नियम पर निर्भर करता है. इस features एट्रिब्यूट को पैकेज लेवल के features एट्रिब्यूट के साथ जोड़ा जाता है. उदाहरण के लिए, अगर पैकेज लेवल पर ["a", "b"] सुविधाएं चालू हैं और टारगेट के features एट्रिब्यूट में ["-a", "c"] शामिल है, तो नियम के लिए चालू की गई सुविधाएं "b" और "c" होंगी. उदाहरण देखें.
package_metadata	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से पैकेज का default_package_metadata होता है उन लेबल की सूची जो इस टारगेट के बारे में मेटाडेटा से जुड़े हैं. आम तौर पर, लेबल ऐसे आसान नियम होते हैं जो एक जैसी वैल्यू देने वाली कंपनी की जानकारी देते हैं. नियम और पहलू, इन लेबल का इस्तेमाल करके बिल्ड ग्राफ़ का कुछ अतिरिक्त विश्लेषण कर सकते हैं. rules_license एट्रिब्यूट का इस्तेमाल करने का सबसे सही तरीका यह है. इस मामले में, package_metadata और default_package_metadata का इस्तेमाल, टारगेट में पैकेज के लाइसेंस या वर्शन के बारे में जानकारी जोड़ने के लिए किया जाता है. टॉप-लेवल के किसी बाइनरी पर लागू किए गए पहलू का इस्तेमाल, इन पहलुओं को इकट्ठा करने और अनुपालन से जुड़ी रिपोर्ट जनरेट करने के लिए किया जा सकता है.
restricted_to	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू [] है उन एनवायरमेंट की सूची जिनके लिए इस टारगेट को बनाया जा सकता है. यह सूची, डिफ़ॉल्ट रूप से काम करने वाले एनवायरमेंट की सूची के बदले इस्तेमाल की जाती है. यह Bazel के कंस्ट्रेंट सिस्टम का हिस्सा है. ज़्यादा जानकारी के लिए, compatible_with पर जाएं.
tags	स्ट्रिंग की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू [] है टैग का इस्तेमाल किसी भी नियम पर किया जा सकता है. टेस्ट और test_suite नियमों पर टैग, टेस्ट को कैटगरी में बांटने के लिए काम आते हैं. टैग का इस्तेमाल, टेस्ट के अलावा अन्य टारगेट पर किया जाता है. इनका इस्तेमाल, genrule और Starlark कार्रवाइयों के सैंडबॉक्स वाले वर्शन को कंट्रोल करने के लिए किया जाता है. साथ ही, इनका इस्तेमाल इंसानों और/या बाहरी टूल से पार्स करने के लिए किया जाता है. अगर Bazel को किसी भी टेस्ट या genrule टारगेट के tags एट्रिब्यूट में ये कीवर्ड मिलते हैं, तो वह सैंडबॉक्सिंग कोड के व्यवहार में बदलाव करता है. इसके अलावा, अगर उसे किसी भी Starlark कार्रवाई के लिए execution_requirements की कुंजियां मिलती हैं, तो भी वह ऐसा करता है. no-sandbox कीवर्ड का इस्तेमाल करने पर, कार्रवाई या टेस्ट को कभी भी सैंडबॉक्स नहीं किया जाता. इसे अब भी कैश मेमोरी में सेव किया जा सकता है या रिमोट तरीके से चलाया जा सकता है. इनमें से किसी एक या दोनों को रोकने के लिए, no-cache या no-remote का इस्तेमाल करें. no-cache कीवर्ड का इस्तेमाल करने पर, कार्रवाई या जांच के नतीजे कभी भी कैश मेमोरी में सेव नहीं होते. ये नतीजे, डिवाइस में या रिमोट सर्वर पर सेव नहीं होते. ध्यान दें: इस टैग के लिए, डिस्क कैश मेमोरी को लोकल कैश मेमोरी माना जाता है. वहीं, एचटीटीपी और gRPC कैश मेमोरी को रिमोट कैश मेमोरी माना जाता है. Skyframe या परसिस्टेंट ऐक्शन कैश जैसी अन्य कैश पर इसका कोई असर नहीं पड़ता. no-remote-cache कीवर्ड का इस्तेमाल करने पर, कार्रवाई या टेस्ट को कभी भी रिमोटली कैश मेमोरी में सेव नहीं किया जाता. हालांकि, इसे स्थानीय तौर पर कैश मेमोरी में सेव किया जा सकता है. इसे रिमोटली भी एक्ज़ीक्यूट किया जा सकता है. ध्यान दें: इस टैग के लिए, डिस्क कैश मेमोरी को लोकल कैश मेमोरी माना जाता है. वहीं, एचटीटीपी और gRPC कैश मेमोरी को रिमोट कैश मेमोरी माना जाता है. Skyframe या परसिस्टेंट ऐक्शन कैश जैसी अन्य कैश मेमोरी पर इसका कोई असर नहीं पड़ता. अगर लोकल डिस्क कैश और रिमोट कैश, दोनों का इस्तेमाल किया जाता है (कंबाइंड कैश), तो इसे रिमोट कैश माना जाता है. साथ ही, इसे पूरी तरह से बंद कर दिया जाता है. हालांकि, अगर --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 कीवर्ड, सैंडबॉक्स में मौजूद बाहरी नेटवर्क का ऐक्सेस ब्लॉक करता है. इस मामले में, सिर्फ़ लोकल होस्ट से कम्यूनिकेट करने की अनुमति है. यह टैग सिर्फ़ तब काम करता है, जब सैंडबॉक्सिंग चालू हो. 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_values की एक सूची, जो टारगेट प्लैटफ़ॉर्म में मौजूद होनी चाहिए, ताकि इस टारगेट को काम करने वाला माना जा सके. यह नियम के टाइप के हिसाब से पहले से सेट की गई किसी भी पाबंदी के अलावा है. अगर टारगेट प्लैटफ़ॉर्म, बताई गई सभी पाबंदियों को पूरा नहीं करता है, तो टारगेट को उपलब्ध नहीं है माना जाता है. टारगेट पैटर्न को बड़ा करने पर, साथ काम न करने वाले टारगेट को बनाने और उनकी जांच करने की प्रोसेस को छोड़ दिया जाता है.उदाहरण के लिए, //..., :all. कमांड लाइन पर साफ़ तौर पर बताए जाने पर, साथ काम न करने वाले टारगेट की वजह से Bazel एक गड़बड़ी प्रिंट करता है. साथ ही, इससे बिल्ड या टेस्ट फ़ेल हो जाता है. ऐसे टारगेट जो ट्रांज़िटिव तौर पर, काम न करने वाले टारगेट पर निर्भर होते हैं उन्हें भी काम न करने वाला टारगेट माना जाता है. इन्हें बनाने और जाँचने के लिए भी नहीं चुना जाता. खाली सूची (जो डिफ़ॉल्ट होती है) का मतलब है कि टारगेट सभी प्लैटफ़ॉर्म के साथ काम करता है. Workspace के नियमों को छोड़कर, अन्य सभी नियमों के लिए इस एट्रिब्यूट का इस्तेमाल किया जा सकता है. कुछ नियमों के लिए, इस एट्रिब्यूट का कोई असर नहीं होता. उदाहरण के लिए, cc_toolchain के लिए target_compatible_with की जानकारी देना काम का नहीं है. टारगेट स्किप करने की सुविधा के साथ काम न करने वाले प्लैटफ़ॉर्म के बारे में ज़्यादा जानने के लिए, प्लैटफ़ॉर्म पेज देखें.
testonly	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू False है टेस्ट और टेस्ट सुइट के टारगेट को छोड़कर अगर True है, तो सिर्फ़ testonly टारगेट (जैसे कि टेस्ट) इस टारगेट पर निर्भर हो सकते हैं. इसी तरह, testonly नहीं होने वाले नियम को, testonly होने वाले किसी भी नियम पर निर्भर रहने की अनुमति नहीं है. जांच (*_test नियम) और टेस्ट सुइट (test_suite नियम) डिफ़ॉल्ट रूप से testonly होते हैं. इस एट्रिब्यूट का मतलब है कि टारगेट को प्रोडक्शन के लिए रिलीज़ किए गए बाइनरी में शामिल नहीं किया जाना चाहिए. testonly को बिल्ड टाइम पर लागू किया जाता है, न कि रन टाइम पर. साथ ही, यह डिपेंडेंसी ट्री के ज़रिए तेज़ी से फैलता है. इसलिए, इसे सोच-समझकर लागू किया जाना चाहिए. उदाहरण के लिए, स्टब और फ़ेक, यूनिट टेस्ट के लिए फ़ायदेमंद होते हैं. ये इंटिग्रेशन टेस्ट के लिए भी फ़ायदेमंद हो सकते हैं. इनमें प्रोडक्शन के लिए रिलीज़ किए जाने वाले एक ही बाइनरी शामिल होते हैं. इसलिए, इन्हें शायद testonly के तौर पर मार्क नहीं किया जाना चाहिए. इसके उलट, जिन नियमों को लिंक करने से भी खतरा होता है उन्हें testonly के तौर पर मार्क किया जाना चाहिए. ऐसा इसलिए, क्योंकि वे बिना किसी शर्त के सामान्य व्यवहार को बदल देते हैं.
toolchains	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू [] है टारगेट का वह सेट जिसके मेक वैरिएबल को यह टारगेट ऐक्सेस कर सकता है. ये टारगेट, ऐसे नियमों के उदाहरण होते हैं जो TemplateVariableInfo देते हैं या Bazel में बनाए गए टूलचेन टाइप के लिए खास टारगेट होते हैं. इनमें ये शामिल हैं: @bazel_tools//tools/cpp:toolchain_type @rules_java//toolchains:current_java_runtime ध्यान दें कि यह टूलचेन रिज़ॉल्यूशन के कॉन्सेप्ट से अलग है. इसका इस्तेमाल, प्लैटफ़ॉर्म पर निर्भर कॉन्फ़िगरेशन के लिए नियमों को लागू करने के लिए किया जाता है. इस एट्रिब्यूट का इस्तेमाल करके, यह तय नहीं किया जा सकता कि टारगेट कौनसे cc_toolchain या java_toolchain का इस्तेमाल करेगा.
visibility	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू अलग-अलग होती है visibility एट्रिब्यूट से यह तय होता है कि टारगेट को अन्य जगहों के टारगेट पर निर्भर रहने की अनुमति है या नहीं. दृश्यता के बारे में जानकारी के लिए, दस्तावेज़ देखें. BUILD फ़ाइल में सीधे तौर पर या BUILD फ़ाइल से कॉल किए गए लेगसी मैक्रो में एलान किए गए टारगेट के लिए, डिफ़ॉल्ट वैल्यू पैकेज का default_visibility होता है. अगर यह वैल्यू तय की गई है, तो इसका इस्तेमाल किया जाता है. अगर यह वैल्यू तय नहीं की गई है, तो ["//visibility:private"] का इस्तेमाल किया जाता है. एक या उससे ज़्यादा सिंबॉलिक मैक्रो में तय किए गए टारगेट के लिए, डिफ़ॉल्ट वैल्यू हमेशा सिर्फ़ ["//visibility:private"] होती है. इसका मतलब है कि इसका इस्तेमाल सिर्फ़ उस पैकेज में किया जा सकता है जिसमें मैक्रो का कोड होता है.

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

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

एट्रिब्यूट	ब्यौरा
args	स्ट्रिंग की सूची; $(location) और "वैरिएबल बनाएं" के हिसाब से बदलती है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलती है; डिफ़ॉल्ट वैल्यू [] है कमांड लाइन आर्ग्युमेंट, जिन्हें bazel test के साथ एक्ज़ीक्यूट किए जाने पर Bazel, टारगेट को पास करता है. ये आर्ग्युमेंट, --test_arg कमांड लाइन पर दी गई किसी भी --test_arg वैल्यू से पहले पास किए जाते हैं.bazel test
env	स्ट्रिंग की डिक्शनरी; वैल्यू, $(location) और "Make variable" के हिसाब से बदलती हैं; डिफ़ॉल्ट वैल्यू {} है bazel test की मदद से टेस्ट को एक्ज़ीक्यूट करते समय, सेट की जाने वाली अन्य एनवायरमेंट वैरिएबल तय करता है. यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है. जैसे, cc_test, py_test, और sh_test. यह Starlark में तय किए गए टेस्ट के नियमों पर लागू नहीं होता. अपने Starlark नियमों के लिए, "env" एट्रिब्यूट जोड़ा जा सकता है. इसका इस्तेमाल, RunEnvironmentInfo प्रोवाइडर को पॉप्युलेट करने के लिए किया जा सकता है. TestEnvironment Provider.
env_inherit	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू [] है bazel test की मदद से टेस्ट को एक्ज़ीक्यूट करते समय, बाहरी एनवायरमेंट से इनहेरिट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है. जैसे, cc_test, py_test, और sh_test. यह Starlark में तय किए गए टेस्ट के नियमों पर लागू नहीं होता.
size	स्ट्रिंग "enormous", "large", "medium" या "small"; बदला नहीं जा सकता; डिफ़ॉल्ट वैल्यू "medium" है इससे टेस्ट टारगेट की "heaviness" के बारे में पता चलता है. इसका मतलब है कि इसे चलाने के लिए कितना समय/संसाधन चाहिए. यूनिट टेस्ट को "छोटा", इंटिग्रेशन टेस्ट को "मीडियम", और एंड-टू-एंड टेस्ट को "बड़ा" या "बहुत बड़ा" माना जाता है. 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 है इस कुकी का इस्तेमाल, टेस्ट को फ़्लेकी के तौर पर मार्क करने के लिए किया जाता है. अगर यह विकल्प सेट किया जाता है, तो टेस्ट को तीन बार तक चलाया जाता है. अगर टेस्ट हर बार फ़ेल होता है, तो ही उसे फ़ेल के तौर पर मार्क किया जाता है. डिफ़ॉल्ट रूप से, इस एट्रिब्यूट को False पर सेट किया जाता है. साथ ही, टेस्ट सिर्फ़ एक बार किया जाता है. ध्यान दें कि आम तौर पर इस एट्रिब्यूट का इस्तेमाल करने का सुझाव नहीं दिया जाता. अगर टेस्ट में पुष्टि की गई शर्तों का पालन किया जाता है, तो टेस्ट के नतीजे भरोसेमंद होने चाहिए.
shard_count	50 से कम या इसके बराबर का नॉन-नेगेटिव पूर्णांक; डिफ़ॉल्ट वैल्यू -1 है टेस्ट चलाने के लिए, पैरलल शार्ड की संख्या तय करता है. अगर यह वैल्यू सेट की जाती है, तो यह उन सभी अनुमानित तरीकों को बदल देगी जिनका इस्तेमाल, टेस्ट को चलाने के लिए पैरलल शार्ड की संख्या तय करने के लिए किया जाता है. ध्यान दें कि कुछ टेस्ट रूल के लिए, इस पैरामीटर की ज़रूरत हो सकती है. ऐसा इसलिए, ताकि शार्डिंग को चालू किया जा सके. --test_sharding_strategy भी देखें. अगर टेस्ट शार्डिंग चालू है, तो टेस्ट शुरू करते समय एनवायरमेंट वैरिएबल TEST_TOTAL_SHARDS को इस वैल्यू पर सेट किया जाएगा. शार्डिंग के लिए, टेस्ट रनर को टेस्ट शार्डिंग प्रोटोकॉल के साथ काम करना होगा. अगर ऐसा नहीं होता है, तो हर शार्ड में हर टेस्ट चलने की संभावना ज़्यादा होती है. हालांकि, ऐसा नहीं होना चाहिए. शार्डिंग के बारे में ज़्यादा जानकारी के लिए, Test Encyclopedia में Test Sharding देखें.
local	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू False है इस विकल्प से, टेस्ट को सैंडबॉक्सिंग के बिना स्थानीय तौर पर चलाया जाता है. इसे True पर सेट करने का मतलब है कि आपने टैग (tags=["local"]) के तौर पर "local" वैल्यू दी है.

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

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

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

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

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

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

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

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

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

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