Xcode से Bazel पर माइग्रेट करना

इस पेज पर, Bazel की मदद से Xcode प्रोजेक्ट बनाने या उसकी जांच करने का तरीका बताया गया है. इसमें, Xcode और Bazel के बीच के अंतर के बारे में बताया गया है. साथ ही, Xcode प्रोजेक्ट को Bazel प्रोजेक्ट में बदलने का तरीका भी बताया गया है. यह सामान्य गड़बड़ियों को हल करने के लिए, समस्या हल करने के तरीके भी उपलब्ध कराता है.

Xcode और Bazel के बीच अंतर

• Bazel के लिए, आपको हर बिल्ड टारगेट और उसकी डिपेंडेंसी के साथ-साथ, बिल्ड नियमों के ज़रिए उससे जुड़ी बिल्ड सेटिंग के बारे में साफ़ तौर पर बताना होगा.

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

• Bazel की मदद से Xcode प्रोजेक्ट बनाते समय, BUILD फ़ाइलें सटीक जानकारी का सोर्स बन जाती हैं. अगर Xcode में प्रोजेक्ट पर काम किया जा रहा है, तो आपको BUILD फ़ाइलों को अपडेट करने पर, rules_xcodeproj का इस्तेमाल करके, Xcode प्रोजेक्ट का नया वर्शन जनरेट करना होगा. यह वर्शन, BUILD फ़ाइलों से मेल खाता है. BUILD फ़ाइलों में कुछ बदलावों के लिए, जैसे कि किसी टारगेट में डिपेंडेंसी जोड़ना के लिए प्रोजेक्ट को फिर से जनरेट करने की ज़रूरत नहीं है. इससे डेवलपमेंट की रफ़्तार बढ़ सकती है. अगर Xcode का इस्तेमाल नहीं किया जा रहा है, तो bazel build और bazel test कमांड की मदद से, ऐप्लिकेशन को बिल्ड और टेस्ट किया जा सकता है. हालांकि, इसके लिए कुछ सीमाएं हैं. इन सीमाओं के बारे में इस गाइड में आगे बताया गया है.

शुरू करने से पहले

शुरू करने से पहले, ये काम करें:

1. अगर आपने पहले से ऐसा नहीं किया है, तो Baze इंस्टॉल करें.

2. अगर आपको Bazel और इसके कॉन्सेप्ट के बारे में जानकारी नहीं है, तो iOS ऐप्लिकेशन ट्यूटोरियल पूरा करें. आपको Basel के वर्कस्पेस के साथ-साथ, WORKSPACE और BUILD फ़ाइलों के बारे में भी पता होना चाहिए. इसके अलावा, आपको टारगेट, बिल्ड रूल, और Babel पैकेज के बारे में भी जानकारी होनी चाहिए.

3. प्रोजेक्ट की डिपेंडेंसी का विश्लेषण करना और उसे समझना.

प्रोजेक्ट डिपेंडेंसी का विश्लेषण करना

Xcode के उलट, Bazel में आपको BUILD फ़ाइल में हर टारगेट के लिए, सभी डिपेंडेंसी के बारे में साफ़ तौर पर बताना होगा.

बाहरी डिपेंडेंसी के बारे में ज़्यादा जानने के लिए, बाहरी डिपेंडेंसी के साथ काम करना लेख पढ़ें.

Basel की मदद से Xcode प्रोजेक्ट बनाएं या टेस्ट करें

Bazel की मदद से Xcode प्रोजेक्ट बनाने या उसकी जांच करने के लिए, यह तरीका अपनाएं:

1. WORKSPACE फ़ाइल बनाना

2. (प्रयोग के तौर पर) SwiftPM डिपेंडेंसी इंटिग्रेट करें

3. BUILD फ़ाइल बनाने के लिए:

   a. ऐप्लिकेशन टारगेट जोड़ना

   b. (ज़रूरी नहीं) टेस्ट टारगेट जोड़ना

   c. लाइब्रेरी टारगेट जोड़ना

4. (ज़रूरी नहीं) बेहतर तरीके से बने बाइनरी

5. बिल्ड चलाना

6. rules_xcodeproj की मदद से Xcode प्रोजेक्ट जनरेट करना

पहला चरण: WORKSPACE फ़ाइल बनाना

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

दूसरा चरण: (प्रयोग के तौर पर) SwiftPM डिपेंडेंसी इंटिग्रेट करना

swift_bazel की मदद से, SwiftPM डिपेंडेंसी को Bazel वर्कस्पेस में इंटिग्रेट करने के लिए, आपको उन्हें Bazel पैकेज में बदलना होगा. इसके बारे में इस ट्यूटोरियल में बताया गया है.

तीसरा चरण: BUILD फ़ाइल बनाना

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

• चरण 3a: ऐप्लिकेशन टारगेट जोड़ना
• तीसरा चरण (ज़रूरी नहीं): टेस्ट टारगेट जोड़ना
• तीसरा चरण: लाइब्रेरी टारगेट जोड़ना

