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

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

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

कॉन्टेंट

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

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

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

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

लेबल का दायरा बढ़ाना

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

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

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

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

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

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

रनटाइम के दौरान, इस नियम के लिए ज़रूरी फ़ाइलें. फ़ाइल या नियम के टारगेट की सूची बनाई जा सकती है. आम तौर पर, किसी भी टारगेट को अनुमति दी जाती है.

data एट्रिब्यूट में मौजूद टारगेट के डिफ़ॉल्ट आउटपुट और रनफ़ाइलें, किसी भी ऐसे एक्सीक्यूटेबल के *.runfiles सेक्शन में दिखनी चाहिए जो इस टारगेट से आउटपुट होती है या जिसकी रनटाइम डिपेंडेंसी इस टारगेट पर होती है. इसमें डेटा फ़ाइलें या बाइनरी शामिल हो सकती हैं. इनका इस्तेमाल तब किया जाता है, जब इस टारगेट के srcs को लागू किया जाता है. डेटा फ़ाइलों पर निर्भर रहने और उनका इस्तेमाल करने के तरीके के बारे में ज़्यादा जानकारी के लिए, डेटा डिपेंडेंसी सेक्शन देखें.

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

deps

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

इस टारगेट के लिए डिपेंडेंसी. आम तौर पर, सिर्फ़ नियम से जुड़े टारगेट की सूची बनानी चाहिए. (हालांकि, कुछ नियमों के तहत फ़ाइलों को सीधे deps में लिस्ट किया जा सकता है, लेकिन जहां तक हो सके, ऐसा नहीं करना चाहिए.)

आम तौर पर, भाषा के हिसाब से तय किए गए नियम, सूची में दिए गए टारगेट को, खास सेवा देने वाली कंपनियों तक सीमित रखते हैं.

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

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

licenses

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

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

srcs

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

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

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

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

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

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

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

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

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

deprecation

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

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

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

पैकेज के अंदर मौजूद डिपेंडेंसी पर यह चेतावनी लागू नहीं होती. उदाहरण के लिए, किसी पुराने नियम के टेस्ट बनाते समय, आपको चेतावनी नहीं मिलेगी.

अगर बंद किया गया कोई टारगेट, काम नहीं करने वाले किसी दूसरे टारगेट पर निर्भर करता है, तो चेतावनी वाला कोई मैसेज नहीं जारी किया जाता है.

जब लोग इसका इस्तेमाल करना बंद कर देंगे, तब टारगेट को हटाया जा सकता है.

distribs

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

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

exec_compatible_with

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

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

exec_properties

स्ट्रिंग की डिक्शनरी; डिफ़ॉल्ट {} है

स्ट्रिंग का एक डिक्शनरी जिसे इस टारगेट के लिए चुने गए प्लैटफ़ॉर्म के exec_properties में जोड़ा जाएगा. प्लैटफ़ॉर्म के नियम का exec_properties देखें.

अगर कोई कुंजी, प्लैटफ़ॉर्म और टारगेट-लेवल, दोनों प्रॉपर्टी में मौजूद है, तो वैल्यू टारगेट से ली जाएगी.
features

सुविधा स्ट्रिंग की सूची; डिफ़ॉल्ट [] है

सुविधा, स्ट्रिंग टैग है जिसे किसी टारगेट पर चालू या बंद किया जा सकता है. किसी सुविधा का मतलब, नियम के हिसाब से तय होता है.

इस features एट्रिब्यूट को पैकेज लेवल के features एट्रिब्यूट के साथ जोड़ा जाता है. उदाहरण के लिए, अगर पैकेज लेवल पर ["a", "b"] सुविधाएं चालू हैं और टारगेट के features एट्रिब्यूट में ["-a", "c"] हैं, तो नियम के लिए चालू की गई सुविधाएं "b" और "c" होंगी. उदाहरण देखें.

restricted_to

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

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

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

tags

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

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

अगर Bazel को किसी भी टेस्ट के tags एट्रिब्यूट या genrule टारगेट में ये कीवर्ड मिलते हैं, तो वह अपने सैंडबॉक्सिंग कोड के व्यवहार में बदलाव करता है. इसके अलावा, किसी भी 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 के लिए सबसे ज़्यादा काम के होते हैं. ऐसा इसलिए है, क्योंकि इनमें रनटाइम एनोटेशन की सुविधा नहीं होती. टैग और साइज़ एलिमेंट का इस्तेमाल करने से, कोडबेस की जांच करने की नीति के आधार पर, टेस्ट के सुइट को आसानी से इकट्ठा किया जा सकता है.

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

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

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

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

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

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

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

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

testonly

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

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

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

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

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

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

toolchains

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

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

  • @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 variable" के बदले, और Bourne shell tokenization के हिसाब से बदली जा सकती है; डिफ़ॉल्ट [] है

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

ये आर्ग्युमेंट, 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" है

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

यूनिट टेस्ट को "छोटा", इंटिग्रेशन टेस्ट को "मीडियम", और एंड-टू-एंड टेस्ट को "बड़ा" या "बहुत बड़ा" माना जाता है. Bazel, डिफ़ॉल्ट टाइम आउट तय करने के लिए साइज़ का इस्तेमाल करता है. इसे timeout एट्रिब्यूट का इस्तेमाल करके बदला जा सकता है. टाइम आउट, बिल्ड टारगेट में मौजूद सभी टेस्ट के लिए है, न कि हर टेस्ट के लिए. जब स्थानीय तौर पर टेस्ट किया जाता है, तब size का इस्तेमाल शेड्यूल करने के लिए भी किया जाता है: Basel, --local_{ram,cpu}_resources का पालन करने की कोशिश करता है. साथ ही, एक ही समय में बहुत सारे टेस्ट चलाकर, लोकल मशीन को प्रभावित नहीं करता है.

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

साइज़ रैम (एमबी में) सीपीयू (सीपीयू कोर में) डिफ़ॉल्ट टाइम आउट
छोटा 20 1 छोटा (1 मिनट)
मध्यम 100 1 सामान्य (5 मिनट)
बड़ा 300 1 लंबा (15 मिनट)
बहुत बड़ा 800 1 हमेशा के लिए (60 मिनट)

टेस्ट को शुरू करते समय, एनवायरमेंट वैरिएबल TEST_SIZE को इस एट्रिब्यूट की वैल्यू पर सेट किया जाएगा.
timeout

स्ट्रिंग "short", "moderate", "long" या "eternal"; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट वैल्यू, टेस्ट के size एट्रिब्यूट से ली जाती है

जांच पूरी होने में कितना समय लगेगा.

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

टाइम आउट की वैल्यू समयावधि
छोटा 1 मिनट
मध्यम 5 मिनट
लंबा 15 मिनट
अनंत 60 मिनट

ऊपर बताई गई स्थितियों के अलावा, अन्य समय पर, जांच के टाइम आउट को --test_timeout बेज़ल फ़्लैग से बदला जा सकता है. उदाहरण के लिए, मैन्युअल रूप से चलने वाली ऐसी स्थितियों के लिए जिन्हें धीमा माना जाता है. --test_timeout की वैल्यू सेकंड में दी गई हैं. उदाहरण के लिए, --test_timeout=120 टेस्ट टाइम आउट को दो मिनट पर सेट कर देगा.

टेस्ट को स्पैन करने पर, एनवायरमेंट वैरिएबल TEST_TIMEOUT को टेस्ट टाइम आउट (सेकंड में) पर सेट कर दिया जाएगा.
flaky

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

टेस्ट को 'अमान्य' के तौर पर मार्क करता है.

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

shard_count

50 से कम या उसके बराबर कोई पूर्णांक, जिसका मान नकारात्मक न हो; डिफ़ॉल्ट तौर पर -1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

env

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

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

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

ध्यान दें: 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 से जुड़ी किन शर्तों को पूरा करता है.

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

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

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

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

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

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

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

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

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