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

किसी समस्या की रिपोर्ट करें सोर्स देखें नाइटली · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

कॉन्टेंट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

deps

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

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

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

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

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

licenses

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

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

srcs

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

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

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

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

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

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

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

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

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

deprecation

String; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से 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

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

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

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

tags

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

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

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

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

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

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

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

ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म इस पेज पर जाएं.

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 के साथ चलाया गया.

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

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

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

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

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

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

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

यहां जाएं: शर्डिंग की जांच करना में जाकर, शार्डिंग के बारे में ज़्यादा जानकारी हासिल की है.
local

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

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

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

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

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

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

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

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

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

env

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

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

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

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

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

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

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

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

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

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

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

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

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