🙆 🌫️ 🕟 ग्रैडल परियोजना में स्काला को क्रॉस-कंपाइल करना 🥠 ⌨️ 🎟️

यह स्काला प्रोजेक्ट्स के लिए काफी सामान्य है, स्कैला संकलक के कई संस्करणों के लिए संकलित बाइनरी कलाकृतियों को प्रदान करना। एक नियम के रूप में, एक समुदाय में एक विरूपण साक्ष्य के कई संस्करण बनाने के उद्देश्य से, एसबीटी का उपयोग करने के लिए प्रथागत है, जहां यह सुविधा बॉक्स से बाहर है और कुछ लाइनों में कॉन्फ़िगर किया गया है। लेकिन क्या होगा यदि हम एसबीटी का उपयोग किए बिना क्रॉस संकलन के लिए एक उलझन पैदा करना और निर्माण करना चाहते हैं?

मेरी एक जावा परियोजना के लिए, मैंने एक स्केल मुखौटा बनाने का निर्णय लिया। ऐतिहासिक रूप से, पूरे प्रोजेक्ट को ग्रैडल का उपयोग करके इकट्ठा किया गया है, और यह एक ही परियोजना में एक सबमॉड्यूल के रूप में मुखौटा जोड़ने का निर्णय लिया गया था। एक पूरे के रूप में स्नातक स्काला मॉड्यूल को कैवेट के साथ संकलित कर सकता है कि कोई क्रॉस-संकलन समर्थन घोषित नहीं किया गया है। 2017 में एक खुला टिकट है और दो जोड़े ( 1 , 2 ) हैं जो इस सुविधा को आपकी परियोजना में जोड़ने का वादा करते हैं, लेकिन उनके साथ समस्याएं हैं, जो आमतौर पर कलाकृतियों के प्रकाशन से जुड़ी होती हैं। और सामान्य रूप से अधिक कुछ भी नहीं है। मैंने यह जांचने का निर्णय लिया कि वास्तव में विशेष प्लगिन और एसएमएस के बिना क्रॉस संकलन के लिए बिल्ड को कॉन्फ़िगर करना कितना मुश्किल है।

सबसे पहले, हम वांछित परिणाम का वर्णन करते हैं। मैं स्केल कंपाइलर के तीन संस्करणों द्वारा संकलित किए जाने वाले स्रोतों का एक ही सेट चाहूंगा: 2.11, 2.12 और 2.13 (इस समय सबसे वर्तमान 2.13.0-RC2)। और चूंकि स्कला 2.13 में संग्रह में कई पिछड़े असंगत परिवर्तन हैं, इसलिए मैं प्रत्येक कंपाइलर के लिए कोड के लिए अतिरिक्त स्रोत सेटों को जोड़ने में सक्षम होना चाहूंगा। फिर से, एसबीटी में, यह सब विन्यास की कुछ पंक्तियों में जोड़ा जाता है। आइए देखें कि ग्रैडल में क्या किया जा सकता है।

परियोजना की संरचना

पहली कठिनाई जिसका आपको सामना करना पड़ता है वह यह है कि कंपाइलर संस्करण की गणना स्काला-लाइब्रेरी पर घोषित निर्भरता के संस्करण से की जाती है। साथ ही, कंपाइलर के स्केल संस्करण के उपसर्ग वाले सभी निर्भरता को भी बदलना होगा। यानी कंपाइलर के प्रत्येक संस्करण के लिए, निर्भरता सूची अलग होनी चाहिए। इसके अलावा, संकलक के विभिन्न संस्करणों के लिए झंडे का सेट वास्तव में अलग है। कुछ झंडे संस्करणों के बीच बदल दिए गए थे, जबकि कुछ बस अप्रचलित के रूप में चिह्नित थे या पूरी तरह से हटा दिए गए थे। मैंने तय किया कि एक बिल्ड फ़ाइल में विभिन्न कंपाइलरों की सभी बारीकियों को पकड़ने की कोशिश करना बहुत मुश्किल काम है और इसके आगे का समर्थन और भी मुश्किल है। इसलिए, मैंने इस समस्या को हल करने के अन्य संभावित तरीकों का पता लगाने का फैसला किया। लेकिन क्या होगा अगर हम एक ही प्रोजेक्ट डायरेक्टरी स्ट्रक्चर के लिए कॉन्फ़िगरेशन के कई बिल्ड बनाते हैं?

