यह पेज मान लेता है कि आप बेज़ल से परिचित हैं और बेज़ल की सुविधाओं का पूरा लाभ लेने के लिए अपने प्रोजेक्ट की संरचना के बारे में दिशा-निर्देश और सलाह देते हैं.
कुल लक्ष्य हैं:
- साथ-साथ काम करने और इंक्रीमेंटैलिटी को बढ़ावा देने के लिए, सटीक जानकारी का इस्तेमाल किया जा सकता है.
- डिपेंडेंसी को सही तरीके से समझाने के लिए.
- कोड को सही तरीके से डालने और टेस्ट करने के लिए.
- ऐसा बिल्ड कॉन्फ़िगरेशन बनाने के लिए जिसे आसानी से समझा और मैनेज किया जा सके.
ये दिशा-निर्देश ज़रूरी नहीं हैं: कुछ प्रोजेक्ट उन सभी का पालन कर पाएंगे. जैसे कि लिंट के लिए मैन पेज पर यह कहा जा रहा है, "पहले व्यक्ति को एक खास इनाम दिया जाएगा. इससे, उसे असली कार्यक्रम बनाने में मदद मिलेगी, जिसमें सख्त जांच करने पर भी कोई गड़बड़ी न हो." हालांकि, ज़्यादा से ज़्यादा सिद्धांतों को शामिल करके, प्रोजेक्ट को आसानी से पढ़ा जा सकता है. साथ ही, गड़बड़ी की संभावना कम हो सकती है और उसे तेज़ी से बनाया जा सकता है.
यह पेज इस आरएफ़सी में बताए गए ज़रूरी लेवल का इस्तेमाल करता है.
बिल्ड और जांच करना
किसी प्रोजेक्ट को उसकी स्थिर शाखा पर bazel build //... और
bazel test //... को हमेशा चलाया जाना चाहिए. ऐसे टारगेट जो ज़रूरी हैं, लेकिन कुछ खास परिस्थितियों में नहीं बनाए गए हैं (जैसे कि कुछ खास तरह के
फ़्लैग बनाने की ज़रूरत है, किसी खास प्लैटफ़ॉर्म पर न बनाए जाएं, उनके लिए लाइसेंस के कानूनी समझौते ज़रूरी हैं)
खास तौर से टैग किए जाने चाहिए (उदाहरण के लिए, "requires-osx"). इस टैगिंग की मदद से, टारगेट "मैन्युअल" टैग की तुलना में ज़्यादा बारीक लेवल पर फ़िल्टर किए जा सकते हैं. साथ ही, इसकी मदद से BUILD फ़ाइल की जांच करने वाले लोग, टारगेट की पाबंदियों को समझ पाते हैं.
तीसरे पक्ष की डिपेंडेंसी
आपके पास तीसरे पक्ष की डिपेंडेंसी के बारे में बताने का विकल्प है:
WORKSPACEफ़ाइल में रिमोट रिपॉज़िटरी के तौर पर इनका एलान करें.- इसके अलावा, उन्हें अपनी फ़ाइल फ़ोल्डर डायरेक्ट्री में,
third_party/नाम की डायरेक्ट्री में रखें.
बाइनरी के हिसाब से
जब भी हो सके, सोर्स से ही सब कुछ बना लेना चाहिए. आम तौर पर, इसका मतलब यह
है कि some-library.so लाइब्रेरी के आधार पर, आप
BUILD फ़ाइल बनाएंगे और उसके सोर्स से some-library.so बनाएंगे. इसके बाद, उस टारगेट के आधार पर काम करेंगे.
हमेशा सोर्स से बनाने से यह पक्का होता है कि बिल्ड में ऐसी लाइब्रेरी का इस्तेमाल नहीं हो रहा है जिसे ऐसे फ़्लैग या अलग वास्तुकला के साथ बनाया गया हो जो काम नहीं करती. कवरेज, स्टैटिक ऐनलिसिस या डाइनैमिक ऐनलिसिस जैसी कुछ ऐसी सुविधाएं भी हैं जो सिर्फ़ सोर्स पर काम करती हैं.
वर्शन
जब भी हो सके, तब तक सारा कोड सबसे पहले बनाएं. जब वर्शन का इस्तेमाल करना ज़रूरी हो, तो टारगेट किए गए नाम में वर्शन शामिल करने से बचें. उदाहरण के लिए, //guava-20.0 को छोड़कर, //guava. इस नाम से लाइब्रेरी को अपडेट करना आसान हो जाता है (सिर्फ़ एक टारगेट को अपडेट करना पड़ता है). हीरे की निर्भरता से जुड़ी समस्याओं के लिए भी ज़्यादा सुविधाजनक यह है: अगर एक लाइब्रेरी guava-19.0 पर और दूसरी guava-20.0 पर निर्भर है, तो आप दो अलग-अलग वर्शन के मुताबिक लाइब्रेरी बना सकते हैं.
अगर आपने दोनों टारगेट को एक ही guava लाइब्रेरी पर ले जाने के लिए गुमराह करने वाला उपनाम बनाया है,
तो BUILD फ़ाइलें गुमराह करने वाली हैं.
.bazelrc फ़ाइल का इस्तेमाल करके
खास प्रोजेक्ट से जुड़े विकल्पों के लिए, कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल करें
workspace/.bazelrc (bazelrc फ़ॉर्मैट देखें).
अगर आपको अपने प्रोजेक्ट के लिए, हर उपयोगकर्ता के लिए उपलब्ध विकल्पों के साथ काम करना है, तो आपको सोर्स कंट्रोल में चेक इन नहीं करना है. इसके लिए, लाइन में यह शामिल करें:
try-import %workspace%/user.bazelrc
(या किसी और फ़ाइल का नाम) workspace/.bazelrc
के साथ जोड़ें और user.bazelrc को अपने .gitignore में जोड़ें.
पैकेज
बनाई जा सकने वाली फ़ाइलों वाली हर डायरेक्ट्री को एक पैकेज होना चाहिए. अगर BUILD
फ़ाइल, सबडायरेक्ट्री की फ़ाइलों (जैसे, srcs = ["a/b/C.java"]) के बारे में बताती है, तो इसका मतलब है कि उस फ़ाइल में BUILD फ़ाइल जोड़ी जानी चाहिए. यह स्ट्रक्चर जितने लंबे समय तक मौजूद रहेगा, उतनी ही ज़्यादा सर्कुलर डिपेंडेंसी अनजाने में बन जाएंगी, टारगेट का दायरा बढ़ेगा, और रिवर्स डिपेंडेंसी की बढ़ती संख्या को अपडेट करना पड़ेगा.