C ++ प्रोजेक्ट को कैसे टाइप करें और कैसे असेंबल करें

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

आम:

• नि: शुल्क।
• क्रॉस-प्लेटफ़ॉर्म (कम से कम विंडोज और लिनक्स)।

निर्माण प्रणाली:

• विभिन्न प्लेटफार्मों पर बनाने के लिए एक एकल टीम।
• सभी निर्भरताओं के सही खाते के साथ वृद्धिशील विधानसभा: हेडर फाइलें और विधानसभा के लिए उपयोग किए जाने वाले तीसरे पक्ष के घटक।
• असेंबली स्क्रिप्ट में किसी विशेष प्रोजेक्ट के लिए केवल आवश्यक न्यूनतम कॉन्फ़िगरेशन विशिष्ट होना चाहिए। बिल्ड का सामान्य तर्क स्क्रिप्ट से स्क्रिप्ट तक नहीं भटकना चाहिए, लेकिन बिल्ड सिस्टम या इसके प्लग इन में स्थित है।
• निर्मित समानांतर विधानसभा।
• विभिन्न टूलकिन्स के लिए समर्थन (कम से कम जीसीसी, विजुअल सी ++, क्लेंग)।
• संपूर्ण निर्माण स्क्रिप्ट को फिर से लिखने के बिना, न्यूनतम लागत के साथ टूलचैन को बदलने की क्षमता।
• आसानी से उपलब्ध निर्माण विकल्प: डिबग और रिलीज़।
• कुछ अतिरिक्त निम्न स्तर के उपकरणों पर निर्भरता पूरी तरह से अवांछनीय है। एक शब्द में, विधानसभा प्रणाली आत्मनिर्भर होनी चाहिए।
• JVM के लिए pkg-config या Maven Central जैसे तृतीय-पक्ष घटकों के रिपॉजिटरी के साथ बिल्ड सिस्टम का एकीकरण अत्यधिक वांछनीय है।
• बिल्ड सिस्टम प्लगइन्स द्वारा एक्स्टेंसिबल होना चाहिए, जैसा कि प्रत्येक विशिष्ट परियोजना के लिए विधानसभा प्रक्रिया मानक निर्माण अवधारणा (उदाहरण के लिए, या कुछ गैर-मानक छवि की विधानसभा) की तुलना में अधिक जटिल हो सकती है।
• यह सुविधाजनक है जब बिल्ड स्क्रिप्ट कुछ उच्च-स्तरीय प्रोग्रामिंग भाषा या बेहतर डीएसएल है। यह आपको बहुत महंगा और स्पष्ट रूप से स्क्रिप्ट में सीधे निर्माण के व्यवहार को बदलने की अनुमति नहीं देगा।
• कंपाइलर और लिंकर को बिल्ड स्क्रिप्ट से कॉन्फ़िगर करते समय, यह बहुत सुविधाजनक होता है जब सिस्टम कम से कम बुनियादी सार प्रदान करता है: उदाहरण के लिए, मैं एक मैक्रो जोड़ना चाहूंगा - क्यों लगता है कि इसके लिए कौन सा कंपाइलर कमांड लाइन पैरामीटर जिम्मेदार है? / MSVC पर या Gcc पर -D - बिल्ड सिस्टम को इन असंगत विवरणों को स्वयं द्वारा हल करने दें।
• चित्रमय विकास वातावरण (IDEs) के साथ अच्छा एकीकरण।

आईडीई:

• IDE की सही ढंग से "C ++ कोड" को समझने की क्षमता। IDE को सभी प्रोजेक्ट फ़ाइलों, साथ ही सभी तृतीय-पक्ष और सिस्टम हेडर फ़ाइलों और परिभाषाओं (परिभाषित, मैक्रो) को अनुक्रमित करने में सक्षम होना चाहिए।
• आईडीई को प्रोजेक्ट बनाने के लिए कमांड को अनुकूलित करने की क्षमता प्रदान करनी चाहिए, साथ ही हेडर फ़ाइलों और परिभाषाओं को भी देखना चाहिए।
• इसे प्रभावी रूप से टाइपिंग कोड में मदद करनी चाहिए, अर्थात्। सबसे उपयुक्त पूर्ण विकल्प प्रदान करते हैं, वाक्यविन्यास त्रुटियों आदि के बारे में चेतावनी देते हैं।
• एक बड़ी परियोजना को नेविगेट करना सुविधाजनक होना चाहिए, और त्वरित और आसान उपयोग ढूंढना चाहिए।
• रिफैक्टरिंग के लिए पर्याप्त अवसर प्रदान करें: नामकरण, आदि।
• बायलरप्लेट कोड उत्पन्न करने की क्षमता भी आवश्यक है - एक नया वर्ग ढांचा, हेडर फ़ाइल और कार्यान्वयन फ़ाइल बनाना। गेटर्स / सेटर की पीढ़ी, विधि परिभाषाएं, आभासी तरीकों को ओवरलोड करना, विशुद्ध रूप से आभासी कक्षाओं के कार्यान्वयन पैटर्न (इंटरफेस), आदि।
• कोड प्रलेखन टैग जैसे Doxygen के लिए हाइलाइटिंग और समर्थन।

