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

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

सामग्री

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

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

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

"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 में लिस्ट करने की अनुमति है. हालांकि, जहां तक हो सके, ऐसा नहीं करना चाहिए.)

भाषा के हिसाब से बने नियमों के तहत, आम तौर पर लिस्ट किए गए टारगेट को उन टारगेट तक सीमित किया जाता है जिनमें खास providers शामिल होते हैं.

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

ज़्यादातर मामलों में, deps डिपेंडेंसी का इस्तेमाल इसलिए किया जाता है, ताकि एक मॉड्यूल, उसी प्रोग्रामिंग भाषा में लिखे गए और अलग से कंपाइल किए गए दूसरे मॉड्यूल में तय किए गए सिंबल का इस्तेमाल कर सके. कई मामलों में, अलग-अलग भाषाओं के बीच निर्भरता भी हो सकती है: उदाहरण के लिए, java_library टारगेट, cc_library टारगेट में मौजूद C++ कोड पर निर्भर हो सकता है. इसके लिए, cc_library टारगेट को deps एट्रिब्यूट में लिस्ट करना होगा. ज़्यादा जानकारी के लिए, डिपेंडेंसी की परिभाषा देखें.

licenses

स्ट्रिंग की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से ["none"] होता है

इस टारगेट के लिए इस्तेमाल की जाने वाली लाइसेंस-टाइप स्ट्रिंग की सूची. यह लाइसेंसिंग एपीआई का पुराना वर्शन है. Bazel अब इसका इस्तेमाल नहीं करता. इसका इस्तेमाल न करें.

srcs

लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है

इस नियम के तहत प्रोसेस की गई या शामिल की गई फ़ाइलें. आम तौर पर, फ़ाइलों को सीधे तौर पर सूची में शामिल करता है. हालांकि, डिफ़ॉल्ट आउटपुट शामिल करने के लिए, नियम के टारगेट (जैसे कि filegroup या genrule) को सूची में शामिल कर सकता है.

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

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

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

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

लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है

यह ऐसे लेबल की सूची है जो आसपेक्ट को दिखती है. खास तौर पर, इस नियम की रिवर्स डिपेंडेंसी से लागू होने वाले आसपेक्ट को दिखती है. हालांकि, यह इस नियम के खुद के लागू करने के तरीके को नहीं दिखती. किसी खास भाषा के लिए बने नियमों के सेट से जुड़े दस्तावेज़ देखें. इससे आपको यह जानकारी मिलेगी कि किसी पहलू के बारे में दिए गए सुझाव का क्या असर होगा.

किसी पहलू के बारे में जानकारी देने वाले हिंट को टैग के बेहतर विकल्प के तौर पर देखा जा सकता है: टैग सिर्फ़ बूलियन स्थिति के बारे में बताता है. इसका मतलब है कि टैग, tags सूची में मौजूद है या नहीं. वहीं, किसी पहलू के बारे में जानकारी देने वाले हिंट के providers में, स्ट्रक्चर्ड फ़ॉर्मैट में कोई भी जानकारी दी जा सकती है.

असल में, पहलू के बारे में जानकारी देने वाले हिंट का इस्तेमाल, भाषा के हिसाब से बनाए गए अलग-अलग नियमों के सेट के बीच इंटरऑपरेबिलिटी के लिए किया जाता है. उदाहरण के लिए, मान लें कि आपके पास एक 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 एट्रिब्यूट को package लेवल के 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_value की सूची. इस टारगेट को काम करने वाला माना जाए, इसके लिए टारगेट प्लैटफ़ॉर्म में ये मौजूद होने चाहिए. यह नियम के टाइप के हिसाब से पहले से सेट की गई किसी भी पाबंदी के अलावा है. अगर टारगेट प्लैटफ़ॉर्म, बताई गई सभी पाबंदियों को पूरा नहीं करता है, तो टारगेट को उपलब्ध नहीं है माना जाता है. टारगेट पैटर्न को बड़ा करने पर, साथ काम न करने वाले टारगेट को बनाने और उनकी जांच करने के लिए स्किप कर दिया जाता है.उदाहरण के लिए, //..., :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 एट्रिब्यूट से यह कंट्रोल किया जाता है कि टारगेट को अन्य जगहों के टारगेट पर निर्भर रहने की अनुमति है या नहीं. visibility के बारे में जानने के लिए, दस्तावेज़ देखें.

BUILD फ़ाइल में सीधे तौर पर या BUILD फ़ाइल से कॉल किए गए लेगसी मैक्रो में एलान किए गए टारगेट के लिए, डिफ़ॉल्ट वैल्यू पैकेज का 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) और "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" है

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

यूनिट टेस्ट को "छोटा", इंटिग्रेशन टेस्ट को "मीडियम", और एंड-टू-एंड टेस्ट को "बड़ा" या "बहुत बड़ा" माना जाता है. 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) और "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 का इस्तेमाल करके देखा जा सकता है. यह टारगेट नेमस्पेस है. हर फ़ाइल टारगेट, डिस्क पर मौजूद किसी एक फ़ाइल ("फ़ाइल सिस्टम नेमस्पेस") से जुड़ा होता है. वहीं, हर नियम टारगेट, डिस्क पर मौजूद शून्य, एक या उससे ज़्यादा फ़ाइलों से जुड़ा हो सकता है. डिस्क पर ऐसी फ़ाइलें हो सकती हैं जिनका कोई टारगेट नहीं है. उदाहरण के लिए, .o C++ कंपाइलेशन के दौरान बनाई गई ऑब्जेक्ट फ़ाइलों को BUILD फ़ाइलों या कमांड लाइन से रेफ़रंस नहीं किया जा सकता. इस तरह, बिल्ड टूल अपने काम करने के तरीके से जुड़ी कुछ जानकारी को छिपा सकता है. इस बारे में ज़्यादा जानकारी BUILD Concept Reference में दी गई है.