बेज़ेल ग्लॉसरी

कार्रवाई

बिल्ड के दौरान चलाने के लिए कोई कमांड. उदाहरण के लिए, कंपाइलर को कॉल करना. यह artifacts को इनपुट के तौर पर लेता है और अन्य आर्टफ़ैक्ट को आउटपुट के तौर पर जनरेट करता है. इसमें कमांड लाइन आर्ग्युमेंट, ऐक्शन की, एनवायरमेंट वैरिएबल, और एलान किए गए इनपुट/आउटपुट आर्टफ़ैक्ट जैसे मेटाडेटा शामिल होते हैं.

यह भी देखें: नियमों से जुड़ा दस्तावेज़

ऐक्शन कैश

यह डिस्क पर मौजूद एक ऐसी कैश मेमोरी होती है जो एक्ज़ीक्यूट किए गए ऐक्शन को उनके बनाए गए आउटपुट से मैप करती है. कैश मेमोरी की कुंजी को ऐक्शन की कहा जाता है. यह Bazel के इंक्रीमेंटैलिटी मॉडल का एक मुख्य कॉम्पोनेंट है. कैश को आउटपुट बेस डायरेक्ट्री में सेव किया जाता है. इसलिए, Bazel सर्वर को फिर से चालू करने पर भी यह मौजूद रहती है.

ऐक्शन ग्राफ़

यह कार्रवाइयों और उन आर्टफ़ैक्ट का इन-मेमोरी ग्राफ़ होता है जिन्हें ये कार्रवाइयां पढ़ती हैं और जनरेट करती हैं. ग्राफ़ में ऐसे आर्टफ़ैक्ट शामिल हो सकते हैं जो सोर्स फ़ाइलों (उदाहरण के लिए, फ़ाइल सिस्टम में) के तौर पर मौजूद हैं. साथ ही, जनरेट किए गए इंटरमीडिएट/फ़ाइनल आर्टफ़ैक्ट भी शामिल हो सकते हैं जिनका ज़िक्र BUILD फ़ाइलों में नहीं किया गया है. इन्हें विश्लेषण के चरण के दौरान बनाया जाता है और लागू करने के चरण के दौरान इस्तेमाल किया जाता है.

ऐक्शन ग्राफ़ क्वेरी (aquery)

यह एक क्वेरी टूल है, जो बिल्ड कार्रवाइयों के बारे में क्वेरी कर सकता है. इससे यह विश्लेषण किया जा सकता है कि बिल्ड के नियम, बिल्ड के असल काम में कैसे बदलते हैं.

ऐक्शन बटन

किसी ऐक्शन की कैश मेमोरी की कुंजी. यह कार्रवाई के मेटाडेटा के आधार पर कैलकुलेट किया जाता है. इसमें कार्रवाई में लागू की जाने वाली कमांड, कंपाइलर फ़्लैग, लाइब्रेरी की जगहें या सिस्टम हेडर शामिल हो सकते हैं. यह कार्रवाई के हिसाब से तय होता है. इस कुकी की मदद से Bazel, अलग-अलग कार्रवाइयों को कैश मेमोरी में सेव कर पाता है या उन्हें अमान्य कर पाता है.

विश्लेषण का फ़ेज़

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

सह-प्रॉडक्ट

सोर्स फ़ाइल या जनरेट की गई फ़ाइल. यह फ़ाइलों की डायरेक्ट्री भी हो सकती है. इसे ट्री आर्टफ़ैक्ट कहा जाता है.

कोई आर्टफ़ैक्ट, कई कार्रवाइयों के लिए इनपुट हो सकता है. हालांकि, इसे ज़्यादा से ज़्यादा एक कार्रवाई से जनरेट किया जाना चाहिए.

फ़ाइल टारगेट से जुड़े किसी आर्टफ़ैक्ट को लेबल से ऐक्सेस किया जा सकता है.

आसपेक्ट

