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