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

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

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

कॉन्टेंट

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

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

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

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

आम तौर पर, "Make" वैरिएबल एक्सपैंशन और बॉर्न शेल टोकनाइज़ेशन के तहत आने वाले एट्रिब्यूट का इस्तेमाल, कंपाइलर और अन्य टूल को आर्बिट्रेरी विकल्प पास करने के लिए किया जाता है. ऐसे एट्रिब्यूट के उदाहरण के तौर पर, 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	स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट [] है इस खास टारगेट के लिए, डिस्ट्रिब्यूशन के तरीके की उन स्ट्रिंग की सूची जिनका इस्तेमाल किया जाना है. यह उस लाइसेंसिंग एपीआई का हिस्सा है जो अब सेवा में नहीं है. अब Basel का इस्तेमाल नहीं किया जाता है. इसका इस्तेमाल न करें.
exec_compatible_with	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट तौर पर [] इस टारगेट के लिए, रनिंग प्लैटफ़ॉर्म में मौजूद constraint_values की सूची. यह, नियम के टाइप से पहले से सेट की गई किसी भी पाबंदी के अलावा है. पाबंदियों का इस्तेमाल, प्रोसेस करने के लिए उपलब्ध प्लैटफ़ॉर्म की सूची को सीमित करने के लिए किया जाता है. ज़्यादा जानकारी के लिए, टूलचेन रिज़ॉल्यूशन के बारे में जानकारी देखें.
exec_properties	स्ट्रिंग की डिक्शनरी; डिफ़ॉल्ट तौर पर {} स्ट्रिंग की एक डिक्शनरी, जिसे इस टारगेट के लिए चुने गए प्लैटफ़ॉर्म के exec_properties में जोड़ा जाएगा. प्लैटफ़ॉर्म के नियम का exec_properties देखें. अगर कोई कुंजी, प्लैटफ़ॉर्म और टारगेट-लेवल, दोनों प्रॉपर्टी में मौजूद है, तो वैल्यू टारगेट से ली जाएगी.
features	सुविधा स्ट्रिंग की सूची; डिफ़ॉल्ट [] है सुविधा, स्ट्रिंग टैग होती है जिसे टारगेट पर चालू या बंद किया जा सकता है. किसी सुविधा का मतलब, उस नियम पर निर्भर करता है जिसे लागू किया जा रहा है. इस 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 कीवर्ड की वजह से, कार्रवाई या जांच को कभी भी कैश मेमोरी में सेव नहीं किया जाता (लोकल या रिमोट तौर पर). ध्यान दें: इस टैग के लिए, डिस्क कैश को लोकल कैश माना जाता है, जबकि एचटीटीपी और gRPC कैश को रिमोट कैश माना जाता है. Skyframe या लगातार चलने वाली कार्रवाई के कैश मेमोरी पर इसका कोई असर नहीं पड़ता. no-remote-cache कीवर्ड की वजह से, कार्रवाई या जांच को कभी भी रिमोट तौर पर कैश मेमोरी में सेव नहीं किया जाता. हालांकि, इसे लोकल तौर पर कैश मेमोरी में सेव किया जा सकता है. साथ ही, इसे रिमोट तौर पर भी चलाया जा सकता है. ध्यान दें: इस टैग के लिए, डिस्क की कैश मेमोरी को लोकल कैश मेमोरी माना जाता है. वहीं, एचटीटीपी और जीआरपीसी कैश मेमोरी को रिमोट माना जाता है. इससे, 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 कीवर्ड, सैंडबॉक्स में मौजूद बाहरी नेटवर्क का ऐक्सेस ब्लॉक करता है. इस मामले में, सिर्फ़ localhost के साथ कम्यूनिकेशन की अनुमति है. इस टैग का असर सिर्फ़ तब होता है, जब सैंडबॉक्सिंग की सुविधा चालू हो. requires-fakeroot, जांच या कार्रवाई को uid और gid 0 (यानी, रूट उपयोगकर्ता) के तौर पर चलाता है. यह सिर्फ़ Linux पर काम करता है. इस टैग को --sandbox_fake_username कमांड-लाइन विकल्प के बजाय प्राथमिकता दी जाती है. आम तौर पर, टेस्ट पर मौजूद टैग का इस्तेमाल, डीबग और रिलीज़ की प्रोसेस में टेस्ट की भूमिका के बारे में जानकारी देने के लिए किया जाता है. आम तौर पर, टैग C++ और Python के लिए सबसे ज़्यादा काम के होते हैं. ऐसा इसलिए है, क्योंकि इनमें रनटाइम एनोटेशन की सुविधा नहीं होती. टैग और साइज़ एलिमेंट का इस्तेमाल करने से, कोडबेस की जांच करने की नीति के आधार पर, टेस्ट के सुइट को आसानी से इकट्ठा किया जा सकता है. अगर बेज़ल, टेस्ट के नियम के 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 की सुविधा देने वाले नियमों के उदाहरण हैं या Baज़ल में पहले से मौजूद टूलचेन टाइप के लिए, खास टारगेट. इनमें शामिल हैं: @bazel_tools//tools/cpp:toolchain_type @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 के साथ लागू होने पर Basel को टारगेट को पास करना है. ये आर्ग्युमेंट, 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" है इससे टेस्ट टारगेट के "भारी होने" की जानकारी मिलती है: इसे चलाने के लिए कितना समय/संसाधन चाहिए. यूनिट टेस्ट को "छोटा", इंटिग्रेशन टेस्ट को "मीडियम", और एंड-टू-एंड टेस्ट को "बड़ा" या "बहुत बड़ा" माना जाता है. Basel, डिफ़ॉल्ट टाइम आउट को तय करने के लिए साइज़ का इस्तेमाल करता है. टाइम आउट को timeout एट्रिब्यूट का इस्तेमाल करके बदला जा सकता है. टाइम आउट, BUILD टारगेट में मौजूद सभी टेस्ट के लिए होता है, न कि हर अलग-अलग टेस्ट के लिए. जब स्थानीय तौर पर टेस्ट किया जाता है, तब 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" दिया गया है.

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

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

एट्रिब्यूट	ब्यौरा
args	स्ट्रिंग की सूची; $(location) और "Make variable" के बदले, और Bourne shell tokenization के हिसाब से तय होती है; इसे कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट [] है कमांड लाइन आर्ग्युमेंट, जिन्हें Baज़ल से टारगेट को पास किया जाएगा, जब उसे run कमांड से या टेस्ट के तौर पर एक्ज़ीक्यूट किया जाएगा. इन आर्ग्युमेंट को 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	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है उन आउटपुट फ़ाइलों के लाइसेंस जिन्हें यह बाइनरी जनरेट करती है. यह उस लाइसेंसिंग एपीआई का हिस्सा है जो अब सेवा में नहीं है. अब 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++ में, इंप्लिसिट आउटपुट का इस्तेमाल बंद कर दिया गया है. जहां भी हो सके, कृपया इसका इस्तेमाल दूसरी भाषाओं में न करें. फ़िलहाल, हमने इन सुविधाओं को बंद करने का कोई तरीका तय नहीं किया है. हालांकि, इन्हें भी बंद कर दिया जाएगा.

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

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

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

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