नियमों के लिए एक ऐसा तरीका जिससे वे अपनी डिपेंडेंसी में अतिरिक्त कार्रवाइयां कर सकें. उदाहरण के लिए, अगर टारगेट A, B पर निर्भर करता है, तो A पर एक ऐसा पहलू लागू किया जा सकता है जो निर्भरता वाले एज को ऊपर की ओर ले जाता है. साथ ही, B में अतिरिक्त कार्रवाइयां करता है, ताकि अतिरिक्त आउटपुट फ़ाइलें जनरेट और इकट्ठा की जा सकें. ये अतिरिक्त कार्रवाइयां, कैश मेमोरी में सेव की जाती हैं. साथ ही, इनका इस्तेमाल उन टारगेट के बीच फिर से किया जाता है जिनके लिए एक ही पहलू की ज़रूरत होती है. इसे aspect() Starlark Build API फ़ंक्शन की मदद से बनाया गया है. इसका इस्तेमाल, उदाहरण के लिए, आईडीई के लिए मेटाडेटा जनरेट करने और लिंटिंग के लिए कार्रवाइयां बनाने के लिए किया जा सकता है.

यह भी देखें: Aspects का दस्तावेज़

आसपेक्ट-ऑन-आसपेक्ट

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

इसका इस्तेमाल हमेशा bazel <startup flags> command <command flags> -- <command arguments> होता है. इसका एक सामान्य उदाहरण bazel --host_jvm_args=-Xmx512M test --compilation_mode=dbg --test_output=errors -- //test:target1 //test:target2 //test/local/... होगा.

ग्राफ़ बनाना

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

बिल्ड सेटिंग

Starlark में तय किया गया कॉन्फ़िगरेशन. Transitions, सबग्राफ़ के कॉन्फ़िगरेशन में बदलाव करने के लिए, बिल्ड सेटिंग सेट कर सकते हैं. अगर उपयोगकर्ता को कमांड-लाइन फ़्लैग के तौर पर दिखाया जाता है, तो इसे बिल्ड फ़्लैग भी कहा जाता है.

क्लीन बिल्ड

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

कॉन्फ़िगरेशन

नियम की परिभाषाओं के अलावा ऐसी जानकारी जिससे नियमों के कार्रवाइयों को जनरेट करने के तरीके पर असर पड़ता है. हर बिल्ड में कम से कम एक कॉन्फ़िगरेशन होता है. इसमें टारगेट प्लैटफ़ॉर्म, ऐक्शन एनवायरमेंट वैरिएबल, और कमांड-लाइन बिल्ड फ़्लैग के बारे में जानकारी होती है. ट्रांज़िशन से अतिरिक्त कॉन्फ़िगरेशन बनाए जा सकते हैं. जैसे, होस्ट टूल या क्रॉस-कंपाइलेशन के लिए.

कॉन्फ़िगरेशन में एक या उससे ज़्यादा कॉन्फ़िगरेशन फ़्रैगमेंट होते हैं. साथ ही, इसमें सेट किए गए सभी Starlark फ़्लैग अलग से शामिल होते हैं.

यह भी देखें: कॉन्फ़िगरेशन

कॉन्फ़िगरेशन फ़्रैगमेंट

फ़्रैगमेंट, बिल्ट-इन कॉन्फ़िगरेशन के हिस्से होते हैं. कॉन्फ़िगरेशन फ़्रैगमेंट की मदद से, नियमों को कॉन्फ़िगरेशन के भाषा के हिसाब से तय किए गए हिस्सों को ऐक्सेस करने की अनुमति मिलती है. बिल्ट-इन फ़्लैग को मिलते-जुलते फ़्रैगमेंट में ग्रुप किया जाता है. जैसे, टेस्ट फ़्लैग, प्लैटफ़ॉर्म फ़्लैग, रिमोट एक्ज़ीक्यूशन फ़्लैग वगैरह. कुछ फ़्रैगमेंट, Starlark नियमों के हिसाब से तय किए जाते हैं.

Starlark फ़्लैग, कॉन्फ़िगरेशन फ़्रैगमेंट का हिस्सा नहीं होते हैं. इन्हें सीधे तौर पर प्रोवाइडर का इस्तेमाल करके ऐक्सेस किया जाता है.

कॉन्फ़िगरेशन ट्रिम करना

