कार्रवाई
बिल्ड के दौरान चलने वाला कमांड, उदाहरण के लिए, कंपाइलर को कॉल करना, जो इनपुट के तौर पर आर्टफ़ैक्ट लेता है और आउटपुट के तौर पर, दूसरे आर्टफ़ैक्ट बनाता है. इसमें कमांड लाइन आर्ग्युमेंट, ऐक्शन बटन, एनवायरमेंट वैरिएबल, और एलान किए गए इनपुट/आउटपुट आर्टफ़ैक्ट जैसे मेटाडेटा शामिल होते हैं.
यह भी देखें: नियम दस्तावेज़
ऐक्शन कैश
ऑन-डिस्क कैश मेमोरी, जो उनके बनाए गए आउटपुट के लिए कार्रवाई करने के तरीके को मैप करती है. कैश बटन को कार्रवाई कुंजी कहा जाता है. Bazel के इंक्रीमेंटैलिटी मॉडल के लिए मुख्य कॉम्पोनेंट. कैश मेमोरी, आउटपुट बेस डायरेक्ट्री में सेव की जाती है, और Bazel सर्वर के रीस्टार्ट होने के बाद भी बची रहती है.
कार्रवाई ग्राफ़
कार्रवाइयों और आर्टफ़ैक्ट का इन-मेमोरी ग्राफ़, जिसे ये कार्रवाइयां पढ़ें और जनरेट करती हैं. ग्राफ़ में ऐसी चीज़ें शामिल हो सकती हैं जो सोर्स फ़ाइलों (जैसे कि फ़ाइल सिस्टम में) के रूप में मौजूद हैं. साथ ही, इनमें ऐसे इंटरमीडिएट/फ़ाइनल आर्टफ़ैक्ट भी शामिल हो सकते हैं जिनके बारे में BUILD फ़ाइलों में नहीं बताया गया है. विश्लेषण के चरण के दौरान बनाया गया और प्लान के मुताबिक प्रोसेस करने के दौरान इस्तेमाल किया गया.
कार्रवाई ग्राफ़ क्वेरी (क्वेरी)
एक क्वेरी टूल, जो बिल्ड कार्रवाइयों पर क्वेरी कर सकता है. इससे यह पता चलता है कि बिल्ड के नियम, असल काम के बिल्ड में कैसे बदलते हैं.
कार्रवाई कुंजी
किसी कार्रवाई की कैश कुंजी. इसका आकलन, ऐक्शन मेटाडेटा के आधार पर किया जाता है. इसमें, कार्रवाई के लिए तय किया जाने वाला निर्देश, कंपाइलर फ़्लैग, लाइब्रेरी की जगह की जानकारी या कार्रवाई के आधार पर सिस्टम के हेडर शामिल होते हैं. Bazel को अलग-अलग कार्रवाइयों को तय करने में मदद करता है या उन्हें कैश मेमोरी में सेव करता है.
विश्लेषण का फ़ेज़
बिल्ड का दूसरा फ़ेज़. कार्रवाई के ग्राफ़ को प्रोसेस करता है, जो BUILD फ़ाइलों में तय होता है. इससे, मेमोरी में कार्रवाई करने का ग्राफ़ बनाया जाता है. इससे, कार्रवाई के क्रम में कार्रवाई करने का चरण तय होता है. इस चरण में नियम लागू किए जाते हैं.
सह-प्रॉडक्ट
कोई सोर्स फ़ाइल या जनरेट की गई फ़ाइल. यह फ़ाइलों की डायरेक्ट्री भी हो सकती है, जिसे ट्री आर्टफ़ैक्ट कहा जाता है.
आर्टफ़ैक्ट कई कार्रवाइयों के लिए एक इनपुट हो सकता है. हालांकि, इसे ज़्यादा से ज़्यादा एक कार्रवाई से ही जनरेट किया जाना चाहिए.
फ़ाइल टारगेट से मेल खाने वाले आर्टफ़ैक्ट को लेबल का इस्तेमाल करके ठीक किया जा सकता है.
पहलू
अपनी डिपेंडेंसी में अन्य कार्रवाइयां बनाने के नियमों का तरीका. उदाहरण के लिए, अगर टारगेट A, B पर निर्भर है, तो A, A पर कोई ऐसा पहलू लागू कर सकता है जो B पर निर्भरता के किनारे को ऊपर ले जाता है. साथ ही, B में अतिरिक्त आउटपुट फ़ाइलें जनरेट और इकट्ठा करने के लिए दूसरी कार्रवाइयां कर सकता है. इन अतिरिक्त कार्रवाइयों को कैश मेमोरी में सेव किया जाता है. साथ ही, एक ही आसपेक्ट के लिए टारगेट किए गए टारगेट के बीच इनका इस्तेमाल किया जाता है. aspect() Starlark Build API फ़ंक्शन से बनाया गया. उदाहरण के लिए, इसका इस्तेमाल आईडीई के लिए मेटाडेटा जनरेट करने और लिंक करने के लिए कार्रवाइयां तैयार करने के लिए किया जा सकता है.
यह भी देखें: पक्षों से जुड़े दस्तावेज़
आसपेक्ट रेशियो
एक कंपोज़िशन मैकेनिज़्म जिससे अन्य पहलुओं के नतीजों
पर नतीजे लागू किए जा सकते हैं. उदाहरण के लिए, आईडीई की मदद से इस्तेमाल करने के लिए जानकारी जनरेट करने वाले आसपेक्ट को उस पहलू के ऊपर लागू किया जा सकता है जो प्रोटो से .java फ़ाइलें जनरेट करता है.
A आसपेक्ट रेशियो (लंबाई-चौड़ाई का B) के ऊपर लागू करने के लिए, यह ज़रूरी है कि सेवा देने वाली कंपनियां, जिनके B का provides एट्रिब्यूट में विज्ञापन दिया गया हो, उनसे मेल खाना चाहिए. यह जानकारी, Arequired_aspect_providers एट्रिब्यूट में दी गई जानकारी से मेल खानी चाहिए.
एट्रिब्यूट
rule का पैरामीटर, जिसका इस्तेमाल टारगेट की गई बिल्ड की जानकारी दिखाने के लिए किया जाता है.
उदाहरण के लिए, srcs, deps, और copts. इनमें टारगेट टारगेट की सोर्स फ़ाइलें, डिपेंडेंसी, और कस्टम कंपाइलर के विकल्प शामिल हैं. किसी दिए गए टारगेट के लिए उपलब्ध
खास एट्रिब्यूट, उनके नियम के टाइप पर निर्भर करते हैं.
.bazelrc
Bazel की कॉन्फ़िगरेशन फ़ाइल, स्टार्टअप फ़्लैग और कमांड फ़्लैग की डिफ़ॉल्ट वैल्यू बदलने के लिए और --config ग्रुप का इस्तेमाल करके, विकल्पों के ऐसे सामान्य ग्रुप तय करने के लिए इस्तेमाल की जाती थी जिन्हें बाद में
Bazel कमांड लाइन पर सेट किया जा सकता है. bazelrc
ब्लेज़
Bazel का Google-आंतरिक वर्शन. Google का मुख्य सिस्टम, मोनो रिपॉज़िटरी (डेटा स्टोर करने की जगह) के लिए है.
बिल्ड फ़ाइल
BUILD फ़ाइल, कॉन्फ़िगरेशन की एक मुख्य फ़ाइल होती है. इससे,
बेज़ल को यह जानने में मदद मिलती है कि कौनसा सॉफ़्टवेयर बनाना है, उनकी डिपेंडेंसी क्या है, और उन्हें कैसे बनाया जाता है. Bazel, इनपुट के तौर पर BUILD फ़ाइल लेता है और इस फ़ाइल का इस्तेमाल डिपेंडेंसी का ग्राफ़ बनाने के लिए करता है. साथ ही, इससे उन कामों को भी करता है जो इंटरमीडिएट और फ़ाइनल सॉफ़्टवेयर आउटपुट बनाने के लिए पूरे होने चाहिए. BUILD फ़ाइल, डायरेक्ट्री और उन सब-डायरेक्ट्री को मार्क करती है जिनमें
BUILD फ़ाइल का कोई पैकेज नहीं होता है. साथ ही, इसमें नियम से बनाए गए
टारगेट हो सकते हैं. फ़ाइल का नाम BUILD.bazel भी हो सकता है.
BUILD.bazel फ़ाइल
BUILD फ़ाइल देखें. उसी डायरेक्ट्री में, BUILD फ़ाइल को
प्राथमिकता दी जाती है.
.bzl फ़ाइल
नियमों, मैक्रो, और Starlark में लिखे कॉन्सटेंट की जानकारी देने वाली फ़ाइल. इसके बाद, उन्हें load() फ़ंक्शन का इस्तेमाल करके, BUILD
फ़ाइलों में इंपोर्ट किया जा सकता है.
ग्राफ़ बनाएं
बैज़ेल बनाने वाला डिपेंडेंसी ग्राफ़. यह बिल्ड करने के लिए, ट्रेल को पार करता है. इसमें टारगेट, कॉन्फ़िगर किए गए टारगेट, कार्रवाइयां, और आर्टफ़ैक्ट जैसे नोड शामिल होते हैं. बिल्ड को तब पूरा माना जाता है, जब सभी आर्टफ़ैक्ट, जिन पर टारगेट के सेट के सेट की पुष्टि हो जाती है, वे अप-टू-डेट होते हैं.
सेटिंग बनाना
कॉन्फ़िगरेशन का Starlark से तय किया गया हिस्सा. ट्रांज़िशन की मदद से, सबग्राफ़ के कॉन्फ़िगरेशन में बदलाव करने के लिए, बिल्ड की सेटिंग तय की जा सकती है. अगर उपयोगकर्ता को कमांड-लाइन फ़्लैग के तौर पर दिखाया जाता है, तो इसे बिल्ड फ़्लैग भी कहा जाता है.
क्लीन बिल्ड
एक ऐसा निर्माण जो पिछले बिल्ड के परिणामों का उपयोग नहीं करता है. आम तौर पर, यह इंक्रीमेंटल बिल्ड से कम होता है, लेकिन आम तौर पर यह ज़्यादा सही होता है. बेज़ल पक्का करता है कि साफ़ और इंक्रीमेंटल बिल दोनों सही हों.
क्लाइंट-सर्वर मॉडल
bazel कमांड-लाइन क्लाइंट, स्थानीय मशीन पर बैकग्राउंड सर्वर को अपने-आप शुरू करता है, ताकि Bazel के कमांड लागू किए जा सकें. सर्वर सभी निर्देशों के साथ बना रहता है,
लेकिन कुछ समय तक कोई गतिविधि न होने पर (या बेज़ल बंद होने पर) अपने-आप रुक जाता है. Bazel को सर्वर और क्लाइंट के बीच बांट देने से, JVM के शुरू होने में लगने वाले समय को कम करने में मदद मिलती है. साथ ही, यह तेज़ी से बढ़ते बिल्ड के साथ काम करता है, क्योंकि कार्रवाई का ग्राफ़ सभी कमांड में मेमोरी में सेव रहता है.
Command
bazel
build, bazel test, bazel run, और bazel query जैसे अलग-अलग Bazel फ़ंक्शन को शुरू करने के लिए, कमांड लाइन पर इस्तेमाल किया जाता है.
कमांड फ़्लैग
कमांड के हिसाब से फ़्लैग का सेट. कमांड फ़्लैग, निर्देश (bazel build <command flags>) के बाद बताया जाता है. फ़्लैग एक या उससे ज़्यादा निर्देशों पर लागू हो सकते हैं. उदाहरण के लिए, --configure सिर्फ़ bazel sync निर्देश के लिए फ़्लैग किया जाता है, लेकिन --keep_going sync, build, test, और अन्य निर्देशों पर लागू होता है. फ़्लैग का इस्तेमाल अक्सर कॉन्फ़िगरेशन के लिए किया जाता है. इसलिए, फ़्लैग की वैल्यू में बदलाव की वजह से, बेज़ल इन-मेमोरी ग्राफ़ को अमान्य कर सकता है और विश्लेषण फ़ेज़ को फिर से शुरू कर सकता है.
कॉन्फ़िगरेशन
नियम परिभाषाओं से बाहर की जानकारी, जो नियमों के कार्रवाइयां जनरेट करने के तरीके पर असर डालती है. हर बिल्ड में कम से कम एक कॉन्फ़िगरेशन होता है, जिसमें टारगेट प्लैटफ़ॉर्म, कार्रवाई से जुड़े एनवायरमेंट वैरिएबल, और कमांड-लाइन फ़्लैग होते हैं. ट्रांज़िशन के साथ, अन्य कॉन्फ़िगरेशन भी जोड़े जा सकते हैं. जैसे, होस्ट टूल या क्रॉस-कंपाइलेशन.
यह भी देखें: कॉन्फ़िगरेशन
कॉन्फ़िगरेशन में काट-छांट की जा रही है
असल में, टारगेट के कॉन्फ़िगरेशन के
हिस्सों को शामिल करने की प्रोसेस को असल में ज़रूरत है. उदाहरण के लिए, अगर आप C++ डिपेंडेंसी //:c के साथ Java बाइनरी बनाते हैं, तो //:c के कॉन्फ़िगरेशन में --javacopt की वैल्यू को शामिल करना बेकार होता है, क्योंकि --javacopt की वजह से, C++ बनाने की कैश मेमोरी में ज़रूरत के हिसाब से ज़रूरत के मुताबिक ब्रेक मिल जाता है.
कॉन्फ़िगर की गई क्वेरी (क्वेरी)
एक क्वेरी टूल, जो कॉन्फ़िगर किए गए टारगेट के बारे में क्वेरी करता है (विश्लेषण फ़ेज़ पूरा होने के बाद). इसका मतलब है कि select() और फ़्लैग करें फ़्लैग (जैसे कि --platforms), नतीजों में सही तरह से दिखते हैं.
यह भी देखें: क्वेरी दस्तावेज़
कॉन्फ़िगर किया गया टारगेट
कॉन्फ़िगरेशन वाले टारगेट का आकलन करने का नतीजा. विश्लेषण का फ़ेज़ बनाने के लिए,
बिल्ड के विकल्पों को उन टारगेट के साथ जोड़ा जाता है जिन्हें बनाने की ज़रूरत है.
उदाहरण के लिए, अगर //:foo एक ही बिल्ड में दो अलग-अलग आर्किटेक्चर के लिए बनाया जाता है, तो इसके दो कॉन्फ़िगर किए गए टारगेट हैं: <//:foo, x86> और <//:foo, arm>.
सही
बिल्ड तब सही होता है, जब उसका आउटपुट अपने ट्रांज़िशनल इनपुट की स्थिति को भरोसे के साथ दिखाता है. सही बिल्ड हासिल करने के लिए, बेज़ल रकमिक, दोबारा जनरेट करने लायक, और विश्लेषण बनाना और कार्रवाई लागू करना तय करते हैं.
निर्भर है
दो टारगेट के बीच एक सीधा किनारा. अगर //:foo के एट्रिब्यूट की वैल्यू में //:bar का रेफ़रंस दिया गया है, तो टारगेट //:foo का टारगेट //:bar पर टारगेट डिपेंडेंसी है. अगर //:foo में की गई कार्रवाई किसी इनपुट
आर्टफ़ैक्ट पर निर्भर करती है, तो इसे //:bar में
कार्रवाई पर निर्भर किया जाता है.
डिसेट
स्थायी निर्भरताओं पर डेटा इकट्ठा करने के लिए डेटा स्ट्रक्चर. ऑप्टिमाइज़ किया गया, ताकि डेप्सेट मर्ज करने से समय और जगह की बचत हो सके, क्योंकि बहुत बड़ी फ़ाइलों पर (लाखों फ़ाइलों) का इस्तेमाल किया जा सकता है. यह बार-बार, स्पेस के असर को कम करने की वजहों के आधार पर तय किया गया है. नियम लागू करने पर, नियमों का फ़ॉर्मैट " फ़्लैट" नहीं होना चाहिए, जब तक कि नियम, बिल्ड ग्राफ़ के सबसे ऊपर न हो. बड़े डेप्टेज़ को समतल करने पर बहुत ज़्यादा मेमोरी का इस्तेमाल होता है. Bazel के आंतरिक तरीकों का इस्तेमाल करके, नेस्टेड सेट के तौर पर भी जाना जाता है.
यह भी देखें: डेसेट दस्तावेज़
डिस्क की कैश मेमोरी
रिमोट कैश मेमोरी की सुविधा के लिए, डिस्क में मौजूद BLOB का स्टोर. इसका इस्तेमाल, असल में दूर से काम करने वाले BLOB स्टोर के साथ जोड़कर किया जा सकता है.
डिस्ट्रिर
सिर्फ़ पढ़ने के लिए उपलब्ध डायरेक्ट्री में, वे फ़ाइलें मौजूद होती हैं जिन्हें Bazel, डेटा स्टोर करने की जगह के नियमों का इस्तेमाल करके, इंटरनेट से फ़ेच करता है. बिल्ड को पूरी तरह ऑफ़लाइन चलाने की सुविधा देता है.
डाइनैमिक एक्ज़ीक्यूशन
एक्ज़ीक्यूशन की ऐसी रणनीति जो अलग-अलग अनुमानों के आधार पर, स्थानीय और दूर से दी गई रणनीति को लागू करती है. साथ ही, तेज़ी से काम करने वाले तरीकों के ज़रिए नतीजे लागू करती है. कुछ कार्रवाइयां तेज़ी से स्थानीय तरीके से लागू की जाती हैं (जैसे, लिंक करना) और बाकी कार्रवाइयां तेज़ी से की जाती हैं. उदाहरण के लिए, एक साथ जोड़कर बनाए गए दूसरे वीडियो ज़्यादा तेज़ी से लोड होते हैं. डाइनैमिक एक्ज़ीक्यूशन की रणनीति से, विज्ञापनों को बनाते समय सबसे बेहतर और साफ़ समय मिल सकता है.
एक्ज़ीक्यूशन का चरण
बिल्ड का तीसरा चरण. विश्लेषण के फ़ेज़ के दौरान बनाए गए ऐक्शन ग्राफ़ में कार्रवाई करें. ये कार्रवाइयां, आर्टफ़ैक्ट को पढ़ने और लिखने के लिए, एक्ज़ीक्यूटेबल (कंपाइलर) का इस्तेमाल करती हैं. स्पॉन रणनीतियां यह तय करती हैं कि इन कार्रवाइयों को कैसे एक्ज़ीक्यूट किया जाएगा: स्थानीय तौर पर, दूर से, डाइनैमिक तौर पर, सैंडबॉक्स, डॉकर वगैरह.
एक्ज़ीक्यूशन रूट
फ़ाइल फ़ोल्डर की आउटपुट बेस डायरेक्ट्री में डायरेक्ट्री, जहां सैंडबॉक्स नहीं किए गए बिल्ड में स्थानीय कार्रवाइयां लागू होती हैं. डायरेक्ट्री का कॉन्टेंट, ज़्यादातर फ़ाइल फ़ोल्डर में डाले गए आर्टफ़ैक्ट के सिमलिंक होते हैं. एक्ज़ीक्यूशन रूट में अन्य इनपुट के तौर पर बाहरी रिपॉज़िटरी के सिमलिंक और आउटपुट के स्टोर के लिए, bazel-out डायरेक्ट्री भी शामिल होती है. लोडिंग फ़ेज़ के दौरान तैयार की गई, डायरेक्ट्री का सिमलिंक फ़ॉरेस्ट बनाया जाता है. यह पैकेज, पैकेज के ट्रांज़िशन के लिए इस्तेमाल होने वाले पैकेज का प्रतिनिधित्व करता है, जिस पर बिल्ड निर्भर करता है. कमांड लाइन पर bazel info
execution_root से ऐक्सेस किया जा सकता है.
फ़ाइल
आर्टफ़ैक्ट देखें.
हेरमिटी
अगर बिल्ड बनाने और जांच करने की कार्रवाइयों पर कोई बाहरी असर नहीं पड़ता है, तो बिल्ड हर्मेटिक होता है. इससे यह तय करने में मदद मिलती है कि नतीजे, तय करने वाले और सही हैं. उदाहरण के लिए, Hermetic बिल्ड आम तौर पर, कार्रवाइयों के लिए नेटवर्क ऐक्सेस, तय किए गए इनपुट का ऐक्सेस सीमित, टाइमस्टैंप या समय क्षेत्र का इस्तेमाल, एनवायरमेंट वैरिएबल के ऐक्सेस को सीमित, और रैंडम नंबर जनरेटर के लिए सेट किए गए सीड का इस्तेमाल करने की अनुमति नहीं देते
इंक्रीमेंटल बिल्ड
इंक्रीमेंटल बिल्ड में पहले के बिल्ड के नतीजों का फिर से इस्तेमाल किया जाता है, ताकि बिल्ड का समय और संसाधन कम खर्च हो. डिपेंडेंसी जांच और कैश मेमोरी का मकसद, इस तरह के बिल्ड के लिए सही नतीजे दिखाना है. इंक्रीमेंटल बिल्ड, साफ़ बिल्ड का उलटा होता है.
लेबल
target का आइडेंटिफ़ायर. //path/to/package:target जैसे पूरी तरह क्वालिफ़ाइड लेबल में, फ़ाइल फ़ोल्डर की रूट डायरेक्ट्री को path/to/package मार्क करना, path/to/package को उस डायरेक्ट्री के तौर पर शामिल करना शामिल है जिसमें टारगेट का एलान करने वाली BUILD
फ़ाइल होती है. साथ ही, ऊपर बताई गई BUILD फ़ाइल में बताए गए टारगेट का नाम :target होता है. टारगेट को my_repository नाम वाले एक्सटर्नल रिपॉज़िटरी में दिखाया गया है. इसे दिखाने के लिए, प्रीफ़िक्स @my_repository//<..> का इस्तेमाल किया जा सकता है.
लोडिंग फ़ेज़
बिल्ड का पहला चरण, जहां बेज़ल पैकेज बनाने के लिए WORKSPACE, BUILD, और .bzl
फ़ाइलों को पार्स करता है. मैक्रो और glob() जैसे कुछ
फ़ंक्शन का मूल्यांकन इस चरण में किया जाता है. बिल्ड के दूसरे फ़ेज़ के साथ इंटरलीव किया गया, विश्लेषण का फ़ेज़, ताकि टारगेट ग्राफ़ बनाया जा सके.
मैक्रो
एक Starlark फ़ंक्शन में, एक से ज़्यादा नियम टारगेट करने के निर्देशों को एक साथ लिखने का तरीका. BUILD फ़ाइलों में सामान्य नियम बताने वाले पैटर्न
का दोबारा इस्तेमाल करने की सुविधा देता है. लोड होने की प्रोसेस के दौरान, नियम के टारगेट से जुड़े एलानों को बड़ा किया गया.
यह भी देखें: मैक्रो दस्तावेज़
याद रखने का तरीका
नियम लेखक की ओर से चुनी गई, ऐसी छोटी स्ट्रिंग जिसे उपयोगकर्ता आसानी से पढ़ सकें. इससे,
यह समझने में मदद मिलती है कि नियम में कोई कार्रवाई कैसे की जा रही है. याद रखने की सुविधा का इस्तेमाल, स्पॉन की रणनीति के आइडेंटिफ़ायर के तौर पर किया जा सकता है. कार्रवाई के उदाहरणों के कुछ उदाहरण
यहां Javac Java के नियम हैं, CppCompile C++ नियमों से, और
AndroidManifestMerger Android के नियम लागू होते हैं.
नेटिव नियम
नियम जो Bazel में बनाए जाते हैं और Java में लागू किए जाते हैं. ऐसे नियम .bzl फ़ाइलों में नेटिव मॉड्यूल के फ़ंक्शन के तौर पर दिखते हैं (उदाहरण के लिए, native.cc_library या native.java_library). उपयोगकर्ता के तय किए गए नियम (नॉन-नेटिव) Starlark का इस्तेमाल करके बनाए जाते हैं.
आउटपुट बेस
Bazel आउटपुट फ़ाइलों को सेव करने के लिए, फ़ाइल फ़ोल्डर की एक डायरेक्ट्री. इसका इस्तेमाल, फ़ाइल फ़ोल्डर के सोर्स ट्री से आउटपुट को अलग करने के लिए किया जाता है. आउटपुट उपयोगकर्ता रूट में स्थित.
आउटपुट ग्रुप
फ़ाइल का ग्रुप, जब बैजल ने टारगेट बनाना पूरा कर लिया
है और उसके बनने की संभावना होती है. नियम अपने सामान्य आउटपुट को "डिफ़ॉल्ट आउटपुट ग्रुप" में रखते हैं
(उदाहरण के लिए, java_library टारगेट .a की .jar फ़ाइल और cc_library टारगेट के लिए .so). डिफ़ॉल्ट आउटपुट ग्रुप, वह आउटपुट ग्रुप होता है जिसकी
आर्टफ़ैक्ट तब बनाई जाती हैं, जब कमांड लाइन को टारगेट करने का अनुरोध किया जाता है.
नियम, ज़्यादा नाम वाले आउटपुट ग्रुप तय कर सकते हैं, जिन्हें
BUILD फ़ाइलों (filegroup नियम) या कमांड लाइन
(--output_groups फ़्लैग) में साफ़ तौर पर बताया जा सकता है.
आउटपुट उपयोगकर्ता रूट
Bazel के आउटपुट सेव करने के लिए, उपयोगकर्ता से जुड़ी खास डायरेक्ट्री. निर्देशिका के नाम को उपयोगकर्ता के सिस्टम उपयोगकर्ता नाम से लिया जाता है. अगर कई उपयोगकर्ता एक ही समय पर सिस्टम पर एक ही प्रोजेक्ट बना रहे हों, तो आउटपुट फ़ाइल की टक्कर को रोकता है. इसमें, अलग-अलग फ़ाइल फ़ोल्डर के आउटपुट के हिसाब से सब-डायरेक्ट्री होती हैं, जिन्हें आउटपुट बेस भी कहा जाता है.
पैकेज
targets का सेट BUILD file से तय होता है. पैकेज का नाम, फ़ाइल फ़ोल्डर के रूट के मुकाबले में BUILD फ़ाइल का पाथ होता है. किसी पैकेज में सबपैकेज या सब-डायरेक्ट्री हो सकते हैं, जिनमें BUILD फ़ाइल होती है. इस तरह से, पैकेज का क्रम तैयार हो जाता है.
पैकेज ग्रुप
पैकेज के सेट को दिखाने वाला टारगेट. अक्सर visibility एट्रिब्यूट की वैल्यू में इस्तेमाल किया जाता है.
प्लैटफ़ॉर्म
किसी बिल्ड में शामिल "मशीन का प्रकार". इसमें मशीन बेज़ल जिन पर चलता है ("होस्ट" प्लैटफ़ॉर्म), मशीन बिल्ड टूल एक्ज़ीक्यूट करने के लिए इस्तेमाल किए जाते हैं ("एक्ज़ीक्यूट" प्लैटफ़ॉर्म), और मशीन टारगेट "टारगेट प्लैटफ़ॉर्म" के लिए बनाए जाते हैं.
सेवा देने वाली कंपनी
डिपेंडेंसी रिलेशन के साथ नियम टारगेट के बीच पास करने के लिए, जानकारी की एक इकाई के बारे में बताने वाला स्कीमा. आम तौर पर, इसमें कंपाइलर के विकल्प, ट्रांज़िट समय के सोर्स या आउटपुट फ़ाइलों जैसी जानकारी शामिल होती है. इसके अलावा, मेटाडेटा भी बनाया जा सकता है. एग्रीगेट किए गए ट्रांज़िटिव डेटा को सही तरीके से सेव करने के लिए, इसे डेटा के साथ इस्तेमाल किया जाता है. पहले से मौजूद
सेवा देने वाली कंपनी का उदाहरण: DefaultInfo.
यह भी देखें: सेवा देने वाली कंपनियों के दस्तावेज़
क्वेरी (कॉन्सेप्ट)
टारगेट प्रॉपर्टी और डिपेंडेंसी स्ट्रक्चर को समझने के लिए, ग्राफ़ बनाएं का तरीका. Bazel में, क्वेरी के तीन वैरिएंट काम करते हैं: query, cquery, और query.
क्वेरी (कमांड)
बिल्ड के बाद का लोड होने का चरण टारगेट ग्राफ़ पर काम करने वाला क्वेरी टूल. यह काफ़ी तेज़ है,
लेकिन select() के असर, फ़्लैग बनाने,
आर्टफ़ैक्ट या कार्रवाइयां बनाने के असर का विश्लेषण नहीं कर सकता.
यह भी देखें: क्वेरी कैसे करें, क्वेरी रेफ़रंस
रिपॉज़िटरी कैश मेमोरी
शेयर किया गया कॉन्टेंट-एड्रेसेबल कैश मेमोरी, जिसे Bazel ने बिल्ड के लिए डाउनलोड किया था, इसे फ़ाइल फ़ोल्डर में शेयर किया जा सकता है. शुरुआती डाउनलोड के बाद
बिल्ड की सुविधा चालू होती है. आम तौर पर, http_archive जैसे डेटा स्टोर करने की जगह के नियमों और repository_ctx.download जैसे रिपॉज़िटरी नियम एपीआई के ज़रिए डाउनलोड की गई फ़ाइलों को कैश मेमोरी में सेव करने के लिए इस्तेमाल किया जाता है. फ़ाइलों को तब ही कैश मेमोरी में सेव किया जाता है, जब डाउनलोड के लिए उनके SHA-256 चेकसम को तय किया गया हो.
फिर से जनरेट करना
बिल्ड या टेस्ट की प्रॉपर्टी, जो बिल्ड या टेस्ट के लिए इनपुट के सेट का इस्तेमाल करती है, वह हमेशा समय, तरीके या एनवायरमेंट के बावजूद, हर बार आउटपुट का एक ही सेट बनाएगी. ध्यान दें, इसका मतलब यह बिल्कुल नहीं है कि आउटपुट सही या मनचाहे आउटपुट हैं.
नियम
BUILD फ़ाइल में नियम टारगेट तय करने के लिए स्कीमा, जैसे कि
cc_library. BUILD फ़ाइल के हिसाब से, एक नियम में एट्रिब्यूट और ब्लैक बॉक्स लॉजिक का एक सेट होता है. तर्क, नियम टारगेट को आउटपुट आर्टफ़ैक्ट बनाने और दूसरे नियम टारगेट को जानकारी पास करने के तरीके बताता है. .bzl लेखकों के हिसाब से,
Bazel का इस्तेमाल, प्रोग्रामिंग की नई भाषाओं और
एनवायरमेंट को सपोर्ट करने के लिए किया जाता है.
लोडिंग फ़ेज़ में, नियम टारगेट करने के लिए नियमों को इंस्टैंशिएट किया जाता है. विश्लेषण के चरण नियम में, टारगेट अपनी डाउनस्ट्रीम डिपेंडेंसी के बारे में, सेवा देने वाली कंपनियों के तौर पर जानकारी देते हैं. साथ ही, उन कार्रवाइयों के बारे में बताते हैं जो उनके आउटपुट आर्टफ़ैक्ट जनरेट करने के तरीके बताती हैं. ये कार्रवाइयां एक्ज़ीक्यूशन चरण में चलती हैं.
यह भी देखें: नियम दस्तावेज़
नियम टारगेट
किसी नियम का इंस्टेंस टारगेट. फ़ाइल टारगेट और पैकेज ग्रुप के साथ कंट्रास्ट. नियम से भ्रमित न हों.
रनफ़ाइल
एक्ज़ीक्यूटेबल के target की रनटाइम डिपेंडेंसी. आम तौर पर, एक्ज़ीक्यूटेबल किसी टेस्ट नियम का एक्ज़ीक्यूटेबल आउटपुट होता है और रनफ़ाइल, टेस्ट की रनटाइम डेटा डिपेंडेंसी होती हैं. एक्ज़ीक्यूटेबल के शुरू होने से पहले (बेज़ल टेस्ट के दौरान), बेज़ल अपनी फ़ाइल की सोर्स डायरेक्ट्री के मुताबिक, एक्ज़ीक्यूटेबल के साथ-साथ रनफ़ाइल के ट्री बनाता है.
यह भी देखें: रनफ़ाइल दस्तावेज़
सैंडबॉक्सिंग
यह तकनीक, पाबंदी वाले और अस्थायी कार्रवाई करने के रूट के अंदर किसी चल रही कार्रवाई को अलग करने की तकनीक है. इससे यह पक्का किया जाता है कि यह अघोषित इनपुट नहीं पढ़ती है या अघोषित आउटपुट नहीं लिखती है. सैंडबॉक्स करने से, बेहतर तरीके का इस्तेमाल करने में काफ़ी मदद मिलती है. हालांकि, आम तौर पर इसकी परफ़ॉर्मेंस बेहतर होती है. इसके लिए ऑपरेटिंग सिस्टम से मदद की ज़रूरत होती है. परफ़ॉर्मेंस की लागत, प्लैटफ़ॉर्म के हिसाब से तय होगी. Linux पर, ऐसा करना ज़रूरी नहीं है, लेकिन macOS पर ऐसा करने से सैंडबॉक्स करने की सुविधा काम नहीं करेगी.
स्काईफ़्रेम
Skyframe, बेज़ल का मुख्य पैरलल, फ़ंक्शनल, और इंक्रीमेंटल इवैलुएशन फ़्रेमवर्क है.
छपाई का काम
Bazel के बनाए गए आर्टफ़ैक्ट में ज़्यादा जानकारी जोड़ने की सुविधा. उदाहरण के लिए, इसका इस्तेमाल स्रोत कंट्रोल, बिल्ड
समय और अन्य फ़ाइल फ़ोल्डर के लिए या रिलीज़ बिल्ड के लिए पर्यावरण से जुड़ी जानकारी के लिए किया जा सकता है.
स्टैंप एट्रिब्यूट के लिए, --workspace_status_command फ़्लैग और नियमों का इस्तेमाल करके चालू करें.
स्टारलार्क
नियम और मैक्रो लिखने के लिए एक्सटेंशन की भाषा. कॉन्फ़िगरेशन (उदाहरण के लिए, व्याकरण और व्याकरण के हिसाब से) Python का ऐसा सबसेट है जिसका मकसद कॉन्फ़िगरेशन करना और बेहतर परफ़ॉर्मेंस देना है. .bzl
फ़ाइल एक्सटेंशन का इस्तेमाल करता है. BUILD फ़ाइलें, Starlark के और भी प्रतिबंधित
वर्शन (जैसे कि def फ़ंक्शन की कोई परिभाषा नहीं) का इस्तेमाल करती हैं. इसे पहले Skylark के नाम से जाना जाता था.
यह भी देखें: Starlark की भाषा से जुड़े दस्तावेज़
स्टार्टअप फ़्लैग
bazel और कमांड के बीच तय किए गए झंडों का सेट,
उदाहरण के लिए, बेज़ल --host_jvm_debug बिल्ड. ये फ़्लैग, बेज़ल सर्वर के
कॉन्फ़िगरेशन में बदलाव करते हैं. इस वजह से, स्टार्टअप फ़्लैग में
किसी भी तरह का बदलाव होने पर, सर्वर रीस्टार्ट हो जाता है. स्टार्टअप फ़्लैग किसी भी आदेश के लिए
विशिष्ट नहीं होते हैं.
टारगेट
BUILD फ़ाइल में बताया गया कोई ऑब्जेक्ट, जिसे किसी लेबल की मदद से पहचाना जा सकता है. टारगेट, असली उपयोगकर्ता के नज़रिये से फ़ाइल फ़ोल्डर की ऐसी यूनिट बनाते हैं जिन्हें
बनाया जा सकता है.
नियम लागू करके तय किए गए टारगेट को नियम टारगेट कहा जाता है. नियम के मुताबिक, ये चलाए जा सकते हैं (जैसे
cc_binary) या टेस्ट किए जा सकने वाले (जैसे cc_test). नियम टारगेट आम तौर पर अपने एट्रिब्यूट (जैसे कि deps) के ज़रिए दूसरे टारगेट पर निर्भर होते हैं; ये डिपेंडेंसी टारगेट ग्राफ़ के आधार पर बनती हैं.
नियम टारगेट के अलावा, फ़ाइल टारगेट और पैकेज ग्रुप टारगेट भी होते हैं. फ़ाइल टारगेट, उन आर्टफ़ैक्ट से जुड़े होते हैं
जिन्हें BUILD फ़ाइल में रेफ़र किया जाता है. एक खास मामले में, किसी भी पैकेज की BUILD फ़ाइल को हमेशा उस पैकेज में सोर्स फ़ाइल टारगेट के तौर पर देखा जाता है.
टारगेट, लोड होने की प्रोसेस के दौरान खोजे जाते हैं. विश्लेषण के चरण के दौरान, टारगेट से जुड़े कॉन्फ़िगरेशन टारगेट बनाने के लिए, बिल्ड के कॉन्फ़िगरेशन से जुड़े होते हैं.
टारगेट ग्राफ़
टारगेट और उनकी डिपेंडेंसी का इन-मेमोरी ग्राफ़. इसे लोड होने की प्रोसेस के दौरान बनाया जाता है. साथ ही, इसका इस्तेमाल विश्लेषण फ़ेज़ में इनपुट के तौर पर किया जाता है.
टारगेट पैटर्न
कमांड लाइन पर टारगेट का ग्रुप बताने का तरीका. आम तौर पर, इस्तेमाल किए जाने वाले पैटर्न ये हैं: :all सभी नियम टारगेट, :* (सभी नियम + फ़ाइल टारगेट),
... (मौजूदा पैकेज और सभी सबपैकेज बार-बार). //...:* के कॉम्बिनेशन का इस्तेमाल किया जा सकता है. जैसे, सभी पैकेज के सभी नियम और फ़ाइल टारगेट, बार-बार फ़ाइल फ़ोल्डर के रूट से होते हैं.
जांच
टेस्ट के नियमों से लागू हुए टारगेट नियम में, एक टेस्ट एक्ज़ीक्यूटेबल शामिल होता है. एक्ज़ीक्यूटेबल के पूरा होने से वापस आने पर, शून्य होने का संकेत मिलता है. Bazel और टेस्ट के बीच एग्ज़ैक्ट कॉन्ट्रैक्ट (जैसे कि टेस्ट एनवायरमेंट वैरिएबल, टेस्ट के नतीजे इकट्ठा करने के तरीके) की जानकारी, टेस्ट एनसाइक्लोपीडिया में दी गई है.
टूल चेन
किसी भाषा के आउटपुट बनाने के लिए टूल का एक सेट. आम तौर पर, टूलचेन में कंपाइलर, लिंकर, अनुवादक, और/या लिंटर शामिल होते हैं. टूल अलग-अलग प्लैटफ़ॉर्म पर अलग-अलग हो सकते हैं. इसका मतलब है कि Windows वर्शन के लिए, Unix कंपाइलर टूल चेन के कॉम्पोनेंट अलग-अलग हो सकते हैं, भले ही टूलचेन एक ही भाषा का हो. इस प्लैटफ़ॉर्म के लिए सही टूलचेन चुनने को टूलचेन रिज़ॉल्यूशन कहा जाता है.
टॉप-लेवल टारगेट
अगर बिल्ड कमांड के लिए लाइन पर अनुरोध किया गया है, तो बिल्ड टारगेट टॉप-लेवल है. उदाहरण के लिए, अगर //:foo, //:bar पर निर्भर है और bazel build //:foo को कॉल किया जाता है, तो इस बिल्ड के लिए //:foo टॉप-लेवल है और //:bar टॉप-लेवल नहीं है. हालांकि, दोनों टारगेट बनाने की ज़रूरत होगी. टॉप-लेवल और नॉन-टॉप-लेवल टारगेट के बीच
एक अहम अंतर यह है कि बेज़ल कमांड लाइन या
ट्रांज़िशन
कॉन्फ़िगरेशन की स्थिति को एक वैल्यू से दूसरी वैल्यू पर मैप करने. अलग-अलग कॉन्फ़िगरेशन के लिए, बिल्ड ग्राफ़ में टारगेट को चालू करता है, भले ही उन्हें उसी नियम से इंस्टैंशिएट किया गया हो. आम तौर पर, ट्रांज़िशन का इस्तेमाल स्प्लिट ट्रांज़िशन के साथ होता है. इसमें टारगेट ग्राफ़ के कुछ हिस्सों को अलग-अलग कॉन्फ़िगरेशन के साथ फ़ोर्क किया जाता है. उदाहरण के लिए, एक बिल्ड में ट्रांज़िशन का इस्तेमाल करके ARM और x86 के लिए कंपाइल की गई नेटिव बाइनरी वाला Android APK बनाया जा सकता है.
यह भी देखें: उपयोगकर्ता के तय किए गए ट्रांज़िशन
ट्री आर्टफ़ैक्ट
ऐसी आर्टफ़ैक्ट जो फ़ाइलों के कलेक्शन को दिखाती है. हालांकि, ये फ़ाइलें अपने-आप आर्टफ़ैक्ट नहीं हैं, लेकिन इन पर काम करने वाली किसी कार्रवाई के बजाय, ट्री आर्टफ़ैक्ट को अपने इनपुट या आउटपुट के तौर पर रजिस्टर करना चाहिए.
वीडियो के दिखने की स्थिति
बिल्ड सिस्टम में अनचाही डिपेंडेंसी रोकने के दो तरीकों में से एक:
टारगेट विज़िबिलिटी, यह कंट्रोल करती है कि कोई टारगेट दूसरे टारगेट पर निर्भर है या नहीं; और किसको दिखे, यह कंट्रोल करने के लिए कि BUILD या .bzl फ़ाइल दी गई .bzl फ़ाइल को लोड करे. संदर्भ के बिना, आम तौर पर
"किसको दिखे" का मतलब टारगेट विज़िबिलिटी से है.
यह भी देखें: वीडियो दिखने से जुड़े दस्तावेज़
फ़ाइल फ़ोल्डर
जिस डायरेक्ट्री में WORKSPACE फ़ाइल और सोर्स कोड को शामिल करना है
उस बनाने के लिए डायरेक्ट्री. // से शुरू होने वाले लेबल, फ़ाइल फ़ोल्डर की डायरेक्ट्री से मिलते-जुलते होते हैं.
WORKSPACE फ़ाइल
किसी डायरेक्ट्री के फ़ाइल फ़ोल्डर के बारे में बताता है. फ़ाइल खाली हो सकती है. हालांकि, इसमें नेटवर्क या लोकल फ़ाइल सिस्टम से अतिरिक्त डिपेंडेंसी पाने के लिए, डेटा स्टोर करने की बाहरी जगहों के एलान शामिल होते हैं.