इन "विशलिस्ट" के प्रकाश में मैंने कई विधानसभा प्रणालियों और चित्रमय विकास वातावरण पर विचार किया है। यह संक्षिप्त समीक्षा किसी भी तरह से पूर्ण होने का दिखावा नहीं करती है और इसमें मेरे व्यक्तिपरक आकलन शामिल हैं, लेकिन शायद यह किसी के लिए एक प्रारंभिक कदम के रूप में उपयोगी होगा।

बनाओ - [पुरातनता] एक मास्टोडन और असेंबली सिस्टम का एक योग्य-योग्य वयोवृद्ध, जिसे हर कोई अभी भी रिटायर नहीं करना चाहता है, लेकिन उसे अधिक से अधिक नई परियोजनाओं को लेने के लिए मजबूर किया जाता है। यह अपनी स्वयं की विशिष्ट भाषा के साथ एक बहुत ही निम्न-स्तरीय उपकरण है, जहां एक टैब के बजाय एक स्थान के लिए आपको तुरंत मौके पर निष्पादन की धमकी दी जाती है। मेक का उपयोग करते हुए, आप कुछ भी कर सकते हैं जो आप चाहते हैं - किसी भी जटिलता का निर्माण, लेकिन आपको इसके लिए एक स्क्रिप्ट लिखने के प्रयासों के साथ भुगतान करना होगा, साथ ही साथ इसे अद्यतित रखना होगा। बिल्ड से लॉजिक को प्रोजेक्ट से ट्रांसफर करना भी महंगा होगा। कुछ आधुनिक मेकअप विकल्प हैं: जैसे कि निंजा और जाम, लेकिन वे सार को नहीं बदलते हैं - ये बहुत ही निम्न-स्तरीय उपकरण हैं। कोडांतरक की तरह, आप अपनी पसंद के अनुसार कुछ भी लिख सकते हैं, लेकिन क्या यह इसके लायक है?

CMake - [मध्य युग] मेक के निम्न-स्तरीय विवरण से दूर होने का पहला प्रयास। लेकिन, दुर्भाग्य से, यह बहुत दूर तक जाना संभव नहीं था - यहां इंजन वही है जिसके लिए सीएमके एक और टेक्स्ट फाइल के आधार पर अधिक उच्च-स्तरीय बिल्ड विवरण के साथ विशाल मेक-फाइल्स उत्पन्न करता है। Qmake एक समान तरीके से काम करता है। यह दृष्टिकोण मुझे एक पुराने लकड़ी के घर के सुंदर मुखौटे की याद दिलाता है, जिसे ध्यान से ताजा प्लास्टिक के साथ मिलाया गया था। CMake एक स्थिर और अच्छी तरह से सिद्ध प्रणाली है, यहां तक ​​कि ग्रहण के साथ एक अंतर्निहित एकीकरण भी है, लेकिन, दुर्भाग्य से, यह मुझे सूट नहीं किया क्योंकि यह लेख की शुरुआत में निर्धारित आवश्यकताओं का हिस्सा है। लिनक्स के तहत, सब कुछ ठीक लग रहा है, लेकिन अगर आपको MSVC का उपयोग करके विंडोज पर एक ही प्रोजेक्ट बनाने की आवश्यकता है - और मैं MinGW के मूल कंपाइलर को प्राथमिकता देता हूं, NMake के लिए फाइलें उत्पन्न होंगी। यानी एक अन्य उपकरण पर निर्भरता और दूसरे प्लेटफॉर्म के लिए अलग-अलग बिल्ड कमांड। और यह सब एक बिट कुटिल वास्तुकला का परिणाम है, जब काम का थोक अन्य "सहायकों" द्वारा किया जाता है।

