लेबल

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 . 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

लेबल, टारगेट के लिए आइडेंटिफ़ायर होता है. कैननिकल फ़ॉर्मैट में, कोई सामान्य लेबल ऐसा दिखता है:

@@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 जैसी स्ट्रिंग का मतलब, इस्तेमाल के कॉन्टेक्स्ट के हिसाब से दो तरह से होता है: जब Bazel को लेबल की ज़रूरत होती है, तो इनका मतलब क्रमशः //my/app:app और @@some_repo//my/app:app होता है. हालांकि, जब Bazel को किसी पैकेज (उदाहरण के लिए, 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.

तकनीकी लेवल पर, Bazel इन चीज़ों को लागू करता है:

• पैकेज के नाम में ये वर्ण इस्तेमाल किए जा सकते हैं: अंग्रेज़ी के छोटे अक्षर a से z, अंग्रेज़ी के बड़े अक्षर A से Z, अंक 0 से 9, वर्ण ! \"#$%&'()*+,-.;<=>?@[]^_`{|} (हां, इसमें स्पेस वर्ण भी है!), और फ़ॉरवर्ड स्लैश / (क्योंकि यह डायरेक्ट्री को अलग करने वाला वर्ण है).
• पैकेज के नाम, फ़ॉरवर्ड स्लैश कैरेक्टर / से शुरू या खत्म नहीं हो सकते.
• पैकेज के नाम में सबस्ट्रिंग // नहीं हो सकती. इससे कोई मतलब नहीं होगा---इससे जुड़ा डायरेक्ट्री पाथ क्या होगा?
• पैकेज के नाम में सबस्ट्रिंग /./ या /../ या /.../ वगैरह नहीं हो सकती. ऐसा इसलिए किया जाता है, ताकि पैकेज के लॉजिकल नाम और फ़िज़िकल डायरेक्ट्री के नाम के बीच अनुवाद करते समय भ्रम की स्थिति न पैदा हो. ऐसा इसलिए है, क्योंकि पाथ स्ट्रिंग में बिंदु वाले वर्ण का सेमेटिक मतलब होता है.

व्यावहारिक तौर पर:

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

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

टारगेट

BUILD फ़ाइलें