इस पेज पर, Bazel की मदद से Xcode प्रोजेक्ट बनाने या उसकी जांच करने का तरीका बताया गया है. इसमें Xcode और Bazel के बीच के अंतर के बारे में बताया गया है. साथ ही, Xcode प्रोजेक्ट को Bazel प्रोजेक्ट में बदलने का तरीका भी बताया गया है. इसमें, आम तौर पर होने वाली गड़बड़ियों को ठीक करने के तरीके भी बताए गए हैं.
Xcode और Bazel के बीच के अंतर
Bazel के लिए, आपको हर बिल्ड टारगेट और उसकी डिपेंडेंसी के साथ-साथ, बिल्ड के नियमों के ज़रिए बिल्ड की सेटिंग साफ़ तौर पर बतानी होती हैं.
Bazel के लिए, प्रोजेक्ट की सभी डिपेंडेंसी, वर्कस्पेस डायरेक्ट्री में मौजूद होनी चाहिए. इसके अलावा, इन्हें
MODULE.bazelफ़ाइल में डिपेंडेंसी के तौर पर भी बताया जा सकता है.Bazel की मदद से Xcode प्रोजेक्ट बनाने पर,
BUILDफ़ाइलें, सोर्स ऑफ़ ट्रुथ बन जाती हैं. अगर Xcode में प्रोजेक्ट पर काम किया जाता है, तोBUILDफ़ाइलों को अपडेट करने पर, rules_xcodeproj का इस्तेमाल करके Xcode प्रोजेक्ट का नया वर्शन जनरेट करना होगा. यह वर्शन,BUILDफ़ाइलों से मेल खाना चाहिए.BUILDफ़ाइलों में कुछ बदलाव करने पर, प्रोजेक्ट को फिर से जनरेट करने की ज़रूरत नहीं होती. जैसे, किसी टारगेट में डिपेंडेंसी जोड़ना. इससे डेवलपमेंट की प्रोसेस तेज़ हो सकती है. अगर Xcode का इस्तेमाल नहीं किया जा रहा है, तोbazel buildऔरbazel testकमांड, बिल्ड और टेस्ट की सुविधाएं देती हैं. हालांकि, इनकी कुछ सीमाएं हैं. इनके बारे में इस गाइड में आगे बताया गया है.
शुरू करने से पहले
शुरू करने से पहले, यह काम करें:
अगर आपने Bazel को पहले से इंस्टॉल नहीं किया है, तो उसे इंस्टॉल करें.
अगर आपको Bazel और उसके कॉन्सेप्ट के बारे में जानकारी नहीं है, तो iOS ऐप्लिकेशन ट्यूटोरियल पूरा करें. आपको Bazel वर्कस्पेस के बारे में जानकारी होनी चाहिए. इसमें
MODULE.bazelऔरBUILDफ़ाइलें शामिल हैं. साथ ही, आपको टारगेट, बिल्ड के नियम, और Bazel पैकेज के कॉन्सेप्ट के बारे में भी जानकारी होनी चाहिए.प्रोजेक्ट की डिपेंडेंसी का विश्लेषण करें और उन्हें समझें.
प्रोजेक्ट की डिपेंडेंसी का विश्लेषण करना
Xcode के उलट, Bazel के लिए ज़रूरी है कि BUILD फ़ाइल में हर टारगेट के लिए सभी डिपेंडेंसी साफ़ तौर पर बताई जाएं.
बाहरी डिपेंडेंसी के बारे में ज़्यादा जानने के लिए, बाहरी डिपेंडेंसी के साथ काम करना लेख पढ़ें.
Bazel की मदद से Xcode प्रोजेक्ट बनाना या उसकी जांच करना
Bazel की मदद से Xcode प्रोजेक्ट बनाने या उसकी जांच करने के लिए, यह तरीका अपनाएं:
पहला चरण: MODULE.bazel फ़ाइल बनाना
नई डायरेक्ट्री में MODULE.bazel फ़ाइल बनाएं. यह डायरेक्ट्री, Bazel वर्कस्पेस का रूट बन जाती है. अगर प्रोजेक्ट में कोई बाहरी डिपेंडेंसी इस्तेमाल नहीं की जाती है, तो यह फ़ाइल खाली हो सकती है. अगर प्रोजेक्ट, ऐसी फ़ाइलों या पैकेज पर निर्भर करता है जो प्रोजेक्ट की किसी डायरेक्ट्री में नहीं हैं, तो MODULE.bazel फ़ाइल में इन बाहरी डिपेंडेंसी के बारे में बताएं.
दूसरा चरण: (एक्सपेरिमेंटल) SwiftPM डिपेंडेंसी इंटिग्रेट करना
तीसरा चरण: BUILD फ़ाइल बनाना
वर्कस्पेस और बाहरी डिपेंडेंसी तय करने के बाद, आपको BUILD फ़ाइल बनानी होगी. इससे Bazel को पता चलता है कि प्रोजेक्ट का स्ट्रक्चर कैसा है. Bazel वर्कस्पेस के रूट में BUILD फ़ाइल बनाएं और इसे प्रोजेक्ट का शुरुआती बिल्ड करने के लिए कॉन्फ़िगर करें. इसके लिए, यह तरीका अपनाएं:
- तीसरा चरण (a): ऐप्लिकेशन टारगेट जोड़ना
- तीसरा चरण (b): (ज़रूरी नहीं) टेस्ट टारगेट जोड़ना
- तीसरा चरण(c): लाइब्रेरी टारगेट जोड़ना
अहम जानकारी: पैकेज और Bazel के अन्य कॉन्सेप्ट के बारे में ज़्यादा जानने के लिए, वर्कस्पेस, पैकेज, और टारगेट लेख पढ़ें.
तीसरा चरण (a): ऐप्लिकेशन टारगेट जोड़ना
macos_application
या
ios_application
नियम वाला टारगेट जोड़ें. इस टारगेट से, macOS या iOS ऐप्लिकेशन बंडल बनता है.
टारगेट में, कम से कम ये जानकारी दें:
bundle_id- बाइनरी का बंडल आईडी (रिवर्स-डीएनएस पाथ के बाद ऐप्लिकेशन का नाम) .provisioning_profile- Apple Developer खाते से प्रोविज़निंग प्रोफ़ाइल (अगर iOS डिवाइस के लिए बिल्ड किया जा रहा है).families(सिर्फ़ iOS के लिए) - ऐप्लिकेशन को iPhone, iPad या दोनों के लिए बिल्ड करना है.infoplists- .plist फ़ाइलों की सूची, जिन्हें फ़ाइनल Info.plist फ़ाइल में मर्ज करना है.minimum_os_version- macOS या iOS का वह कम से कम वर्शन जिस पर ऐप्लिकेशन काम करता है. इससे यह पक्का होता है कि Bazel, ऐप्लिकेशन को एपीआई के सही लेवल के साथ बिल्ड करे.
तीसरा चरण (b): (ज़रूरी नहीं) टेस्ट टारगेट जोड़ना
Bazel के Apple बिल्ड नियम, Apple के सभी प्लैटफ़ॉर्म पर यूनिट और यूज़र इंटरफ़ेस (यूआई) टेस्ट चलाने की सुविधा देते हैं. टेस्ट टारगेट जोड़ने के लिए, यह तरीका अपनाएं:
macos_unit_testmacOS पर, लाइब्रेरी और ऐप्लिकेशन पर आधारित यूनिट टेस्ट चलाने के लिए, जोड़ें.iOS पर, लाइब्रेरी पर आधारित यूनिट टेस्ट बनाने और चलाने के लिए,
ios_unit_testजोड़ें.iOS सिम्युलेटर में, यूज़र इंटरफ़ेस टेस्ट बनाने और चलाने के लिए,
ios_ui_testजोड़ें.visionOS के लिए भी इसी तरह के टेस्ट के नियम मौजूद हैं.
कम से कम, minimum_os_version एट्रिब्यूट के लिए कोई वैल्यू तय करें. पैकेजिंग के अन्य एट्रिब्यूट, जैसे कि bundle_identifier और infoplists के लिए, आम तौर पर इस्तेमाल की जाने वाली वैल्यू डिफ़ॉल्ट तौर पर सेट होती हैं. हालांकि, यह पक्का करें कि ये डिफ़ॉल्ट वैल्यू, प्रोजेक्ट के साथ काम करती हों. साथ ही, ज़रूरत के हिसाब से इनमें बदलाव करें. ऐसे टेस्ट के लिए जिनमें iOS सिम्युलेटर की ज़रूरत होती है, ios_application टारगेट का नाम, test_host एट्रिब्यूट की वैल्यू के तौर पर भी तय करें.
तीसरा चरण(c): लाइब्रेरी टारगेट जोड़ना
हर
Objective-C लाइब्रेरी के लिए objc_library टारगेट और हर Swift लाइब्रेरी के लिए
swift_library
टारगेट जोड़ें. ऐप्लिकेशन और/या टेस्ट, इन लाइब्रेरी पर निर्भर करते हैं.
लाइब्रेरी टारगेट जोड़ने के लिए, यह तरीका अपनाएं:
ऐप्लिकेशन लाइब्रेरी टारगेट को, ऐप्लिकेशन टारगेट में डिपेंडेंसी के तौर पर जोड़ें.
टेस्ट लाइब्रेरी टारगेट को, टेस्ट टारगेट में डिपेंडेंसी के तौर पर जोड़ें.
srcsएट्रिब्यूट में, लागू करने के सोर्स की सूची जोड़ें.hdrsएट्रिब्यूट में, हेडर की सूची जोड़ें.
rules_apple के उदाहरणों वाली डायरेक्ट्री में, अलग-अलग तरह के ऐप्लिकेशन के मौजूदा उदाहरण सीधे तौर पर देखे जा सकते हैं. उदाहरण के लिए:
बिल्ड के नियमों के बारे में ज़्यादा जानने के लिए, Bazel के लिए Apple के नियम लेख पढ़ें.
इस समय, बिल्ड की जांच करना एक अच्छा तरीका है:
bazel build //:<application_target>
चौथा चरण: (ज़रूरी नहीं) बिल्ड को ज़्यादा बेहतर बनाना
अगर प्रोजेक्ट बड़ा है या बड़ा हो रहा है, तो इसे कई Bazel पैकेज में बांटने पर विचार करें. बिल्ड को ज़्यादा बेहतर बनाने से ये फ़ायदे मिलते हैं:
बिल्ड को इंक्रीमेंटल तरीके से बनाने की सुविधा मिलती है,
बिल्ड के टास्क को एक साथ चलाने की सुविधा मिलती है,
भविष्य में उपयोगकर्ताओं के लिए, रखरखाव बेहतर तरीके से किया जा सकता है,
टारगेट और पैकेज में, सोर्स कोड की विज़िबिलिटी को बेहतर तरीके से कंट्रोल किया जा सकता है. इससे ऐसी समस्याएं नहीं होतीं, जैसे कि लाइब्रेरी में लागू करने की जानकारी, सार्वजनिक एपीआई में लीक हो जाना.
प्रोजेक्ट को ज़्यादा बेहतर बनाने के लिए सुझाव:
हर लाइब्रेरी को उसके Bazel पैकेज में रखें. उन लाइब्रेरी से शुरुआत करें जिनके लिए कम से कम डिपेंडेंसी की ज़रूरत होती है. इसके बाद, डिपेंडेंसी ट्री में आगे बढ़ें.
BUILDफ़ाइलें जोड़ते समय और टारगेट तय करते समय, इन नए टारगेट को उन टारगेट केdepsएट्रिब्यूट में जोड़ें जो इन पर निर्भर करते हैं.glob()फ़ंक्शन, पैकेज की सीमाओं को पार नहीं करता. इसलिए, पैकेज की संख्या बढ़ने पर,glob()से मैच होने वाली फ़ाइलें कम हो जाएंगी.mainडायरेक्ट्री मेंBUILDफ़ाइल जोड़ते समय, उससे जुड़ीtestडायरेक्ट्री में भीBUILDफ़ाइल जोड़ें.पैकेज में, विज़िबिलिटी की सीमाओं को लागू करें.
BUILDफ़ाइलों में हर बड़े बदलाव के बाद, प्रोजेक्ट को बिल्ड करें और बिल्ड की गड़बड़ियों को ठीक करें.
पांचवा चरण: बिल्ड चलाना
पूरी तरह से माइग्रेट किए गए बिल्ड को चलाएं, ताकि यह पक्का किया जा सके कि यह बिना किसी गड़बड़ी या चेतावनी के पूरा हो. किसी भी गड़बड़ी के सोर्स को आसानी से ढूंढने के लिए, हर ऐप्लिकेशन और टेस्ट टारगेट को अलग-अलग चलाएं.
उदाहरण के लिए:
bazel build //:my-targetछठा चरण: rules_xcodeproj की मदद से Xcode प्रोजेक्ट जनरेट करना
Bazel की मदद से बिल्ड करने पर, MODULE.bazel और BUILD फ़ाइलें, बिल्ड के बारे में सोर्स ऑफ़ ट्रुथ बन जाती हैं. Xcode को इसकी जानकारी देने के लिए, आपको
Bazel के साथ काम करने वाला Xcode प्रोजेक्ट जनरेट करना होगा. इसके लिए,
rules_xcodeproj
का इस्तेमाल करें.
समस्या का हल
Bazel में गड़बड़ियां तब हो सकती हैं, जब यह चुने गए Xcode वर्शन के साथ सिंक नहीं होता. जैसे, अपडेट लागू करने पर. अगर आपको Xcode में गड़बड़ियां आ रही हैं, तो ये तरीके आज़माएं. उदाहरण के लिए, "Apple CROSSTOOL का इस्तेमाल करने के लिए, Xcode का वर्शन तय करना ज़रूरी है".
Xcode को मैन्युअल तरीके से चलाएं और नियम और शर्तें स्वीकार करें.
Xcode select का इस्तेमाल करके, सही वर्शन बताएं. साथ ही, लाइसेंस स्वीकार करें और Bazel की स्थिति साफ़ करें.
sudo xcode-select -s /Applications/Xcode.app/Contents/Developersudo xcodebuild -licensebazel sync --configure
- अगर इससे समस्या ठीक नहीं होती है, तो
bazel clean --expungeचलाकर देखें.