कॉन्फ़िगरेशन के सिर्फ़ उन हिस्सों को शामिल करने की प्रोसेस जिनकी किसी टारगेट को असल में ज़रूरत होती है. उदाहरण के लिए, अगर आपको 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 डायरेक्ट्री में मौजूद एक डायरेक्ट्री होती है. इसमें लोकल actions को नॉन-sandboxed बिल्ड में एक्ज़ीक्यूट किया जाता है. डायरेक्ट्री में मौजूद कॉन्टेंट, वर्कस्पेस से मिले इनपुट आर्टफ़ैक्ट के ज़्यादातर सिंबल लिंक होते हैं. एक्ज़ीक्यूशन रूट में, अन्य इनपुट के तौर पर बाहरी रिपॉज़िटरी के सिमलिंक और आउटपुट सेव करने के लिए bazel-out डायरेक्ट्री भी होती है. इसे लोडिंग फ़ेज़ के दौरान तैयार किया जाता है. इसके लिए, उन डायरेक्ट्री का सिमलिंक फ़ॉरेस्ट बनाया जाता है जो उन पैकेज के ट्रांज़िटिव क्लोज़र को दिखाती हैं जिन पर कोई बिल्ड निर्भर करता है. कमांड लाइन पर bazel info execution_root की मदद से ऐक्सेस किया जा सकता है.

फ़ाइल

आर्टफ़ैक्ट देखें.

Hermeticity

कोई बिल्ड हर्मेटिक तब होता है, जब उसके बिल्ड और टेस्ट ऑपरेशन पर किसी बाहरी चीज़ का असर न पड़े. इससे यह पक्का करने में मदद मिलती है कि नतीजे, तय किए गए हों और सही हों. उदाहरण के लिए, हर्मेटिक बिल्ड आम तौर पर कार्रवाइयों के लिए नेटवर्क ऐक्सेस की अनुमति नहीं देते हैं, घोषित किए गए इनपुट के ऐक्सेस को सीमित करते हैं, तय किए गए टाइमस्टैंप और टाइमज़ोन का इस्तेमाल करते हैं, एनवायरमेंट वैरिएबल के ऐक्सेस को सीमित करते हैं, और रैंडम नंबर जनरेटर के लिए तय किए गए सीड का इस्तेमाल करते हैं

इंक्रीमेंटल बिल्ड

इंक्रीमेंटल बिल्ड, पहले के बिल्ड के नतीजों का फिर से इस्तेमाल करता है, ताकि बिल्ड करने में लगने वाला समय और रिसॉर्स का इस्तेमाल कम किया जा सके. डिपेंडेंसी की जांच करने और कैश मेमोरी में सेव करने का मकसद, इस तरह के बिल्ड के लिए सही नतीजे जनरेट करना है. इंक्रीमेंटल बिल्ड, क्लीन बिल्ड से बिलकुल उलट होता है.

Android SDK के इंस्टॉल की संख्या/ सक्रिय उपयोगकर्ता

यह वह जगह है जहां Bazel, बाइनरी के तौर पर डिलीवर किए गए ज़रूरी टूल को अनपैक करता है.

bazel info install_base का इस्तेमाल करके, इंस्टॉल किए गए ऐप्लिकेशन की संख्या देखी जा सकती है.

लेबल

टारगेट के लिए आइडेंटिफ़ायर. आम तौर पर, इसका फ़ॉर्म @repo//path/to/package:target होता है. इसमें repo, टारगेट को शामिल करने वाले रिपॉज़िटरी का (ज़ाहिर तौर पर) नाम होता है. path/to/package, उस डायरेक्ट्री का पाथ होता है जिसमें टारगेट का एलान करने वाली BUILD फ़ाइल शामिल होती है. इस डायरेक्ट्री को पैकेज भी कहा जाता है. साथ ही, target, टारगेट का नाम होता है. स्थिति के हिसाब से, इस सिंटैक्स के कुछ हिस्सों को शामिल नहीं किया जा सकता.

यह भी देखें: लेबल

लोडिंग फ़ेज़

यह बिल्ड का पहला फ़ेज़ होता है. इसमें Bazel, BUILD फ़ाइलों को एक्ज़ीक्यूट करके पैकेज बनाता है. इस फ़ेज़ में, मैक्रो और glob() जैसे कुछ फ़ंक्शन का आकलन किया जाता है. विश्लेषण के चरण में, बिल्ड के दूसरे चरण के साथ इंटरलीव किया जाता है, ताकि टारगेट ग्राफ़ बनाया जा सके.

लेगसी मैक्रो

यह मैक्रो का एक टाइप है. इसे सामान्य Starlark फ़ंक्शन के तौर पर एलान किया जाता है. साथ ही, यह BUILD फ़ाइल को एक्ज़ीक्यूट करने के साइड इफ़ेक्ट के तौर पर चलता है.

