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

इस सेक्शन में ऐसे अलग-अलग शब्दों और अवधारणाओं के बारे में बताया गया है, जो कई फ़ंक्शन के लिए सामान्य हैं या जो नियम बनाते हैं.

विषय सूची

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

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

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

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

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

लेबल एक्सपैंशन

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

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

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

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

एट्रिब्यूट	ब्यौरा
data	List of labels ; optional रनटाइम के दौरान, इस नियम के तहत ज़रूरी फ़ाइलें. फ़ाइल या नियम से जुड़े टारगेट की सूची बनाई जा सकती है. आम तौर पर, सभी टारगेट को अनुमति देता है. data एट्रिब्यूट में शामिल टारगेट के डिफ़ॉल्ट आउटपुट और रनफ़ाइल, किसी भी एक्ज़ीक्यूटेबल के *.runfiles एरिया में दिखना चाहिए, जो इस टारगेट के मुताबिक आउटपुट है या उस पर रनटाइम डिपेंडेंसी है. इसमें इस टारगेट के srcs के एक्ज़ीक्यूट होने के दौरान इस्तेमाल की गई डेटा फ़ाइलें या बाइनरी शामिल हो सकती हैं. डेटा फ़ाइलों पर निर्भर होने और उनका इस्तेमाल करने के तरीके के बारे में ज़्यादा जानकारी के लिए, डेटा डिपेंडेंसी सेक्शन देखें. अगर नए नियम ऐसे इनपुट प्रोसेस करते हैं जो रनटाइम के दौरान दूसरे इनपुट का इस्तेमाल कर सकते हैं, तो उन्हें data एट्रिब्यूट तय करना चाहिए. नियम लागू करने वाले फ़ंक्शन को भी किसी भी data एट्रिब्यूट के आउटपुट और रनफ़ाइल से टारगेट के रनफ़ाइल को भरना चाहिए. साथ ही, किसी भी डिपेंडेंसी एट्रिब्यूट से रनफ़ाइल को भी भरना चाहिए, जो सोर्स कोड या रनटाइम डिपेंडेंसी देता है.
deps	List of labels ; optional इस टारगेट के लिए डिपेंडेंसी. आम तौर पर, सिर्फ़ नियम से जुड़े टारगेट की सूची बनाई जानी चाहिए. (हालांकि, कुछ नियमों की मदद से फ़ाइलों को सीधे deps में शामिल किया जा सकता है. हालांकि, जहां तक हो सके, इससे बचना चाहिए.) किसी खास भाषा के लिए बने नियमों के तहत, सूची में शामिल टारगेट सिर्फ़ उन लोगों को दिए जाते हैं जो सेवा देने वाली खास कंपनियां उपलब्ध कराते हैं. deps का इस्तेमाल करके किसी टारगेट पर निर्भर होने के मतलब का सटीक सिमैंटिक, नियम के हिसाब से होता है. साथ ही, किसी खास नियम के दस्तावेज़ में ज़्यादा जानकारी दी जाती है. सोर्स कोड को प्रोसेस करने वाले नियमों के लिए, deps आम तौर पर srcs में इस्तेमाल होने वाली कोड डिपेंडेंसी के बारे में बताता है. ज़्यादातर मामलों में, deps डिपेंडेंसी का इस्तेमाल किया जाता है, ताकि एक मॉड्यूल उसी प्रोग्रामिंग भाषा में लिखे गए और अलग से कंपाइल किए गए किसी दूसरे मॉड्यूल में तय किए गए चिह्नों का इस्तेमाल कर सके. कई मामलों में, क्रॉस-भाषा डिपेंडेंसी भी इस्तेमाल की जा सकती है: उदाहरण के लिए, java_library टारगेट, cc_library टारगेट में C++ कोड पर निर्भर हो सकता है. बाद वाले कोड को deps एट्रिब्यूट में शामिल करें. ज़्यादा जानकारी के लिए डिपेंडेंसी की परिभाषा देखें.
licenses	List of strings; optional; nonconfigurable इस खास टारगेट के लिए इस्तेमाल किए जाने वाले लाइसेंस-टाइप स्ट्रिंग की सूची. यह लाइसेंस देने वाले ऐसे एपीआई का हिस्सा है जो अब काम नहीं करता. हालांकि, Bazel अब इस्तेमाल नहीं करता है. इसका इस्तेमाल न करें.
srcs	List of labels ; optional इस नियम के तहत प्रोसेस की गई या शामिल की गई फ़ाइलें. आम तौर पर, फ़ाइलों को सीधे तौर पर सूची में रखा जाता है, लेकिन उनके डिफ़ॉल्ट आउटपुट को शामिल करने के लिए नियम टारगेट (जैसे कि filegroup या genrule) की सूची बनाई जा सकती है. भाषा के हिसाब से नियमों के लिए यह ज़रूरी है कि सूची में शामिल फ़ाइलों में खास फ़ाइल एक्सटेंशन हों.

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

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

