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

एक रात का किराया · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.7

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

सामग्री

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

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

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

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

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

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

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

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

ऐसे टारगेट जो ट्रांज़िटिव तरीके से, काम न करने वाले टारगेट पर निर्भर होते हैं उन्हें भी काम न करने वाला टारगेट माना जाता है. इन्हें बनाने और इनकी जाँच करने के लिए भी नहीं चुना जाता.

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

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

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

testonly

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

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

इसी तरह, testonly नहीं होने वाले नियम को testonly वाले किसी भी नियम पर निर्भर रहने की अनुमति नहीं है.

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

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

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

toolchains

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

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

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

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

visibility

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

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

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

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

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

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

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

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

env

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

यह 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) और "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 में तय किए गए, एक्ज़ीक्यूटेबल नियमों पर लागू नहीं होता.

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