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