लेबल, टारगेट के लिए आइडेंटिफ़ायर होता है. अपने पूरे कैननिकल वर्शन में कोई सामान्य लेबल फ़ॉर्म ऐसा दिखता है:
@@myrepo//my/app/main:app_binary
लेबल का पहला हिस्सा, डेटा स्टोर करने की जगह का नाम होता है, @@myrepo. डबल-@
सिंटैक्स बताता है कि यह कैननिकल रेपो है
नाम दिया गया है, जो
फ़ाइल फ़ोल्डर है. कैननिकल रेपो नाम वाले लेबल, साफ़ तौर पर टारगेट की पहचान करते हैं
इससे कोई फ़र्क़ नहीं पड़ता कि वे किस बारे में हैं.
अक्सर कैननिकल रेपो नाम, आर्केन स्ट्रिंग होता है, जो
@@rules_java++toolchains+local_jdk. आम तौर पर, यह देखा जाता है कि
पैरंट रेपो नाम वाले लेबल,
जो ऐसा दिखता है:
@myrepo//my/app/main:app_binary
सिर्फ़ अंतर यह है कि रेपो के नाम से पहले, दो के बजाय एक @ जोड़ा जा रहा है.
यह आपको myrepo नाम के रेपो के बारे में बताता है, जो कि अलग हो सकता है
उस संदर्भ के हिसाब से जिसमें यह लेबल दिखता है.
सामान्य मामले में कोई लेबल, उसी रिपॉज़िटरी (डेटा स्टोर करने की जगह) का रेफ़रंस देता है जिससे
इसका इस्तेमाल किया जाता है, तो रेपो नाम वाला हिस्सा हटाया जा सकता है. इसलिए, @@myrepo में पहले
लेबल आम तौर पर इस रूप में लिखा जाता है
//my/app/main:app_binary
लेबल का दूसरा हिस्सा, 'ज़रूरी शर्तें पूरी नहीं करने वाले पैकेज का नाम' है
my/app/main, पैकेज का पाथ
रिपॉज़िटरी रूट के मुताबिक होना चाहिए. साथ मिलकर, रिपॉज़िटरी का नाम और
शर्तें पूरी न करने वाले पैकेज का नाम, पूरी तरह क्वालिफ़ाइड पैकेज का नाम बनाता है
@@myrepo//my/app/main. जब कोई लेबल इसी के बारे में बताता हो
वह पैकेज जिसमें इसका इस्तेमाल किया गया है, पैकेज का नाम (और वैकल्पिक रूप से, कोलन)
छोड़ा जा सकता है. इसलिए, @@myrepo//my/app/main में,
इस लेबल को निम्न में से किसी एक तरीके से लिखा जा सकता है:
app_binary
:app_binary
आम बात यह है कि फ़ाइलों के लिए कोलन का इस्तेमाल नहीं किया जाता, लेकिन नियमों के लिए सेव रखा जाएगा, लेकिन वह ज़रूरी नहीं है.
कोलन के बाद लेबल का हिस्सा, app_binary अयोग्य टारगेट है
नाम. जब यह पैकेज पाथ के आखिरी कॉम्पोनेंट से मैच करता है, तो यह और
कोलन, हटाया जा सकता है. इसलिए, ये दो लेबल एक जैसे हैं:
//my/app/lib
//my/app/lib:lib
पैकेज की सबडायरेक्ट्री में फ़ाइल टारगेट का नाम, फ़ाइल का पाथ होता है
पैकेज रूट (BUILD फ़ाइल वाली डायरेक्ट्री) से मिलता-जुलता है. इसलिए,
यह फ़ाइल, रिपॉज़िटरी की my/app/main/testdata सबडायरेक्ट्री में है:
//my/app/main:testdata/input.txt
//my/app और @@some_repo//my/app जैसी स्ट्रिंग के दो मतलब होते हैं:
जिस संदर्भ में उनका इस्तेमाल किया जाता है: जब बज़ल किसी लेबल की उम्मीद करता है, तो उसका मतलब होता है
//my/app:app और @@some_repo//my/app:app. हालांकि, जब बेज़ल
पैकेज की उम्मीद है (जैसे कि package_group स्पेसिफ़िकेशन में), तो वे रेफ़रंस के तौर पर
वह लेबल शामिल है.
BUILD फ़ाइलों में एक आम गलती यह है कि किसी पैकेज को देखने के लिए //my/app का इस्तेमाल किया जा रहा है या
एक पैकेज के सभी टारगेट पर लागू होते हैं--ऐसा नहीं होता. याद रखें, यह
//my/app:app के बराबर है, इसलिए यह my/app में app टारगेट को नाम देता है
मौजूदा डेटा स्टोर करने की जगह का पैकेज.
हालांकि, किसी पैकेज को रेफ़र करने के लिए, //my/app का इस्तेमाल करने की सलाह दी जाती है
या .bzl फ़ाइलों में, package_group की जानकारी दी गई है. ऐसा इसलिए, क्योंकि यह साफ़ तौर पर बताया गया है
बताता है कि पैकेज का नाम ऐब्सलूट है और टॉप-लेवल में रूट है
फ़ाइल फ़ोल्डर की डायरेक्ट्री.
रिलेटिव लेबल का इस्तेमाल, अन्य पैकेज में टारगेट की जानकारी देने के लिए नहीं किया जा सकता; यह
इस मामले में, रिपॉज़िटरी आइडेंटिफ़ायर और पैकेज का नाम हमेशा बताना ज़रूरी है.
उदाहरण के लिए, अगर सोर्स ट्री में पैकेज my/app और
पैकेज my/app/testdata (इन दोनों डायरेक्ट्री में से हर डायरेक्ट्री की अपनी है
BUILD फ़ाइल है), बाद वाले पैकेज में testdepot.zip नाम की फ़ाइल होती है. यहां
के भीतर इस फ़ाइल को संदर्भ देने के लिए दो तरीके हैं (एक गलत, एक सही)
//my/app:BUILD:
गलत — testdata एक अलग पैकेज है, इसलिए मिलते-जुलते पाथ का इस्तेमाल नहीं किया जा सकता
testdata/testdepot.zip
सही — testdata को उसके पूरे पाथ के साथ देखें
//my/app/testdata:testdepot.zip
@@// से शुरू होने वाले लेबल
जो अब भी रिपॉज़िटरी (डेटा स्टोर करने की जगह) से भी काम करेगा.
इसलिए, @@//a/b/c
किसी बाहरी डेटा स्टोर करने की जगह से रेफ़र किए जाने पर, //a/b/c.
पुरानी प्रॉपर्टी, डेटा स्टोर करने की मुख्य जगह का रेफ़रंस देती है, जबकि बाद वाला डेटा, मुख्य डेटा स्टोर करने की जगह का होता है
बाहरी डेटा स्टोर करने की जगह में //a/b/c ढूंढता है.
यह खास तौर पर तब ज़रूरी होता है, जब
डेटा स्टोर करने की जगह जो मुख्य डेटा स्टोर करने की जगह में मौजूद टारगेट से जुड़ी होती है.
डेटा स्टोर करने की बाहरी जगहों से इस्तेमाल किया जाता है.
टारगेट को रेफ़र करने के अलग-अलग तरीकों के बारे में जानने के लिए, यह देखें टारगेट पैटर्न.
लेबल के बारे में लेक्सिकल जानकारी
लेबल सिंटैक्स उन मेटावर्णों के इस्तेमाल से बचने की कोशिश करता है जिनका खास मतलब होता है शेल. इससे अनजाने में होने वाली कोटेशन की समस्याओं से बचने में मदद मिलती है. साथ ही, लेबल में बदलाव करने वाले टूल और स्क्रिप्ट बना सकता है, जैसे कि Bazu क्वेरी की भाषा.
टारगेट के लिए, सही नामों की जानकारी नीचे दी गई है.
टारगेट के नाम — package-name:target-name
target-name, पैकेज में मौजूद टारगेट का नाम होता है. नियम का नाम
BUILD में, नियम के एलान में मौजूद name एट्रिब्यूट की वैल्यू है
file; फ़ाइल का नाम
BUILD फ़ाइल.
टारगेट के नाम, a–z सेट से लिए गए वर्णों से बने होने चाहिए,
A–Z, 0–9, और विराम चिह्न !%-@^_"#$&'()*-+,;<=>?[]{|}~/..
फ़ाइल नाम, सामान्य रूप में मिलते-जुलते पाथनेम होने चाहिए. इसका मतलब है कि उन्हें ऐसा करना चाहिए
न तो स्लैश के साथ शुरू होता है और न ही खत्म होता है (उदाहरण के लिए, /foo और foo/
प्रतिबंधित है) और न ही इसमें पाथ सेपरेटर के तौर पर लगातार कई स्लैश हैं
(उदाहरण के लिए, foo//bar). इसी तरह, अप-लेवल रेफ़रंस (..) और
मौजूदा-डायरेक्ट्री के रेफ़रंस (./) इस्तेमाल नहीं किए जा सकते.
गलत — अन्य पैकेज की फ़ाइलों का रेफ़रंस देने के लिए, .. का इस्तेमाल न करें
सही — इस्तेमाल करें
//package-name:filename
हालांकि, फ़ाइल टारगेट के नाम के साथ / का इस्तेमाल करना आम बात है, लेकिन इनका इस्तेमाल करने से बचें
नियमों के नामों में /. खास तौर पर, जब किसी लेबल का शॉर्टहैंड फ़ॉर्मैट
इस्तेमाल किया जाता है, तो इससे पाठक भ्रमित हो सकता है. //foo/bar/wiz लेबल हमेशा एक शॉर्टहैंड होता है
//foo/bar/wiz:wiz के लिए, भले ही ऐसा कोई पैकेज foo/bar/wiz न हो; यह
कभी भी //foo:bar/wiz का संदर्भ नहीं देता, भले ही वह टारगेट मौजूद हो.
हालांकि, कुछ स्थितियों में स्लैश का इस्तेमाल करना आसान होता है या कभी-कभी ज़रूरी भी होते हैं. उदाहरण के लिए, कुछ नियमों के नाम का मेल खाना ज़रूरी है भी शामिल हो सकती है, जो पैकेज की सबडायरेक्ट्री में मौजूद हो सकती है.
पैकेज के नाम — //package-name:target-name
पैकेज का नाम उस डायरेक्ट्री का नाम होता है जिसमें इसकी BUILD फ़ाइल होती है,
डेटा स्टोर करने की जगह की टॉप-लेवल डायरेक्ट्री के मुताबिक होना चाहिए.
उदाहरण के लिए: my/app.
तकनीकी स्तर पर, Basel ने इन चीज़ों को लागू किया है:
- पैकेज के नाम में
aसेzतक के छोटे अक्षर हैं, जिन्हें इस्तेमाल करने की अनुमति है.AसेZतक के बड़े अक्षर,0से9तक के अंक, वर्ण! \"#$%&'()*+,-.;<=>?@[]^_`{|}(हां, इसमें एक स्पेस वर्ण है वहाँ पहुँच गया है!), और निश्चित रूप से स्लैश/(क्योंकि यह डायरेक्टरी है सेपरेटर). - पैकेज के नाम, फ़ॉरवर्ड स्लैश वर्ण
/से शुरू या खत्म नहीं हो सकते. - पैकेज के नाम में
//सबस्ट्रिंग नहीं हो सकती. इससे फ़र्क़ नहीं पड़ेगा कि Sense---उससे जुड़ी डायरेक्ट्री का पाथ क्या होगा? - पैकेज के नाम में सबस्ट्रिंग
/./,/../या/.../वगैरह नहीं हो सकते. यह नीति उल्लंघन ठीक करने का यह तरीका इसलिए अपनाया जाता है, ताकि लॉजिकल के बीच अनुवाद करते समय, भ्रम की स्थिति से बचा जा सके पैकेज का नाम और एक फ़िज़िकल डायरेक्ट्री का नाम, जिसे पाथ स्ट्रिंग में डॉट वर्ण.
व्यावहारिक स्तर पर:
- ऐसी डायरेक्ट्री वाली भाषा के लिए जो इसके मॉड्यूल के लिए अहम हो सिस्टम (उदाहरण के लिए, Java) का इस्तेमाल करते हैं, तो उन डायरेक्ट्री नामों को चुनना ज़रूरी है जो मान्य आइडेंटिफ़ायर सबमिट करें. उदाहरण के लिए, लीडिंग से शुरू न करें अंकों को शामिल न करें और विशेष वर्णों, खास तौर पर अंडरस्कोर और हाइफ़न का इस्तेमाल न करें.
- हालांकि, Baज़ल, फ़ाइल फ़ोल्डर के रूट पैकेज में टारगेट के साथ काम करता है (उदाहरण के लिए,
//:foo), तो उस पैकेज को खाली छोड़ देना ही बेहतर होगा, ताकि सभी सही पैकेज पाएं ब्यौरे वाले नाम होते हैं.
नियम
नियम, इनपुट और आउटपुट के बीच के संबंध के बारे में बताता है और आउटपुट तैयार करने के चरण. नियम कई अलग-अलग प्रकार (कभी-कभी नियम क्लास भी कहा जाता है) जो कंपाइल करके एक्ज़ीक्यूटेबल और लाइब्रेरी, टेस्ट एक्ज़ीक्यूटेबल और अन्य आउटपुट, जो बिल्ड एनसाइक्लोपीडिया में बताए गए हैं.
BUILD फ़ाइलें, नियमों का इस्तेमाल करके टारगेट तय करती हैं.
नीचे दिए गए उदाहरण में, टारगेट my_app का एलान किया गया है
cc_binary नियम का इस्तेमाल करके.
cc_binary(
name = "my_app",
srcs = ["my_app.cc"],
deps = [
"//absl/base",
"//absl/strings",
],
)
हर नियम को शुरू करने के लिए, एक name एट्रिब्यूट होता है (यह एक मान्य वैल्यू होनी चाहिए)
टारगेट का नाम), जो पैकेज में मौजूद किसी टारगेट के बारे में बताता है
BUILD फ़ाइल में से.
हर नियम में एट्रिब्यूट का एक सेट होता है; दिए गए एट्रिब्यूट के लिए, लागू होने वाले एट्रिब्यूट नियम है और हर विशेषता का महत्व और सिमेंटिक्स किस तरह का है; बिल्ड एनसाइक्लोपीडिया देखें नियमों और उनसे जुड़े एट्रिब्यूट की लिस्ट दी गई है. हर एट्रिब्यूट का एक नाम होता है और एक प्रकार. एट्रिब्यूट में पूर्णांक, लेबल, सूची जैसे कुछ सामान्य टाइप शामिल हो सकते हैं लेबल की सूची, स्ट्रिंग, स्ट्रिंग की सूची, आउटपुट लेबल, आउटपुट लेबल की सूची. नहीं हर नियम में सभी विशेषताओं की जानकारी होनी चाहिए. इस तरह, एट्रिब्यूट कुंजियों (नाम) से लेकर वैकल्पिक, टाइप किए गए मानों तक का शब्दकोश.
कई नियमों में मौजूद srcs एट्रिब्यूट का टाइप "लेबल की सूची" है; यह
के तौर पर लेबल की एक सूची है. हर लेबल का नाम
इस नियम के लिए इनपुट.
कुछ मामलों में, नियम का नाम अपने हिसाब से रखा जाता है. इसके अलावा, नियम से जनरेट होने वाली फ़ाइलों के नाम दिलचस्प हैं और यह सही है . ज़्यादा जानकारी के लिए, यह देखें सामान्य नियम: सामान्य नियम.
अन्य मामलों में, नाम अहम होता है: *_binary और *_test नियमों के लिए,
उदाहरण के लिए, नियम का नाम
बिल्ड.
टारगेट पर डायरेक्ट किए गए एकाइक्लिक ग्राफ़ को टारगेट ग्राफ़ कहा जाता है या बिल्ड डिपेंडेंसी ग्राफ़ और वह डोमेन होता है जिस पर Baez क्वेरी टूल काम करता है.
| टारगेट | फ़ाइलें बनाएं |