सलाह: पैकेज और Bazel के अन्य कॉन्सेप्ट के बारे में ज़्यादा जानने के लिए, फ़ाइल फ़ोल्डर, पैकेज, और टारगेट लेख पढ़ें.

चरण 3a: ऐप्लिकेशन टारगेट जोड़ना

macos_application या ios_application नियम का टारगेट जोड़ें. यह टारगेट, macOS या iOS ऐप्लिकेशन बंडल बनाता है. टारगेट में, कम से कम ये चीज़ें बताएं:

• bundle_id - बाइनरी का बंडल आईडी (ऐप्लिकेशन के नाम के बाद रिवर्स-डीएनएस पाथ).

• provisioning_profile - अपने Apple Developer खाते से प्रोविज़निंग प्रोफ़ाइल (अगर iOS डिवाइस के लिए बनाना है).

• families (सिर्फ़ iOS के लिए) - यह तय करना कि ऐप्लिकेशन को iPhone, iPad या दोनों के लिए बनाना है या नहीं.

• infoplists - फ़ाइनल Info .plist फ़ाइल में मिलने के लिए.plist फ़ाइलों की सूची.

• minimum_os_version - macOS या iOS का कम से कम वर्शन, जो इस ऐप्लिकेशन पर काम करता हो. इससे यह पक्का होता है कि Bazel, ऐप्लिकेशन को सही एपीआई लेवल के साथ बनाए.

तीसरा चरण: (ज़रूरी नहीं) टेस्ट टारगेट जोड़ना

Bazel के Apple के लिए बने बिल्ड नियम, iOS और macOS पर लाइब्रेरी पर आधारित यूनिट टेस्ट चलाने के साथ-साथ, macOS पर ऐप्लिकेशन पर आधारित टेस्ट चलाने की सुविधा देते हैं. iOS या किसी भी प्लैटफ़ॉर्म पर यूज़र इंटरफ़ेस (यूआई) टेस्ट पर ऐप्लिकेशन-आधारित टेस्ट करने के लिए, Basel, टेस्ट आउटपुट तैयार करेगा, लेकिन टेस्ट को criteria_xcodeproj के साथ जनरेट किए गए प्रोजेक्ट के ज़रिए Xcode में चलाया जाना चाहिए. टेस्ट टारगेट इस तरह जोड़ें:

• macOS पर लाइब्रेरी-आधारित और ऐप्लिकेशन-आधारित यूनिट टेस्ट चलाने के लिए, macos_unit_test.

• ios_unit_test iOS पर लाइब्रेरी पर आधारित यूनिट टेस्ट चलाने के लिए. जिन टेस्ट के लिए iOS सिम्युलेटर की ज़रूरत होती है उनके लिए, Bazel टेस्ट के आउटपुट बना देगा, लेकिन टेस्ट नहीं चलाएगा. आपको rules_xcodeproj की मदद से Xcode प्रोजेक्ट जनरेट करना होगा और Xcode में जाकर टेस्ट चलाने होंगे.

• ios_ui_test का इस्तेमाल, iOS सिम्युलेटर में यूज़र इंटरफ़ेस की जांच करने के लिए ज़रूरी आउटपुट बनाने के लिए किया जाता है. इसके लिए, Xcode का इस्तेमाल करें. आपको Terms_xcodeproj के साथ Xcode प्रोजेक्ट जनरेट करना होगा और Xcode में टेस्ट चलाना होगा. Bazel, यूज़र इंटरफ़ेस (यूआई) टेस्ट को नेटिव तौर पर नहीं चला सकता.

कम से कम, minimum_os_version एट्रिब्यूट की वैल्यू सबमिट करें. हालांकि, bundle_identifier और infoplists जैसे अन्य पैकेजिंग एट्रिब्यूट, सबसे ज़्यादा इस्तेमाल होने वाली वैल्यू पर डिफ़ॉल्ट रूप से सेट होते हैं. हालांकि, पक्का करें कि ये डिफ़ॉल्ट एट्रिब्यूट, प्रोजेक्ट के साथ काम करते हों और ज़रूरत के मुताबिक उनमें बदलाव करें. जिन टेस्ट के लिए iOS सिम्युलेटर की ज़रूरत होती है उनके लिए, test_host एट्रिब्यूट की वैल्यू के तौर पर ios_application टारगेट का नाम भी बताएं.

तीसरा चरण: लाइब्रेरी टारगेट जोड़ना

हर Objective-C लाइब्रेरी के लिए objc_library टारगेट और हर उस Swift लाइब्रेरी के लिए swift_library टारगेट जोड़ें जिस पर ऐप्लिकेशन और/या टेस्ट निर्भर करते हैं.

लाइब्रेरी के टारगेट इस तरह जोड़ें:

• ऐप्लिकेशन लाइब्रेरी टारगेट को ऐप्लिकेशन टारगेट पर डिपेंडेंसी के तौर पर जोड़ें.

• टेस्ट लाइब्रेरी टारगेट को, टेस्ट टारगेट की डिपेंडेंसी के तौर पर जोड़ें.