चींटी - [पुर्नजागरण] जावा के लिए एक प्रकार का बना क्लोन। सच कहूँ तो, मैंने चींटी (साथ ही साथ मावेन) को C ++ की निर्माण प्रणाली की जाँच करने में काफी समय बिताया। और मुझे तुरंत यह एहसास हुआ कि सी ++ का समर्थन पूरी तरह से "शो के लिए" है और पर्याप्त रूप से विकसित नहीं है। इसके अलावा, यहां तक ​​कि जावा परियोजनाओं में चींटी पहले से ही शायद ही कभी इस्तेमाल की जाती है। एक स्क्रिप्टिंग भाषा के रूप में (साथ ही साथ मावेन के लिए) XML को यहाँ चुना गया है - यह विले पक्षी भाषा :)। आशावाद के इस तथ्य ने मुझे विषय में आगे विसर्जन के लिए बिल्कुल भी नहीं जोड़ा।

SCons एक [नया युग] स्व-निहित, क्रॉस-प्लेटफॉर्म बिल्ड सिस्टम है जिसे पायथन में लिखा गया है। SCons जावा और C ++ बिल्ड दोनों के साथ समान रूप से अच्छा करता है। वृद्धिशील विधानसभा के लिए हेडर की निर्भरता को सही ढंग से काम किया जाता है (जैसा कि मैं इसे समझता हूं, एक निश्चित डेटाबेस बिल्ड मेटाडेटा के साथ बनाया गया है), और विंडोज पर MSVC एक टैम्बोरिन के बिना काम करता है। निर्माण स्क्रिप्ट भाषा पायथन है। एक बहुत ही सभ्य प्रणाली, और मैं भी इस पर अपना शोध समाप्त करना चाहता था, लेकिन जैसा कि आप जानते हैं, पूर्णता की कोई सीमा नहीं है, और अधिक विस्तृत परीक्षा से उपरोक्त आवश्यकताओं के प्रकाश में कुछ नुकसान सामने आए हैं।

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

दूरस्थ कलाकृतियों और एक पर दूसरे के निर्माण की उच्च-स्तरीय निर्भरता के लिए कोई समर्थन नहीं है।

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

ग्रैडल [वर्तमान] - मेरे पास पहले से ही जावा और कोटलिन परियोजनाओं के लिए ग्रैडल का उपयोग करने का एक सकारात्मक अनुभव था और मुझे इसके लिए उच्च उम्मीदें थीं।

जेवीएम भाषाओं के लिए, ग्रैडल के पास एक परियोजना के निर्माण के लिए आवश्यक पुस्तकालयों के साथ काम करने की एक बहुत ही सुविधाजनक अवधारणा है (निर्माण निर्भरताएं):

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

सबसे पहले, मैंने C ++ समर्थन के लिए "पुराना" प्लगइन की जाँच की - `cpp` - और निराश था - स्क्रिप्ट संरचना सहज नहीं है: मॉडल, घटक, मूल निवासी - और विभिन्न प्रकार के बायनेरिज़ से कुछ प्रकार के मिश्म दोनों निष्पादन योग्य और लाइब्रेरी सभी एक स्क्रिप्ट में। यह स्पष्ट नहीं है कि इकाई परीक्षणों को कहां रखा जाए। यह संरचना जावा के लिए मेरे द्वारा उपयोग की जाने वाली सामग्री से बहुत भिन्न थी।

लेकिन यह पता चला कि C ++ समर्थन के लिए "नए" प्लगइन्स हैं: `cpp-application` - अनुप्रयोगों के लिए, पुस्तकालयों के लिए` cpp-पुस्तकालय`: स्थिर और गतिशील, और अंत में इकाई परीक्षण के लिए `cpp-unit-test`। और यही मैं ढूंढ रहा था! :)

डिफ़ॉल्ट प्रोजेक्ट फ़ोल्डर संरचना जावा प्रोजेक्ट के समान है:

• src / main / cpp - मुख्य * .cpp प्रोजेक्ट फ़ाइलों के लिए रूट फ़ोल्डर।
• src / main / हेडर - आंतरिक हेडर फ़ाइलों के लिए फ़ोल्डर।
• src / main / public - एक्सपोर्टेड हेडर्स के लिए फोल्डर - लाइब्रेरियों के लिए।
• src / test / cpp - टेस्ट यूनिट की * .cpp फ़ाइलों के लिए फ़ोल्डर।

ऐसी संरचना कठोर नहीं है - इसे हमेशा स्क्रिप्ट में बदला जा सकता है, लेकिन फिर भी विशेष आवश्यकता के बिना ऐसा करना आवश्यक नहीं है, यह काफी उचित है।

वैसे, बिल्ड स्क्रिप्ट आमतौर पर build.gradle है , यह चुनने के लिए Groovy या Kotlin भाषा ( build.gradle.kts ) का DSL है। स्क्रिप्ट के अंदर, ग्रेड एपीआई और स्क्रिप्ट में जोड़े गए प्लगइन्स के एपीआई हमेशा उपलब्ध होते हैं।

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