ग्रैडल परियोजना में सबमॉड्यूल्स को शामिल करने की घोषणा में, आप उस निर्देशिका को निर्दिष्ट कर सकते हैं जहां सबमॉड्यूल की जड़ और इसके कॉन्फ़िगरेशन के लिए जिम्मेदार फ़ाइल का नाम स्थित होगा। आइए कई आयातों के लिए एक ही निर्देशिका निर्दिष्ट करें और कंपाइलर के प्रत्येक संस्करण के लिए बिल्ड स्क्रिप्ट की कई प्रतियां बनाएं।

settings.gradle

rootProject.name = 'test' include 'java-library' include 'scala-facade_2.11' project(':scala-facade_2.11').with { projectDir = file('scala-facade') buildFileName = 'build-2.11.gradle' } include 'scala-facade_2.12' project(':scala-facade_2.12').with { projectDir = file('scala-facade') buildFileName = 'build-2.12.gradle' } include 'scala-facade_2.13' project(':scala-facade_2.13').with { projectDir = file('scala-facade') buildFileName = 'build-2.13.gradle' }

बुरा नहीं है, लेकिन समय-समय पर हम इस तथ्य से संबंधित अजीब संकलन त्रुटियों को प्राप्त कर सकते हैं कि सभी तीन बिल्ड स्क्रिप्ट एक ही बिल्ड निर्देशिका का उपयोग करते हैं। हम इसे प्रत्येक बिल्ड के लिए सेट करके ठीक कर सकते हैं:

निर्माण 2.12.gradle

 plugins { id 'scala' } buildDir = 'build-2.12' clean { delete 'build-2.12' } // ...

अब यह बहुत सुंदर है। केवल एक समस्या के साथ, कि इस तरह के एक निर्माण से आपके पसंदीदा आईडीई पागल हो जाएगा, और सबसे अधिक संभावना है कि आपके प्रोजेक्ट का संपादन साधनों का उपयोग करके किया जाएगा। मुझे लगा कि यह कोई बड़ी मुसीबत नहीं है, क्योंकि आप हमेशा सबमोडुल्स के अतिरिक्त आयात पर टिप्पणी कर सकते हैं और क्रॉस बिल्ड को एक नियमित बिल्ड में बदल सकते हैं, जिसके साथ आपका आईडीई सबसे अधिक जानता है कि कैसे काम करना है।

अतिरिक्त स्रोत सेट के बारे में क्या? फिर, अलग-अलग फ़ाइलों के साथ, यह काफी सरल हो गया, एक नई निर्देशिका बनाएं और इसे एक स्रोत सेट के रूप में कॉन्फ़िगर करें।

निर्माण 2.12.gradle

 // ... sourceSets { compat { scala { srcDir 'src/main/scala-2.12-' } } main { scala { compileClasspath += compat.output } } test { scala { compileClasspath += compat.output runtimeClasspath += compat.output } } } // ...

निर्माण 2.13.gradle

 // ... sourceSets { compat { scala { srcDir 'src/main/scala-2.13+' } } main { scala { compileClasspath += compat.output } } test { scala { compileClasspath += compat.output runtimeClasspath += compat.output } } } // ...

परियोजना की अंतिम संरचना इस प्रकार है:

अंतिम परियोजना

यहां आप बाहरी कॉन्फ़िगरेशन फ़ाइलों में अलग-अलग सामान्य टुकड़ों को भी अलग कर सकते हैं और पुनरावृत्ति की संख्या को कम करने के लिए उन्हें बिल्ड में आयात कर सकते हैं। लेकिन मेरे लिए यह बहुत अच्छी तरह से, घोषित रूप से, पृथक, और सभी संभव ग्रेड प्लगइन्स के साथ संगत निकला।

कुल मिलाकर, समस्या हल हो गई थी, ग्रैगल का लचीलापन काफी गैर-तुच्छ सेटअप को काफी सुरुचिपूर्ण ढंग से व्यक्त करने के लिए पर्याप्त था, और स्काला क्रॉस बिल्ड न केवल एसबीटी का उपयोग करना संभव है, और यदि एक कारण या किसी अन्य के लिए आप एक अवसर के रूप में क्रॉस प्रोजेक्ट का निर्माण करने के लिए ग्रेड का उपयोग करते हैं, तो आप के लिए एक अवसर के रूप में पार संकलन भी उपलब्ध है। मुझे उम्मीद है कि यह पोस्ट किसी के लिए उपयोगी होगी। आपका ध्यान के लिए धन्यवाद।

ग्रैडल परियोजना में स्काला को क्रॉस-कंपाइल करना

More articles: