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