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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

इस पेज पर, 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 कमांड की मदद से, ऐप्लिकेशन को बिल्ड और टेस्ट किया जा सकता है. हालांकि, इसके लिए कुछ सीमाएं हैं. इन सीमाओं के बारे में इस गाइड में आगे बताया गया है.

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

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

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

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

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

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

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

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

Bazel की मदद से Xcode प्रोजेक्ट बनाना या उसका टेस्ट करना

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

1. MODULE.bazel फ़ाइल बनाना

2. (एक्सपेरिमेंटल) SwiftPM डिपेंडेंसी इंटिग्रेट करना

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

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

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

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

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

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

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

पहला चरण: MODULE.bazel फ़ाइल बनाना

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

ध्यान दें: प्रोजेक्ट का सोर्स कोड, डायरेक्ट्री ट्री में उस जगह पर रखें जहां MODULE.bazel फ़ाइल मौजूद है.

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

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

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

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

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

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

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

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

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 के लिए बने बिल्ड नियम, Apple के सभी प्लैटफ़ॉर्म पर यूनिट और यूज़र इंटरफ़ेस (यूआई) टेस्ट चलाने की सुविधा देते हैं. टेस्ट टारगेट इस तरह जोड़ें:

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

• ios_unit_test iOS पर लाइब्रेरी पर आधारित यूनिट टेस्ट बनाने और चलाने के लिए.

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

• tvOS, watchOS, और visionOS के लिए भी टेस्ट के मिलते-जुलते नियम मौजूद हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

बिल्ड नियमों के बारे में ज़्यादा जानने के लिए, 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 को इस बारे में बताने के लिए, आपको rules_xcodeproj का इस्तेमाल करके, Bazel के साथ काम करने वाला Xcode प्रोजेक्ट जनरेट करना होगा.

समस्या का हल

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 को चलाकर भी देखें.

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