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