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

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

इस सेक्शन में ऐसे कई शब्दों और कॉन्सेप्ट की जानकारी दी गई है जो कई फ़ंक्शन या नियम बनाने में इस्तेमाल होते हैं.

विषय सूची

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

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

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

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

licenses

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

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

srcs

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

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

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

बिल्ड के सभी नियमों में आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट

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

एट्रिब्यूट कंपनी का ब्यौरा
compatible_with

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

इस टारगेट के साथ काम करने वाले एनवायरमेंट के साथ-साथ, एनवायरमेंट की सूची भी बनाई जा सकती है.

यह Baज़ल के कंस्ट्रेंट सिस्टम का हिस्सा है. इससे उपयोगकर्ता यह तय कर पाते हैं कि कौनसे टारगेट एक-दूसरे पर निर्भर हो सकते हैं और कौनसे नहीं. उदाहरण के लिए, संगठन के बाहर डिप्लॉय की जा सकने वाली बाइनरी फ़ाइलें, कंपनी के सीक्रेट कोड वाली लाइब्रेरी पर निर्भर नहीं होनी चाहिए. ज़्यादा जानकारी के लिए, 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

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

इस टारगेट के लिए बनाए गए एनवायरमेंट की सूची, डिफ़ॉल्ट तौर पर काम करने वाले एनवायरमेंट के बजाय बनाई जा सकती है.

यह Baze के कंस्ट्रेंट सिस्टम का हिस्सा है. ज़्यादा जानकारी के लिए, compatible_with पर जाएं.

tags

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

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

Baज़ल, अपने सैंडबॉक्सिंग कोड के काम करने के तरीके में बदलाव करता है. ऐसा तब होता है, जब उसे किसी भी टेस्ट या genrule टारगेट के tags एट्रिब्यूट में ये कीवर्ड या Starlark के किसी भी ऐक्शन के लिए execution_requirements की कुंजियां मिलती हैं.

  • no-sandbox कीवर्ड के नतीजे के तौर पर कार्रवाई या जांच को कभी सैंडबॉक्स नहीं किया जा सकता. इसे अब भी कैश मेमोरी में सेव किया जा सकता है या कहीं से भी चलाया जा सकता है - इनमें से किसी एक या दोनों को रोकने के लिए no-cache या no-remote का इस्तेमाल करें.
  • कार्रवाई या जांच करने पर, no-cache कीवर्ड के नतीजे कभी भी कैश मेमोरी में सेव नहीं किए जाते (कहीं से भी या स्थानीय तौर पर)
  • no-remote-cache कीवर्ड की जांच करने पर, कार्रवाई या जांच करने पर, उसे कभी भी कहीं से भी कैश मेमोरी में सेव नहीं किया जाता. हालांकि, इसे कहीं से भी कैश मेमोरी में सेव किया जा सकता है. ध्यान दें: इस टैग के लिए, डिस्क-कैश को लोकल कैश मेमोरी माना जाता है, जबकि एचटीटीपी और जीआरपीसी कैश मेमोरी को रिमोट माना जाता है. अगर लोकल डिस्क कैश और रिमोट कैश के कॉम्बिनेशन (कॉम्बिन्ड कैश) का इस्तेमाल किया जाता है, तो इसे रिमोट कैश माना जाता है और पूरी तरह से बंद किया जाता है. ऐसा तब तक होता है, जब तक --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 टेस्ट के लिए सबसे ज़्यादा काम के होते हैं, जिनमें रनटाइम एनोटेशन की सुविधा नहीं होती. टैग और साइज़ एलिमेंट का इस्तेमाल करने से, कोड बेस चेक-इन नीति के आधार पर, टेस्ट के सुइट को असेंबल किया जा सकता है.

अगर Baज़ल को जांच के नियम के tags एट्रिब्यूट में ये कीवर्ड मिलते हैं, तो वह टेस्ट के काम करने के तरीके में बदलाव करता है:

  • exclusive, टेस्ट को "खास" मोड में चलाने के लिए मजबूर करेगा, ताकि यह पक्का किया जा सके कि एक ही समय पर कोई और टेस्ट न चल रहा हो. बिल्ड की सभी गतिविधियों और सामान्य जांचों को पूरा करने के बाद, ऐसे टेस्ट सीरियल के तौर पर किए जाएंगे. इस तरह की जांचों के लिए, रिमोट तरीके से एक्ज़ीक्यूट करने की सुविधा बंद है, क्योंकि रिमोट मशीन पर चल रही चीज़ों पर बैज का कंट्रोल नहीं होता.
  • अगर टेस्ट को स्थानीय तौर पर लागू किया जाता है, तो exclusive-if-local उसे "खास" मोड में चलाने के लिए मजबूर करेगा. हालांकि, अगर टेस्ट को कहीं से भी लागू किया जाता है, तो यह टेस्ट साथ-साथ चलाएगा.
  • manual कीवर्ड, टारगेट पैटर्न वाइल्डकार्ड (..., :*, :all वगैरह) और test_suite नियमों को बढ़ाने से टारगेट को बाहर कर देगा. इन नियमों में build, test, और coverage निर्देशों के लिए बनाए/चलाने के लिए टॉप-लेवल टारगेट के सेट का पता लगाते समय, साफ़ तौर पर टेस्ट की सूची नहीं दी गई है. हालांकि, इससे query कमांड के साथ-साथ अन्य कॉन्टेक्स्ट में, टारगेट वाइल्डकार्ड या टेस्ट सुइट के एक्सपैंशन पर कोई असर नहीं पड़ता. ध्यान दें कि manual का मतलब यह नहीं है कि किसी टारगेट को लगातार बिल्ड/टेस्ट सिस्टम से अपने-आप बनाया या चलाया नहीं जाना चाहिए. उदाहरण के लिए, हो सकता है कि किसी टारगेट को bazel test ... से बाहर रखना ज़रूरी हो, क्योंकि इसके लिए खास बेज़ल फ़्लैग की ज़रूरत होती है. हालांकि, इसे फिर भी अच्छी तरह से कॉन्फ़िगर किए गए प्री-सबमिट या लगातार टेस्ट रन में शामिल किया जाना चाहिए.
  • external कीवर्ड की मदद से, टेस्ट को बिना किसी शर्त के लागू किया जाएगा (चाहे --cache_test_results वैल्यू कुछ भी हो).
टेस्ट एन्साइक्लोपीडिया में टैग कन्वेंशन देखें. इससे आपको टेस्ट टारगेट से जुड़े टैग के ज़्यादा कन्वेंशन दिखेंगे.
target_compatible_with

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

constraint_value की एक सूची, जो टारगेट प्लैटफ़ॉर्म में मौजूद होनी चाहिए, तभी इस टारगेट को काम करने वाला माना जाएगा. यह नियम टाइप की ओर से पहले से सेट की गई पाबंदियों के अलावा है. अगर टारगेट प्लैटफ़ॉर्म, दी गई सूची में शामिल सभी शर्तों को पूरा नहीं करता है, तो उसे माना जाएगा कि टारगेट incompatible. टारगेट पैटर्न को बड़ा करने पर, काम न करने वाले टारगेट को बनाने और टेस्ट करने के लिए स्किप कर दिया जाता है.उदाहरण के लिए, //..., :all. जब कमांड लाइन में साफ़ तौर पर बताया गया हो, तो काम न करने वाले टारगेट की वजह से Basel से गड़बड़ी प्रिंट होती है. इससे बिल्ड या टेस्ट फ़ेल हो जाता है.

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

एक खाली सूची (जो डिफ़ॉल्ट है) का मतलब है कि टारगेट सभी प्लैटफ़ॉर्म के साथ काम करता है.

Workspace के नियमों के अलावा, अन्य सभी नियम इस एट्रिब्यूट के साथ काम करते हैं. कुछ नियमों के लिए, इस एट्रिब्यूट का कोई असर नहीं होता. उदाहरण के लिए, cc_toolchain के लिए target_compatible_with की जानकारी देना मददगार नहीं है.

टारगेट स्किप करने की सुविधा के साथ काम न करने वाले लिंक के बारे में ज़्यादा जानने के लिए, प्लैटफ़ॉर्म पेज पर जाएं.

testonly

बूलियन; कॉन्फ़िगर नहीं किया जा सकता. जांच और टेस्ट सुइट के टारगेट को छोड़कर, डिफ़ॉल्ट तौर पर False है

अगर True, तो सिर्फ़ टेस्ट करने के लिए टारगेट (जैसे कि टेस्ट) इस टारगेट पर निर्भर हो सकते हैं.

बराबर है, ऐसे नियम जो testonly नहीं है उसे ऐसे किसी भी नियम पर निर्भर करने की अनुमति नहीं है जो testonly है.

डिफ़ॉल्ट रूप से, टेस्ट (*_test नियम) और टेस्ट सुइट (test_suite के नियम) testonly होते हैं.

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

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

toolchains

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

टारगेट का वह सेट जिसके वैरिएबल बनाएं को यह टारगेट ऐक्सेस कर सकता है. ये टारगेट या तो उन नियमों के उदाहरण हैं जो TemplateVariableInfo देते हैं या Basel में पहले से मौजूद टूलचेन टाइप के लिए खास टारगेट. इनमें शामिल हैं:

  • @bazel_tools//tools/cpp:current_cc_toolchain
  • @bazel_tools//tools/jdk:current_java_runtime

ध्यान रखें कि यह टूलचेन रिज़ॉल्यूशन के कॉन्सेप्ट से अलग है. इसका इस्तेमाल प्लैटफ़ॉर्म पर निर्भर कॉन्फ़िगरेशन के लिए, नियम लागू करने के दौरान किया जाता है. इस एट्रिब्यूट का इस्तेमाल करके, यह तय नहीं किया जा सकता कि टारगेट के लिए किस cc_toolchain या java_toolchain का इस्तेमाल किया जाएगा.

visibility

लेबल की सूची: इसे कॉन्फ़िगर नहीं किया जा सकता; अगर बताया गया है, तो डिफ़ॉल्ट रूप से पैकेज से default_visibility या "//visibility:private" है

टारगेट का visibility एट्रिब्यूट यह कंट्रोल करता है कि टारगेट का इस्तेमाल दूसरे पैकेज में किया जा सकता है या नहीं. किसको दिखे से जुड़े दस्तावेज़ देखें.

जांच के सभी नियमों के लिए आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट (*_test)

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

एट्रिब्यूट कंपनी का ब्यौरा
args

स्ट्रिंग की सूची, जो $(location) और "Makeवैरिएबल" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करती है. डिफ़ॉल्ट रूप से [] पर सेट होती है

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

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

env

स्ट्रिंग की डिक्शनरी; वैल्यू $(location) और "वैरिएबल बनाएं" के विकल्प पर निर्भर करती हैं. वैल्यू, डिफ़ॉल्ट तौर पर [] पर निर्भर करती है

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 एट्रिब्यूट का इस्तेमाल करके बदला जा सकता है. टाइम आउट, बिल्ड टारगेट में मौजूद सभी टेस्ट के लिए है, न कि हर टेस्ट के लिए. जब स्थानीय तौर पर टेस्ट किया जाता है, तो size का इस्तेमाल शेड्यूल करने के लिए भी किया जाता है: Baze, --local_{ram,cpu}_resources का पालन करने की कोशिश करता है. साथ ही, एक साथ कई बार टेस्ट करने से मशीन को नुकसान नहीं पहुंचाता है.

टेस्ट साइज़ यहां दिए गए डिफ़ॉल्ट टाइम आउट और सबसे ज़्यादा इस्तेमाल होने वाले लोकल रिसॉर्स के मुताबिक होते हैं:

साइज़ रैम (एमबी में) सीपीयू (सीपीयू कोर में) डिफ़ॉल्ट टाइम आउट
छोटा 20 1 छोटा (1 मिनट)
medium 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 होता है

यह बताता है कि टेस्ट करने के लिए, पैरलल शार्ड की संख्या कितनी है.

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

अगर टेस्ट शार्डिंग चालू है, तो टेस्ट को शुरू करते समय एनवायरमेंट वैरिएबल TEST_TOTAL_SHARDS को इस मान पर सेट कर दिया जाएगा.

शार्डिंग के लिए टेस्ट रनर को टेस्ट शार्डिंग प्रोटोकॉल का समर्थन करना ज़रूरी है. अगर ऐसा नहीं है, तो हो सकता है कि यह हर शार्ड में हर टेस्ट चलाएगा, जो आपकी पसंद नहीं है.

शार्डिंग के बारे में ज़्यादा जानकारी के लिए, टेस्ट एन्साइक्लोपीडिया में शर्डिंग की जांच करना देखें.
local

बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से False है

इससे टेस्ट को सैंडबॉक्स किए बिना, स्थानीय तौर पर चलाने के लिए मजबूर किया जाता है.

इसे 'सही है' पर सेट करना, "स्थानीय" को टैग (tags=["local"]) के तौर पर देने के बराबर है.

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

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

एट्रिब्यूट कंपनी का ब्यौरा
args

स्ट्रिंग की सूची; $(location) और "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन के तहत आने वाली स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर [] है

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

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

env

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

bazel run की मदद से टारगेट लागू करने पर, सेट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल तय करता है.

यह एट्रिब्यूट सिर्फ़ cc_binary, py_binary, और sh_binary जैसे नेटिव नियमों पर लागू होता है. यह Starlark के तय किए गए एक्ज़ीक्यूटेबल नियमों पर लागू नहीं होता है.

ध्यान दें: जब टारगेट को Baज़ल के बाहर से चलाया जाता है, तब एनवायरमेंट वैरिएबल सेट नहीं होते हैं (उदाहरण के लिए, 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 से जुड़ी किन शर्तों को पूरा करता है.

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

जिन एट्रिब्यूट ने अपने दस्तावेज़ में nonconfigurable के तौर पर मार्क किया है वे इस सुविधा का इस्तेमाल नहीं कर सकते. आम तौर पर, किसी एट्रिब्यूट को कॉन्फ़िगर नहीं किया जा सकता, क्योंकि select() को ठीक करने का तरीका तय करने से पहले, Baze को अपनी वैल्यू के बारे में जानकारी होनी चाहिए.

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

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

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

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

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

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

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