Bazel, Workspace ट्री में मौजूद सोर्स कोड से सॉफ़्टवेयर बनाता है. इसे
Workspace कहा जाता है. फ़ाइल फ़ोल्डर में मौजूद सोर्स फ़ाइलें, पैकेज के नेस्ट किए गए क्रम में व्यवस्थित होती हैं. हर पैकेज एक डायरेक्ट्री होती है, जिसमें संबंधित सोर्स फ़ाइलों का सेट और एक BUILD फ़ाइल होती है. BUILD फ़ाइल से पता चलता है कि सोर्स से कौनसे सॉफ़्टवेयर आउटपुट बनाए जा सकते हैं.
फ़ाइल फ़ोल्डर
फ़ाइल फ़ोल्डर आपके फ़ाइल सिस्टम में मौजूद एक डायरेक्ट्री ट्री है, जिसमें उस सॉफ़्टवेयर की सोर्स
फ़ाइलें होती हैं जिसे आप बनाना चाहते हैं. हर फ़ाइल फ़ोल्डर में WORKSPACE नाम की एक टेक्स्ट फ़ाइल होती है. यह खाली हो सकती है या आउटपुट बनाने के लिए ज़रूरी बाहरी डिपेंडेंसी के रेफ़रंस हो सकते हैं.
जिन डायरेक्ट्री में WORKSPACE नाम की फ़ाइल होती है उन्हें फ़ाइल फ़ोल्डर की रूट माना जाता है. इसलिए, बेज़ल, फ़ाइल फ़ोल्डर में शामिल किसी फ़ाइल फ़ोल्डर में मौजूद किसी भी डायरेक्ट्री ट्री को नज़रअंदाज़ कर देता है. ऐसा तब होता है, जब WORKSPACE फ़ाइल किसी दूसरे फ़ाइल फ़ोल्डर में बनती है.
Bazel, WORKSPACE.bazel फ़ाइल को WORKSPACE फ़ाइल के उपनाम के तौर पर भी इस्तेमाल करता है. दोनों फ़ाइलें मौजूद होने पर, WORKSPACE.bazel का इस्तेमाल किया जाता है.
डेटा स्टोर करने की जगह
कोड डेटा स्टोर की जगहों में व्यवस्थित किया जाता है. WORKSPACE
फ़ाइल वाली डायरेक्ट्री, डेटा स्टोर करने की मुख्य जगह का रूट होती है. इसे @ भी कहा जाता है. अन्य (बाहरी)
डेटा स्टोर करने की जगह, फ़ाइल फ़ोल्डर के नियमों का इस्तेमाल करके WORKSPACE फ़ाइल में तय की जाती हैं या Bzlmod सिस्टम में मॉड्यूल और एक्सटेंशन से जनरेट की जाती हैं. ज़्यादा जानकारी के लिए बाहरी
डिपेंडेंसी की खास जानकारी देखें.
Bazel की मदद से बंडल किए गए फ़ाइल फ़ोल्डर के नियमों को, बिल्ड एनसाइक्लोपीडिया में Workspace नियम सेक्शन में और एम्बेड किए गए Starlark डेटा के नियमों के दस्तावेज़ में दिया गया है.
बाहर के डेटा स्टोर करने की जगहें भी खुद ही रिपॉज़िटरी हैं, इसलिए इनमें अक्सर एक WORKSPACE फ़ाइल भी होती है. हालांकि, बैज़ल ने इन अतिरिक्त WORKSPACE फ़ाइलों को अनदेखा कर दिया है. खास तौर पर, डेटा स्टोर करने की ऐसी जगहें जो ट्रांज़िट समय पर निर्भर होती हैं, वे अपने-आप नहीं जुड़तीं.
पैकेज
रिपॉज़िटरी में कोड संगठन की मुख्य इकाई पैकेज है. पैकेज संबंधित फ़ाइलों का एक संग्रह है. साथ ही, इसमें यह भी बताया गया है कि आउटपुट फ़ाइलें बनाने के लिए उनका इस्तेमाल कैसे किया जा सकता है.
पैकेज, एक डायरेक्ट्री है. इसमें BUILD या BUILD.bazel नाम वाली BUILD फ़ाइल होती है. एक पैकेज में, सभी डायरेक्ट्री की और इसके नीचे की सभी सबडायरेक्ट्री शामिल होती हैं. हालांकि, इनमें वे डायरेक्ट्री शामिल नहीं होती हैं जिनमें BUILD फ़ाइल होती है. इस परिभाषा में, कोई भी फ़ाइल या
डायरेक्ट्री दो अलग-अलग पैकेज का हिस्सा नहीं हो सकती.
उदाहरण के लिए, यहां दिए गए डायरेक्ट्री ट्री में दो पैकेज,
my/appऔर सबपैकेज my/app/tests हैं. ध्यान दें कि my/app/data, पैकेज नहीं है, लेकिन
पैकेज my/app से जुड़ी डायरेक्ट्री है.
src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc
टारगेट
पैकेज, टारगेट का एक कंटेनर होता है, जिसे पैकेज की
BUILD फ़ाइल में बताया जाता है. ज़्यादातर टारगेट, दो मुख्य टाइप में से एक होते हैं, फ़ाइलें और नियम.
फ़ाइलों को आगे दो टाइप में बांटा गया है. सोर्स फ़ाइलें आम तौर पर लोगों की कोशिशों से तैयार होती हैं. साथ ही, उन्हें रिपॉज़िटरी में चेक इन किया जाता है. जनरेट की गई फ़ाइलें, जिन्हें कभी-कभी ली गई फ़ाइलें या आउटपुट फ़ाइलें कहा जाता है, चेक इन नहीं होती हैं. हालांकि, ये सोर्स फ़ाइलों से जनरेट की जाती हैं.
दूसरे तरह के टारगेट का एलान नियम के साथ किया जाता है. हर एक इंस्टेंस इंस्टेंस, इनपुट के एक सेट और आउटपुट फ़ाइलों के सेट के बीच के संबंध की जानकारी देता है. किसी नियम में दिए गए इनपुट, सोर्स फ़ाइलें हो सकते हैं, लेकिन वे दूसरे नियमों के आउटपुट भी हो सकते हैं.
ज़्यादातर मामलों में किसी नियम में इनपुट एक स्रोत फ़ाइल होती है या जनरेट की गई फ़ाइल इस तथ्य की मदद से, कॉम्प्लेक्स सोर्स फ़ाइल को किसी नियम के ज़रिए बनाई गई फ़ाइल से बदलना आसान हो जाता है. ऐसा तब होता है, जब अच्छी तरह से व्यवस्थित की गई फ़ाइल के रखरखाव का बोझ बहुत ज़्यादा बढ़ जाता है और इसे हासिल करने के लिए कोई प्रोग्राम लिखा जाता है. इस फ़ाइल के उपभोक्ताओं को किसी बदलाव की ज़रूरत नहीं है. इसके उलट, जनरेट की गई फ़ाइल को आसानी से सिर्फ़ स्थानीय बदलावों वाली सोर्स फ़ाइल से बदला जा सकता है.
नियम के इनपुट में अन्य नियम भी शामिल हो सकते हैं. इस तरह के संबंधों की सटीक जानकारी अक्सर काफ़ी जटिल होती है. इसके अलावा, यह भाषा या नियम पर निर्भर भी होती है, लेकिन आसान नहीं: C++ लाइब्रेरी नियम A में इनपुट के लिए, C++ लाइब्रेरी का दूसरा नियम B हो सकता है. इस डिपेंडेंसी का असर यह होता है कि B के हेडर की फ़ाइलें, कंपाइलेशन के दौरान A में उपलब्ध होती हैं. साथ ही, लिंक करने के दौरान B के सिंबल A से उपलब्ध होते हैं. साथ ही, एक्ज़ीक्यूशन के दौरान B का रनटाइम डेटा A के लिए उपलब्ध होता है.
सभी नियमों का एक अंतर यह है कि नियम के ज़रिए जनरेट की गई फ़ाइलें, हमेशा उसी पैकेज से जुड़ी होती हैं, जैसा कि नियम में होता है. किसी दूसरे पैकेज में फ़ाइलें जनरेट नहीं की जा सकती. हालांकि, किसी नियम के इनपुट का किसी दूसरे पैकेज से आना असामान्य नहीं है.
पैकेज ग्रुप, पैकेज के ऐसे सेट होते हैं जिनका मकसद कुछ नियमों की सुलभता को सीमित करना होता है. पैकेज ग्रुप, package_group फ़ंक्शन से तय होते हैं. उनके पास
तीन प्रॉपर्टी होती हैं: उनमें शामिल पैकेज की सूची, उनका नाम, और शामिल किए गए अन्य
ग्रुप ग्रुप. इनका इस्तेमाल करने के सिर्फ़ एक तरीके हैं: नियमों के visibility एट्रिब्यूट से या package फ़ंक्शन के default_visibility एट्रिब्यूट से. ये न तो फ़ाइलें जनरेट करते हैं और न ही उनका इस्तेमाल करते हैं. ज़्यादा
जानकारी के लिए, package_group
दस्तावेज़ देखें.