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