लेबल, टारगेट के लिए आइडेंटिफ़ायर होता है. अपने पूरे कैननिकल यूआरएल में कोई सामान्य लेबल फ़ॉर्म ऐसा दिखता है:
@@myrepo//my/app/main:app_binary
लेबल का पहला हिस्सा, @@myrepo रिपॉज़िटरी का नाम होता है. दो बार @ वाला सिंटैक्स यह दिखाता है कि यह कैननिकल रिपॉज़िटरी का नाम है. यह नाम, वर्कस्पेस में यूनीक होता है. कैननिकल रिपॉज़िटरी के नाम वाले लेबल, किसी टारगेट की पहचान साफ़ तौर पर करते हैं. भले ही, वे किसी भी संदर्भ में दिखें.
अक्सर कैननिकल रेपो नाम एक आर्केन स्ट्रिंग होता है, जो
@@rules_java~7.1.0~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 जैसी स्ट्रिंग का मतलब, इस्तेमाल के कॉन्टेक्स्ट के हिसाब से दो तरह से होता है: जब Bazel को लेबल की ज़रूरत होती है, तो इनका मतलब क्रमशः //my/app:app और @@some_repo//my/app:app होता है. हालांकि, जब बेज़ल
एक पैकेज की उम्मीद है (जैसे कि package_group स्पेसिफ़िकेशन में), तो वे
वह लेबल शामिल है.
BUILD फ़ाइलों में अक्सर यह गलती की जाती है कि किसी पैकेज या पैकेज के सभी टारगेट का रेफ़रंस देने के लिए, //my/app का इस्तेमाल किया जाता है. हालांकि, ऐसा नहीं करना चाहिए. याद रखें, यह
//my/app:app के बराबर है, इसलिए यह my/app में app टारगेट को नाम देता है
मौजूदा डेटा स्टोर करने की जगह का पैकेज.
हालांकि, package_group या .bzl फ़ाइलों में, पैकेज का रेफ़रंस देने के लिए //my/app का इस्तेमाल करने का सुझाव दिया जाता है. ऐसा इसलिए, क्योंकि इससे साफ़ तौर पर पता चलता है कि पैकेज का नाम सही है और वह वर्कस्पेस की टॉप-लेवल डायरेक्ट्री में मौजूद है.
रिलेटिव लेबल का इस्तेमाल, अन्य पैकेज में टारगेट की जानकारी देने के लिए नहीं किया जा सकता; यह
इस मामले में, रिपॉज़िटरी आइडेंटिफ़ायर और पैकेज का नाम हमेशा बताना ज़रूरी है.
उदाहरण के लिए, अगर सोर्स ट्री में पैकेज 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 खोजता है.
यह खास तौर पर तब ज़रूरी होता है, जब
डेटा स्टोर करने की जगह जो मुख्य डेटा स्टोर करने की जगह में मौजूद टारगेट से जुड़ी होती है.
डेटा स्टोर करने की बाहरी जगहों से इस्तेमाल किया जाता है.
टारगेट को रेफ़र करने के अलग-अलग तरीकों के बारे में जानने के लिए, टारगेट पैटर्न देखें.
किसी लेबल की लेक्सिकल स्पेसिफ़िकेशन
लेबल सिंटैक्स उन मेटावर्णों के इस्तेमाल से बचने की कोशिश करता है जिनका खास मतलब होता है शेल. इससे, अनजाने में कोटेशन में शामिल होने से जुड़ी समस्याओं से बचा जा सकता है. साथ ही, Bazel क्वेरी लैंग्वेज जैसे लेबल में बदलाव करने वाले टूल और स्क्रिप्ट को आसानी से बनाया जा सकता है.
टारगेट के लिए इस्तेमाल किए जा सकने वाले नामों के बारे में यहां पूरी जानकारी दी गई है.
टारगेट के नाम — package-name:target-name
target-name, पैकेज में मौजूद टारगेट का नाम है. किसी नियम का नाम, BUILD फ़ाइल में नियम के एलान में name एट्रिब्यूट की वैल्यू होती है. किसी फ़ाइल का नाम, 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.
पैकेज के नाम में सिर्फ़ A-Z, a–z, 0–9, '/', '-', '.', '@', और '_' सेट में मौजूद वर्ण होने चाहिए. साथ ही, पैकेज का नाम स्लैश से शुरू नहीं होना चाहिए.
किसी ऐसी भाषा के लिए जिसका डायरेक्ट्री स्ट्रक्चर, उसके मॉड्यूल सिस्टम (जैसे, Java) के लिए अहम है, डायरेक्ट्री के ऐसे नाम चुनना ज़रूरी है जो भाषा में मान्य आइडेंटिफ़ायर हों.
हालांकि, Baज़ल, फ़ाइल फ़ोल्डर के रूट पैकेज में टारगेट के साथ काम करता है (उदाहरण के लिए,
//:foo), तो उस पैकेज को खाली छोड़ देना ही बेहतर होगा, ताकि सभी सही पैकेज पाएं
ब्यौरे वाले नाम होते हैं.
पैकेज के नाम में सबस्ट्रिंग // नहीं होनी चाहिए. साथ ही, इनके आखिर में स्लैश नहीं होना चाहिए.
नियम
नियम, इनपुट और आउटपुट के बीच के संबंध के बारे में बताता है और आउटपुट तैयार करने के चरण. नियम कई अलग-अलग प्रकार (कभी-कभी नियम क्लास भी कहा जाता है) जो कंपाइल करके एक्ज़ीक्यूटेबल और लाइब्रेरी, टेस्ट एक्ज़ीक्यूटेबल और अन्य आउटपुट, जो बिल्ड एनसाइक्लोपीडिया में बताए गए हैं.
BUILD फ़ाइलें, नियमों का इस्तेमाल करके टारगेट तय करती हैं.
नीचे दिए गए उदाहरण में, cc_binary नियम का इस्तेमाल करके टारगेट my_app के एलान को देखा जा सकता है.
cc_binary(
name = "my_app",
srcs = ["my_app.cc"],
deps = [
"//absl/base",
"//absl/strings",
],
)
हर नियम को शुरू करने के लिए, एक name एट्रिब्यूट होता है (यह एक मान्य वैल्यू होनी चाहिए)
टारगेट का नाम), जो पैकेज में मौजूद किसी टारगेट के बारे में बताता है
BUILD फ़ाइल में से.
हर नियम में एट्रिब्यूट का एक सेट होता है. किसी दिए गए नियम के लिए लागू होने वाले एट्रिब्यूट और हर एट्रिब्यूट का मतलब और सेमेटिक्स, नियम के टाइप पर निर्भर करता है. नियमों और उनके एट्रिब्यूट की सूची के लिए, बिल्ड एनसाइक्लोपीडिया देखें. हर एट्रिब्यूट का एक नाम होता है और एक प्रकार. एट्रिब्यूट में पूर्णांक, लेबल, सूची जैसे कुछ सामान्य टाइप शामिल हो सकते हैं लेबल की सूची, स्ट्रिंग, स्ट्रिंग की सूची, आउटपुट लेबल, आउटपुट लेबल की सूची. नहीं हर नियम में सभी विशेषताओं की जानकारी होनी चाहिए. इस तरह, एट्रिब्यूट कुंजियों (नाम) से लेकर वैकल्पिक, टाइप किए गए मानों तक का शब्दकोश.
कई नियमों में मौजूद srcs एट्रिब्यूट का टाइप "लेबल की सूची" है; यह
के तौर पर लेबल की एक सूची है. हर लेबल का नाम
इस नियम के लिए इनपुट.
कुछ मामलों में, नियम के टाइप का नाम कुछ हद तक मनमुताबिक होता है. साथ ही, नियम से जनरेट की गई फ़ाइलों के नाम ज़्यादा दिलचस्प होते हैं. यह बात genrules के लिए भी सही है. ज़्यादा जानकारी के लिए, सामान्य नियम: genrule देखें.
अन्य मामलों में, नाम का ज़्यादा महत्व होता है: उदाहरण के लिए, *_binary और *_test नियमों के लिए, नियम के नाम से यह तय होता है कि बिल्ड से तैयार किए गए, रन किए जा सकने वाले प्रोग्राम का नाम क्या होगा.
टारगेट पर डायरेक्ट किए गए एकाइक्लिक ग्राफ़ को टारगेट ग्राफ़ कहा जाता है या बिल्ड डिपेंडेंसी ग्राफ़ और वह डोमेन होता है जिस पर Baez क्वेरी टूल काम करता है.
| टारगेट | BUILD फ़ाइलें |