Qt क्रिएटर 2.3 और रिमोट लिनक्स डिप्लॉय

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

यह मेरे लिए दिलचस्प क्यों था? हाँ, क्योंकि:
1) हमारे कार्यालय में हमारे पास एक लोहे का एक टुकड़ा है , जिसके लिए क्यूटी / एंबेडेड + लिनक्स पर आधारित हमारे अपने फर्मवेयर को धीरे-धीरे देखा जा रहा है।
2) क्यूटी का उपयोग करके लिखे गए कार्यक्रमों में से किसी के अगले संस्करण का क्रॉस-संकलन, तैनाती और डिबगिंग, जैसा कि आप अनुमान लगा सकते हैं, उपयोग करने की आवश्यकता को देखते हुए अविश्वसनीय खुशी और यौन संतुष्टि देता है।
बिल्ड, एस, परिनियोजन, और बहुत कुछ जैसे स्व-निर्मित स्क्रिप्ट का एक गुच्छा।
3) उत्पादकता नीचे जाती है (लेकिन झुंझलाहट का स्तर ऊपर जाता है) और मैंने एंड्रॉइड एंड्रॉइड फोन पर पैकेजों को तैनात करने की विधि को चोरी करने के लिए एंड्रॉइड-लाइटहाउस स्रोत कोड में खुदाई करना शुरू कर दिया ... भगवान का शुक्र है कि मैंने कुछ भी लिखने का प्रबंधन नहीं किया है)।

हमें क्या दिया जा रहा है? जैसा कि आप पहले जानते हैं, क्यूटी निर्माता के पास पहले से ही सिम्बियन (USB-MicroUSB के माध्यम से) और मैमो (ssh के माध्यम से) के लिए एप्लिकेशन को तैनात करने के लिए उपकरण थे। जाहिरा तौर पर इस संस्करण में, डेवलपर्स ने विचार को दिमाग में लाने का फैसला किया और, मैमो तैनाती उपकरण के एकीकरण के कारण, उन्हें साधारण लिनक्स मशीनों पर अनुप्रयोगों को तैनात करने की अनुमति दी।

हमारे निपटान में सेटिंग्स में नए टैब के एक जोड़े हैं:

• इंस्ट्रूमेंटेशन - यहां आप कंपाइलर को निर्दिष्ट कर सकते हैं। बेशक, एक सरल और एक क्रॉस-कंपाइलर दोनों।
• लिनक्स डिवाइस - यहां आप रिमोट मशीन पर इकट्ठे एप्लिकेशन की तैनाती सेटिंग्स देख सकते हैं

चलो चलते हैं

प्रारंभिक शर्तें:
मुख्य लिनक्स-मशीन, जिस पर क्यूटी निर्माता 2.3 बीटा विकास वातावरण खड़ा है, जीडीबी है और आवश्यक कार्यक्रम के लिए स्रोत कोड हैं।
Ssh एक्सेस और gdbserver स्थापित रिमोट लिनक्स डिवाइस।
असेंबली के लिए क्रॉस-टूलचेन (संकलित क्यूटी / एंबेडेड ऑफ कोर्स) और क्रॉस-कंपाइलर के साथ। जो, उदाहरण के लिए, जैसा कि मेरे मामले में है, स्रोत के समान मशीन पर कभी झूठ नहीं बोलना चाहिए, लेकिन पड़ोसी सर्वर पर भी)। वह निफ्गा कार्यों को सुविधाजनक नहीं बनाता है ... लेकिन फिर भी मैं इसे इस उदाहरण के साथ समझाऊंगा। बिल्डरोट का उपयोग टूलकिट के रूप में किया जाता है, कोडरचरी का उपयोग कंपाइलरों के सेट के रूप में किया जाता है। मंच - एआरएम (armv7a)।

तो, पहली बात यह है कि क्यूटी के क्रॉस-संकलित संस्करण के बारे में क्यूमेक से कुछ के बारे में पूछें ... नम्रतापूर्वक, उस मशीन पर जाएं जिस पर हमारे पास क्रॉस-बिल्ड टूल हैं और ऐसा कुछ करें:

# /root/openaos/br11_glibc_building/output/staging/usr/bin/qmake -v QMake version 2.01a Using Qt version 4.7.1 in /root/openaos/br11_glibc_building/output/staging/usr/lib 

हमारे पुस्तकालय के स्थान के बारे में इस तरह के संकेत। बस मामले में, फ़ाइल को देखें

 /root/openaos/br11_glibc_building/output/staging/usr/mkspecs/qws/linux-arm-g++/qmake.conf 

