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

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

सामग्री

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

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

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

"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 एट्रिब्यूट में बाद वाले टारगेट को लिस्ट करना होगा. ज़्यादा जानकारी के लिए, डिपेंडेंसी की परिभाषा देखें.

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

लेबल की सूची; nonconfigurable; डिफ़ॉल्ट रूप से पैकेज का 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 होता है. अगर यह वैल्यू तय की गई है, तो default_visibility का इस्तेमाल किया जाता है. अगर यह वैल्यू तय नहीं की गई है, तो ["//visibility:private"] का इस्तेमाल किया जाता है. एक या उससे ज़्यादा सिंबॉलिक मैक्रो में तय किए गए टारगेट के लिए, डिफ़ॉल्ट वैल्यू हमेशा सिर्फ़ ["//visibility:private"] होती है. इसका मतलब है कि इसका इस्तेमाल सिर्फ़ उस पैकेज में किया जा सकता है जिसमें मैक्रो का कोड होता है.

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

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

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

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

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

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

env

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

यह 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" होता है

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

यूनिट टेस्ट को "छोटा", इंटिग्रेशन टेस्ट को "मीडियम", और एंड-टू-एंड टेस्ट को "बड़ा" या "बहुत बड़ा" माना जाता है. 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) और "Make variable" के साथ-साथ Bourne shell tokenization के लिए उपलब्ध है; बदला नहीं जा सकता; डिफ़ॉल्ट वैल्यू [] है

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

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

env

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

यह टारगेट को 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 कॉन्सेप्ट रेफ़रंस पढ़ें.