कार्रवाई
बिल्ड के दौरान चलाने के लिए कोई कमांड. उदाहरण के लिए, कंपाइलर को कॉल करना. यह आर्टफ़ैक्ट को इनपुट के तौर पर लेता है और दूसरे आर्टफ़ैक्ट को आउटपुट के तौर पर जनरेट करता है. इसमें कमांड लाइन आर्ग्युमेंट, ऐक्शन की, एनवायरमेंट वैरिएबल, और इनपुट/आउटपुट आर्टफ़ैक्ट जैसे मेटाडेटा शामिल होते हैं.
यह भी देखें: नियमों से जुड़ा दस्तावेज़
ऐक्शन कैश
यह डिस्क पर मौजूद एक कैश मेमोरी होती है. इसमें, लागू की गई कार्रवाइयों को उनके बनाए गए आउटपुट से मैप किया जाता है. कैश मेमोरी की कुकी को ऐक्शन कुकी कहा जाता है. यह Bazel के इंक्रीमेंटैलिटी मॉडल का मुख्य कॉम्पोनेंट है. कैश को आउटपुट बेस डायरेक्ट्री में सेव किया जाता है. इसलिए, Bazel सर्वर को फिर से शुरू करने पर भी यह मौजूद रहती है.
ऐक्शन ग्राफ़
कार्रवाइयों और आर्टफ़ैक्ट का इन-मेमोरी ग्राफ़. ये कार्रवाइयां, इन आर्टफ़ैक्ट को पढ़ती हैं और जनरेट करती हैं. ग्राफ़ में ऐसे आर्टफ़ैक्ट शामिल हो सकते हैं जो सोर्स फ़ाइलों (उदाहरण के लिए, फ़ाइल सिस्टम में) के तौर पर मौजूद हैं. साथ ही, जनरेट किए गए इंटरमीडिएट/फ़ाइनल आर्टफ़ैक्ट भी शामिल हो सकते हैं जिनका ज़िक्र BUILD फ़ाइलों में नहीं किया गया है. इन्हें विश्लेषण के चरण के दौरान बनाया जाता है और लागू करने के चरण के दौरान इस्तेमाल किया जाता है.
ऐक्शन ग्राफ़ क्वेरी (aquery)
यह एक क्वेरी टूल है. इसकी मदद से, कार्रवाइयों के बारे में क्वेरी की जा सकती है. इससे यह विश्लेषण किया जा सकता है कि बिल्ड के नियम, बिल्ड के असल काम में कैसे बदलते हैं.
ऐक्शन बटन
किसी कार्रवाई की कैश मेमोरी की कुंजी. यह कार्रवाई के मेटाडेटा के आधार पर तय किया जाता है. इसमें कार्रवाई में लागू की जाने वाली कमांड, कंपाइलर फ़्लैग, लाइब्रेरी की जगहें या सिस्टम हेडर शामिल हो सकते हैं. यह कार्रवाई के हिसाब से तय होता है. इस कुकी की मदद से Bazel, अलग-अलग कार्रवाइयों को कैश मेमोरी में सेव कर पाता है या उन्हें हटा पाता है.
विश्लेषण का फ़ेज़
बिल्ड का दूसरा फ़ेज़. यह BUILD फ़ाइलों में दिए गए टारगेट ग्राफ़ को प्रोसेस करता है, ताकि मेमोरी में मौजूद ऐक्शन ग्राफ़ बनाया जा सके. इससे यह तय होता है कि एक्ज़ीक्यूशन फ़ेज़ के दौरान, कार्रवाइयां किस क्रम में की जाएंगी. इस फ़ेज़ में, नियमों को लागू करने के तरीके का आकलन किया जाता है.
सह-प्रॉडक्ट
सोर्स फ़ाइल या जनरेट की गई फ़ाइल. यह फ़ाइलों की डायरेक्ट्री भी हो सकती है. इसे ट्री आर्टफ़ैक्ट कहा जाता है.
कोई आर्टफ़ैक्ट, कई कार्रवाइयों के लिए इनपुट हो सकता है. हालांकि, इसे ज़्यादा से ज़्यादा एक कार्रवाई से जनरेट किया जाना चाहिए.
फ़ाइल टारगेट से जुड़े किसी आर्टफ़ैक्ट को लेबल किया जा सकता है.
आसपेक्ट
नियमों के लिए एक ऐसा तरीका जिससे वे अपनी डिपेंडेंसी में अतिरिक्त कार्रवाइयां कर सकें. उदाहरण के लिए, अगर टारगेट A, B पर निर्भर करता है, तो A पर एक ऐसा पहलू लागू किया जा सकता है जो निर्भरता वाले एज को ऊपर की ओर ले जाता है. साथ ही, अतिरिक्त आउटपुट फ़ाइलें जनरेट और इकट्ठा करने के लिए, B में अतिरिक्त कार्रवाइयां करता है. ये अतिरिक्त कार्रवाइयां कैश मेमोरी में सेव की जाती हैं. साथ ही, इनका इस्तेमाल उन टारगेट के बीच फिर से किया जाता है जिनके लिए एक ही पहलू की ज़रूरत होती है. इसे aspect() Starlark Build API फ़ंक्शन की मदद से बनाया गया है. इसका इस्तेमाल, उदाहरण के लिए, आईडीई के लिए मेटाडेटा जनरेट करने और लिंटिंग के लिए कार्रवाइयां बनाने के लिए किया जा सकता है.
यह भी देखें: पहलू से जुड़े दस्तावेज़
आस्पेक्ट-ऑन-आस्पेक्ट
यह कंपोज़िशन का एक ऐसा तरीका है जिसमें किसी पहलू के नतीजों पर दूसरे पहलू लागू किए जा सकते हैं. उदाहरण के लिए, आईडीई के इस्तेमाल के लिए जानकारी जनरेट करने वाले पहलू को, .java फ़ाइलें जनरेट करने वाले पहलू के ऊपर लागू किया जा सकता है.
A पहलू को B पहलू पर लागू करने के लिए, providers को provides एट्रिब्यूट में B का विज्ञापन दिखाना होगा. साथ ही, A को required_aspect_providers एट्रिब्यूट में यह एलान करना होगा कि उसे क्या चाहिए.
एट्रिब्यूट
यह नियम का एक पैरामीटर है. इसका इस्तेमाल, हर टारगेट के हिसाब से बिल्ड की जानकारी देने के लिए किया जाता है.
उदाहरण के लिए, srcs, deps, और copts. ये क्रमशः किसी टारगेट की सोर्स फ़ाइलें, डिपेंडेंसी, और कस्टम कंपाइलर विकल्प तय करते हैं. किसी टारगेट के लिए उपलब्ध एट्रिब्यूट, उसके नियम के टाइप पर निर्भर करते हैं.
.bazelrc
Bazel की कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल, स्टार्टअप फ़्लैग और कमांड फ़्लैग की डिफ़ॉल्ट वैल्यू बदलने के लिए किया जाता है. साथ ही, विकल्पों के सामान्य ग्रुप तय करने के लिए भी इसका इस्तेमाल किया जाता है. इन ग्रुप को बाद में, Bazel कमांड लाइन पर --config फ़्लैग का इस्तेमाल करके एक साथ सेट किया जा सकता है. Bazel, कई bazelrc फ़ाइलों (सिस्टम-वाइड, हर वर्कस्पेस, हर उपयोगकर्ता या कस्टम लोकेशन से) की सेटिंग को एक साथ इस्तेमाल कर सकता है. साथ ही, bazelrc फ़ाइल, अन्य bazelrc फ़ाइलों से भी सेटिंग इंपोर्ट कर सकती है.
Blaze
Bazel का 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 के अलग-अलग फ़ंक्शन को शुरू करने के लिए किया जाता है. जैसे, bazel
build, bazel test, bazel run, और bazel query.
कमांड फ़्लैग
किसी कमांड के लिए फ़्लैग का सेट. कमांड फ़्लैग, कमांड (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
ट्रांज़िटिव डिपेंडेंसी का डेटा इकट्ठा करने के लिए डेटा स्ट्रक्चर. इसे इस तरह से ऑप्टिमाइज़ किया गया है कि डिपसेट को मर्ज करने में कम समय लगे और कम जगह इस्तेमाल हो. ऐसा इसलिए, क्योंकि बहुत बड़े डिपसेट (लाखों फ़ाइलें) होना आम बात है. इसे इसलिए लागू किया गया है, ताकि स्पेस बचाने के लिए अन्य depsets को बार-बार रेफ़र किया जा सके. नियम लागू करने के दौरान, डिपसेट को सूचियों में बदलकर उन्हें "फ़्लैट" नहीं किया जाना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि नियम, बिल्ड ग्राफ़ के सबसे ऊपर न हो. बड़े डिपसेट को फ़्लैट करने पर, बहुत ज़्यादा मेमोरी खर्च होती है. Bazel के इंटरनल इंप्लीमेंटेशन में, इन्हें नेस्टेड सेट भी कहा जाता है.
यह भी देखें: Depset का दस्तावेज़
डिस्क की कैश मेमोरी
यह रिमोट कैश मेमोरी की सुविधा के लिए, डिस्क पर मौजूद लोकल ब्लॉब स्टोर है. इसका इस्तेमाल, रिमोट के असल डेटा स्टोर के साथ किया जा सकता है.
Distdir
यह सिर्फ़ पढ़ने के लिए उपलब्ध डायरेक्ट्री होती है. इसमें ऐसी फ़ाइलें होती हैं जिन्हें Bazel, इंटरनेट से फ़ेच करता है. इसके लिए, वह रिपॉज़िटरी के नियमों का इस्तेमाल करता है. इस विकल्प को चालू करने पर, बिल्ड पूरी तरह से ऑफ़लाइन मोड में चलाए जा सकते हैं.
डाइनैमिक एक्ज़ीक्यूशन
यह एक ऐसी रणनीति है जो अलग-अलग अनुमानित तरीकों के आधार पर, लोकल और रिमोट एक्ज़ीक्यूशन में से किसी एक को चुनती है. साथ ही, यह सबसे तेज़ तरीके से एक्ज़ीक्यूट होने वाले तरीके के नतीजों का इस्तेमाल करती है. कुछ कार्रवाइयां, स्थानीय तौर पर तेज़ी से पूरी होती हैं. जैसे, लिंक करना. वहीं, कुछ कार्रवाइयां रिमोट तौर पर तेज़ी से पूरी होती हैं. जैसे, ज़्यादा पैरलल किए जा सकने वाले कंपाइलेशन. डाइनैमिक एक्ज़ीक्यूशन की रणनीति से, सबसे कम समय में इंक्रीमेंटल और क्लीन बिल्ड तैयार किए जा सकते हैं.
एक्ज़ीक्यूशन फ़ेज़
बिल्ड का तीसरा चरण. यह कुकी, विश्लेषण के चरण के दौरान बनाए गए ऐक्शन ग्राफ़ में मौजूद ऐक्शन को लागू करती है. ये कार्रवाइयां, एक्ज़ीक्यूटेबल (कंपाइलर, स्क्रिप्ट) को आर्टफ़ैक्ट को पढ़ने और लिखने के लिए शुरू करती हैं. स्पॉन करने की रणनीतियों से यह कंट्रोल किया जाता है कि इन कार्रवाइयों को कैसे पूरा किया जाए: स्थानीय तौर पर, रिमोट से, डाइनैमिक तौर पर, सैंडबॉक्स में, डॉकर में वगैरह.
एक्ज़ीक्यूशन रूट
यह workspace की output base डायरेक्ट्री में मौजूद एक डायरेक्ट्री होती है. इसमें, नॉन-सैंडबॉक्स बिल्ड में लोकल कार्रवाइयां की जाती हैं. डायरेक्ट्री में मौजूद कॉन्टेंट, वर्कस्पेस से मिले इनपुट आर्टफ़ैक्ट के सिंबल वाले लिंक होते हैं. एक्ज़ीक्यूशन रूट में, अन्य इनपुट के तौर पर बाहरी रिपॉज़िटरी के सिमलिंक और आउटपुट सेव करने के लिए bazel-out डायरेक्ट्री भी होती है. इसे लोडिंग फ़ेज़ के दौरान तैयार किया जाता है. इसके लिए, उन डायरेक्ट्री का सिमलिंक फ़ॉरेस्ट बनाया जाता है जो उन पैकेज के ट्रांज़िटिव क्लोज़र को दिखाती हैं जिन पर कोई बिल्ड निर्भर करता है. कमांड लाइन पर bazel info
execution_root की मदद से ऐक्सेस किया जा सकता है.
फ़ाइल
आर्टफ़ैक्ट देखें.
Hermeticity
कोई बिल्ड हर्मेटिक तब होता है, जब उसके बिल्ड और टेस्ट ऑपरेशन पर किसी बाहरी चीज़ का असर न पड़े. इससे यह पक्का करने में मदद मिलती है कि नतीजे, तय किए गए हों और सही हों. उदाहरण के लिए, हर्मेटिक बिल्ड आम तौर पर कार्रवाइयों के लिए नेटवर्क ऐक्सेस की अनुमति नहीं देते हैं, एलान किए गए इनपुट के ऐक्सेस को सीमित करते हैं, तय किए गए टाइमस्टैंप और टाइमज़ोन का इस्तेमाल करते हैं, एनवायरमेंट वैरिएबल के ऐक्सेस को सीमित करते हैं, और रैंडम नंबर जनरेटर के लिए तय किए गए सीड का इस्तेमाल करते हैं
इंक्रीमेंटल बिल्ड
इंक्रीमेंटल बिल्ड, पहले के बिल्ड के नतीजों का फिर से इस्तेमाल करता है. इससे बिल्ड करने में लगने वाला समय और रिसोर्स का इस्तेमाल कम होता है. डिपेंडेंसी की जांच करने और कैश मेमोरी में सेव करने का मकसद, इस तरह के बिल्ड के लिए सही नतीजे जनरेट करना है. इंक्रीमेंटल बिल्ड, क्लीन बिल्ड से बिलकुल अलग होता है.
लेबल
टारगेट के लिए आइडेंटिफ़ायर. पूरी तरह से क्वालिफ़ाइड लेबल, जैसे कि
//path/to/package:target में // शामिल होता है. इसका इस्तेमाल वर्कस्पेस रूट
डायरेक्ट्री को मार्क करने के लिए किया जाता है. path/to/package, उस डायरेक्ट्री के तौर पर काम करता है जिसमें टारगेट का एलान करने वाली BUILD
फ़ाइल मौजूद होती है. साथ ही, :target, ऊपर बताई गई BUILD फ़ाइल में एलान किए गए टारगेट के नाम के तौर पर काम करता है. @my_repository//<..> प्रीफ़िक्स का इस्तेमाल करके यह भी बताया जा सकता है कि टारगेट को my_repository नाम की ]बाहरी रिपॉज़िटरी] में तय किया गया है.
लोडिंग फ़ेज़
यह बिल्ड का पहला चरण होता है. इसमें Bazel, WORKSPACE, BUILD, और .bzl
फ़ाइलों को पार्स करके पैकेज बनाता है. इस फ़ेज़ में, मैक्रो और glob() जैसे कुछ फ़ंक्शन का आकलन किया जाता है. टारगेट ग्राफ़ बनाने के लिए, विश्लेषण के चरण को बिल्ड के दूसरे चरण के साथ इंटरलीव किया जाता है.
मैक्रो
एक ऐसा तरीका जिससे कई rule टारगेट के एलान को एक साथ, एक Starlark फ़ंक्शन के तहत कंपोज़ किया जा सकता है. इस कुकी की मदद से, BUILD फ़ाइलों में सामान्य नियम के एलान वाले पैटर्न को फिर से इस्तेमाल किया जा सकता है. लोडिंग फ़ेज़ के दौरान, नियम के टारगेट के बारे में जानकारी देने के लिए इसका इस्तेमाल किया जाता है.
यह भी देखें: मैक्रो का दस्तावेज़
याद रखने का तरीका
यह एक छोटी स्ट्रिंग होती है, जिसे नियम बनाने वाला व्यक्ति चुनता है. इससे यह समझने में आसानी होती है कि नियम में कार्रवाई क्या कर रही है. इसे कोई भी व्यक्ति आसानी से पढ़ सकता है. निमोनिक का इस्तेमाल, स्पॉन रणनीति चुनने के लिए आइडेंटिफ़ायर के तौर पर किया जा सकता है. कार्रवाई के लिए इस्तेमाल होने वाले कुछ निमोनिक के उदाहरण यहां दिए गए हैं: Java के नियमों के लिए Javac, C++ के नियमों के लिए CppCompile, और Android के नियमों के लिए AndroidManifestMerger.
नेटिव नियम
नियम, Bazel में पहले से मौजूद होते हैं और Java में लागू किए जाते हैं. इस तरह के नियम, .bzl फ़ाइलों में नेटिव मॉड्यूल के फ़ंक्शन के तौर पर दिखते हैं. उदाहरण के लिए, native.cc_library या native.java_library. उपयोगकर्ता के तय किए गए नियम (नॉन-नेटिव) Starlark का इस्तेमाल करके बनाए जाते हैं.
आउटपुट बेस
Bazel की आउटपुट फ़ाइलों को सेव करने के लिए, वर्कस्पेस के हिसाब से डायरेक्ट्री. इस कुकी का इस्तेमाल, workspace के सोर्स ट्री से आउटपुट को अलग करने के लिए किया जाता है. यह output user root में मौजूद होता है.
आउटपुट ग्रुप
फ़ाइलों का ऐसा ग्रुप जिसे Bazel, टारगेट को बनाने के बाद बनाता है. नियमों के सामान्य आउटपुट, "डिफ़ॉल्ट आउटपुट ग्रुप" में रखे जाते हैं
(उदाहरण के लिए, cc_library टारगेट के लिए java_library, .a, और .so की .jar फ़ाइल). डिफ़ॉल्ट आउटपुट ग्रुप, वह आउटपुट ग्रुप होता है जिसके आर्टफ़ैक्ट तब बनाए जाते हैं, जब कमांड लाइन पर किसी टारगेट का अनुरोध किया जाता है.
नियमों में, नाम वाले ज़्यादा आउटपुट ग्रुप तय किए जा सकते हैं. इन्हें BUILD फ़ाइलों (filegroup नियम) या कमांड लाइन (--output_groups फ़्लैग) में साफ़ तौर पर बताया जा सकता है.
उपयोगकर्ता रूट को आउटपुट करें
यह उपयोगकर्ता के हिसाब से डायरेक्ट्री होती है. इसका इस्तेमाल Bazel के आउटपुट सेव करने के लिए किया जाता है. डायरेक्ट्री का नाम, उपयोगकर्ता के सिस्टम के उपयोगकर्ता नाम से लिया जाता है. अगर एक ही समय पर कई उपयोगकर्ता सिस्टम पर एक ही प्रोजेक्ट बना रहे हैं, तो यह कुकी आउटपुट फ़ाइल के टकराव को रोकती है. इसमें हर फ़ाइल फ़ोल्डर के बिल्ड आउटपुट से जुड़ी सबडायरेक्ट्री होती हैं. इन्हें आउटपुट बेस भी कहा जाता है.
पैकेज
BUILD फ़ाइल में तय किए गए टारगेट का सेट. किसी पैकेज का नाम, BUILD फ़ाइल का पाथ होता है. यह पाथ, Workspace के रूट के हिसाब से होता है. किसी पैकेज में सबपैकेज या 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 को नई प्रोग्रामिंग भाषाओं और एनवायरमेंट के साथ काम करने के लिए बढ़ाने का मुख्य तरीका है.
लोडिंग फ़ेज़ में, नियमों को इंस्टैंशिएट किया जाता है, ताकि नियम के टारगेट जनरेट किए जा सकें. विश्लेषण के चरण में, नियम के टारगेट, डाउनस्ट्रीम डिपेंडेंसी को प्रोवाइडर के तौर पर जानकारी देते हैं. साथ ही, ऐक्शन रजिस्टर करते हैं, जिनसे यह पता चलता है कि आउटपुट आर्टफ़ैक्ट कैसे जनरेट किए जाएं. ये कार्रवाइयां, एक्ज़ीक्यूशन फ़ेज़ में की जाती हैं.
यह भी देखें: नियमों से जुड़ा दस्तावेज़
नियम का टारगेट
ऐसा टारगेट जो किसी नियम का इंस्टेंस हो. यह फ़ाइल टारगेट और पैकेज ग्रुप से अलग होता है. इसे नियम से भ्रमित न हों.
Runfiles
किसी एक्ज़ीक्यूटेबल टारगेट की रनटाइम डिपेंडेंसी. आम तौर पर, एक्ज़ीक्यूटेबल, टेस्ट के नियम का एक्ज़ीक्यूटेबल आउटपुट होता है. साथ ही, रनफ़ाइलें, टेस्ट की रनटाइम डेटा डिपेंडेंसी होती हैं. Bazel, एक्ज़ीक्यूटेबल को शुरू करने से पहले (bazel test के दौरान), सोर्स डायरेक्ट्री स्ट्रक्चर के मुताबिक टेस्ट एक्ज़ीक्यूटेबल के साथ-साथ रनफ़ाइल का ट्री तैयार करता है.
यह भी देखें: रनफ़ाइल के बारे में जानकारी देने वाला दस्तावेज़
सैंडबॉक्सिंग
यह एक ऐसी तकनीक है जिसकी मदद से, किसी प्रतिबंधित और कुछ समय के लिए उपलब्ध एक्ज़ीक्यूशन रूट में चल रही कार्रवाई को अलग किया जाता है. इससे यह पक्का करने में मदद मिलती है कि यह कार्रवाई, बिना बताए गए इनपुट को न पढ़े या बिना बताए गए आउटपुट को न लिखे. सैंडबॉक्सिंग से हर्मेटिसिटी में काफ़ी सुधार होता है. हालांकि, आम तौर पर इससे परफ़ॉर्मेंस पर असर पड़ता है. साथ ही, इसके लिए ऑपरेटिंग सिस्टम से सहायता की ज़रूरत होती है. परफ़ॉर्मेंस मॉनिटरिंग की लागत, प्लैटफ़ॉर्म के हिसाब से अलग-अलग होती है. Linux पर, इससे कोई खास फ़र्क़ नहीं पड़ता. हालांकि, macOS पर सैंडबॉक्सिंग का इस्तेमाल नहीं किया जा सकता.
Skyframe
Skyframe, Bazel का मुख्य पैरलल, फ़ंक्शनल, और इंक्रीमेंटल इवैल्यूएशन फ़्रेमवर्क है.
छपाई का काम
यह सुविधा, Bazel की मदद से बनाए गए आर्टफ़ैक्ट में अतिरिक्त जानकारी एम्बेड करने के लिए है. उदाहरण के लिए, इसका इस्तेमाल सोर्स कंट्रोल, बिल्ड टाइम, और रिलीज़ बिल्ड के लिए वर्कस्पेस या एनवायरमेंट से जुड़ी अन्य जानकारी के लिए किया जा सकता है.
--workspace_status_command फ़्लैग और नियमों के ज़रिए चालू करें. ये नियम, स्टैंप एट्रिब्यूट के साथ काम करते हैं.
Starlark
नियम और मैक्रो लिखने के लिए एक्सटेंशन की भाषा. यह Python का एक सीमित सबसेट है. इसका इस्तेमाल कॉन्फ़िगरेशन और बेहतर परफ़ॉर्मेंस के लिए किया जाता है. इसमें सिंटैक्टिक और व्याकरण के नियमों का पालन किया जाता है. .bzl
फ़ाइल एक्सटेंशन का इस्तेमाल करता है. BUILD फ़ाइलें, Starlark के ज़्यादा पाबंदियों वाले वर्शन का इस्तेमाल करती हैं. जैसे, def फ़ंक्शन की परिभाषाएं नहीं होती हैं. इसे पहले Skylark के नाम से जाना जाता था.
यह भी देखें: Starlark भाषा का दस्तावेज़
स्टार्टअप फ़्लैग
bazel और command के बीच तय किए गए फ़्लैग का सेट. उदाहरण के लिए, bazel --host_jvm_debug build. इन फ़्लैग से, Bazel सर्वर के कॉन्फ़िगरेशन में बदलाव होता है. इसलिए, स्टार्टअप फ़्लैग में किसी भी तरह का बदलाव करने पर, सर्वर रीस्टार्ट हो जाता है. स्टार्टअप फ़्लैग, किसी भी कमांड के लिए खास नहीं होते.
टारगेट
यह एक ऐसा ऑब्जेक्ट होता है जिसे BUILD फ़ाइल में तय किया जाता है और जिसकी पहचान label से होती है. टारगेट, असली उपयोगकर्ता के नज़रिए से वर्कस्पेस की ऐसी यूनिट को कहते हैं जिन्हें बनाया जा सकता है.
नियम को इंस्टैंटिएट करके तय किए गए टारगेट को नियम टारगेट कहा जाता है. नियम के हिसाब से, ये रन किए जा सकते हैं (जैसे, cc_binary) या इनकी जांच की जा सकती है (जैसे, cc_test). नियम के टारगेट आम तौर पर, एट्रिब्यूट (जैसे, deps) के ज़रिए अन्य टारगेट पर निर्भर करते हैं. ये निर्भरताएं, टारगेट ग्राफ़ का आधार बनती हैं.
नियम के टारगेट के अलावा, फ़ाइल टारगेट और पैकेज ग्रुप टारगेट भी होते हैं. फ़ाइल टारगेट, उन आर्टफ़ैक्ट से मेल खाते हैं जिनका रेफ़रंस, BUILD फ़ाइल में दिया गया है. खास मामले के तौर पर, किसी भी पैकेज की BUILD फ़ाइल को हमेशा उस पैकेज में सोर्स फ़ाइल टारगेट माना जाता है.
लोडिंग फ़ेज़ के दौरान टारगेट का पता चलता है. विश्लेषण के चरण के दौरान, टारगेट को बिल्ड कॉन्फ़िगरेशन से जोड़ा जाता है, ताकि कॉन्फ़िगर किए गए टारगेट बनाए जा सकें.
टारगेट ग्राफ़
टारगेट और उनकी डिपेंडेंसी का इन-मेमोरी ग्राफ़. यह लोडिंग फ़ेज़ के दौरान जनरेट होता है और इसका इस्तेमाल विश्लेषण फ़ेज़ के इनपुट के तौर पर किया जाता है.
टारगेट पैटर्न
कमांड लाइन पर टारगेट के ग्रुप को तय करने का तरीका. आम तौर पर इस्तेमाल किए जाने वाले पैटर्न ये हैं: :all (नियम के सभी टारगेट), :* (नियम और फ़ाइल के सभी टारगेट), ... (मौजूदा पैकेज और सभी सबपैकेज). इनका एक साथ इस्तेमाल किया जा सकता है. उदाहरण के लिए, //...:* का मतलब है कि workspace के रूट से सभी पैकेज में, सभी नियमों और फ़ाइल टारगेट को बार-बार शामिल किया जाता है.
जांच
नियम टारगेट, जांच के नियमों से इंस्टैंटिएट किए जाते हैं. इसलिए, इसमें जांच के लिए इस्तेमाल किया जा सकने वाला प्रोग्राम शामिल होता है. एक्ज़ीक्यूटेबल के पूरा होने पर, शून्य का रिटर्न कोड मिलने का मतलब है कि टेस्ट सफल रहा. Bazel और टेस्ट के बीच कानूनी समझौते (जैसे, टेस्ट एनवायरमेंट वैरिएबल, टेस्ट के नतीजे इकट्ठा करने के तरीके) के बारे में टेस्ट एनसाइक्लोपीडिया में बताया गया है.
टूलचेन
किसी भाषा के लिए आउटपुट जनरेट करने वाले टूल का सेट. आम तौर पर, टूलचेन में कंपाइलर, लिंकर, इंटरप्रेटर या/और लिंटर शामिल होते हैं. टूलचेन, प्लैटफ़ॉर्म के हिसाब से भी अलग-अलग हो सकती है. इसका मतलब है कि Unix कंपाइलर टूलचेन के कॉम्पोनेंट, Windows वर्शन के लिए अलग-अलग हो सकते हैं. भले ही, टूलचेन एक ही भाषा के लिए हो. प्लैटफ़ॉर्म के लिए सही टूलचेन चुनने की प्रोसेस को टूलचेन रिज़ॉल्यूशन कहा जाता है.
टॉप-लेवल का टारगेट
अगर Bazel कमांड लाइन पर किसी टारगेट का अनुरोध किया जाता है, तो उसे टॉप-लेवल का टारगेट माना जाता है. उदाहरण के लिए, अगर //:foo, //:bar पर निर्भर करता है और bazel build //:foo को कॉल किया जाता है, तो इस बिल्ड के लिए //:foo टॉप-लेवल का है और //:bar टॉप-लेवल का नहीं है. हालांकि, दोनों टारगेट को बिल्ड करना होगा. टॉप-लेवल और नॉन-टॉप-लेवल टारगेट के बीच एक अहम अंतर यह है कि Bazel कमांड लाइन पर (या .bazelrc के ज़रिए) सेट किए गए कमांड फ़्लैग, टॉप-लेवल टारगेट के लिए कॉन्फ़िगरेशन सेट करेंगे. हालांकि, नॉन-टॉप-लेवल टारगेट के लिए, इन्हें ट्रांज़िशन से बदला जा सकता है.
ट्रांज़िशन
configuration की स्थिति को एक वैल्यू से दूसरी वैल्यू पर मैप करना. इस विकल्प को चालू करने पर, बिल्ड ग्राफ़ में मौजूद टारगेट के अलग-अलग कॉन्फ़िगरेशन हो सकते हैं. भले ही, उन्हें एक ही नियम से इंस्टैंशिएट किया गया हो. ट्रांज़िशन का इस्तेमाल आम तौर पर स्प्लिट ट्रांज़िशन के साथ किया जाता है. इसमें टारगेट ग्राफ़ के कुछ हिस्सों को अलग-अलग कॉन्फ़िगरेशन के साथ फ़ोर्क किया जाता है. उदाहरण के लिए, एक ही बिल्ड में स्प्लिट ट्रांज़िशन का इस्तेमाल करके, ARM और x86 के लिए कंपाइल किए गए नेटिव बाइनरी के साथ Android APK बनाया जा सकता है.
यह भी देखें: उपयोगकर्ता के तय किए गए ट्रांज़िशन
ट्री आर्टफ़ैक्ट
आर्टफ़ैक्ट, फ़ाइलों के कलेक्शन को दिखाता है. ये फ़ाइलें, खुद आर्टफ़ैक्ट नहीं हैं. इसलिए, इन पर काम करने वाले ऐक्शन को ट्री आर्टफ़ैक्ट को अपने इनपुट या आउटपुट के तौर पर रजिस्टर करना होगा.
किसको दिखे
बिल्ड सिस्टम में अवांछित डिपेंडेंसी को रोकने के लिए, दो में से एक तरीका:
टारगेट की विज़िबिलिटी, यह कंट्रोल करने के लिए कि क्या कोई टारगेट अन्य टारगेट पर निर्भर हो सकता है; और लोड विज़िबिलिटी, यह कंट्रोल करने के लिए कि क्या कोई BUILD या .bzl फ़ाइल, दी गई .bzl फ़ाइल को लोड कर सकती है. कॉन्टेक्स्ट के बिना, आम तौर पर "दिखने की स्थिति" का मतलब टारगेट दिखने की स्थिति से होता है.
यह भी देखें: 'किसको दिखे' सेटिंग से जुड़ा दस्तावेज़
Workspace
एक डायरेक्ट्री, जिसमें WORKSPACE फ़ाइल और उस सॉफ़्टवेयर का सोर्स कोड शामिल हो जिसे आपको बनाना है. // से शुरू होने वाले लेबल, वर्कस्पेस डायरेक्ट्री से जुड़े होते हैं.
WORKSPACE फ़ाइल
यह किसी डायरेक्ट्री को वर्कस्पेस के तौर पर तय करता है. फ़ाइल खाली हो सकती है. हालांकि, इसमें आम तौर पर बाहरी रिपॉज़िटरी के एलान शामिल होते हैं, ताकि नेटवर्क या लोकल फ़ाइल सिस्टम से अतिरिक्त डिपेंडेंसी फ़ेच की जा सकें.