रनिंग यूनिट टेस्टिंग का सिद्धांत जावा में समान है: ग्रेडल टेस्ट मुख्य घटक का निर्माण करेगा, फिर परीक्षण, यदि वे src / test / cpp फ़ोल्डर में हैं, और फिर टेस्ट एप्लिकेशन चलाएं।

कुख्यात परिभाषित एक अमूर्त तरीके से सेट किया जा सकता है - ग्रैडल स्वयं आवश्यक संकलक विकल्प उत्पन्न करेगा। कई और अमूर्त सेटिंग्स हैं जैसे अनुकूलन, डिबगिंग जानकारी, आदि।

बॉक्स में से, GCC, Microsoft Visual C ++, CLang समर्थित हैं।

प्लग-इन सिस्टम बहुत विकसित है, और विस्तार वास्तुकला सुविधाजनक है - आप तैयार किए गए तर्क ले सकते हैं और इसे सजाने / विस्तार कर सकते हैं। दो प्रकार के प्लगइन्स हैं: गतिशील, जो सीधे ग्रूवी में लिखे गए हैं और स्क्रिप्ट में एम्बेडेड हैं या जावा (या जेवीएम के साथ किसी अन्य भाषा में) में लिखे गए हैं और बाइनरी कलाकृतियों में संकलित हैं। प्लगइन्स के लिए, एक फ्री ग्रैडल आर्टिफैक्ट है जिसमें कोई भी अपना प्लगइन पोस्ट कर सकता है, जो सभी के लिए उपलब्ध होगा। जो इस लेख के लेखक द्वारा सफलतापूर्वक किया गया था :) लेकिन उस पर और बाद में।
मैं सी + + के लिए ग्रैडल में द्विआधारी घटकों के साथ काम करने की प्रणाली पर अधिक विस्तार से ध्यान देना चाहूंगा: यह लगभग जावा में जैसा है! निर्भरता का निर्माण लगभग उसी तरह काम करता है जैसा मैंने ऊपर वर्णित किया है।

उदाहरण के लिए एक समग्र निर्माण करें:

• बर्तन - पुस्तकालय फ़ोल्डर
• एप्लिकेशन उस एप्लिकेशन के साथ फ़ोल्डर है जो उपयोग करता है।
• settings.gradle - कम्पोजिट बिल्ड में इन दो घटकों के संयोजन के लिए ग्रैडल फ़ाइल।

एप्लिकेशन फ़ोल्डर से बिल्ड.ग्रेड फ़ाइल में, निम्न निर्भरता लिखने के लिए पर्याप्त है:

dependencies { implementation project(':utils') } 

बाकी काम करेंगे ग्रैडल! बर्तन हेडर फ़ाइलों के लिए खोज करने के लिए संकलक के लिए एक पथ जोड़ें और लाइब्रेरी बिनर को लिंक करें।

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

जैसा कि यह पता चला, ग्रैडल आगे बढ़े और मावेन रिपॉजिटरी को सी ++ कलाकृतियों को अपलोड करने की क्षमता का एहसास हुआ! ऐसा करने के लिए, मानक `maven-publish` प्लगइन का उपयोग करें।

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

बाइनरी लाइब्रेरी खुद को और सार्वजनिक हेडर फ़ाइलों को फाइल करती है - src / main / public फ़ोल्डर से।

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

अब यदि आप अपने प्रोजेक्ट में किसी की लाइब्रेरी का उपयोग करना चाहते हैं, तो आप बिल्ड स्क्रिप्ट में ऐसा कुछ लिख सकते हैं:

  repositories { maven { url = 'https://akornilov.bitbucket.io/maven' } } unitTest { dependencies { implementation 'org.bitbucket.akornilov.tools:gtest:1.8.1' } } 

यह यहां कहता है कि इकाई परीक्षण के लिए आपको मावेन रिपॉजिटरी से gtest विरूपण साक्ष्य संस्करण 1.8.1 का उपयोग करने की आवश्यकता है ।

वैसे, यह एक बहुत ही वास्तविक रिपॉजिटरी है जिसमें मेरा टेस्ट बिल्ड Google टेस्ट v1.8.1 पोस्ट किया गया है, जिसे विंडोज और लिनक्स x86_64 के लिए ग्रैडल का उपयोग करके बनाया गया है।

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