लेगसी मैक्रो, फ़ंक्शन के तौर पर काम कर सकते हैं. इसका मतलब है कि ये सुविधाजनक हो सकते हैं. हालांकि, इन्हें पढ़ना, लिखना, और इस्तेमाल करना मुश्किल भी हो सकता है. ऐसा हो सकता है कि लेगसी मैक्रो, अपने तर्कों में अचानक बदलाव कर दे या select() या गलत टाइप वाला तर्क दिए जाने पर काम न करे.

सिंबॉलिक मैक्रो से तुलना करें.

यह भी देखें: लेगसी मैक्रो का दस्तावेज़

मैक्रो

यह एक ऐसा तरीका है जिससे कई नियम टारगेट के एलान को एक साथ, एक Starlark कॉल करने लायक फ़ंक्शन के तहत कंपोज़ किया जा सकता है. इस कुकी की मदद से, BUILD फ़ाइलों में सामान्य नियम के एलान वाले पैटर्न को फिर से इस्तेमाल किया जा सकता है. लोडिंग फ़ेज़ के दौरान, टारगेट करने के लिए इस्तेमाल किए गए नियम की जानकारी को बढ़ाया जाता है.

यह दो तरह की होती है: सिंबॉलिक मैक्रोज़ (Bazel 8 के बाद से) और लेगसी मैक्रोज़.

याद रखने का तरीका

यह एक छोटी स्ट्रिंग होती है, जिसे नियम बनाने वाला व्यक्ति चुनता है. इससे यह समझने में आसानी होती है कि नियम में कार्रवाई क्या कर रही है. निमोनिक का इस्तेमाल, स्पॉन रणनीति चुनने के लिए आइडेंटिफ़ायर के तौर पर किया जा सकता है. कार्रवाई के लिए इस्तेमाल होने वाले कुछ निमोनिक के उदाहरण यहां दिए गए हैं: Java के नियमों के लिए Javac, C++ के नियमों के लिए CppCompile, और Android के नियमों के लिए AndroidManifestMerger.

मॉड्यूल

Bazel प्रोजेक्ट, जिसके कई वर्शन हो सकते हैं. इनमें से हर वर्शन, अन्य मॉड्यूल पर निर्भर हो सकता है. यह अन्य डिपेंडेंसी मैनेजमेंट सिस्टम में मौजूद जाने-पहचाने कॉन्सेप्ट के जैसा ही है. जैसे, Maven आर्टफ़ैक्ट, npm पैकेज, Go मॉड्यूल या Cargo क्रेट. मॉड्यूल, Bazel के बाहरी डिपेंडेंसी मैनेजमेंट सिस्टम का मुख्य हिस्सा होते हैं.

हर मॉड्यूल के साथ एक repo जुड़ा होता है. इसके रूट में एक MODULE.bazel फ़ाइल होती है. इस फ़ाइल में, मॉड्यूल के बारे में मेटाडेटा होता है. जैसे, इसका नाम और वर्शन. इसमें इसकी सीधी डिपेंडेंसी और टूलचेन रजिस्ट्रेशन और मॉड्यूल एक्सटेंशन इनपुट सहित कई अन्य डेटा भी शामिल होता है.

मॉड्यूल का मेटाडेटा, Bazel की रजिस्ट्री में होस्ट किया जाता है.

यह भी देखें: Bazel मॉड्यूल

मॉड्यूल एक्सटेंशन

यह एक लॉजिक है, जिसे मॉड्यूल डिपेंडेंसी ग्राफ़ से इनपुट पढ़कर और repo के नियमों को लागू करके, repos जनरेट करने के लिए चलाया जा सकता है. मॉड्यूल एक्सटेंशन में repo rules जैसी सुविधाएं होती हैं. इनकी मदद से, इंटरनेट ऐक्सेस किया जा सकता है, फ़ाइल I/O किया जा सकता है वगैरह.

यह भी देखें: मॉड्यूल एक्सटेंशन

नेटिव नियम

नियम, Bazel में बनाए जाते हैं और Java में लागू किए जाते हैं. इस तरह के नियम, .bzl फ़ाइलों में नेटिव मॉड्यूल के फ़ंक्शन के तौर पर दिखते हैं. उदाहरण के लिए, native.cc_library या native.java_library. उपयोगकर्ता के तय किए गए नियम (नॉन-नेटिव) Starlark का इस्तेमाल करके बनाए जाते हैं.

