लेबल

सभी लक्ष्य सटीक रूप से एक ही पैकेज से संबंधित होते हैं. टारगेट के नाम को लेबल कहा जाता है. हर लेबल किसी टारगेट की खास तौर पर पहचान करता है. कैननिकल फ़ॉर्म में एक सामान्य लेबल ऐसा दिखता है:

@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 Query Language.

जिन टारगेट नामों की अनुमति है उनकी सटीक जानकारी नीचे दी गई है.

टारगेट के नाम — 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), वहां उन डायरेक्ट्री के नाम चुनना ज़रूरी है जो उस भाषा के मान्य आइडेंटिफ़ायर हों.

हालांकि, Bazel, Workspace के रूट पैकेज में शामिल टारगेट के साथ काम करता है (उदाहरण के लिए, //:foo), लेकिन उस पैकेज को खाली छोड़ना बेहतर होगा, ताकि काम के सभी पैकेज के नाम पूरी जानकारी देने वाले हों.

पैकेज के नाम में सबस्ट्रिंग // नहीं होनी चाहिए और न ही वह स्लैश से खत्म हो सकता है.

नियम

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

BUILD फ़ाइलें, नियम लागू करके टारगेट के बारे में जानकारी देती हैं.

नीचे दिए गए उदाहरण में, हम cc_binary नियम का इस्तेमाल करके टारगेट my_app का एलान देखते हैं.

cc_binary(
    name = "my_app",
    srcs = ["my_app.cc"],
    deps = [
        "//absl/base",
        "//absl/strings",
    ],
)

शुरू किए जाने वाले हर नियम में एक name एट्रिब्यूट होता है, जो टारगेट का मान्य नाम होना चाहिए. यह BUILD फ़ाइल के पैकेज में मौजूद टारगेट के बारे में जानकारी देता है.

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

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

कुछ मामलों में, इस तरह के नियम का नाम कुछ हद तक सही नहीं होता है. ज़्यादा दिलचस्प, नियम से जनरेट की गई फ़ाइलों के नाम होते हैं. यह जेन नियमों के बारे में सही होता है. ज़्यादा जानकारी के लिए, सामान्य नियम: genrole देखें.

अन्य मामलों में, नाम अहम है: *_binary और *_test नियमों के लिए, उदाहरण के लिए, नियम के नाम से बिल्ड के बनाए गए एक्ज़ीक्यूटेबल का नाम तय होता है.

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

arrow_backटारगेट

फ़ाइलें बनाएंarrow_forward