Bazel, सोर्स कोड से सॉफ़्टवेयर बनाता है. यह डायरेक्ट्री ट्री में व्यवस्थित होता है, जिसे
वर्कस्पेस कहा जाता है. फ़ाइल फ़ोल्डर में सोर्स फ़ाइलों को पैकेज के नेस्ट किए गए क्रम में रखा जाता है. इसमें हर पैकेज एक डायरेक्ट्री होती है, जिसमें मिलती-जुलती सोर्स फ़ाइलों का सेट और एक BUILD फ़ाइल होती है. BUILD फ़ाइल से यह पता चलता है कि सोर्स से कौनसे सॉफ़्टवेयर
आउटपुट बनाए जा सकते हैं.
फ़ाइल फ़ोल्डर
वर्कस्पेस आपके फ़ाइल सिस्टम का डायरेक्ट्री ट्री होता है. इसमें उन सॉफ़्टवेयर की सोर्स फ़ाइलें शामिल होती हैं जिन्हें आपको बनाना है. हर फ़ाइल फ़ोल्डर में WORKSPACE नाम की एक टेक्स्ट फ़ाइल होती है, जो खाली हो सकती है या उसमें आउटपुट बनाने के लिए ज़रूरी बाहरी डिपेंडेंसी के रेफ़रंस हो सकते हैं.
जिन डायरेक्ट्री में WORKSPACE फ़ाइल होती है उन्हें
वर्कस्पेस का रूट माना जाता है. इसलिए, Bazel, WORKSPACE फ़ाइल वाली सबडायरेक्ट्री पर रूट किए गए फ़ाइल फ़ोल्डर में किसी भी डायरेक्ट्री ट्री को अनदेखा कर देता है, क्योंकि वे एक दूसरा फ़ाइल फ़ोल्डर बनाते हैं.
Bazel, WORKSPACE फ़ाइल के उपनाम के तौर पर WORKSPACE.bazel फ़ाइल का भी इस्तेमाल करता है. अगर दोनों फ़ाइलें मौजूद हैं, तो WORKSPACE.bazel का इस्तेमाल किया जाता है.
डेटा स्टोर करने की जगह
कोड डेटा स्टोर करने की जगहों में व्यवस्थित किया गया है. WORKSPACE फ़ाइल वाली डायरेक्ट्री, मुख्य रिपॉज़िटरी का रूट होती है. इसे @ भी कहा जाता है. अन्य, (बाहरी)
डेटा स्टोर करने की जगहों को WORKSPACE फ़ाइल में फ़ाइल फ़ोल्डर के नियमों का इस्तेमाल करके तय किया जाता है या
Bzlmod सिस्टम में मॉड्यूल और एक्सटेंशन से जनरेट किया जाता है. ज़्यादा जानकारी के लिए बाहरी डिपेंडेंसी के बारे में खास जानकारी देखें.
Bazel के साथ बंडल किए गए फ़ाइल फ़ोल्डर के नियम, बिल्ड एन्साइक्लोपीडिया के Workspace के नियम सेक्शन में और एम्बेड किए गए Starlark रिपॉज़िटरी के नियमों के दस्तावेज़ में दिए गए हैं.
डेटा स्टोर करने की बाहरी जगहें अपने-आप डेटा स्टोर करने की जगह होती हैं, इसलिए उनमें अक्सर
WORKSPACE फ़ाइल भी होती है. हालांकि, इन अतिरिक्त WORKSPACE फ़ाइलों को Bazel
अनदेखा करता है. खास तौर पर, ट्रांज़िट स्थिति वाले रिपॉज़िटरी अपने-आप नहीं जुड़े होते.
पैकेज
डेटा स्टोर करने की जगह में, कोड व्यवस्थित करने की मुख्य यूनिट package होती है. पैकेज, संबंधित फ़ाइलों का संग्रह होता है. इसमें, आउटपुट आर्टफ़ैक्ट बनाने के लिए इस्तेमाल किए जाने के तरीकों की जानकारी भी दी जाती है.
पैकेज वह डायरेक्ट्री होती है जिसमें 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
दस्तावेज़ देखें.