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

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

कॉन्टेंट

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

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

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

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

लेबल को बड़ा करें

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

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

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

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

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

List of labels ; optional

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

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

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

deps

List of labels ; optional

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

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

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

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

licenses

List of strings; optional; nonconfigurable

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

srcs

List of labels ; optional

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

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

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

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

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

List of labels ; optional; nonconfigurable

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

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

deprecation

String; optional; nonconfigurable

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

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

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

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

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

distribs

List of strings; optional; nonconfigurable

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

exec_compatible_with

List of labels ; optional; nonconfigurable

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

exec_properties

Dictionary of strings; optional

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

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

List of feature strings; optional

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

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

restricted_to

List of labels ; optional; nonconfigurable

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

यह Basel के कंस्ट्रेंट सिस्टम का हिस्सा है. यहां जाएं: compatible_with अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है देखें.

tags

List of strings; optional; nonconfigurable

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

List of labels ; optional

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

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

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

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

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

testonly

Boolean; optional; default False except for test and test suite targets; nonconfigurable

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

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

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

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

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

toolchains

List of labels ; optional; nonconfigurable

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

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

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

visibility

List of labels ; optional; default default_visibility from package if specified, or //visibility:private otherwise; nonconfigurable

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

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

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

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

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization

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

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

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

टेस्ट को एक्ज़ीक्यूट करने पर, इस नीति से अतिरिक्त एनवायरमेंट वैरिएबल सेट किए जाते हैं bazel test.

यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि cc_test, py_test और sh_test. यह इन पर लागू नहीं होता है Starlark के तय किए हुए टेस्ट नियम. Starlark के अपने नियमों के लिए, "env" जोड़ा जा सकता है विशेषता और इसका इस्तेमाल टेस्ट एनवायरमेंट सेवा देने वाली कंपनी.

env_inherit

List of strings; optional

इस नीति से इनहेरिट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल तय करता है बाहरी एनवायरमेंट, जब bazel test से जांच की जाती है.

यह एट्रिब्यूट सिर्फ़ cc_test, py_test, और sh_test. यह Starlark के तय किए टेस्ट नियमों पर लागू नहीं होता.

size

String "enormous", "large" "medium" or "small", default is "medium"; optional; nonconfigurable

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

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

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

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

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

String "short", "moderate", "long", "eternal" (with the default derived from the test's size attribute); nonconfigurable

लौटने से पहले जांच को कितने समय तक चलने की उम्मीद है.

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

टाइम आउट का मान समयावधि
छोटा 1 मिनट
मध्यम 5 मिनट
लंबा 15 मिनट
इटरनल 60 मिनट

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

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

Boolean; optional; default False; nonconfigurable

टेस्ट को फ़्लैकी के तौर पर मार्क करता है.

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

shard_count

Non-negative integer less than or equal to 50; optional

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

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

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

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

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

Boolean; default False; nonconfigurable

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

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

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

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

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

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization; nonconfigurable

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

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

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

टारगेट bazel run ने चलाया.

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

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

output_licenses

List of strings; optional

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

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

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

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

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

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

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

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