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