Qt बिल्ड सिस्टम: बिल्ड लाइफबॉय

नोट (06/17/2013): लेख के उदाहरणों का वाक्य-विन्यास नवीनतम संस्करणों के अनुरूप नहीं है। प्रलेखन की जाँच करें। इसके अलावा मार्च में, क्यूबीएस निर्माता QBS समर्थन के साथ 2.7 जारी किया गया था।
बहुत समय पहले नहीं, क्यूटी विकास टीम ने एक नई बिल्ड प्रणाली - क्यूबीएस शुरू की। बेशक, मुख्य प्रतिक्रिया यह थी कि "आप क्यूएमकेई क्यों सूट नहीं करते?", "बस CMAKE अनुकूलित करें", "एक और बिल्ड सिस्टम [xkcd, standard]"। नई प्रणाली का वादा किया लाभ: सभी डेवलपर्स के लिए लचीलापन, स्पष्ट वाक्यविन्यास (क्यूएमएल एक जावास्क्रिप्ट जैसी घोषणात्मक भाषा है), बिल्ड की गति (शुद्ध और वृद्धिशील), साथ ही आसान एक्स्टेंसिबिलिटी।
हमने यह सब कुछ पहले ही सुना है, इसलिए इस लेख में हम यह पता लगाने की कोशिश करेंगे कि डेवलपर्स इस प्रणाली में कैसे आए, सबसे सरल उदाहरणों पर विचार करें, बुनियादी निर्माणों की जांच करें और देखें कि फिलहाल IDE स्तर पर क्या समर्थन मौजूद है।

कहानी

साथ में, हम Jörg बोर्नमैन, QBS डेवलपर के मार्ग का अनुसरण करने का प्रयास करेंगे।

बनाने की आलोचना (और डेरिवेटिव)

पीटर मिलर का 1999 का लेख पुनरावर्ती मेक और आम तौर पर मेकफाइल्स की सुविधा के मुद्दे को संबोधित करता है।

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

2005 के एड्रियन निएग लेख में अधिक सामान्य समस्याओं पर चर्चा की गई है:

• मेक की पोर्टेबिलिटी बहुत बढ़ जाती है, क्योंकि मेक-अप स्वयं काम नहीं करता है, दर्जनों अन्य उपयोगिताओं जो प्लेटफ़ॉर्म-विशिष्ट हैं, को मेकफाइल में निर्दिष्ट किया जा सकता है;
• पुनरावर्ती मेक (पिछले लेख की तरह ही राय) का उपयोग करते समय स्केलेबिलिटी भयानक है, और शामिल या अन्य एक्सटेंशन का उपयोग करते समय पर्याप्त नहीं है। विशेष रूप से, विधानसभा प्रदर्शन बहुत तेज़ी से गिरता है।

" क्या गलत है GNU मेक के साथ " लेख में
भाषा के minuses और समान समस्याओं को पहले की तरह अधिक विवरण में वर्णित किया गया है (मैं दोहराऊंगा नहीं)

• भाषा के गैर-स्पष्ट और स्पष्ट रूप से त्रुटिपूर्ण तत्व (जो केवल ifeq, ifneq, ifdef और iffef हैं)
• समस्याओं को टाइप करें (केवल तार के साथ काम करें)
• कमांड लाइन विकल्प बदलते समय खराब निर्भरता संकल्प
• एक ही समय में चलने और समानांतर होने की समस्या
• कार्यक्रम को अचानक रोककर असेंबली ट्री को "मार" करना आसान है।
• और कई अन्य छोटे जाम हैं जो आधुनिक आवश्यकताओं (लेखक के अनुसार) के लिए अनुपयुक्त वास्तुकला का संकेत देते हैं।

इयान लांस टेलर , 2007 द्वारा एक संक्षिप्त टिप्पणी में, मेक ही है के प्रतिस्थापन के रूप में Cmake का मुख्य दोष है। बहुत ज्यादा। मुड़ा हुआ। यह कई भाषाओं का नारकीय मिश्रण है, केवल विकास और डिबगिंग गुरु ही इसका समर्थन कर सकते हैं (वास्तव में जटिल प्रणालियों के लिए) (इसे डीबग करना भी समस्याग्रस्त है)। एक और दोष यह है कि लचीलेपन (यहां तक ​​कि लचीलेपन) के लिए, आपको उत्पन्न स्क्रिप्ट में प्रदर्शन के नुकसान के साथ भुगतान करना होगा।