आईडीई के साथ एकीकरण के लिए, ग्रैडल में विज़ुअल स्टूडियो और एक्सकोड के लिए दो अंतर्निहित प्लगइन्स हैं। वे अच्छी तरह से काम करते हैं, सिवाय इसके कि विज़ुअल स्टूडियो प्लगइन src / test / cpp फ़ोल्डर से यूनिट टेस्ट कोड को अनदेखा करता है और केवल मुख्य कोड के लिए एक प्रोजेक्ट बनाता है।

अब यह आईडीई के बारे में बात करने और उन्हें ग्रेडल के साथ दोस्त बनाने का समय है

ग्रहण CDT (2018-12R) एक परिपक्व और गुणवत्तापूर्ण उत्पाद है। यदि वह आपकी परियोजना को सफलतापूर्वक पार्स करने में कामयाब रहा, तो आप भाग्यशाली हैं - इसे संपादित करना आरामदायक होगा। सबसे अधिक संभावना है, वह ऑटो के सबसे भ्रमित प्रकारों को "समझने" भी देगा। लेकिन अगर नहीं ... तो वह एक लाल बिंदीदार रेखा के साथ एक पंक्ति में सब कुछ हिंसक रूप से जोर देगा और बुरे शब्दों में शपथ लेगा। उदाहरण के लिए, यह मानक MSVC और Windows SDK हेडर फ़ाइलों को नहीं पचाता है। यहां तक ​​कि पूरी तरह से हानिरहित प्रिंटफ़ को लाल बिंदीदार रेखा के साथ रेखांकित किया गया है और इसे कुछ सार्थक नहीं माना जाता है। Std :: string भी थी। लिनक्स के तहत, अपने मूल gcc के साथ, सब कुछ ठीक है। लेकिन यहां तक ​​कि जब वह एक बहन एंड्रॉइड नेटिव से प्रोजेक्ट को इंडेक्स करने के लिए प्राप्त करने की कोशिश कर रहा था, तो समस्याएं शुरू हो गईं। बायोनिक हेडर में, उन्होंने बिंदु-रिक्त size_t की परिभाषा को देखने से इनकार कर दिया, और इसके साथ-साथ सभी कार्यों का भी उपयोग किया। शायद, विंडोज के तहत, आप स्थिति को ठीक कर सकते हैं यदि Microsoft हेडर फ़ाइलों के बजाय उसे पर्ची करते हैं, उदाहरण के लिए, साइगविन या मिनगव एसडीके, लेकिन ये ट्रिक मेरे लिए बहुत दिलचस्प नहीं हैं, मैं अभी भी इस स्तर के सॉफ़्टवेयर को "खाने के लिए क्या दूंगा", और न सिर्फ पसंद करेंगे वह "प्यार करता है"।
टेम्प्लेट कोड को नेविगेट करने, रीफैक्टरिंग और जेनरेट करने की संभावनाएं अद्भुत हैं, लेकिन अक्षरों को टाइप करते समय सहायक से सवाल पूछे जाते हैं: मान लीजिए कि हम किसी लंबे नाम से कुछ अक्षर टाइप करते हैं, तो पूर्ण विकल्प क्यों नहीं प्रदान करते हैं? नहीं, सहायक धैर्यपूर्वक इंतजार करता है जब तक कि उपयोगकर्ता नहीं मिलता है। या -> या ::। मुझे लगातार Ctrl + Space - कष्टप्रद प्रेस करना है। जावा में, इस कष्टप्रद कमी को ट्रिगर के रूप में सीडीटी में पूरे वर्णमाला का चयन करके ठीक किया जा सकता है, लेकिन मुझे एक सरल समाधान नहीं मिला।





NetBeans 8.1 / 10.0 - मैं जावा के लिए इस आईडीई का उपयोग करता था, मुझे सभी आवश्यक कार्यक्षमता के साथ एक अच्छे और हल्के सॉफ्टवेयर के रूप में याद किया गया था। C ++ के लिए, इसमें समुदाय द्वारा विकसित नहीं बल्कि सीधे NetBeans द्वारा एक प्लगइन विकसित किया गया है। C ++ प्रोजेक्ट्स के लिए, मेक और gcc पर काफी कठिन निर्भरता है। कोड संपादक इत्मीनान से है। मुझे टेम्प्लेट कोड जनरेटर में एक बहुत ही साधारण चीज नहीं मिली: हम क्लास हेडर फ़ाइल में एक नई विधि जोड़ते हैं - आपको एक सीपीपी फ़ाइल में विधि बॉडी उत्पन्न करने की आवश्यकता है - यह नहीं जानता कि कैसे। कोड की "समझ" की डिग्री औसत है, ऐसा लगता है कि कुछ पार्स कर रहा है, लेकिन कुछ नहीं है। उदाहरण के लिए, एक ऑटो-इटरेटर के साथ मानचित्र पर चलना उसके लिए पहले से ही मुश्किल है। वह Google टेस्ट से मैक्रों की कसम खाता है। बिल्ड कमांड को कस्टमाइज़ करना समस्याग्रस्त है - लिनक्स पर gcc के साथ और उपलब्ध कराएं (यह इस तथ्य के बावजूद कि एक और बिल्ड सिस्टम पहले से ही उपयोग में है) यह काम करेगा, विंडोज पर इसे मिनगॉव की आवश्यकता होगी, लेकिन अगर यह करता है, तो भी इसे बनाने से इंकार कर देगा। सामान्य तौर पर, सी ++ के साथ नेटबीन्स में काम करना संभव है, लेकिन मैं इसे सहज नहीं कहूंगा; मुझे शायद इस माहौल से प्यार करना होगा ताकि इसके विभिन्न घावों पर ध्यान न दिया जा सके।





