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