आउटपुट बेस

Bazel की आउटपुट फ़ाइलों को सेव करने के लिए, वर्कस्पेस के हिसाब से डायरेक्ट्री. इस कुकी का इस्तेमाल, वर्कस्पेस के सोर्स ट्री (मुख्य रिपो) से आउटपुट को अलग करने के लिए किया जाता है. यह output user root में मौजूद होता है.

आउटपुट ग्रुप

फ़ाइलों का ऐसा ग्रुप जिसे Bazel, टारगेट बनाने के बाद बनाता है. नियम, अपने सामान्य आउटपुट को "डिफ़ॉल्ट आउटपुट ग्रुप" में रखते हैं (उदाहरण के लिए, java_library की .jar फ़ाइल, cc_library टारगेट के लिए .a और .so). डिफ़ॉल्ट आउटपुट ग्रुप, वह आउटपुट ग्रुप होता है जिसके आर्टफ़ैक्ट तब बनाए जाते हैं, जब कमांड लाइन पर किसी टारगेट का अनुरोध किया जाता है. नियमों में, नाम वाले ज़्यादा आउटपुट ग्रुप तय किए जा सकते हैं. इन्हें BUILD फ़ाइलों (filegroup नियम) या कमांड लाइन (--output_groups फ़्लैग) में साफ़ तौर पर बताया जा सकता है.

उपयोगकर्ता रूट को आउटपुट करें

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

पैकेज

BUILD फ़ाइल से तय किए गए टारगेट का सेट. पैकेज का नाम, repo रूट के हिसाब से BUILD फ़ाइल का पाथ होता है. किसी पैकेज में सबपैकेज या BUILD फ़ाइलें शामिल हो सकती हैं. इस तरह, पैकेज का क्रम बनता है.

पैकेज ग्रुप

टारगेट, पैकेज के सेट को दिखाता है. इसका इस्तेमाल अक्सर visibility एट्रिब्यूट की वैल्यू में किया जाता है.

प्लैटफ़ॉर्म

बिल्ड में शामिल "मशीन टाइप". इसमें Bazel को चलाने वाली मशीन ("होस्ट" प्लैटफ़ॉर्म), बिल्ड टूल को चलाने वाली मशीनें ("exec" प्लैटफ़ॉर्म), और टारगेट के लिए बिल्ड की गई मशीनें ("टारगेट प्लैटफ़ॉर्म") शामिल हैं.

सेवा देने वाली कंपनी

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

यह भी देखें: सेवा देने वाली कंपनी का दस्तावेज़

क्वेरी (कॉन्सेप्ट)

बिल्ड ग्राफ़ का विश्लेषण करने की प्रोसेस, ताकि टारगेट प्रॉपर्टी और डिपेंडेंसी स्ट्रक्चर को समझा जा सके. Bazel, क्वेरी के तीन वर्शन के साथ काम करता है: query, cquery, और aquery.

क्वेरी (कमांड)

यह एक क्वेरी टूल है. यह बिल्ड के लोडिंग के बाद के फ़ेज़ के टारगेट ग्राफ़ पर काम करता है. यह प्रोसेस काफ़ी तेज़ होती है. हालांकि, इससे select(), बिल्ड फ़्लैग, आर्टफ़ैक्ट या बिल्ड ऐक्शन के असर का विश्लेषण नहीं किया जा सकता.

यह भी देखें: क्वेरी करने का तरीका, क्वेरी का रेफ़रंस

रिपॉज़िटरी

एक डायरेक्ट्री ट्री, जिसकी रूट डायरेक्ट्री में बाउंड्री मार्कर फ़ाइल होती है. इसमें ऐसी सोर्स फ़ाइलें होती हैं जिनका इस्तेमाल Bazel बिल्ड में किया जा सकता है. इसे अक्सर छोटा करके सिर्फ़ repo कहा जाता है.