KDevelop 5.3.1 - कभी केडीई (लिनक्स) के लिए एक डेवलपर टूल के रूप में कल्पना की गई थी, लेकिन अब विंडोज के लिए एक संस्करण है। इसमें सुंदर वाक्य रचना हाइलाइटिंग (केट पर आधारित) के साथ एक तेज और सुखद कोड संपादक है। यह वाम बिल्ड सिस्टम के साथ छेड़छाड़ करने के लिए काम नहीं करेगा - उसके लिए, मुख्य बिल्ड सिस्टम सीएमके है। यह MSVC और Windows SDK हेडर के प्रति सहिष्णु है, किसी भी स्थिति में printf और std :: string किसी Eclipse CDT की तरह एक स्ट्रैंडर के लिए नेतृत्व नहीं करता है। लिखने के कोड के लिए एक बहुत तेज सहायक - यह टाइपिंग करते समय लगभग तुरंत अच्छा समापन विकल्प प्रदान करता है। इसमें टेम्प्लेट कोड बनाने का एक दिलचस्प अवसर है: आप अपना स्वयं का टेम्प्लेट लिख सकते हैं और इसे ऑनलाइन डाल सकते हैं। टेम्प्लेट से बनाते समय, आप तैयार किए गए टेम्प्लेट के डेटाबेस से जुड़ सकते हैं और अपना पसंदीदा डाउनलोड कर सकते हैं। केवल एक चीज जो परेशान है: एक नया वर्ग बनाने के लिए अंतर्निहित टेम्पलेट विंडोज और लिनक्स दोनों के तहत कुटिल रूप से काम करता है। क्लास बनाने के लिए विज़ार्ड में कई विंडो होती हैं जिनमें आप बहुत सी चीजों को कॉन्फ़िगर कर सकते हैं: किस कंस्ट्रक्टर की जरूरत है, कौन से क्लास के सदस्य हैं आदि। लेकिन विंडोज के तहत अंतिम चरण में कुछ प्रकार की त्रुटि पॉप अप में होती है, जिसमें से पाठ असंभव है और 1 बाइट के आकार में दो फाइलें h और cpp बनाई जाती हैं। लिनक्स में, किसी कारण से, आप कंस्ट्रक्टरों का चयन नहीं कर सकते हैं - टैब खाली है, और आउटपुट पर केवल हेडर फ़ाइल सही ढंग से उत्पन्न होती है। सामान्य तौर पर, इस तरह के परिपक्व उत्पाद के लिए बचपन की बीमारियां किसी भी तरह से तुच्छ दिखती हैं।





QtCreator 4.8.1 (ओपन सोर्स एडिशन) - शायद, इस नाम को सुनकर, आप हैरान हो जाते हैं कि एक क्यू के साथ एक गीगाबाइट वितरण किट के साथ Qt के तहत इस राक्षस को यहाँ कैसे कैद किया गया। लेकिन यह सामान्य परियोजनाओं के लिए पर्यावरण का एक "हल्का" संस्करण है। इसकी वितरण किट का वजन लगभग 150 एमबी है और यह Qt के लिए विशिष्ट चीजों को नहीं लेती है: download.qt.io/official_releases/qtcreator/4.8 ।
वास्तव में, वह लगभग सब कुछ कर सकता है जो मैंने अपनी आवश्यकताओं के बारे में जल्दी और सही तरीके से लिखा था। यह विंडोज और लिनक्स दोनों के मानक हेडर को पार्स करता है, इसे किसी भी बिल्ड सिस्टम के लिए कस्टमाइज़ करता है, पूरा करने के विकल्प बताता है, आसानी से नई कक्षाएं, विधि निकाय उत्पन्न करता है, रिफैक्टिंग और कोड नेविगेशन की अनुमति देता है। यदि आप केवल इस या उस समस्या को दूर करने के बारे में लगातार सोचने के बिना आराम से काम करना चाहते हैं, तो यह QtCreator को देखने के लिए समझ में आता है।





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

