लेबल

किसी समस्या की शिकायत करेंopen_in_new स्रोत देखेंopen_in_new

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

@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 से है. हालांकि, जब Bazel को किसी पैकेज (जैसे, package_group से जुड़ी जानकारी) की ज़रूरत होती है, तो वह उस पैकेज की जानकारी दिखाता है जिसमें वह लेबल होता है.

BUILD फ़ाइलों में आम तौर पर, किसी पैकेज के बारे में बताने के लिए //my/app का इस्तेमाल किया जाता है या किसी पैकेज में मौजूद सभी टारगेट को इस्तेमाल करने के लिए कहा जाता है--ऐसा नहीं होता. याद रखें, यह //my/app:app के बराबर है. इसलिए, यह डेटा स्टोर करने की मौजूदा जगह के my/app पैकेज में app टारगेट को नाम देता है.

हालांकि, पैकेज के बारे में बताने के लिए //my/app के इस्तेमाल को package_group या .bzl फ़ाइलों की विशेषताओं में बताया जाता है. ऐसा इसलिए, क्योंकि इससे साफ़ तौर पर पता चलता है कि पैकेज का नाम पूरा है और उसे फ़ाइल फ़ोल्डर की टॉप-लेवल डायरेक्ट्री में रूट किया गया है.

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

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

पैकेज के नाम में सबस्ट्रिंग, // नहीं हो सकती.

नियम

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

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

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

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

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

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

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

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

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

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

arrow_backटारगेट

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