QMake में क्या गलत है?

Qt अवसंरचना में, Qmake बिल्ड सिस्टम का आज व्यापक रूप से उपयोग किया जाता है, जो आधिकारिक तौर पर समर्थित है और अभी भी विकसित किया जा रहा है। "सिर्फ एक और एक" निर्माण प्रणाली की आवश्यकता क्यों थी?

मारियस स्टॉर्म-ऑलसेन लेख निम्नलिखित क्यूमेक दोषों का विश्लेषण करता है:

• स्वयं, मूल भाषा वाक्य रचना।
  
  QTDIR / mkspecs / features / अनन्य_builds.prf को देखने का प्रयास करें:
  

  DEFINES += QT_NO_CAST_TO_ASCII !macx:DEFINES += QT_USE_FAST_OPERATOR_PLUS QT_USE_FAST_CONCATENATION unix { CONFIG(debug, debug|release):OBJECTS_DIR = $${OUT_PWD}/.obj/debug-shared CONFIG(release, debug|release):OBJECTS_DIR = $${OUT_PWD}/.obj/release-shared CONFIG(debug, debug|release):MOC_DIR = $${OUT_PWD}/.moc/debug-shared CONFIG(release, debug|release):MOC_DIR = $${OUT_PWD}/.moc/release-shared RCC_DIR = $${OUT_PWD}/.rcc UI_DIR = $${OUT_PWD}/.uic } 

  
  
  इसे तुरंत समझने के लिए, "आधा लीटर" भी पर्याप्त नहीं है। हालांकि सीएमके अभी भी इससे मुकाबला कर सकती है।
  प्रोग्रामर को C ++, पास्कल, जावास्क्रिप्ट, जीत और यूनिक्स शेल और एसक्यूएल बताएं - यह सब ज्ञान बिल्ड सिस्टम को माहिर करने में बेकार हो जाएगा।
  अपने आप से, मैं उस "#" चरित्र को पथों में जोड़ सकता हूं और $ $ LITERAL_HASH के साथ उपद्रव के कारण मुझे बहुत परेशानी हुई (विशेष भाषा के पात्रों से बचने के तरीके के बारे में क्यों सोचा? चलो हमारे मैक्रोज़ को बेहतर ढंग से पेश करें)।
  
• आईडीई समर्थन।
  Qt निर्माता किसी प्रोजेक्ट में नई फ़ाइलों को जोड़ने का समर्थन करता है, लेकिन यदि आप इसके "सामान्य" सिंटैक्स से थोड़ा दूर जाते हैं, तो यह अंत में एक नया HEADERS या FILES निर्माण जोड़ सकता है।
  
• Qmake में असेंबली प्रति सैकेंड की कमी।
  Qmake आपके प्रोजेक्ट का निर्माण नहीं करता है। नाम भ्रामक है। यह केवल एक मेकफाइल उत्पन्न करता है, और असेंबली मेक यूटिलिटीज (* nix - gnu make, win-nmake, jom या mingw-make) में से एक द्वारा की जाती है।
• क्रॉस-संकलन, पैकेज बिल्डिंग और तैनाती के लिए पारदर्शी समर्थन का अभाव।

अंत में, हम उस बिंदु पर आते हैं जहां नई बिल्ड प्रणाली और इसके लिए आवश्यकताओं पर क्यूटी मेलिंग सूची में चर्चा की गई थी:

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

लाइफबॉय का परिचय - क्यूटी बिल्ड सिस्टम

15 फरवरी, 2012 को, जोर्ग बोर्नमैन ने QBS प्रोजेक्ट को Qt लैब में जनता के सामने पेश किया। अब वह अल्फा अवस्था में भी नहीं है, लेकिन कहीं बीच में प्रोटोटाइप और अल्फा संस्करण के बीच है। औचित्य में, हम कह सकते हैं कि क्यूटी निर्माता पहले से ही इसकी मदद से जा रहा है।
नई प्रणाली को डिजाइन करने के मूल सिद्धांत:

• घोषणा - क्यूएमएल सिंटैक्स का उपयोग करता है;
• एक्स्टेंसिबिलिटी - असेंबली, या कोड जनरेटर, आदि के लिए अपने स्वयं के मॉड्यूल लिखना संभव है (नीचे हम डेल्फी परियोजनाओं को इकट्ठा करने के लिए अपने खुद के मॉड्यूल को लिखने की कोशिश करेंगे);
• गति;
• डायरेक्ट असेंबली qmake नहीं है, यह "मध्यस्थ" नहीं है। Qbs खुद कंपाइलर, लिंकर, और और क्या आवश्यक है।

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