इस उद्देश्य के लिए, मैंने ग्रैडल 'cpp-ide-जनरेटर' के लिए एक प्लगइन लिखा और ग्रैडल प्लगिन पोर्टल पर प्रकाशित किया।

प्लगइन का उपयोग केवल 'cpp-application`, `cpp-Library` और` cpp-unit-test` के साथ किया जा सकता है।
यहाँ इसका निर्माण build.gradle में उपयोग का एक उदाहरण है:

  plugins { id 'cpp-library' id 'maven-publish' id 'cpp-unit-test' id 'org.bitbucket.akornilov.cpp-ide-generator' version '0.3' } library { // Library specific parameters } // Configuration block of plugin: ide { autoGenerate = false eclipse = true qtCreator = true netBeans = true kdevelop = true } 

प्लगइन उपरोक्त सभी ग्राफिकल विकास के वातावरण के साथ एकीकरण का समर्थन करता है, लेकिन प्लगइन कॉन्फ़िगरेशन ब्लॉक - ide में, आप अनावश्यक आईडी के लिए समर्थन को अक्षम कर सकते हैं:

  kdevelop = false 

यदि AutoGenerate पैरामीटर सही पर सेट है, तो निर्माण के दौरान सभी अनुमत IDEs के लिए प्रोजेक्ट फ़ाइलें स्वतः ही जेनरेट हो जाएंगी। इसके अलावा, ऑटोमैटिक जनरेशन मोड में, बिल्ड साफ होने पर प्रोजेक्ट फाइल्स डिलीट हो जाएंगी: ग्रेडल क्लीन ।

वृद्धिशील पीढ़ी समर्थित है, अर्थात्। केवल उन फ़ाइलों को जिन्हें वास्तविक अपडेट की आवश्यकता है, अपडेट किया जाएगा।

यहां उन लक्ष्यों की एक सूची दी गई है जो प्लगइन जोड़ता है:

• GenerIde - सभी अनुमत IDEs के लिए प्रोजेक्ट फ़ाइल जनरेट करें।
• cleanIde - सभी अनुमत आईडीई के लिए परियोजना फाइलों को हटा दें।
• GenerIde [नाम] - दिए गए नाम (IDE की अनुमति दी जानी चाहिए) के साथ IDE के लिए प्रोजेक्ट फ़ाइलें उत्पन्न करें, उदाहरण के लिए GenerIdeQtCreator।
• उपलब्ध नाम: ग्रहण, NetBeans, QtCreator, KDevelop।
• cleanIde [नाम] - दिए गए नाम के साथ IDE के लिए प्रोजेक्ट फ़ाइलों को हटाएं, उदाहरण के लिए cleanIdeQtCreator।

निर्माण के दौरान, प्लगइन "सूँघता है" निर्माण और इससे प्रोजेक्ट फ़ाइलों को बनाने के लिए सभी आवश्यक जानकारी निकालता है। परियोजना को खोलने के बाद, सभी स्रोत फाइलें आईडीई में दिखाई देनी चाहिए, सभी हेडर के लिए मार्ग पंजीकृत होना चाहिए, और कॉन्फ़िगर / निर्माण / स्पष्ट करने के लिए मूल बिल्ड कमांड को भी कॉन्फ़िगर किया जाना चाहिए।

दूसरा प्लगइन जो मुझे करना था उसे `cpp-build-tuner` कहा जाता है और यह cpp-application`,` cpp-Library` और `cpp-unit-test` के साथ मिलकर काम करता है।

प्लगइन की कोई सेटिंग नहीं है, यह इसे अपलोड करने के लिए पर्याप्त है:

  plugins { id 'cpp-library' id 'maven-publish' id 'cpp-unit-test' id 'org.bitbucket.akornilov.cpp-build-tuner' version '0.5' } 

प्लगइन विभिन्न बिल्ड विकल्पों के लिए टूलचिन्स (कंपाइलर और लिंकर) की सेटिंग्स के साथ छोटे जोड़तोड़ करता है - डिबग और रिलीज़। MSVC, gcc, CLang समर्थित हैं।

यह MSVC के लिए विशेष रूप से सच है, क्योंकि डिफ़ॉल्ट रूप से, रिलीज़ बिल्ड के परिणामस्वरूप, आपको "बोल्ड" मिलेगा, न कि बेज़ाडाश जानकारी के साथ सौंदर्यपूर्ण बिनर और एक सांख्यिकीय रूप से जुड़े मानक पुस्तकालय। मैं दृश्य स्टूडियो में ही MSVC के लिए सेटिंग्स का "जासूसी" हिस्सा है, जो डिफ़ॉल्ट रूप से अपने C ++ प्रोजेक्ट्स में जोड़ता है। Gcc / CLang और MSVC दोनों के लिए, लिंक समय ऑप्टिमाइज़ेशन रिलीज़ प्रोफ़ाइल में शामिल हैं।

नोट: प्लगइन्स को ग्रेडल v5.2.1 के नवीनतम संस्करण के साथ परीक्षण किया गया था और पिछले संस्करणों के साथ संगतता के लिए परीक्षण नहीं किया गया था।

प्लगइन्स के स्रोत कोड, साथ ही पुस्तकालयों के लिए ग्रैडल का उपयोग करने के सरल उदाहरण: स्थिर और गतिशील, साथ ही उनका उपयोग करने वाले एप्लिकेशन को देखा जा सकता है: bitbucket.org/akornilov/tools अगला ग्रेड / सीपीपी।

उदाहरण यह भी दिखाते हैं कि इकाई परीक्षण पुस्तकालयों के लिए Google टेस्ट का उपयोग कैसे करें।

गूगल टेस्ट v1.8.1 के साथ मावेन रिपोजिटरी जो ग्रैडल (मॉक के बिना) में बनाया गया है।

युपीडी:

QtCreato के Windows संस्करण 4.6.2 से पुराने हैं (और इन पंक्तियों को लिखते समय कम से कम, 4.10 समावेशी तक) MSVC SDK को समझने के लिए "कैसे भूल गए"। एसटीडी के सभी स्थान :: अंतरिक्ष को लाल रंग में रेखांकित किया गया है और सूचकांक से इंकार किया गया है। इसलिए, फिलहाल, विंडोज के तहत काम करने के लिए संस्करण 4.6.2 सबसे उपयुक्त है।

cpp-build-tuner v1.0 प्लगइन का एक नया संस्करण जारी किया गया है (और cpp-ide-generator v0.5 मामूली सुधार है)।
1) cpp-build-tuner कॉन्फ़िगरेशन ब्लॉक जोड़ा गया।

 buildTuner { lto = false gtest = '1.8.1' libraries { common = ['cutils.lib'] windows = ['ole32', 'user32'] linux = ['pthread', 'z'] } libDirs.common = ['../build/debug', '../release'] } 

lto (बूलियन) - रिलीज़ बिल्ड के लिए LTO को सक्षम या अक्षम करता है। डिफ़ॉल्ट रूप से सक्षम।

gtest (string) - यूनिट टेस्ट के लिए Google टेस्ट सपोर्ट जोड़ता है। वर्तमान में केवल संस्करण 1.8.1 ही GCC, MinGW-W64 और MSVC के लिए समर्थित है।

पुस्तकालयों (कंटेनर) - जोड़ने के लिए पुस्तकालयों की एक सूची। कंटेनर के अंदर तीन फ़ील्ड हैं (लाइनों की सूची): किसी भी प्लेटफ़ॉर्म के लिए common - लाइब्रेरी, केवल विंडोज़ और linux - केवल लिनक्स के लिए।

libDirs (कंटेनर) - एक लिंकर के साथ पुस्तकालयों की खोज के लिए फ़ोल्डर्स की एक सूची। कंटेनर संरचना लाइब्रेरी सूची के समान है।

2) cpp-application लिए एप्लिकेशन चलाने की क्षमता को जोड़ा गया। प्लगइन इस के लिए प्रोजेक्ट में अतिरिक्त कार्य जोड़ता है: run , runDebug ( run के समान) और runRelease । टास्क क्रमशः assembleDebug assemble , assembleDebug और assembleRelease पर निर्भर करते हैं।
मानक जावा एप्लिकेशन प्लगइन की तरह, आप स्टार्टअप पर कमांड लाइन पैरामीटर पास कर सकते हैं: gradle run --args="arg1 arg2 ..." ।

युपीडी

होस्टिंग प्लगइन्स के परिवर्तन के संबंध में, समूह को बदल दिया गया था:

 plugins { id 'loggersoft.cpp-build-tuner' version '1.1' id 'loggersoft.cpp-ide-generator' version '0.5' } 

नया प्रोजेक्ट पता: gradle-cpp.sourceforge.io

प्रलेखन:
sourceforge.net/p/gradle-cpp/wiki/cpp-build-tuner
sourceforge.net/p/gradle-cpp/wiki/cpp-ide-generator