• srcs एट्रिब्यूट में, लागू करने के सोर्स की सूची बनाएं.

• hdrs एट्रिब्यूट में हेडर की सूची बनाएं.

अलग-अलग तरह के ऐप्लिकेशन के मौजूदा उदाहरणों को सीधे rules_apple examples directory में ब्राउज़ किया जा सकता है. उदाहरण के लिए:

• macOS ऐप्लिकेशन के टारगेट

• iOS ऐप्लिकेशन टारगेट

• एक से ज़्यादा प्लैटफ़ॉर्म वाले ऐप्लिकेशन (macOS, iOS, watchOS, tvOS)

बिल्ड नियमों के बारे में ज़्यादा जानने के लिए, Bazel के लिए Apple के नियम देखें.

इस समय, बिल्ड की जांच करना बेहतर होगा:

bazel build //:<application_target>

चौथा चरण: (ज़रूरी नहीं) बाइनरी को ज़्यादा बेहतर बनाना

अगर प्रोजेक्ट बड़ा है या आगे चलकर बड़ा हो जाता है, तो उसे कई Bazel पैकेज में बांटें. ज़्यादा जानकारी देने से ये फ़ायदे मिलते हैं:

• बिल्ड की बढ़ती हुई क्षमता,

• बिल्ड टास्क को एक साथ चलाने की सुविधा को बेहतर बनाया गया है,

• आने वाले समय में, उपयोगकर्ताओं के लिए बेहतर रखरखाव,

• सभी टारगेट और पैकेज में सोर्स कोड की विज़िबिलिटी को बेहतर तरीके से कंट्रोल किया जा सकता है. इससे, लाइब्रेरी में लागू करने की जानकारी, सार्वजनिक एपीआई में लीक होने जैसी समस्याओं से बचा जा सकता है.

प्रोजेक्ट के बारे में ज़्यादा जानकारी देने के लिए सलाह:

• हर लाइब्रेरी को उसके अपने Basel पैकेज में रखें. सबसे कम डिपेंडेंसी वाले डिपेंडेंसी ट्री से शुरू करें और ऊपर की ओर बढ़ें.

• BUILD फ़ाइलें जोड़ने और टारगेट तय करने के दौरान, इन नए टारगेट को उन टारगेट के deps एट्रिब्यूट में जोड़ दें जो उन पर निर्भर करते हैं.

• glob() फ़ंक्शन, पैकेज की सीमाओं को पार नहीं करता. इसलिए, पैकेज की संख्या बढ़ने पर, glob() से मैच होने वाली फ़ाइलों की संख्या कम हो जाएगी.

• main डायरेक्ट्री में BUILD फ़ाइल जोड़ते समय, उससे जुड़ी test डायरेक्ट्री में भी BUILD फ़ाइल जोड़ें.

• सभी पैकेज के लिए, विज्ञापन दिखने की सीमाएं लागू करें.

• BUILD फ़ाइलों में हर बड़े बदलाव के बाद, प्रोजेक्ट बनाएं और बिल्ड में आने वाली गड़बड़ियां ठीक करें.

पांचवां चरण: बिल्ड चलाना

पूरी तरह माइग्रेट किए गए बिल्ड को चलाकर, पक्का करें कि यह बिना किसी गड़बड़ी या चेतावनी के पूरा हो जाए. हर ऐप्लिकेशन और टेस्ट टारगेट को अलग-अलग चलाएं, ताकि किसी भी गड़बड़ी के सोर्स को आसानी से ढूंढा जा सके.

उदाहरण के लिए:

bazel build //:my-target

छठा चरण: rules_xcodeproj की मदद से Xcode प्रोजेक्ट जनरेट करना

Basel के साथ बनाते समय, WORKSPACE और BUILD फ़ाइलें बिल्ड की सच का स्रोत बन जाती हैं. Xcode को इसके बारे में बताने के लिए, आपको rules_xcodeproj का इस्तेमाल करके एक ऐसा Xcode प्रोजेक्ट जनरेट करना होगा जो Baze के साथ काम करता हो.

समस्या का हल

Bazel में गड़बड़ियां तब हो सकती हैं, जब यह चुने गए Xcode वर्शन के साथ सिंक न हो. जैसे, अपडेट लागू करने पर. अगर आपको Xcode के साथ गड़बड़ी हो रही है, तो इसे आज़माने के लिए यहां कुछ चीज़ें दी गई हैं, उदाहरण के लिए "Apple CROSSTOOL का इस्तेमाल करने के लिए Xcode वर्शन तय होना ज़रूरी है".

• Xcode को मैन्युअल तरीके से चलाएं और सभी नियम और शर्तें स्वीकार करें.

• सही वर्शन दिखाने, लाइसेंस स्वीकार करने, और Bazel की स्थिति को हटाने के लिए, Xcode select का इस्तेमाल करें.

  sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
  sudo xcodebuild -license
  bazel sync --configure

• अगर यह तरीका काम नहीं करता है, तो bazel clean --expunge को चलाकर भी देखें.