एट्रिब्यूट	ब्यौरा
compatible_with	List of labels ; optional; nonconfigurable उन एनवायरमेंट की सूची जिनके लिए इस टारगेट को बनाया जा सकता है. साथ ही, डिफ़ॉल्ट रूप से काम करने वाले एनवायरमेंट की सूची भी होती है. यह Bazel के कंस्ट्रेंट सिस्टम का हिस्सा है. इससे उपयोगकर्ताओं को यह पता चलता है कि कौनसे टारगेट एक-दूसरे पर निर्भर हो सकते हैं और कौनसे नहीं. उदाहरण के लिए, बाहर से डिप्लॉय किए जा सकने वाले बाइनरी का इस्तेमाल, कंपनी के सीक्रेट कोड वाली लाइब्रेरी पर निर्भर नहीं होना चाहिए. ज़्यादा जानकारी के लिए, ConstraintSemantics देखें.
deprecation	String; optional; nonconfigurable इस टारगेट से जुड़ा चेतावनी वाला मैसेज. आम तौर पर, इसका इस्तेमाल उपयोगकर्ताओं को यह बताने के लिए किया जाता है कि टारगेट पुराना हो गया है या किसी दूसरे नियम ने उसकी जगह ले ली है, पैकेज के लिए निजी है या किसी वजह से उसे नुकसान पहुंचाने वाला माना जा सकता है. कुछ रेफ़रंस (जैसे वेबपेज, बग नंबर या माइग्रेशन सीएलएस) शामिल करना बेहतर होता है, ताकि आसानी से पता लगाया जा सके कि मैसेज से बचने के लिए कौनसे बदलाव करने ज़रूरी हैं. अगर कोई ऐसा नया टारगेट है जिसका इस्तेमाल करके, उस टारगेट को कम किया जा सकता है, तो पुराने टारगेट के सभी उपयोगकर्ताओं को माइग्रेट करना अच्छा रहेगा. इस एट्रिब्यूट से चीज़ों को बनाने के तरीके पर कोई असर नहीं पड़ता. हालांकि, इससे बिल्ड टूल के डाइग्नोस्टिक आउटपुट पर असर पड़ सकता है. जब deprecation एट्रिब्यूट वाला नियम, किसी दूसरे पैकेज में मौजूद टारगेट पर निर्भर होता है, तो बिल्ड टूल चेतावनी जारी करता है. इंट्रा-पैकेज डिपेंडेंसी को इस चेतावनी में शामिल नहीं किया जाता. इसलिए, उदाहरण के लिए, ऐसे नियम के टेस्ट बनाने के लिए चेतावनी न मिले जो अब काम नहीं करते. अगर रोका गया टारगेट, किसी दूसरे काम न करने वाले टारगेट पर निर्भर है, तो चेतावनी वाला कोई मैसेज नहीं भेजा जाता. जब लोग इसका इस्तेमाल बंद कर देते हैं, तो टारगेट को हटाया जा सकता है.
distribs	List of strings; optional; nonconfigurable इस खास टारगेट के लिए इस्तेमाल की जाने वाली डिस्ट्रिब्यूशन-तरीका स्ट्रिंग की सूची. यह लाइसेंस देने वाले ऐसे एपीआई का हिस्सा है जो अब काम नहीं करता. हालांकि, Bazel अब इस्तेमाल नहीं करता है. इसका इस्तेमाल न करें.
exec_compatible_with	List of labels ; optional; nonconfigurable constraint_values की सूची, जो इस टारगेट के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म में मौजूद होनी चाहिए. यह नियम टाइप के हिसाब से, पहले से सेट की गई हर कंस्ट्रेंट के अलावा होता है. पाबंदियों का इस्तेमाल, उपलब्ध एक्ज़ीक्यूशन प्लैटफ़ॉर्म की सूची को सीमित करने के लिए किया जाता है. ज़्यादा जानकारी के लिए, टूलचेन रिज़ॉल्यूशन की जानकारी देखें.
exec_properties	Dictionary of strings; optional स्ट्रिंग का डिक्शनरी, जिसे इस टारगेट के लिए चुने गए प्लैटफ़ॉर्म के exec_properties में जोड़ा जाएगा. प्लैटफ़ॉर्म नियम का exec_properties देखें. अगर प्लैटफ़ॉर्म और टारगेट-लेवल प्रॉपर्टी, दोनों में कुंजी मौजूद है, तो वैल्यू को टारगेट से ले लिया जाएगा.
features	List of feature strings; optional सुविधा एक स्ट्रिंग टैग है, जिसे किसी टारगेट के लिए चालू या बंद किया जा सकता है. किसी सुविधा का मतलब, नियम पर निर्भर करता है. इस features एट्रिब्यूट को, पैकेज लेवल features एट्रिब्यूट के साथ जोड़ा जाता है. उदाहरण के लिए, अगर ["a", "b"] सुविधाएं पैकेज लेवल पर चालू की गई हैं और टारगेट के features एट्रिब्यूट में ["-a", "c"] शामिल है, तो नियम के लिए चालू की गई सुविधाएं "b" और "c" होंगी. उदाहरण देखें.
restricted_to	List of labels ; optional; nonconfigurable उन एनवायरमेंट की सूची जिनके लिए यह टारगेट बनाया जा सकता है, न कि डिफ़ॉल्ट रूप से काम करने वाले एनवायरमेंट के. यह Bazel के कंस्ट्रेंट सिस्टम का हिस्सा है. ज़्यादा जानकारी के लिए, compatible_with पर जाएं.
tags	List of strings; optional; nonconfigurable टैग किसी भी नियम पर इस्तेमाल किए जा सकते हैं. टेस्ट के टैग और test_suite नियमों से, टेस्ट को कैटगरी में बांटने में मदद मिलती है. नॉन-टेस्ट टारगेट के टैग का इस्तेमाल, सैंडबॉक्स किए गए genrules और Starlark ऐक्शन को कंट्रोल करने के लिए किया जाता है. साथ ही, इनका इस्तेमाल लोगों और/या बाहरी टूल से पार्स करने के लिए भी किया जाता है. अगर किसी टेस्ट या genrule टारगेट के tags एट्रिब्यूट में ये कीवर्ड मिलते हैं, तो Bazel अपने सैंडबॉक्सिंग कोड के काम करने के तरीके में बदलाव करता है. इसके अलावा, Starlark की किसी भी कार्रवाई के लिए, execution_requirements की कुंजियां मिलने पर, Bazel बदलाव कर देता है. कार्रवाई या टेस्ट में no-sandbox कीवर्ड के नतीजे कभी सैंडबॉक्स नहीं किए जाते; इसे अब भी कैश मेमोरी में सेव किया जा सकता है या रिमोट तरीके से चलाया जा सकता है - इनमें से किसी एक या दोनों को रोकने के लिए no-cache या no-remote का इस्तेमाल करें. कार्रवाई या टेस्ट में no-cache कीवर्ड के नतीजे कभी भी कैश मेमोरी में सेव नहीं किए जाते (कहीं और से या स्थानीय तौर पर) कार्रवाई या टेस्ट में no-remote-cache कीवर्ड के नतीजे कभी भी रिमोट तरीके से कैश मेमोरी में सेव नहीं किए जाते. हालांकि, इसे डिवाइस में कैश मेमोरी में सेव किया जा सकता है. हालांकि, इसे रिमोट तरीके से भी इस्तेमाल किया जा सकता है. ध्यान दें: इस टैग के लिए, डिस्क-कैश को लोकल कैश मेमोरी माना जाता है, जबकि एचटीटीपी और 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 यह पक्का करते हुए जांच को "खास" मोड में चलाने के लिए हर हाल में करेगा, ताकि एक ही समय पर कोई भी अन्य टेस्ट न चल रहे हों. सभी बिल्ड गतिविधि और सामान्य टेस्ट पूरे होने के बाद, इस तरह के टेस्ट सीरियल के हिसाब से किए जाएंगे. इस तरह की जांच के लिए, रिमोट एक्ज़ीक्यूशन की सुविधा बंद रहती है. ऐसा इसलिए होता है, क्योंकि बैजल के पास रिमोट मशीन पर चल रही चीज़ों को कंट्रोल करने का विकल्प नहीं होता है. अगर exclusive-if-local स्थानीय तौर पर टेस्ट किया जाता है, तो उसे "खास" मोड में चलाए जाने के लिए ज़बरदस्ती लागू किया जाएगा. हालांकि, अगर इसे रिमोट तरीके से एक्ज़ीक्यूट किया जाता है, तो यह टेस्ट साथ-साथ चलाएगा. manual कीवर्ड, टारगेट पैटर्न वाइल्डकार्ड (..., :*, :all वगैरह) और test_suite नियमों के विस्तार से टारगेट को बाहर निकाल देगा, जो build, test, और coverage कमांड के लिए बनाने/चलाने के लिए टॉप-लेवल टारगेट के सेट का पता लगाते समय, टेस्ट को साफ़ तौर पर सूची में शामिल नहीं करता है. इससे, query कमांड के साथ-साथ अन्य कॉन्टेक्स्ट में, टारगेट वाइल्डकार्ड या टेस्ट सुइट एक्सपैंशन पर कोई असर नहीं पड़ता. ध्यान दें कि manual यह नहीं बताता है कि लगातार बिल्ड/टेस्ट सिस्टम से कोई टारगेट अपने-आप नहीं बनाया या चलाया जाना चाहिए. उदाहरण के लिए, किसी टारगेट को bazel test ... से बाहर रखना ज़रूरी हो सकता है, क्योंकि इसके लिए खास Bazel फ़्लैग की ज़रूरत होती है, लेकिन फिर भी इसे सही तरीके से कॉन्फ़िगर किए गए प्रीसबमिट या लगातार होने वाले टेस्ट में शामिल किया जाना चाहिए. external कीवर्ड, हर हाल में टेस्ट को बिना किसी शर्त के लागू करेगा (चाहे --cache_test_results वैल्यू कुछ भी हो). टेस्ट एनसाइक्लोपीडिया में टैग कन्वेंशन देखें. इससे आपको टेस्ट टारगेट से जुड़े टैग के बारे में ज़्यादा जानकारी मिलती है.
target_compatible_with	List of labels ; optional constraint_value की सूची, जो टारगेट प्लैटफ़ॉर्म में मौजूद होनी चाहिए, ताकि इस टारगेट को काम करता माना जा सके. यह नियम टाइप के हिसाब से, पहले से सेट की गई पाबंदियों के अलावा है. अगर टारगेट प्लैटफ़ॉर्म, सूची में दी गई सभी सीमाओं को पूरा नहीं करता है, तो टारगेट को incompatible माना जाता है. टारगेट पैटर्न को बड़ा करने पर, काम न करने वाले टारगेट बिल्डिंग और टेस्ट करने के दौरान स्किप कर दिए जाते हैं (जैसे, //..., :all). कमांड लाइन पर साफ़ तौर पर बताए जाने पर, काम न करने वाले टारगेट की वजह से Bazel गड़बड़ी प्रिंट करता है. इसकी वजह से, बिल्ड या टेस्ट काम नहीं करता है. जो टारगेट पूरी तरह से काम नहीं करने वाले टारगेट पर निर्भर रहते हैं उन्हें ही काम का नहीं माना जाता है. इन्हें भी बनाने और टेस्ट करने के लिए हटा दिया जाता है. एक खाली सूची (जो डिफ़ॉल्ट है) बताती है कि टारगेट सभी प्लैटफ़ॉर्म के साथ काम करता है. फ़ाइल फ़ोल्डर के नियम को छोड़कर, बाकी सभी नियम इस एट्रिब्यूट के साथ काम करते हैं. कुछ नियमों के लिए, इस एट्रिब्यूट का कोई असर नहीं होता. उदाहरण के लिए, cc_toolchain के लिए target_compatible_with तय करना फ़ायदेमंद नहीं है. काम न करने वाले टारगेट को स्किप करने के बारे में ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म पेज देखें.
testonly	Boolean; optional; default False except for test and test suite targets; nonconfigurable अगर सही है, तो सिर्फ़ जांच करने वाले टारगेट (जैसे कि टेस्ट) इस टारगेट पर निर्भर कर सकते हैं. इसी तरह, जो नियम testonly नहीं है उसे testonly वाले किसी भी नियम पर निर्भर करने की अनुमति नहीं है. टेस्ट (*_test नियम) और टेस्ट सुइट (test_suite नियम) डिफ़ॉल्ट रूप से testonly होते हैं. इस एट्रिब्यूट का मकसद यह है कि टारगेट, प्रोडक्शन के लिए रिलीज़ किए गए बाइनरी फ़ॉर्मैट में नहीं होना चाहिए. क्योंकि testसिर्फ़ बिल्ड के समय लागू किया जाता है, न कि रन टाइम पर. साथ ही, डिपेंडेंसी ट्री के ज़रिए वायरल होता है. इसलिए, इसे सोच-समझकर लागू किया जाना चाहिए. जैसे, यूनिट टेस्ट के लिए काम आने वाले स्टब और फ़ेक, इंटिग्रेशन टेस्ट के लिए भी काम आ सकते हैं. इनमें ऐसी बाइनरी शामिल हैं जिन्हें प्रोडक्शन के लिए रिलीज़ किया जाएगा. इसलिए, इन्हें शायद सिर्फ़ टेस्ट के लिए मार्क नहीं किया जाना चाहिए. इसके ठीक उलट, जो नियम लिंक करना भी खतरनाक हैं, उन्हें सिर्फ़ टेस्ट-ओनली के तौर पर मार्क किया जाना चाहिए. शायद इसलिए, क्योंकि वे सामान्य व्यवहार को बिना किसी शर्त के ओवरराइड करते हैं.
toolchains	List of labels ; optional; nonconfigurable टारगेट का वह सेट जिसके वैरिएबल बनाएं इस टारगेट को ऐक्सेस करने की अनुमति है. ये टारगेट या तो TemplateVariableInfo देने वाले नियमों के उदाहरण हैं या Bazel में बने टूलचेन टाइप के लिए खास टारगेट हैं. इनमें शामिल हैं: @bazel_tools//tools/cpp:current_cc_toolchain @bazel_tools//tools/jdk:current_java_runtime ध्यान रखें कि यह टूलचेन रिज़ॉल्यूशन से अलग है. इसका इस्तेमाल प्लैटफ़ॉर्म पर निर्भर कॉन्फ़िगरेशन के लिए, नियम लागू करने में किया जाता है. इस एट्रिब्यूट का इस्तेमाल करके, यह पता नहीं लगाया जा सकता कि टारगेट किस cc_toolchain या java_toolchain का इस्तेमाल करेगा.
visibility	List of labels ; optional; default default_visibility from package if specified, or //visibility:private otherwise; nonconfigurable टारगेट पर मौजूद visibility एट्रिब्यूट से यह कंट्रोल किया जाता है कि टारगेट को दूसरे पैकेज में इस्तेमाल किया जा सकता है या नहीं. किसको दिखे से जुड़ा दस्तावेज़ देखें.

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

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

एट्रिब्यूट	ब्यौरा
args	List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization वे कमांड लाइन तर्क जिन्हें bazel test के साथ एक्ज़ीक्यूट करने पर, Bazel टारगेट को भेजता है. इन तर्कों को, bazel test कमांड लाइन पर दी गई किसी भी --test_arg वैल्यू से पहले पास किया जाता है.
env	Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution इस नीति से, अतिरिक्त एनवायरमेंट वैरिएबल के बारे में जानकारी मिलती है, जिन्हें bazel test से टेस्ट एक्ज़ीक्यूट होने पर सेट किया जाता है. यह एट्रिब्यूट सिर्फ़ cc_test, py_test, और sh_test जैसे नेटिव नियमों पर लागू होता है. यह स्टारलार्क के तय किए गए जांच के नियमों पर लागू नहीं होता. अपने Starlark नियमों के लिए, एक "env" एट्रिब्यूट जोड़ा जा सकता है. साथ ही, इसका इस्तेमाल TestEnvironment प्रोवाइडर को पॉप्युलेट करने के लिए किया जा सकता है.
env_inherit	List of strings; optional इस नीति से, ऐसे अतिरिक्त एनवायरमेंट वैरिएबल तय किए जाते हैं जो बाहरी एनवायरमेंट से इनहेरिट किए जाते हैं. ऐसा तब होता है, जब bazel test से टेस्ट एक्ज़ीक्यूट होता है. यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि cc_test, py_test, और sh_test. यह स्टारलार्क के तय किए गए जांच के नियमों पर लागू नहीं होता.
size	String "enormous", "large" "medium" or "small", default is "medium"; optional; nonconfigurable इससे पता चलता है कि टेस्ट टारगेट को कितना "ज़्यादा" चाहिए: इसे चलाने के लिए कितना समय/संसाधन चाहिए. यूनिट टेस्ट को "छोटा", इंटिग्रेशन टेस्ट "मीडियम", और एंड-टू-एंड टेस्ट "बड़ा" या "बहुत ज़्यादा" माने जाते हैं. Bazel, डिफ़ॉल्ट टाइम आउट तय करने के लिए साइज़ का इस्तेमाल करता है. इसे timeout एट्रिब्यूट का इस्तेमाल करके बदला जा सकता है. यह टाइम आउट, BUILD टारगेट में मौजूद सभी जांचों के लिए है, न कि हर एक टेस्ट के लिए. जब टेस्ट स्थानीय तौर पर किया जाता है, तो size का इस्तेमाल शेड्यूलिंग के लिए भी किया जाता है: Bazel, --local_{ram,cpu}_resources का सम्मान करने की कोशिश करता है. साथ ही, एक ही समय पर बहुत सारे भारी टेस्ट करता है, ताकि वह स्थानीय मशीन पर असर न डाले. टेस्ट साइज़, नीचे दिए गए डिफ़ॉल्ट टाइम आउट और अनुमानित स्थानीय रिसॉर्स के इस्तेमाल से जुड़े होते हैं: साइज़ रैम (एमबी में) सीपीयू (सीपीयू कोर में) टाइम आउट की डिफ़ॉल्ट सेटिंग छोटा 20 1 छोटी (1 मिनट) medium 100 1 सामान्य (5 मिनट) बड़ा 300 1 लंबे (15 मिनट) विशाल 800 1 इटर्नल (60 मिनट) टेस्ट को तैयार करते समय, एनवायरमेंट वैरिएबल TEST_SIZE को इस एट्रिब्यूट की वैल्यू पर सेट किया जाएगा.
timeout	String "short", "moderate", "long", "eternal" (with the default derived from the test's size attribute); nonconfigurable वापस लौटने से पहले टेस्ट कितनी देर तक चलना चाहिए. टेस्ट का साइज़ एट्रिब्यूट, रिसॉर्स के अनुमान को कंट्रोल करता है. हालांकि, टेस्ट का टाइम आउट अलग से सेट किया जा सकता है. अगर साफ़ तौर पर नहीं बताया गया है, तो समयसीमा टेस्ट के साइज़ पर आधारित होती है. जांच के टाइम आउट को --test_timeout फ़्लैग से बदला जा सकता है. उदाहरण के लिए, कुछ ऐसी स्थितियों में चलने के लिए जिन्हें आम तौर पर धीमा माना जाता है. टेस्ट टाइम आउट वैल्यू, नीचे दी गई समयावधि के हिसाब से होती हैं: टाइम आउट की वैल्यू समयावधि छोटा 1 मिनट मध्यम 5 मिनट लंबा 15 मिनट अनंत 60 मिनट ऊपर बताई गई स्थितियों के अलावा, जांच के टाइम आउट को --test_timeout बेज़ेल फ़्लैग से बदला जा सकता है. उदाहरण के लिए, ऐसी स्थितियों को मैन्युअल तौर पर चलाने के लिए जिन्हें आम तौर पर धीमा माना जाता है. --test_timeout की वैल्यू सेकंड में होती हैं. उदाहरण के लिए, --test_timeout=120 जांच का टाइम आउट दो मिनट पर सेट करेगा. टेस्ट को शुरू करते समय, एनवायरमेंट वैरिएबल TEST_TIMEOUT को टेस्ट के टाइम आउट (सेकंड में) पर सेट किया जाएगा.
flaky	Boolean; optional; default False; nonconfigurable टेस्ट को फ़्लैकी के तौर पर मार्क करता है. सेट किए जाने पर, टेस्ट को ज़्यादा से ज़्यादा तीन बार करता है. अगर इसे हर बार फ़ेल कर दिया जाता है, तो इसे 'फ़ेल हुआ' के तौर पर मार्क किया जाता है. डिफ़ॉल्ट रूप से, यह एट्रिब्यूट 'गलत' पर सेट होता है और जांच सिर्फ़ एक बार की जाती है. ध्यान दें कि आम तौर पर इस एट्रिब्यूट के इस्तेमाल की सलाह नहीं दी जाती है. जब दावे बरकरार रहते हैं, तब जांच को भरोसेमंद तरीके से पास किया जाना चाहिए.
shard_count	Non-negative integer less than or equal to 50; optional यह तय करता है कि टेस्ट करने के लिए, पैरलल शार्ड की संख्या कितनी है. यह वैल्यू, ऐसे पैरलल शार्ड की संख्या तय करने के लिए इस्तेमाल किए जाने वाले किसी भी अनुमान को बदल देगी जिनसे टेस्ट करना है. ध्यान दें कि कुछ टेस्ट नियमों के लिए, इस पैरामीटर को पहली जगह शार्डिंग की सुविधा चालू करने की ज़रूरत पड़ सकती है. --test_sharding_strategy भी देखें. अगर टेस्ट शार्डिंग चालू है, तो टेस्ट को बनाते समय एनवायरमेंट वैरिएबल TEST_TOTAL_SHARDS को इस वैल्यू पर सेट कर दिया जाएगा. शार्डिंग के लिए टेस्ट रनर की ज़रूरत होती है, ताकि वह टेस्ट शार्डिंग प्रोटोकॉल के साथ काम कर सके. अगर ऐसा नहीं है, तो हो सकता है कि यह हर शार्ड में हर टेस्ट को चलाएगा, जो कि आप चाहते नहीं हैं. शार्डिंग के बारे में जानकारी के लिए, टेस्ट एन्साइक्लोपीडिया में टेस्टिंग देखें.
local	Boolean; default False; nonconfigurable सैंडबॉक्सिंग के बिना, टेस्ट को स्थानीय रूप से चलाने के लिए मजबूर करता है. इसे 'सही है' पर सेट करने का मतलब, "स्थानीय" को टैग (tags=["local"]) के तौर पर देने के बराबर है.

सभी बाइनरी नियमों (*_बाइनरी) के लिए सामान्य विशेषताएं

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

एट्रिब्यूट	ब्यौरा
args	List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization; nonconfigurable वे कमांड लाइन तर्क जिन्हें Bazel, टारगेट को तब पास करेगा, जब उसे run कमांड या टेस्ट के तौर पर लागू किया जाएगा. इन तर्कों को bazel run या bazel test कमांड लाइन पर दिए गए तर्कों से पहले पास किया जाता है. ध्यान दें: जब टारगेट को Bazel के बाहर चलाया जाता है, तो आर्ग्युमेंट पास नहीं होते. उदाहरण के लिए, bazel-bin/ में बाइनरी को मैन्युअल तरीके से एक्ज़ीक्यूट करके.
env	Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution इस नीति से, अतिरिक्त एनवायरमेंट वैरिएबल तय किए जाते हैं, जिन्हें bazel run से टारगेट को एक्ज़ीक्यूट करने पर सेट किया जाता है. यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि cc_binary, py_binary, और sh_binary. यह Starlark के तय किए गए एक्ज़ीक्यूटेबल नियमों पर लागू नहीं होता. ध्यान दें: जब टारगेट को Bazel के बाहर चलाया जाता है, तब एनवायरमेंट वैरिएबल सेट नहीं किए जाते. उदाहरण के लिए, bazel-bin/ में मैन्युअल तरीके से बाइनरी लागू करके.
output_licenses	List of strings; optional यह बाइनरी, जो आउटपुट फ़ाइलें जनरेट करती है उनके लाइसेंस. यह लाइसेंस देने वाले ऐसे एपीआई का हिस्सा है जो अब काम नहीं करता. हालांकि, 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 फ़ाइलों या कमांड लाइन से रेफ़र नहीं किया जा सकता. इस तरह से हो सकता है कि बिल्ड टूल, लागू करने से जुड़ी कुछ जानकारी छिपा दे. इससे यह पता चलता है कि आपका काम कैसे करता है. इस बारे में ज़्यादा जानकारी, बिल्ड कॉन्सेप्ट के रेफ़रंस में दी गई है.