चलो कोशिश करना शुरू करते हैं!

लेखक स्रोत से क्यूब्स के निर्माण की सलाह देता है, लेकिन आप यह ध्यान रख सकते हैं कि जीत और लिनक्स उपयोगकर्ताओं के लिए बाइनरी असेंबली हैं
जीत - MSVC2010 के तहत बनाया गया। मैं गिट से एक संस्करण बनाने की भी सलाह दूंगा (मुझे प्लगइन्स और एमओसी के साथ समस्या थी)।
द्विआधारी रूप में, क्यूटी QtCore और QtScript लाइब्रेरीज़ पर निर्भर करता है (+ Qt5 के लिए समवर्ती)
आइए C ++ में एक हैलो वर्ल्ड प्रोजेक्ट बनाएं:
main.cpp

 #include <iostream> using namespace std; int main() { cout << "Hello world!" << endl; return 0; } 

हम एक न्यूनतम qbs परियोजना भी बनाते हैं:
hello.qbp

 import qbs.base 1.0 CppApplication { name: "HelloWorld" files: "main.cpp" } 

लिनक्स:
1. वर्तमान फ़ोल्डर में शेल खोलें।
2. उस पथ को जोड़ें जहां आपने पैठ (या बल्कि, बिन फ़ोल्डर) के लिए क्यूब्स अनपैक / एकत्र किए हैं
पथ = ~ / qbs / बिन /: $ पथ
3. क्यूब्स लॉन्च:
QBS

 Found project file /home/mapron//example-3/hello.qbp loading project took: 69 ms build graph took: 18 ms for debug: - [hpp, application] HelloWorld as debug compiling main.cpp linking HelloWorld Build done. 

उसके बाद, बिल्ड प्रोग्राम प्रोजेक्ट के विश्लेषण को शुरू करेगा और निर्माण / डिबग फ़ोल्डर में निष्पादन योग्य फ़ाइल एकत्र करेगा (ठीक है, क्या हमने अभी तक गंतव्य फ़ोल्डर निर्दिष्ट नहीं किया है?)
WINDOWS:
4. चूंकि विंडोज के तहत, एक नियम के रूप में, कंपाइलर और क्यूटी पैट में नहीं हैं, क्यूब्स आपको " क्यूब्स प्लेटफ़ॉर्म जांच " चलाने के लिए कह सकते हैं, जिसे किया जाना चाहिए।
5. उसके बाद qbs config अद्यतन या जैसे चलाने के लिए आवश्यक हो सकता है (यदि यह पूछता है, तो यह पहले से ही तय हो सकता है)।
6. उसके बाद, जब Qbs [बिल्ड] लॉन्च किया जाता है, तो आपको असेंबली बाइनरी मिलेगी "HelloWorld.exe"

हम पढ़ाई जारी रखते हैं

अब चलो कुछ और अधिक जटिल विधानसभा को मास्टर करने की कोशिश करते हैं, और एक ही समय में, भाषा से निपटते हैं।
सबसे पहले, एक नया फ़ोल्डर बनाएं और Qt के साथ उदाहरण फ़ोल्डर से " 2dpainting " और " collidingmice " फ़ोल्डर की प्रतिलिपि बनाएँ।
एक बार में दो क्यों? हम एक ही बार में दो उत्पादों को असेंबल करने के लिए एक कॉन्फ़िगरेशन बनाएंगे।
उत्पाद Qmake का निर्माण करते समय ".pro" फ़ाइल के समान निर्माण प्रणाली का लक्ष्य "निकास" है। एक qbs परियोजना में कई उत्पाद हो सकते हैं।
सबसे पहले, " example.qbp " प्रोजेक्ट बनाएं

 //     QML import qbs.base 1.0 import qbs.fileinfo 1.0 as FileInfo Project { //    - . moduleSearchPaths: "qbs" //     ,   cpp  qt //        -   . Product { name: "2dpainting" //    ( ,    ) type: "application" //  - , ..  . Depends { name: "cpp" } //      C++ Depends { name: "Qt"; submodules: ["core", "gui", "opengl"] } //  Qt  QtCore, QtGui, QtOpengl files: [ //     .    ,  . "2dpainting/glwidget.h", "2dpainting/helper.h", "2dpainting/widget.h", "2dpainting/window.h", "2dpainting/glwidget.cpp", "2dpainting/helper.cpp", "2dpainting/main.cpp", "2dpainting/widget.cpp", "2dpainting/window.cpp", ] } } 