यह सुनिश्चित करने के लिए कि टूलचिन को इंगित किया गया है, काफी सही है:

 QMAKE_LFLAGS = -L/root/openaos/br11_glibc_building/output/staging/lib -L/root/openaos/br11_glibc_building/output/staging/usr/lib QMAKE_CXXFLAGS = --sysroot=/root/openaos/br11_glibc_building/output/staging -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -Os -mtune=cortex-a8 -march=armv7-a -mab$ QMAKE_CFLAGS = --sysroot=/root/openaos/br11_glibc_building/output/staging -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -Os -mtune=cortex-a8 -march=armv7-a -mabi=$ QMAKE_STRIP = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-strip QMAKE_RANLIB = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-ranlib QMAKE_OBJCOPY = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-objcopy QMAKE_AR = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-ar cqs QMAKE_LINK_SHLIB = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-g++ --sysroot=/root/openaos/br11_glibc_building/output/staging QMAKE_LINK = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-g++ --sysroot=/root/openaos/br11_glibc_building/output/staging QMAKE_CXX = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-g++ QMAKE_CC = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-gcc 

प्रारंभिक तैयारी का अगला चरण sshfs के लिए सभी आवश्यक निर्देशिकाओं को माउंट करना है ताकि टूलचैन और अन्य लोगों ने उन्हें कहीं भी माउंट न किया हो, लेकिन उसी मशीन पर बहुत खुशी से रहते हैं जहां उन्हें होना चाहिए। जैसा कि आप अनुमान लगा सकते हैं, आपको 2 निर्देशिकाओं को माउंट करना होगा: / रूट / कोडरचेरी / और / रूट / ओपनऑस / br11_glibc_building /

कर रहा है ...

 $ sudo chmod 777 /root $ cd /root $ mkdir oabroot $ sshfs root@openaos-build.lan.arta.kz:/ oabroot/ $ ln -s oabroot/root/openaos/ ./ $ ln -s oabroot/root/codesourcery/ ./ $ ls -l  4 lrwxrwxrwx 1 kafeg kafeg 26 2011-07-22 16:10 codesourcery -> oabroot/root/codesourcery/ drwxr-xr-x 1 root root 4096 2011-07-13 08:44 oabroot lrwxrwxrwx 1 kafeg kafeg 21 2011-07-22 16:10 openaos -> oabroot/root/openaos/ 

हां, मुझे पता है, निश्चित रूप से रूट निर्देशिका को ऐसे अधिकार देना थोड़ा बदसूरत है और आम तौर पर बोनी दिखता है ... लेकिन क्या करें जब आप इस सभी असेंबली कचरे को उजागर करते हैं, तो थोड़ा अनुभव और समय था ... और एक आभासी मशीन पर, रूट का उपयोग क्यों करें?

फिर भी, हम जारी रखते हैं। वास्तव में, इस समय, विधानसभा उपकरण पहले से ही हमारे मेजबान मशीन पर उपलब्ध हैं, और यदि आप ls / root / openaos / br11_glibc_building / output / staging / usr / lib जैसा कुछ निष्पादित करते हैं, तो आप लापता निर्देशिका के बारे में संदेश नहीं प्राप्त कर सकते हैं, लेकिन काफी पर्याप्त, कम से कम और बाधित ls प्रतिक्रिया, सैकड़ों फाइलों के आउटपुट। कभी-कभी तो ऐसा भी लगता है कि आखिर ये सब क्यों जरूरी है ... =)

ठीक है। निर्माता को चलाएँ और सेटिंग्स पर जाएँ। सबसे पहले, यह नव निर्मित क्यूटी के रास्ते को इंगित करने के लायक है (इस क्षण में कुछ बस्ती मर गई, जिसने मुझे एक स्तूप में डाल दिया, लेकिन जहां हमारा गायब नहीं हुआ ...):


तस्वीर से यह स्पष्ट है कि विकास के माहौल ने पुस्तकालय और अन्य कचरा पाया, लेकिन बहुत परेशान था कि वह नहीं जानती थी कि यह सब कैसे संकलित किया जाए और टूलचिन को कहां से लाया जाए। समझाएं ...

ऐसा करने के लिए, "टूलकिट" अनुभाग पर जाएं, एक नया जीसीसी प्रकार संकलक जोड़ें और आवश्यक फ़ील्ड भरें - संकलक और डिबगर का पथ:


एक बार फिर, हम क्यूटी सेक्शन और वॉयला में लौटते हैं, गायब टूलचिन के बारे में संदेश गायब हो जाते हैं:


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


क्या उल्लेखनीय है, अगर आप रिमोट मशीन पर पासवर्ड नहीं रखना चाहते हैं, तो आप तुरंत कनेक्शन सेटिंग्स इंटरफ़ेस से एसएच कीज़ की एक जोड़ी उत्पन्न कर सकते हैं और यहां तक ​​कि सार्वजनिक कुंजी को डिवाइस पर भी तैनात कर सकते हैं। और फिर शांति से पासवर्ड हटाएं या पासवर्ड भूल जाएं ... सच है, एक बग अभी भी यहां मौजूद है। सार्वजनिक कुंजी को <उपयोगकर्ता निर्देशिका> / में दर्ज किया जाएगा। ssh / अधिकृत_की और इसलिए कुंजी प्राधिकरण काम करेगा यदि एक पूर्ण ssh सर्वर डिवाइस पर स्थापित किया गया है, और कुछ ड्रॉपबियर नहीं है, उदाहरण के लिए। यह आइटम "डिवाइस प्रकार" पर भी ध्यान देने योग्य है, जो बताता है कि कुछ भी हमें वर्चुअल मशीन पर हमारे रिमोट लिनक्स को चलाने से रोकता है। हालांकि यह पहले से ही स्पष्ट था ...

