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

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

सामग्री

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

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

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

"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) की सूची दिखा सकता है.

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

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

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

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

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

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

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

deprecation

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

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

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

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

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

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

distribs

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

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

exec_compatible_with

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

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

exec_properties

स्ट्रिंग का शब्दकोश; डिफ़ॉल्ट वैल्यू {} है

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

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

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

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

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

restricted_to

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

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

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

tags

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

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

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

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

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

visibility

लेबल की सूची; nonconfigurable; डिफ़ॉल्ट वैल्यू default_visibility है. अगर package तय किया गया है, तो "//visibility:private" अन्यथा

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

सभी टेस्ट नियमों (*_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" एट्रिब्यूट जोड़ा जा सकता है. इसका इस्तेमाल, TestEnvironment प्रोवाइडर को पॉप्युलेट करने के लिए किया जा सकता है.

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

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

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

env

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

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 में से किस मानदंड को पूरा करता है.

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