इस पेज पर यह माना जाता है कि आप Bazel से परिचित हैं. साथ ही, इस पेज पर बैजेल की सुविधाओं का पूरा फ़ायदा उठाने के लिए, अपने प्रोजेक्ट को बनाने के बारे में दिशा-निर्देश और सलाह दी गई है.
कुल लक्ष्य हैं:
- समानता और बढ़ोतरी का इस्तेमाल करने के लिए, निर्भरता का इस्तेमाल करें.
- डिपेंडेंसी को बेहतर ढंग से बनाए रखने के लिए.
- कोड को अच्छी तरह से व्यवस्थित करने और उसकी जांच करने लायक बनाने के लिए.
- ऐसा बिल्ड कॉन्फ़िगरेशन बनाने में जिसे समझना और उसका रखरखाव करना आसान हो.
इन दिशा-निर्देशों की ज़रूरत नहीं है: कुछ प्रोजेक्ट उन सभी का पालन कर पाएंगे. जैसा कि लिंट के लिए मैन पेज पर कहा गया है, "सर्टिफ़ाइड चेकिंग की सुविधा में कोई गड़बड़ी न करने वाला असली प्रोग्राम बनाने वाले पहले व्यक्ति को एक खास इनाम दिया जाएगा." हालांकि, इन नियमों में जितनी हो सके उतनी जानकारी शामिल करने से प्रोजेक्ट पढ़ने में आसान, गड़बड़ी की कम संभावना, और जल्दी तैयार होता है.
यह पेज इस आरएफ़सी में बताए गए ज़रूरी लेवल का इस्तेमाल करता है.
बिल्ड और टेस्ट चलाना
किसी प्रोजेक्ट की स्थिर शाखा पर bazel build //... और
bazel test //... हमेशा चलने चाहिए. ऐसे टारगेट जो ज़रूरी हैं
लेकिन कुछ खास परिस्थितियों में नहीं बने हैं (जैसे कि किसी खास बिल्ड फ़्लैग की ज़रूरत है, किसी प्लैटफ़ॉर्म पर न बनाएं, लाइसेंस के लिए कानूनी समझौते की ज़रूरत होती है) उन्हें खास तौर पर टैग किया जाना चाहिए (उदाहरण के लिए, "requires-osx"). इस
टैगिंग से, टारगेट को "मैन्युअल" टैग के मुकाबले ज़्यादा बेहतर लेवल पर फ़िल्टर किया जा सकता है. साथ ही, BUILD फ़ाइल की जांच करने वाले व्यक्ति को यह समझने में मदद मिलती है कि टारगेट की पाबंदियां क्या हैं.
तीसरे पक्ष की डिपेंडेंसी
आप तीसरे पक्ष की डिपेंडेंसी सेट कर सकते हैं:
WORKSPACEफ़ाइल में जाकर, उन्हें डेटा स्टोर करने की जगह होने के बारे में बताएं.- या उन्हें अपने फ़ाइल फ़ोल्डर में
third_party/नाम की डायरेक्ट्री में रखें.
बाइनरी के आधार पर
जब भी हो सके, हर चीज़ को स्रोत से बनाया जाना चाहिए. इसका मतलब यह है कि लाइब्रेरी some-library.so के आधार पर, आप एक BUILD फ़ाइल बनाएंगे और उसके स्रोतों से some-library.so बनाएंगे, फिर उस टारगेट पर निर्भर रहेंगे चुनें.
हमेशा स्रोत से निर्माण करने पर यह पक्का हो जाता है कि बिल्ड ऐसी लाइब्रेरी का उपयोग नहीं कर रहा है, जो असंगत फ़्लैग या किसी अन्य वास्तुकला के साथ बनाई गई हो. कवरेज, स्थिर विश्लेषण या डाइनैमिक विश्लेषण जैसी कुछ सुविधाएं भी हैं, जो सिर्फ़ स्रोत पर काम करती हैं.
वर्शन
जहां भी हो सके, सभी कोड हेड से बनाएं. जब वर्शन का इस्तेमाल किया जाना चाहिए, तो टारगेट नाम में वर्शन शामिल करने से बचें (उदाहरण के लिए, //guava,
//guava-20.0 नहीं). इस नाम से लाइब्रेरी को अपडेट करना आसान हो जाता है (सिर्फ़ एक टारगेट को अपडेट करने की ज़रूरत है). यह हीरे की निर्भरता से जुड़ी समस्याओं के लिए भी ज़्यादा कारगर है: अगर एक लाइब्रेरी 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 फ़ाइल को उस सबडायरेक्ट्री में जोड़ा जाना चाहिए. यह संरचना जितनी लंबी होगी, अनजाने में सर्कुलर डिपेंडेंसी बनाने की संभावना उतनी ही ज़्यादा होगी. किसी टारगेट के दायरे में कमी होगी और बढ़ती हुई
अलग-अलग तरह की डिपेंडेंसी को अपडेट करना होगा.