रेपो बाउंड्री मार्कर फ़ाइल MODULE.bazel (यह सिग्नल देती है कि यह रेपो, Bazel मॉड्यूल को दिखाता है), REPO.bazel या लेगसी कॉन्टेक्स्ट में WORKSPACE या WORKSPACE.bazel हो सकती है. किसी भी repo boundary marker फ़ाइल से, repo की सीमा का पता चलेगा. ऐसी कई फ़ाइलें, किसी डायरेक्ट्री में एक साथ मौजूद हो सकती हैं.

मुख्य रेपो वह रेपो होती है जिसमें मौजूदा Bazel कमांड चलाई जा रही है.

बाहरी रेपो को MODULE.bazel फ़ाइलों में मॉड्यूल तय करके या मॉड्यूल एक्सटेंशन में रेपो के नियमों को लागू करके तय किया जाता है. इन्हें डिस्क पर पहले से तय की गई "मैजिकल" जगह पर, ज़रूरत के हिसाब से फ़ेच किया जा सकता है.

हर रिपॉज़िटरी का एक यूनीक और स्थायी कैननिकल नाम होता है. साथ ही, दूसरी रिपॉज़िटरी से देखने पर, उसके दिखने वाले नाम अलग-अलग हो सकते हैं.

यह भी देखें: बाहरी डिपेंडेंसी के बारे में खास जानकारी

डेटाबेस की कैश मेमोरी

यह एक शेयर की गई, कॉन्टेंट के हिसाब से पता लगाने वाली कैश मेमोरी होती है. इसमें Bazel की मदद से डाउनलोड की गई फ़ाइलें होती हैं. इन फ़ाइलों का इस्तेमाल बिल्ड के लिए किया जाता है. साथ ही, इन्हें वर्कस्पेस के साथ शेयर किया जा सकता है. यह शुरुआती डाउनलोड के बाद, ऑफ़लाइन बिल्ड की सुविधा चालू करता है. इसका इस्तेमाल आम तौर पर, repository rules के ज़रिए डाउनलोड की गई फ़ाइलों को कैश मेमोरी में सेव करने के लिए किया जाता है. जैसे, http_archive और repository rule API, जैसे कि repository_ctx.download. फ़ाइलों को सिर्फ़ तब कैश मेमोरी में सेव किया जाता है, जब डाउनलोड करने के लिए उनके SHA-256 चेकसम दिए गए हों.

रिपॉज़िटरी का नियम

यह रिपॉज़िटरी की परिभाषाओं के लिए एक स्कीमा है. इससे Bazel को यह पता चलता है कि रिपॉज़िटरी को कैसे बनाया जाए या "फ़ेच" किया जाए. इसे अक्सर रेपो नियम कहा जाता है. Repo नियमों को Bazel, अंदरूनी तौर पर लागू करता है. इससे मॉड्यूल की मदद से बैकअप लिए गए रेपो को तय किया जाता है. इसके अलावा, इन्हें मॉड्यूल एक्सटेंशन भी लागू कर सकते हैं. Repo के नियम, इंटरनेट को ऐक्सेस कर सकते हैं या फ़ाइल I/O कर सकते हैं. Repo के सबसे सामान्य नियम http_archive हैं. इनका इस्तेमाल, इंटरनेट से सोर्स फ़ाइलें शामिल करने वाले संग्रह को डाउनलोड करने के लिए किया जाता है.

यह भी देखें: Repo rule से जुड़े दस्तावेज़

रिसर्च दोहराने की क्षमता

किसी बिल्ड या टेस्ट की ऐसी प्रॉपर्टी जिसमें बिल्ड या टेस्ट के लिए इनपुट का एक सेट, हर बार आउटपुट का एक ही सेट जनरेट करता है. भले ही, समय, तरीका या एनवायरमेंट कुछ भी हो. ध्यान दें कि इसका मतलब यह नहीं है कि आउटपुट सही हैं या आपकी ज़रूरत के मुताबिक हैं.

नियम

BUILD फ़ाइल में नियमों के टारगेट तय करने के लिए स्कीमा, जैसे कि cc_library. BUILD फ़ाइल के लेखक के हिसाब से, किसी नियम में एट्रिब्यूट का सेट और ब्लैक बॉक्स लॉजिक शामिल होता है. लॉजिक से, नियम के टारगेट को यह पता चलता है कि आउटपुट आर्टफ़ैक्ट कैसे जनरेट करने हैं और अन्य नियम के टारगेट को जानकारी कैसे भेजनी है. .bzlलेखकों के नज़रिए से, नियम Bazel को नई प्रोग्रामिंग भाषाओं और एनवायरमेंट के साथ काम करने के लिए बढ़ाने का मुख्य तरीका है.

