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

समस्या की शिकायत करें सोर्स देखें ठीक

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

Xcode और Baज़र के बीच अंतर

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

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

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

वेब कंटेनर इंस्टॉल करने से पहले

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

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

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

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

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

Xcode के उलट, Babel के लिए यह ज़रूरी है कि आप BUILD फ़ाइल में हर टारगेट के लिए सभी डिपेंडेंसी के बारे में साफ़ तौर पर जानकारी दें.

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

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

Basel के साथ Xcode प्रोजेक्ट बनाने या टेस्ट करने के लिए, ये काम करें:

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

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

3. BUILD फ़ाइल बनाएं:

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

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

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

4. (ज़रूरी नहीं) बिल्ड को बेहतर तरीके से तैयार करना

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

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

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

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

ध्यान दें: प्रोजेक्ट सोर्स कोड को WORKSPACE फ़ाइल वाली डायरेक्ट्री ट्री में डालें.

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

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

ध्यान दें: SwiftPM सहायता एक मैन्युअल प्रोसेस है, जिसमें कई वैरिएबल होते हैं. Baज़र के साथ SwiftPM इंटिग्रेशन की पुष्टि पूरी नहीं हुई है और यह आधिकारिक तौर पर काम नहीं करता है.

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

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

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

सलाह: पैकेज और Basel के अन्य सिद्धांतों के बारे में ज़्यादा जानने के लिए, Workspace, पैकेज, और टारगेट लेख पढ़ें.

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

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

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

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

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

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

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

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

Baze के Apple बिल्ड नियम, Apple के सभी प्लैटफ़ॉर्म पर यूनिट और यूज़र इंटरफ़ेस (यूआई) टेस्ट करने की सुविधा देते हैं. टेस्ट टारगेट इस तरह जोड़ें:

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

• ios_unit_test का इस्तेमाल, iOS पर लाइब्रेरी के हिसाब से यूनिट टेस्ट बनाने और चलाने के लिए किया जाता है.

• ios_ui_test का इस्तेमाल, iOS सिम्युलेटर में यूज़र इंटरफ़ेस की जांच करने और चलाने के लिए किया जाता है.

• टेस्ट के ऐसे ही नियम, tvOS, watchOS, और visionOS के लिए भी लागू होते हैं.

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

चरण 3c: लाइब्रेरी के टारगेट जोड़ना

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

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

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

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

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

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

ध्यान दें: किसी खास टाइप के सभी सोर्स और/या हेडर शामिल करने के लिए, glob फ़ंक्शन का इस्तेमाल किया जा सकता है. इसका इस्तेमाल सोच-समझकर करें, क्योंकि इसमें ऐसी फ़ाइलें भी शामिल हो सकती हैं जिन्हें आपको Basel को बनाने की अनुमति नहीं है.

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

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

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

• मल्टी प्लैटफ़ॉर्म ऐप्लिकेशन (macOS, iOS, watchOS, tvOS)

बिल्ड रूल के बारे में ज़्यादा जानकारी के लिए, Baze के लिए Apple के नियम लेख पढ़ें.

इस समय, बिल्ड की जांच करना एक अच्छा आइडिया है:

bazel build //:<application_target>

चौथा चरण: (ज़रूरी नहीं) बिल्ड को बेहतर तरीके से तैयार करना

अगर प्रोजेक्ट बड़ा है या जैसे-जैसे यह बढ़ता जा रहा है, तो इसे कई बेज़ल पैकेज में बांटें. जानकारी के इस बेहतर लेवल से, ये चीज़ें मिलती हैं:

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

• बिल्ड टास्क पर साथ में ज़्यादा काम करना,

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

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

प्रोजेक्ट की जानकारी देने के लिए सलाह:

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

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

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

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

• सभी पैकेज में यह तय करें कि वे ज़्यादा से ज़्यादा कितने लोगों को दिखें.

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

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

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

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

bazel build //:my-target

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

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

समस्या हल करना

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

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

• Xcode चुनने का इस्तेमाल करके सही वर्शन बताएं, लाइसेंस स्वीकार करें, और बेज़ल की स्थिति मिटाएं.

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

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

ध्यान दें: अगर आपने अपने Xcode को किसी दूसरे पाथ में सेव किया है, तो उस पाथ पर ले जाने के लिए, xcode-select -s का इस्तेमाल किया जा सकता है.