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