लोडिंग फ़ेज़ में, नियमों को इंस्टैंटिएट किया जाता है, ताकि नियम के टारगेट जनरेट किए जा सकें. विश्लेषण के चरण में, नियम के टारगेट, डाउनस्ट्रीम डिपेंडेंसी को प्रोवाइडर के तौर पर जानकारी देते हैं. साथ ही, कार्रवाइयां रजिस्टर करते हैं, जिनसे यह पता चलता है कि आउटपुट आर्टफ़ैक्ट कैसे जनरेट किए जाएं. ये कार्रवाइयां, एक्ज़ीक्यूशन फ़ेज़ में की जाती हैं.

यह भी देखें: नियमों से जुड़ा दस्तावेज़

नियम का टारगेट

ऐसा टारगेट जो किसी नियम का इंस्टेंस हो. यह फ़ाइल टारगेट और पैकेज ग्रुप से अलग होता है. इसे नियम से भ्रमित न हों.

Runfiles

किसी एक्ज़ीक्यूटेबल टारगेट की रनटाइम डिपेंडेंसी. आम तौर पर, एक्ज़ीक्यूटेबल, टेस्ट के नियम का एक्ज़ीक्यूटेबल आउटपुट होता है. साथ ही, रनफ़ाइलें, टेस्ट की रनटाइम डेटा डिपेंडेंसी होती हैं. एक्ज़ीक्यूटेबल को शुरू करने से पहले (bazel test के दौरान), Bazel, रनफ़ाइल का ट्री तैयार करता है. साथ ही, सोर्स डायरेक्ट्री स्ट्रक्चर के मुताबिक टेस्ट एक्ज़ीक्यूटेबल तैयार करता है.

यह भी देखें: रनफ़ाइल का दस्तावेज़

सैंडबॉक्सिंग

यह एक ऐसी तकनीक है जिसकी मदद से, किसी प्रतिबंधित और कुछ समय के लिए उपलब्ध एक्ज़ीक्यूशन रूट में चल रही कार्रवाई को अलग किया जाता है. इससे यह पक्का करने में मदद मिलती है कि यह कार्रवाई, बिना बताए गए इनपुट को न पढ़े या बिना बताए गए आउटपुट को न लिखे. सैंडबॉक्सिंग से हर्मेटिसिटी में काफ़ी सुधार होता है. हालांकि, आम तौर पर इससे परफ़ॉर्मेंस पर असर पड़ता है. साथ ही, इसके लिए ऑपरेटिंग सिस्टम से सहायता की ज़रूरत होती है. परफ़ॉर्मेंस कॉस्ट, प्लैटफ़ॉर्म के हिसाब से तय होती है. Linux पर, इससे कोई खास फ़र्क़ नहीं पड़ता. हालांकि, macOS पर सैंडबॉक्सिंग का इस्तेमाल नहीं किया जा सकता.

Skyframe

Skyframe, Bazel का मुख्य पैरलल, फ़ंक्शनल, और इंक्रीमेंटल इवैल्यूएशन फ़्रेमवर्क है.

स्पॉन करने की रणनीति

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

इस्तेमाल: फ़्लैग का इस्तेमाल करके, एक्ज़ीक्यूशन की रणनीति तय करें. प्लान लागू करने की रणनीति तय करने के लिए, आम तौर पर इन फ़्लैग का इस्तेमाल किया जाता है:

• --spawn_strategy: सभी कार्रवाइयों के लिए, ग्लोबल डिफ़ॉल्ट के तौर पर सेट करें.
• --strategy <mnemonic>: किसी खास ऐक्शन के लिए, ग्लोबल डिफ़ॉल्ट रणनीति को बदलें.

फ़्लैग की पूरी सूची के लिए, एक्ज़ीक्यूशन की रणनीति देखें.

इनमें ये रणनीतियां शामिल हैं:

• local की वजह से, कमांड को लोकल सबप्रोसेस के तौर पर एक्ज़ीक्यूट किया जाता है.
• sandboxed की वजह से, निर्देश लोकल मशीन पर सैंडबॉक्स में लागू होते हैं. सैंडबॉक्सिंग देखें.
• worker की वजह से, कमांड को परसिस्टेंट वर्कर का इस्तेमाल करके एक्ज़ीक्यूट किया जाता है.
• docker की वजह से, निर्देश लोकल मशीन पर Docker सैंडबॉक्स में लागू होते हैं.
• remote की वजह से, कमांड को रिमोट तौर पर लागू किया जाता है.

छपाई का काम

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

Starlark

नियम और मैक्रो लिखने के लिए एक्सटेंशन की भाषा. यह Python का एक सीमित सबसेट है. इसका इस्तेमाल कॉन्फ़िगरेशन और बेहतर परफ़ॉर्मेंस के लिए किया जाता है. इसमें सिंटैक्टिक और व्याकरण के नियमों का पालन किया जाता है. .bzl फ़ाइल एक्सटेंशन का इस्तेमाल करता है. BUILD फ़ाइलों में, Starlark के और भी ज़्यादा पाबंदियों वाले वर्शन का इस्तेमाल किया जाता है. जैसे, def फ़ंक्शन की कोई परिभाषा नहीं होती. इसे पहले Skylark के नाम से जाना जाता था.

यह भी देखें: Starlark भाषा का दस्तावेज़

Starlark फ़्लैग

नियमों में कस्टम फ़्लैग तय किए जा सकते हैं. इन्हें Starlark फ़्लैग कहा जाता है, क्योंकि इन्हें Starlark नियमों का इस्तेमाल करके लागू किया जाता है. ये फ़्लैग, अलग-अलग BUILD फ़ाइलों के मुकाबले ज़्यादा लेवल पर यह कंट्रोल करते हैं कि नियम कैसे काम करेगा.

यह भी देखें: कॉन्फ़िगरेशन

Starlark के नियम

Starlark में लिखे गए कस्टम नियम, जो Bazel को नई बिल्ड सुविधाओं के साथ बढ़ाते हैं.

यह भी देखें: नियम

स्टार्टअप फ़्लैग

bazel और command के बीच तय किए गए फ़्लैग का सेट. उदाहरण के लिए, bazel --host_jvm_debug build. इन फ़्लैग से, Bazel सर्वर के कॉन्फ़िगरेशन में बदलाव होता है. इसलिए, स्टार्टअप फ़्लैग में किसी भी तरह का बदलाव करने पर, सर्वर रीस्टार्ट हो जाता है. स्टार्टअप फ़्लैग, किसी भी कमांड के लिए खास नहीं होते.

सिंबॉलिक मैक्रो

यह macro का एक फ़्लेवर है. इसे rule जैसे attribute स्कीमा के साथ एलान किया जाता है. इससे, एलान किए गए इंटरनल targets को उनके पैकेज से छिपाया जा सकता है. साथ ही, मैक्रो के एलान किए गए टारगेट पर नाम रखने के एक तय पैटर्न को लागू किया जा सकता है. इसे लेगसी मैक्रो के बड़े कोडबेस में आने वाली कुछ समस्याओं से बचने के लिए डिज़ाइन किया गया है.

यह भी देखें: सिंबॉलिक मैक्रो का दस्तावेज़

टारगेट

यह एक ऐसा ऑब्जेक्ट होता है जिसे BUILD फ़ाइल में तय किया जाता है और जिसकी पहचान label से होती है. टारगेट, असली उपयोगकर्ता के नज़रिए से वर्कस्पेस की ऐसी यूनिट को कहते हैं जिन्हें बनाया जा सकता है.

नियम को इंस्टैंटिएट करके तय किए गए टारगेट को नियम टारगेट कहा जाता है. नियम के हिसाब से, ये रन किए जा सकते हैं (जैसे कि 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

सभी Bazel कमांड, एक ही मुख्य रिपॉज़िटरी से चलती हैं.

ध्यान दें कि पहले "रिपॉज़िटरी" और "वर्कस्पेस" के कॉन्सेप्ट को एक ही माना जाता था. "वर्कस्पेस" शब्द का इस्तेमाल अक्सर मुख्य रिपॉज़िटरी के लिए किया जाता था. कभी-कभी इसे "रिपॉज़िटरी" के पर्यायवाची के तौर पर भी इस्तेमाल किया जाता था. आसान शब्दों में समझाने के लिए, इस तरह के इस्तेमाल से बचना चाहिए.