इस सेक्शन में ऐसे कई शब्दों और सिद्धांतों के बारे में बताया गया है जो कई फ़ंक्शन या नियम बनाने होते हैं.
कॉन्टेंट
- बोर्न शेल टोकनाइज़ेशन
- लेबल को बड़ा करना
- ऐसे एट्रिब्यूट जिन्हें बनाने के ज़्यादातर नियमों में तय किया जाता है
- बिल्ड के सभी नियमों के लिए आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट
- टेस्ट के सभी नियमों के लिए सामान्य एट्रिब्यूट (*_test)
- बाइनरी के सभी नियमों के लिए सामान्य एट्रिब्यूट (*_बाइनरी)
- कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट
- इंप्लिसिट आउटपुट टारगेट
बॉर्न शेल टोकनाइज़ेशन
कुछ नियमों की कुछ स्ट्रिंग एट्रिब्यूट को एक से ज़्यादा में बांटा गया है बॉर्न शेल के टोकनाइज़ेशन नियमों के मुताबिक शब्द: बिना कोटेशन मार्क वाले स्पेस में अलग-अलग शब्दों और एक डबल-कोट वाले वर्णों और बैकस्लैश का इस्तेमाल टोकनाइज़ेशन.
ये एट्रिब्यूट, इस टोकनाइज़ेशन के दायरे में आते हैं इस दस्तावेज़ में दी गई परिभाषाओं में साफ़ तौर पर बताया गया हो.
  "बनाएं" के तहत आने वाले एट्रिब्यूट वैरिएबल एक्सपैंशन और बॉर्न शेल
  टोकनाइज़ेशन का इस्तेमाल आम तौर पर, आर्बिट्रेरी विकल्प को
  कंपाइलर और अन्य टूल. ऐसे एट्रिब्यूट के उदाहरण:
  cc_library.copts और java_library.javacopts.
  इन सभी विकल्पों का इस्तेमाल करने पर,
  कॉन्फ़िगरेशन के हिसाब से बनी सूची में बड़ा करने के लिए सिंगल स्ट्रिंग वैरिएबल
  विकल्प शब्दों का.
लेबल को बड़ा करें
  बहुत कम नियमों वाले कुछ स्ट्रिंग एट्रिब्यूट पर लेबल लगाया जा सकता है
  एक्सपैंशन: अगर उन स्ट्रिंग में
  सबस्ट्रिंग, जैसे कि //mypkg:target और वह लेबल
  जो मौजूदा नियम की पूर्वापेक्षा है, तो उसे
  उस फ़ाइल का पाथनेम जिसे
  टारगेट
  //mypkg:target.
  एट्रिब्यूट के उदाहरण में genrule.cmd और
  cc_binary.linkopts.  इनमें विवरण काफ़ी अलग-अलग हो सकते हैं
  प्रत्येक मामले में, इन समस्याओं पर: क्या सापेक्ष लेबल
  बड़ा किया गया; एक से ज़्यादा फ़ाइलों में दिखने वाले लेबल कैसे होते हैं
  ट्रीट वगैरह.  के लिए नियम के एट्रिब्यूट का दस्तावेज़ देखें
  खास जानकारी.
ज़्यादातर बिल्ड नियमों में तय किए जाने वाले सामान्य एट्रिब्यूट
इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जिन्हें बिल्ड के कई नियमों के तहत तय किया जाता है. सभी नहीं.
| एट्रिब्यूट | ब्यौरा | 
|---|---|
| data | 
 रनटाइम के दौरान इस नियम के मुताबिक ज़रूरी फ़ाइलें. फ़ाइल या नियम के टारगेट की सूची बना सकता है. सामान्य रूप से किसी भी टारगेट को अनुमति देता है. 
 
नए नियमों में  | 
| deps | 
 
