फ़ाइल फ़ोल्डर, पैकेज, और टारगेट

बैजल, स्रोत कोड से सॉफ़्टवेयर बनाता है जिसे फ़ाइल फ़ोल्डर के डायरेक्ट्री ट्री में व्यवस्थित किया गया है. फ़ाइल फ़ोल्डर में मौजूद स्रोत फ़ाइलें, पैकेज के नेस्ट किए गए क्रम में व्यवस्थित होती हैं. यहां हर पैकेज में ऐसी डायरेक्ट्री होती है जिसमें मिलते-जुलते स्रोत फ़ाइलों का सेट और BUILD फ़ाइल होती है. BUILD फ़ाइल से पता चलता है कि स्रोत से कौनसे सॉफ़्टवेयर आउटपुट बनाए जा सकते हैं.

फ़ाइल फ़ोल्डर

फ़ाइल फ़ोल्डर आपके फ़ाइल सिस्टम पर मौजूद एक डायरेक्ट्री ट्री होता है, जिसमें उस सॉफ़्टवेयर की सोर्स फ़ाइल होती है जिसे आप बनाना चाहते हैं. हर फ़ाइल फ़ोल्डर में WORKSPACE नाम की टेक्स्ट फ़ाइल होती है जो खाली हो सकती है या इसमें आउटपुट बनाने के लिए ज़रूरी बाहरी डिपेंडेंसी हो सकती है.

WORKSPACE नाम वाली फ़ाइल को फ़ाइल फ़ोल्डर का रूट माना जाता है. इसलिए, बैजल WORKSPACE फ़ाइल वाली किसी सबडायरेक्ट्री में रूट किए गए किसी डायरेक्ट्री डायरेक्ट्री को अनदेखा कर देता है, क्योंकि वह दूसरा फ़ाइल फ़ोल्डर बनाता है.

बैजल, WORKSPACE फ़ाइल के उपनाम के रूप में WORKSPACE.bazel फ़ाइल का भी इस्तेमाल करता है. अगर दोनों फ़ाइलें मौजूद हैं, तो WORKSPACE.bazel का इस्तेमाल किया जाता है.

डेटा स्टोर करने की जगह

कोड को डेटा स्टोर करने की जगह में व्यवस्थित किया गया है. WORKSPACE फ़ाइल वाली निर्देशिका मुख्य रिपॉज़िटरी का रूट है, जिसे @ भी कहा जाता है. अन्य, (बाहरी) डेटा स्टोर करने की जगहों को WORKSPACE फ़ाइल में फ़ाइल फ़ोल्डर के नियमों का इस्तेमाल करके बताया जाता है.

बैजल के साथ बंडल किए गए फ़ाइल फ़ोल्डर के नियमों को यहां दस्तावेज़ में दिया गया है Workspace के नियम सेक्शन मेंएनसाइक्लोपीडिया बनाएं और दस्तावेज़ Starlark डेटा स्टोर करने की जगह से जुड़े नियम चुनें.

बाहरी डेटा स्टोर करने की जगहें खुद होती हैं, क्योंकि इनमें अक्सर 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 के सिंबल उपलब्ध होते हैं और निष्पादन के दौरान B का रनटाइम डेटा A के लिए उपलब्ध होता है.

सभी नियमों का एक उलटा यह है कि नियम से हमेशा जनरेट हुई फ़ाइलें हमेशा उसी पैकेज से जुड़ी होती हैं, जिस पर नियम लागू होता है; दूसरे पैकेज में फ़ाइलें जनरेट करना संभव नहीं है. हालांकि, आम तौर पर किसी नियम के इनपुट किसी दूसरे पैकेज से आते हैं.

पैकेज ग्रुप ऐसे पैकेज के सेट होते हैं जिनका मकसद कुछ खास नियमों की सुलभता को सीमित करना होता है. पैकेज ग्रुप package_group फ़ंक्शन से तय किए जाते हैं. आपके पास तीन प्रॉपर्टी होती हैं: शामिल पैकेज की सूची, उनका नाम और दूसरे पैकेज समूह जिनमें वे शामिल हैं. उन्हें रेफ़र करने के लिए, सिर्फ़ नियमों के visibility या package फ़ंक्शन के default_visibility एट्रिब्यूट से अनुमति दिए गए तरीकों के इस्तेमाल की अनुमति दी जाती है; वे फ़ाइलें जनरेट या इस्तेमाल नहीं करते. ज़्यादा जानकारी के लिए, package_group दस्तावेज़ देखें.

लेबल