OK पर क्लिक करें और सेटिंग्स डायलॉग को बंद करें। क्या वह सब है? अंजीर =)

लोहे के टुकड़े से संबंधित परियोजना खोलें, टैब पर जाएं "प्रोजेक्ट्स" और विधानसभा की कॉन्फ़िगरेशन को हमें जिस पर ज़रूरत है उसे बदल दें।


जैसा कि आप देख सकते हैं, कॉन्फ़िगरेशन बदलते समय, आवश्यक क्यूटी संस्करण और आवश्यक टूलचैन स्वचालित रूप से चुने गए थे। सच है, यहां हम अभी भी दूसरी बग की प्रतीक्षा कर रहे हैं - कोई भी बात नहीं है कि क्यूटी प्रोफाइल का चयन किया गया है, डिफ़ॉल्ट रूप से -spec पैरामीटर linux-g ++ के बराबर होगा। और हमें "-spec qws / linux-arm-g-++" की आवश्यकता है, जिसे क्यूमेक बिल्ड चरण के "उन्नत विकल्प" फ़ील्ड में लिखकर ठीक किया जा सकता है। यदि ऐसा नहीं किया जाता है, तो निश्चित रूप से भयानक गलतियों का एक गुच्छा होगा:

 ... qatomic_arm.h:131: Error: no such instruction: `swpb %dl,%al,[%ebx]' ... 

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

 unix:!symbian:!maemo5:isEmpty(MEEGO_VERSION_MAJOR) { target.path = /opt/authorize/bin INSTALLS += target } 

अगला, थोड़ा कम हम एप्लिकेशन लॉन्च का एक नया संस्करण जोड़ते हैं - "बिन_नाम (रिमोट)", उदाहरण के लिए एक पैरामीटर जोड़ें "-qws", क्योंकि यह अभी भी लाइब्रेरी के एंबेडेड संस्करण के लिए एक आवेदन है। यह कुछ इस प्रकार है:


पहले से ही बुरा नहीं है ... आगे क्या है? अगला - इकट्ठा करने की कोशिश करो! संपादक -> बिल्ड (Esc -> Ctrl + R)। और तब तक प्रतीक्षा करें जब तक हमारा आवेदन इकट्ठा न हो जाए। मेरे मामले में, यह सबसे लंबी प्रक्रिया है ...

एक कॉफी है? अब अपने हार्डवेयर के टुकड़े को देखें ... क्या आपकी एप्लिकेशन विंडो वहां दिखाई दी है? यदि सब कुछ सही ढंग से एक साथ चला गया, तो यह पहले से ही होना चाहिए ...

बस ... यदि आपकी परियोजना में, वास्तविक अनुप्रयोगों के अलावा, साझा पुस्तकालय भी हैं, तो डिवाइस को अपलोड करने के लिए टार आर्काइव बनाने के चरण में, एक त्रुटि:

 Creating package file ... Error reading file '/root/oabroot/*/libqmlgestureareaplugin.so.1': No such file or directory.      artagui (: Desktop)       «Create tarball» 

यह निश्चित रूप से ठीक करना आसान है, लेकिन अभी भी आवेदन विधानसभा के अंत में इस तरह के त्रुटि संदेश प्राप्त करना बहुत अच्छा नहीं है। हमें इस परियोजना में शामिल सभी साझा पुस्तकालयों के लिए कुछ ऐसा करना होगा:

 $ ln -s /root/oabroot/*/libqmlgestureareaplugin.so /root/oabroot/*/libqmlgestureareaplugin.so.1 $ ln -s /root/oabroot/*/libqmlgestureareaplugin.so /root/oabroot/*/libqmlgestureareaplugin.so.1.0 $ ln -s /root/oabroot/*/libqmlgestureareaplugin.so /root/oabroot/*/libqmlgestureareaplugin.so.1.0.0 

और अंत में, अंतिम सुधार के बाद, आप विकास पर्यावरण के अंतिम लॉग को देख सकते हैं, जो पहले से ही इसकी तत्परता के बारे में चिल्लाता है:


और एप्लिकेशन लॉन्च लॉग खुशी से चिल्लाता है:

 Killing remote process(es)... Starting remote process ... Remote process started. Killing remote process(es)... 

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

यहाँ एक विशेषता है कि एक बार फिर से पता चलता है कि:
a) सॉफ्टवेयर डेवलपमेंट सरल हो सकता है
बी) क्यूटी डेवलपर्स मुख्य रूप से अपने उपयोगकर्ताओं (यानी, अपने उत्पाद का उपयोग करने वाले) के बारे में सोचते हैं और एक पूरे के रूप में पुस्तकालय की उत्पादकता और आकर्षण बढ़ाने के लिए हर संभव प्रयास करते हैं।

धन्यवाद, मुझे आशा है कि कोई उपयोगी होगा।