इस टारगेट पर निर्भरता. आम तौर पर, सिर्फ़ नियम से जुड़े टारगेट की सूची बनानी चाहिए. (हालांकि,
कुछ नियम फ़ाइलों को सीधे  आम तौर पर, भाषा के हिसाब से बने नियम, सूची में दिए गए टारगेट को उन लोगों तक सीमित कर देते हैं जिनके पास खास providers के लिए. 
इसका मतलब है कि टारगेट के लिए दूसरे वाक्य का इस्तेमाल करने पर निर्भर रहने का मतलब क्या होता है
 
अक्सर, किसी एक मॉड्यूल को इस्तेमाल करने की अनुमति देने के लिए,  | 
| licenses | 
 इस टारगेट के लिए इस्तेमाल की जाने वाली लाइसेंस-टाइप स्ट्रिंग की सूची. यह उस लाइसेंसिंग एपीआई का हिस्सा है जो अब सेवा में नहीं है. अब Basel का इस्तेमाल नहीं किया जाता है. ये काम न करें इसका इस्तेमाल करें. | 
| srcs | 
 
इस नियम के तहत प्रोसेस की गई या शामिल की गई फ़ाइलें. आम तौर पर, इसमें फ़ाइलों को सीधे तौर पर शामिल किया जाता है, लेकिन
नियम से जुड़े टारगेट (जैसे कि  भाषा के हिसाब से बनाए गए नियमों के मुताबिक, सूची में मौजूद फ़ाइलों में अक्सर फ़ाइल एक्सटेंशन. | 
बिल्ड के सभी नियमों में आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट
इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जिन्हें सभी बिल्ड में सीधे तौर पर जोड़ा गया है नियम.
| एट्रिब्यूट | ब्यौरा | 
|---|---|
| compatible_with | 
 उन एनवायरमेंट की सूची जिनके लिए यह टारगेट बनाया जा सकता है. इसके अलावा, डिफ़ॉल्ट रूप से काम करने वाले एनवायरमेंट. यह Basel के कंस्ट्रेंट सिस्टम का हिस्सा है. इसकी मदद से, लोग यह एलान कर सकते हैं कि किस टारगेट एक-दूसरे पर निर्भर हो सकते हैं या नहीं. उदाहरण के लिए, संगठन से बाहर डिप्लॉय किए जा सकने वाले प्रॉडक्ट बाइनरी, कंपनी के सीक्रेट कोड वाली लाइब्रेरी पर निर्भर नहीं होनी चाहिए. यहां जाएं: ConstraintSemantics का इस्तेमाल करें. | 
| deprecation | 
 इस टारगेट से जुड़ा चेतावनी वाला मैसेज. आम तौर पर, इसका इस्तेमाल उपयोगकर्ताओं को यह सूचना देने के लिए किया जाता है कि टारगेट पुराना हो गया है. या किसी दूसरे नियम के तहत आ गया हो, किसी पैकेज के लिए निजी हो या किसी वजह से नुकसान पहुंचाने वाला कॉन्टेंट हो सकता है. अपने समाचार संगठन के लिए, कुछ रेफ़रंस (जैसे कि वेबपेज, गड़बड़ी की संख्या या माइग्रेशन सीएलएस का उदाहरण) ताकि यह आसानी से पता लगाया जा सके कि इस मैसेज से बचने के लिए कौनसे बदलाव करने हैं. अगर किसी नए टारगेट का इस्तेमाल आइटम की जगह कम करने के लिए किया जा सकता है, तो यह पुराने टारगेट के सभी उपयोगकर्ताओं को माइग्रेट कर देना चाहिए. 
इस एट्रिब्यूट का, चीज़ों को बनाने के तरीके पर कोई असर नहीं पड़ता. हालांकि, यह
बिल्ड टूल के डाइग्नोस्टिक्स आउटपुट पर असर पड़ सकता है.  बिल्ड टूल समस्या का हल
जब  इंट्रा-पैकेज डिपेंडेंसी को इस चेतावनी से छूट दी जाती है, ताकि, उदाहरण के लिए, अमान्य नियम की जांच करने से कोई चेतावनी पाएं. अगर बंद किया गया कोई टारगेट, काम नहीं करने वाले किसी दूसरे टारगेट पर निर्भर करता है, तो कोई चेतावनी नहीं होगी मैसेज जारी किया गया. जब लोग इसका इस्तेमाल करना बंद कर देंगे, तब टारगेट को हटाया जा सकता है. | 
| distribs | 
 इस खास टारगेट के लिए इस्तेमाल की जाने वाली डिस्ट्रिब्यूशन-तरीका स्ट्रिंग की सूची. यह उस लाइसेंसिंग एपीआई का हिस्सा है जो अब सेवा में नहीं है. अब Basel का इस्तेमाल नहीं किया जाता है. ये काम न करें इसका इस्तेमाल करें. | 
| exec_compatible_with | 
 
इसकी सूची
 | 
| exec_properties | 
  स्ट्रिंग का एक डिक्शनरी जिसे इस टारगेट के लिए चुने गए प्लैटफ़ॉर्म के  अगर प्लैटफ़ॉर्म और टारगेट-लेवल प्रॉपर्टी, दोनों में कुंजी मौजूद है, तो वैल्यू को टारगेट से लिया जाएगा. | 
| features | 
 सुविधा, स्ट्रिंग टैग है जिसे किसी टारगेट पर चालू या बंद किया जा सकता है. कॉन्टेंट बनाने सुविधा का मतलब नियम पर निर्भर करता है. इस  | 
| restricted_to | 
 उन एनवायरमेंट की सूची जिनके लिए यह टारगेट बनाया जा सकता है, इसके बजाय डिफ़ॉल्ट रूप से काम करने वाले एनवायरमेंट. 
यह Basel के कंस्ट्रेंट सिस्टम का हिस्सा है. यहां जाएं:
 | 
| tags | 
   
  टैग का इस्तेमाल किसी भी नियम पर किया जा सकता है. टेस्ट और टेस्ट पर टैग
   
  अगर Basel को ये चीज़ें मिलती हैं, तब वह अपने सैंडबॉक्सिंग कोड के काम करने के तरीके में बदलाव करता है
  किसी भी टेस्ट या  
 टेस्ट पर टैग का इस्तेमाल आम तौर पर, आपके टेस्ट की भूमिका के बारे में बताने के लिए किया जाता है डीबग और रिलीज़ करने की प्रोसेस. आम तौर पर, C++ और Python के लिए टैग सबसे ज़्यादा काम के होते हैं जिनमें रनटाइम एनोटेशन की सुविधा नहीं होती है. टैग और साइज़ का इस्तेमाल करना एलिमेंट, कोड बेस के आधार पर टेस्ट के सुइट को असेंबल करने की सुविधा देते हैं चेक-इन से जुड़ी नीति. 
  अगर Baज़ल को, टेस्ट रनिंग के काम करने के तरीके में बदलाव किया जाता है, तो
  जांच के नियम की  
 | 
| target_compatible_with | 
 
इसकी सूची
 काम न करने वाले टारगेट पर अस्थायी रूप से निर्भर टारगेट वे खुद होते हैं असंगत माना जाता है. इन्हें बनाने और टेस्ट करने के लिए भी छोड़ दिया जाता है. खाली सूची (जो डिफ़ॉल्ट है) का मतलब है कि टारगेट इस्तेमाल किया जा सकता है. 
 
Workspace के नियमों के अलावा, अन्य सभी नियम इस पर काम करते हैं
एट्रिब्यूट की वैल्यू सबमिट करें.
कुछ नियमों के लिए, इस एट्रिब्यूट का कोई असर नहीं होता. उदाहरण के लिए,
 
 ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म इस पेज पर जाएं. | 
| testonly | 
 अगर सही है, तो सिर्फ़ टेस्ट करने के लिए टारगेट किए गए टारगेट (जैसे कि टेस्ट) ही इस टारगेट पर निर्भर हो सकते हैं. 
इसी तरह, ऐसे नियम की अनुमति नहीं है जो  
टेस्ट ( इस एट्रिब्यूट का मतलब यह है कि टारगेट प्रोडक्शन के लिए रिलीज़ की जाने वाली बाइनरी में शामिल हैं. सिर्फ़ टेस्ट करने की सुविधा, बिल्ड टाइम पर लागू होती है, न कि रन टाइम पर. इसके बाद, यह अपने-आप लागू होती है डिपेंडेंसी ट्री के ज़रिए वायरल होने पर, इसे सोच-समझकर लागू किया जाना चाहिए. इसके लिए उदाहरण के लिए, स्टब और नकली यूनिट टेस्ट के लिए काम के हो सकते हैं. इंटिग्रेशन टेस्ट के लिए भी मददगार साबित हो सकते हैं इसमें वही बाइनरी शामिल हैं जिन्हें प्रोडक्शन में रिलीज़ किया जाएगा और इसलिए, उसे सिर्फ़ टेस्ट करने के लिए मार्क नहीं किया जाना चाहिए. इसके उलट, ऐसे नियम में लिंक करना भी खतरनाक हो सकता है, क्योंकि सामान्य व्यवहार को ओवरराइड करते हैं, तो उसे निश्चित रूप से केवल परीक्षणकर्ता के रूप में चिह्नित किया जाना चाहिए. | 
| toolchains | 
 
  टारगेट का वह सेट जिसके वैरिएबल बनाएं यह टारगेट है
  को ऐक्सेस करने की अनुमति है. ये टारगेट या तो ऐसे नियमों के उदाहरण हैं जो
  Basel में पहले से मौजूद टूलचेन टाइप के लिए,  
 
  ध्यान दें कि यह
    टूलचेन रिज़ॉल्यूशन
    जिसका इस्तेमाल प्लैटफ़ॉर्म-निर्भर कॉन्फ़िगरेशन के लिए नियम लागू करने में किया जाता है. इसका इस्तेमाल नहीं किया जा सकता
  एट्रिब्यूट की मदद से यह पता लगाएं कि कौनसा  | 
| visibility | 
 
टारगेट की  | 
जांच के सभी नियमों के लिए आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट (*_test)
इस सेक्शन में, ऐसे एट्रिब्यूट के बारे में बताया गया है जो जांच के सभी नियमों में एक जैसे होते हैं.
| एट्रिब्यूट | ब्यौरा | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| args | 
 कमांड लाइन के तर्क जो बेज़ल टारगेट को तब पास करता है, जब वह
 
ये आर्ग्युमेंट किसी  | ||||||||||||||||||||
| env | 
   
  टेस्ट को एक्ज़ीक्यूट करने पर, इस नीति से अतिरिक्त एनवायरमेंट वैरिएबल सेट किए जाते हैं
   
  यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि  | ||||||||||||||||||||
| env_inherit | 
 इस नीति से इनहेरिट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल तय करता है
  बाहरी एनवायरमेंट, जब  
  यह एट्रिब्यूट सिर्फ़  | ||||||||||||||||||||
| size | 
 यह बताता है कि टेस्ट टारगेट की "बहुत ज़्यादा वैल्यू" है या नहीं: इसे चलाने में कितना समय/संसाधन लगेगा. यूनिट टेस्ट को "छोटे", इंटिग्रेशन टेस्ट को "मीडियम", और शुरू से लेकर आखिर तक की जांच को "बड़ा" माना जाता है या
"विशाल". Baज़र, साइज़ का इस्तेमाल करके डिफ़ॉल्ट टाइम आउट तय करता है. टाइम आउट को
 टेस्ट साइज़ इन डिफ़ॉल्ट टाइम आउट और माने गए सबसे ज़्यादा लोकल संसाधन के मुताबिक होते हैं इस्तेमाल: 
 एनवायरमेंट वैरिएबल  | ||||||||||||||||||||
| timeout | 
 लौटने से पहले जांच को कितने समय तक चलने की उम्मीद है. 
हालांकि, टेस्ट का साइज़ एट्रिब्यूट, रिसॉर्स के अनुमान को कंट्रोल करता है, लेकिन टेस्ट का
टाइम आउट को अलग से सेट किया जा सकता है.  अगर साफ़ तौर पर इसके बारे में नहीं बताया गया है, तो
टाइम आउट टेस्ट के साइज़ पर आधारित होता है. जांच
टाइम आउट को  
 
ऊपर दिए गए समय के अलावा, किसी अन्य समय पर, जांच के टाइम आउट को
 टेस्ट को शुरू करने पर, एनवायरमेंट वैरिएबल  | ||||||||||||||||||||
| flaky | 
 टेस्ट को फ़्लैकी के तौर पर मार्क करता है. अगर यह नीति सेट की जाती है, तो यह टेस्ट को ज़्यादा से ज़्यादा तीन बार लागू करता है. साथ ही, इसे सिर्फ़ 'फ़ेल' के तौर पर मार्क करता है में गड़बड़ी होती है. डिफ़ॉल्ट रूप से, यह एट्रिब्यूट 'गलत है' पर सेट होता है और टेस्ट सिर्फ़ एक बार चलाया जाता है. ध्यान दें, आम तौर पर इस एट्रिब्यूट का इस्तेमाल करने की सलाह नहीं दी जाती है - जांच में भरोसे के साथ पास होना चाहिए, जबकि उनके दावे सही साबित हों. | ||||||||||||||||||||
| shard_count | 
 पैरलल शार्ड की संख्या बताता है का इस्तेमाल टेस्ट करने के लिए किया जा सकता है. यह मान ऐसे किसी भी अनुभव को ओवरराइड कर देगा, जिसका उपयोग
समानांतर शार्ड, जिससे परीक्षण करना है. ध्यान दें कि कुछ टेस्ट के लिए
नियम हैं, तो शार्डिंग को चालू करने के लिए इस पैरामीटर की ज़रूरत पड़ सकती है
पहले स्थान पर हैं.  अगर टेस्ट शार्डिंग चालू है, तो टेस्ट को शुरू करते समय एनवायरमेंट वैरिएबल  शार्डिंग के लिए टेस्ट रनर को टेस्ट शार्डिंग प्रोटोकॉल का समर्थन करना ज़रूरी है. अगर ऐसा नहीं होता है, तो हो सकता है कि यह हर शार्ड पर हर टेस्ट चलाए, जिसमें वह नहीं है जो आप चाहते हैं. यहां जाएं: शर्डिंग की जांच करना में जाकर, शार्डिंग के बारे में ज़्यादा जानकारी हासिल की है. | ||||||||||||||||||||
| local | 
 इससे टेस्ट को सैंडबॉक्स किए बिना, स्थानीय तौर पर चलाने के लिए मजबूर किया जाता है. इसे 'सही है' पर सेट करना, "स्थानीय" देने के बराबर है टैग के तौर पर
( | 
सभी बाइनरी नियमों के लिए सामान्य एट्रिब्यूट (*_बाइनरी)
इस सेक्शन में, ऐसे एट्रिब्यूट के बारे में बताया गया है जो सभी बाइनरी नियमों में आम हैं.
| एट्रिब्यूट | ब्यौरा | 
|---|---|
| args | 
 
कमांड लाइन के आर्ग्युमेंट, जिन्हें एक्ज़ीक्यूट करने पर Basel को टारगेट को पास करना है
 
ध्यान दें: टारगेट को रन करने पर, आर्ग्युमेंट पास नहीं होते
का इस्तेमाल करें (उदाहरण के लिए, मैन्युअल तरीके से बाइनरी को
 | 
| env | 
 टारगेट
   
  यह एट्रिब्यूट सिर्फ़  
ध्यान दें: टारगेट को रन करने पर, एनवायरमेंट वैरिएबल सेट नहीं होते हैं
का इस्तेमाल करें (उदाहरण के लिए, मैन्युअल तरीके से बाइनरी को
 | 
| 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().
देखें कॉन्फ़िगर करने लायक बिल्ड एट्रिब्यूट की मदद से ज़्यादा जानकारी पाएं.
इंप्लिसिट आउटपुट टारगेट
C++ में इंप्लिसिट आउटपुट का अब इस्तेमाल नहीं किया जा सकता. कृपया इसका इस्तेमाल करने से बचें अन्य भाषाओं में जवाब दें. फ़िलहाल, हमारे पास किसी भी ऐसी सेवा के इस्तेमाल पर रोक लगाने का तरीका नहीं है हालांकि, इन्हें भी बंद कर दिया जाएगा.
जब आप किसी BUILD फ़ाइल में बिल्ड नियम तय करते हैं, तो आपको साफ़ तौर पर
  पैकेज में नए नाम वाले नियम टारगेट का एलान करना.  कई बिल्ड नियम
  फ़ंक्शन अस्पष्ट रूप से एक या ज़्यादा आउटपुट फ़ाइल को भी शामिल करते हैं
  लक्ष्य, जिनकी सामग्री और अर्थ नियम-विशिष्ट हों.
  उदाहरण के लिए, जब आप स्पष्ट रूप से
  java_binary(name='foo', ...) नियम, आप भी
  इंप्लिसिट तरीके से आउटपुट फ़ाइल का एलान करना
  foo_deploy.jar को उसी पैकेज के सदस्य के तौर पर टारगेट करें.
  (यह विशेष लक्ष्य अपने आप में मौजूद Java संग्रह है
  डिप्लॉयमेंट के लिए उपलब्ध है.)
  इंप्लिसिट आउटपुट टारगेट, दुनिया भर के बेहतरीन सदस्य हैं
  टारगेट ग्राफ़.  अन्य टारगेट की तरह, इन्हें भी मांग पर बनाया जाता है,
  या तो ऐसा जब टॉप लेवल कमांड में बताया गया हो या जब वे
  अन्य बिल्ड टारगेट के लिए ज़रूरी शर्तें हैं.  ये काम किए जा सकते हैं
  इन्हें BUILD फ़ाइलों में डिपेंडेंसी के तौर पर इस्तेमाल किया जाता है और इन्हें यहां देखा जा सकता है
  हम bazel query जैसे विश्लेषण टूल का आउटपुट देते हैं.
हर तरह के बिल्ड नियम के लिए, नियम के दस्तावेज़ में किसी भी इंप्लिसिट टूल के नाम और कॉन्टेंट के बारे में खास जानकारी देने वाला सेक्शन आउटपुट के तौर पर मिलते हैं.
  दोनों के बीच एक अहम, लेकिन थोड़ा मामूली अंतर
  बिल्ड सिस्टम में इस्तेमाल किए गए दो नेमस्पेस:
  लेबल, टारगेट की पहचान करते हैं,
  ये नियम या फ़ाइलें हो सकती हैं. साथ ही, फ़ाइल के टारगेट को
  सोर्स (या इनपुट) फ़ाइल टारगेट और डिराइव्ड (या आउटपुट) फ़ाइल
  टारगेट के लिए.  BUILD फ़ाइलों में आप इन चीज़ों का ज़िक्र कर सकते हैं,
  कमांड-लाइन से बनाया जा सकता है या bazel query का इस्तेमाल करके जांच करें;
  यह टारगेट नेमस्पेस है.  हर फ़ाइल टारगेट के बारे में जानकारी
  डिस्क पर एक वास्तविक फ़ाइल ("फ़ाइल सिस्टम नेमस्पेस") तक; हर नियम
  टारगेट, डिस्क पर एक या उससे ज़्यादा असल फ़ाइलों के बराबर हो सकता है.
  डिस्क पर ऐसी फ़ाइलें हो सकती हैं जिनके लिए कोई टारगेट सेट न हो; इसके लिए
  उदाहरण के लिए, C++ कंपाइलेशन के दौरान बनी .o ऑब्जेक्ट फ़ाइलें
  BUILD फ़ाइलों में या कमांड लाइन से संदर्भ नहीं दिया जा सकता.
  इस तरह से, बिल्ड टूल
  काम करती है या नहीं. यह पूरी जानकारी
  बिल्ड कॉन्सेप्ट का रेफ़रंस.