कंसोल खोलें और बनाने का प्रयास करें, त्रुटि "त्रुटि: बिल्ड वातावरण सेट करते समय त्रुटि: qt.core.incPath सेट नहीं है। अपनी प्रोफ़ाइल में qt.core.incPath या qt.core.path सेट करें। "
अभी के लिए, हम कॉन्फ़िगरेशन के बहुत उपयोगकर्ता-अनुकूल तरीके से अपनी आँखें बंद नहीं करते हैं, और निम्न सामग्री (WINDOWS) के साथ एक फ़ाइल " qbs.config " बनाएँ:

 modules.qbs.platform: MSVC2010 profile: default profiles.default.qt.core.path: C:/QtSDK/Desktop/Qt/4.8.1/msvc2010/ 

या तो LINUX (ubuntu) के तहत:

 modules.qbs.platform: gcc profile: default profiles.default.qt.core.binPath: /usr/bin/ profiles.default.qt.core.libPath: /usr/lib/qt4 profiles.default.qt.core.incPath: /usr/include/qt4 profiles.default.qt.core.mkspecsPath: /usr/share/qt4/mkspecs 

और qbs config --import qbs.config
उसके बाद, qbs सामान्य रूप से प्रोजेक्ट बनाने और आउटपुट फ़ाइल को बिल्ड / डीबग फ़ोल्डर में रखने में सक्षम होगा।
रिलीज़ के लिए प्रोजेक्ट बनाने के लिए, क्यूब्स बिल्ड रिलीज़ करें ।
सभी बिल्ड फ़ाइलों को साफ़ करने के लिए (अर्थात, फ़ोल्डर्स का निर्माण करें), qbs को साफ़ करें ।
अब दो प्रोजेक्ट के लिए एक एक्स्टेंसिबल स्ट्रक्चर को व्यवस्थित करने का प्रयास करते हैं। " 2dpainting " और " collidingmice " उपनिर्देशिकाओं में, विस्तार के साथ हमारी निर्देशिकाओं के नाम फाइलों को ".qbs" बनाएं:

 import qbs.base 1.0 Product { name: "2dpainting" type: "application" Depends { name: "cpp" } Depends { name: "Qt"; submodules: ["core", "gui", "opengl"] } files: [ //     ,    . "glwidget.h", "helper.h", "widget.h", "window.h", "glwidget.cpp", "helper.cpp", "main.cpp", "widget.cpp", "window.cpp", ] } 

 import qbs.base 1.0 Product { name: "collidingmice" type: "application" Depends { name: "cpp" } Depends { name: "Qt"; submodules: ["core", "gui", "opengl"] } files: [ "mouse.h","main.cpp", "mouse.cpp" ,"mice.qrc"] } 

यानी हम स्वतंत्र उत्पादों में कोड को तोड़ते हैं जो समानांतर में बनाए जा सकते हैं। उदाहरणों में परिवर्तन करें ।qbp:

 //     QML import qbs.base 1.0 import qbs.fileinfo 1.0 as FileInfo Project { //    - . moduleSearchPaths: "qbs" //        -   . //      references. :     ! //     ,    references: [ "2dpainting/2dpainting.qbs", "collidingmice/collidingmice.qbs", ] } 

आप फिर से qbs चला सकते हैं। कृपया ध्यान दें कि ".qrc" फ़ाइल के लिए, "आरसीसी" को स्वचालित रूप से कॉल किया जाएगा और यह सब एक साथ जोड़ा जाएगा। इस मामले में, सभी फाइलें एक सूची द्वारा इंगित की जाती हैं, हेडर्स, स्रोत आदि में अलग किए बिना, जैसा कि qeake में था।

यह सब कैसे काम करता है?

शुरुआत के लिए, मैं मदद पर एक त्वरित नज़र रखने की सलाह देता हूं
भाषा की मुख्य अवधारणाएँ: प्रोजेक्ट, उत्पाद, उत्पाद, कलाकारी, मॉड्यूल, नियम, समूह, निर्भरता, टैग।
एक उत्पाद प्रो या vcproj का एक एनालॉग है, अर्थात, विधानसभा के लिए एक लक्ष्य।
एक परियोजना निर्भरता के साथ-साथ आपके उत्पादों का एक सेट है, जिसे समग्र रूप से निर्माण प्रणाली द्वारा माना जाता है। एक परियोजना - एक निर्माण ग्राफ।
टैग एक फ़ाइल वर्गीकरण प्रणाली है। उदाहरण के लिए, "*। Cpp" => "cpp"
नियम - विशिष्ट टैग के साथ चिह्नित परियोजना फ़ाइलों को परिवर्तित करें। कलाकृतियाँ नामक अन्य फाइलें बनाता है। आमतौर पर, ये कंपाइलर या अन्य बिल्ड सिस्टम होते हैं।
एक विरूपण साक्ष्य एक फाइल है, जो नियम के लिए आउटपुट है (और संभवतः अन्य नियमों के लिए इनपुट)। ये आमतौर पर "obj", "exe" फाइलें होती हैं।
कई क्यूएमएल ऑब्जेक्ट्स में एक शर्त संपत्ति होती है जो नियंत्रित करती है कि इसे इकट्ठा किया जाएगा या नहीं। और अगर हमें उस तरह की फ़ाइलों को विभाजित करने की आवश्यकता है? ऐसा करने के लिए, उन्हें एक समूह (समूह) में जोड़ा जा सकता है

 Group { condition: qbs.targetOS == "windows" files: [ "file1", ...] } 

कुछ इस तरह।

आगे क्या?

एक तार्किक प्रश्न, उदाहरण महान हैं, लेकिन आप इस प्रणाली के साथ मुफ्त तैराकी कैसे कर सकते हैं? आप कर सकते हैं:

• प्रलेखन पढ़ें;
• क्यूटी निर्माता स्रोतों को डाउनलोड करें और देखें कि वहां क्यूबीएस का उपयोग कैसे किया जाता है;
• स्वयं QBS के स्रोत कोड को जानें (आपातकाल के मामले में)।

निष्कर्ष

QBS हमें निम्नलिखित लाभ प्रदान करता है:

• सुविधाजनक और स्पष्ट असेंबली कॉन्फ़िगरेशन प्रारूप
• उच्च गति
• स्पष्ट मॉड्यूलर वास्तुकला

लेकिन, दुर्भाग्य से, इसके निम्नलिखित (अस्थायी नुकसान) हैं

• बड़ी संख्या में कीड़े की उपस्थिति (यह अल्फा नहीं है);
• आईडीई के लिए समर्थन की कमी (क्यूटी निर्माता में प्रतीक्षा करें);
• पैकेज असेंबली सिस्टम की कमी, इंस्टॉलर (योजनाओं में)।

दुर्भाग्य से, लेख का प्रारूप सभी विवरणों को प्रकट करने की अनुमति नहीं देता है, भविष्य में विषय को प्रकट करने की योजना में:

1. अपना खुद का मॉड्यूल बनाना (यह उदाहरण के साथ संग्रह में शामिल है);
2. विधानसभा के लिए नियम लिखना;
3. जेएस-मॉड्यूल और उनके समावेश का निर्माण;
4. अपने स्वयं के प्रकार के उत्पाद बनाना;
5. ग्लोबल कॉन्फिग और मॉड्यूल कॉन्फिग के साथ काम करें;
6. अपना स्वयं का प्लगइन लिखना (.drpoj फ़ाइल की निर्भरता को पार्स करने के लिए)।

यह सब इस लेख में हो सकता है, और कुछ ऐसा होगा जो टिप्पणियों में लिखा जाएगा।

लेख के सभी उदाहरणों के साथ पुरालेख के लिए लिंक:
narod.ru/disk/49759080001.18d6748f8ef86e26c6dea2e2c5ed7d13/examples.zip.html
संग्रहित बोनस! DELPHI 2007 प्रोजेक्ट को असेंबल करने के लिए मॉड्यूल का एक उदाहरण लेख में वर्णित नहीं है (यह अगले लेख में पार्स करने की योजना है)।

संदर्भ

labs.qt.nokia.com/2012/02/15/introducing-qbs - view
doc-snapshot.qt-project.org/qbs - प्रलेखन
qt.gitorious.org/qt-labs/qbs - git
Bugreports.qt-project.org/browse/QBS - बगट्रैकर।

नोट: क्यूटी बिल्ड साल्वेशन README स्रोत पेड़ में QBS का आंतरिक नाम है।