ما لكتابة وكيفية تجميع مشروع C ++

بعد طرح هذا السؤال ، قمت أولاً بصياغة المتطلبات: جامدة واختيارية (ولكن مرغوبة) لنظام التجميع وبيئة التطوير الرسومية.
أريد أن أشير على الفور إلى أن الأمر لا يتعلق بكتابة رمز C ++ لبعض الأنظمة الأساسية المحددة مثل Android أو إطار عمل ، على سبيل المثال Qt ، حيث يكون كل شيء جاهزًا ، مع كل من رمز البناء والتحرير ، ولكن حول رمز عام غير مرتبط بمنصة معينة أو إلى الإطار.

عام:

• مجانا
• عبر منصة (على الأقل ويندوز ولينكس).

بناء النظام:

• فريق واحد للبناء على منصات مختلفة.
• تجميع تزايدي مع الحساب الصحيح لجميع التبعيات: ملفات الرأس والمكونات الخارجية المستخدمة للتجميع.
• يجب أن يحتوي البرنامج النصي للتجميع على الحد الأدنى الضروري من التكوين المحدد لمشروع معين. يجب ألا يتنقل المنطق العام للبناء من البرنامج النصي إلى البرنامج النصي ، ولكن يوجد في نظام الإنشاء أو في مكوناته الإضافية.
• المدمج في التجمع الموازي.
• دعم مختلف الأدوات (على الأقل مجلس التعاون الخليجي ، Visual C ++ ، CLang).
• القدرة على تغيير سلسلة الأدوات بأقل تكلفة ، دون إعادة كتابة النص البرمجي بأكمله.
• خيارات البناء القابلة للتحويل بسهولة: Debug and Release.
• الاعتماد على بعض الأدوات الإضافية ذات المستوى المنخفض مثل make غير مرغوب فيه تمامًا. باختصار ، يجب أن يكون نظام التجميع مكتفياً ذاتياً.
• تكامل نظام التصميم مع مستودعات مكونات الطرف الثالث مثل pkg-config أو Maven Central لـ JVM أمر مرغوب فيه للغاية.
• يجب أن يكون نظام الإنشاء قابلاً للامتداد بواسطة الإضافات ، مثل قد يكون إجراء التجميع لكل مشروع محدد أكثر تعقيدًا من مفهوم الإنشاء القياسي (إنشاء الكود ، على سبيل المثال ، أو تجميع بعض الصور غير القياسية).
• يكون الأمر مناسبًا عندما يكون نص الإنشاء عبارة عن لغة برمجة عالية المستوى أو حتى لغة DSL أفضل. سيسمح لك ذلك بتغيير سلوك البناء بشكل غير مباشر ومكلف للغاية في البرنامج النصي.
• عند تكوين المحول البرمجي والرابط من البرنامج النصي للبناء ، يكون ملائمًا للغاية عندما يوفر النظام على الأقل تجريدات أساسية: على سبيل المثال ، أود أن أضيف ماكرو - لماذا تعتقد أن معلمة سطر أوامر برنامج التحويل البرمجي هي المسؤولة عن هذا؟ / D على MSVC أو -D على gcc - دع نظام الإنشاء يحل هذه التفاصيل غير الهامة بمفرده.
• تكامل جيد مع بيئات التطوير الرسومية (IDEs).

IDE:

• قدرة IDE على "فهم" رمز C ++ بشكل صحيح. يجب أن يكون IDE قادراً على فهرسة جميع ملفات المشروع ، وكذلك جميع ملفات تعريفات رأس النظام والجهة الخارجية (التعريفات ، الماكرو).
• يجب أن يوفر IDE القدرة على تخصيص الأوامر لإنشاء مشروع ، وكذلك البحث عن ملفات رأس وتعريفات.
• يجب أن يساعد بشكل فعال في كتابة التعليمات البرمجية ، أي تقديم خيارات الإكمال الأكثر ملاءمة ، والتحذير من أخطاء بناء الجملة ، إلخ.
• يجب أن يكون التنقل في مشروع كبير مناسبًا ، واستخدامه سريع وسهل.
• توفير فرص وافرة لإعادة البناء: إعادة التسمية ، إلخ.
• هناك حاجة أيضًا إلى القدرة على إنشاء رمز ملف تعريف - إنشاء إطار فئة جديد وملف الرأس وملف التنفيذ. إنشاء مجموعات / أدوات تعريف ، طريقة تعريف ، طرق تحميل الظاهري الزائدة ، أنماط تنفيذ فئات افتراضية بحتة (واجهات) ، إلخ.
• تسليط الضوء على ودعم وثائق وثائق رمز مثل Doxygen.

في ضوء "قائمة الأمنيات" هذه ، فكرت في العديد من أنظمة التجميع وبيئات التطوير الرسومية. لا تتظاهر هذه المراجعة القصيرة بأي شكل من الأشكال بأنها كاملة وتحتوي على تقييماتي الشخصية ، ولكن ربما يبدو ذلك مفيدًا لشخص ما كخطوة أولية.

اصنع - [العصور القديمة] مستودون ومحارب قديم بجدارة في أنظمة التجميع ، والتي لا يزال الجميع لا يرغبون في التقاعد ، لكنهم مجبرون على تولي المزيد والمزيد من المشاريع الجديدة. هذه أداة ذات مستوى منخفض جدًا بلغتها المحددة ، حيث يتم تهديدك فورًا بالتنفيذ على الفور بدلاً من علامة تبويب. باستخدام make ، يمكنك أن تفعل أي شيء تريده - بناءً على أي تعقيد ، ولكن عليك دفع ثمن ذلك بجهود لكتابة برنامج نصي ، وكذلك تحديثه. سيكون مكلفًا أيضًا نقل منطق الإنشاء من مشروع إلى آخر. هناك بعض بدائل المكياج الحديثة: مثل النينجا والمربى ، لكنها لا تغير الجوهر - إنها أدوات منخفضة المستوى للغاية. كما هو الحال في المجمع ، يمكنك كتابة أي شيء تريده ، ولكن هل يستحق كل هذا العناء؟

CMake - [العصور الوسطى] أول محاولة للابتعاد عن التفاصيل ذات المستوى المنخفض. ولكن ، لسوء الحظ ، لم يكن من الممكن الانتقال بعيدًا - المحرك هنا هو نفسه الذي تنشئ CMake ملفات تكوينية ضخمة تستند إليه في ملف نصي آخر مع وصف بناء أكثر مستوى. Qmake يعمل بطريقة مماثلة. هذا النهج يذكرني بالواجهة الجميلة لمنزل خشبي قديم ، والذي كان مغمدًا بعناية بالبلاستيك النقي. يعد CMake نظامًا ثابتًا ومثبتًا جيدًا ، بل إنه يوجد تكامل مدمج مع Eclipse ، لكن لسوء الحظ ، لم يناسبني لأنه يتناقض مع جزء من المتطلبات المحددة في بداية المقال. تحت Linux ، يبدو أن كل شيء على ما يرام ، ولكن إذا كنت بحاجة إلى إنشاء نفس المشروع على Windows باستخدام MSVC - وأفضّل المترجم الأصلي إلى MinGW ، سيتم إنشاء ملفات NMake. أي تبعيات على أداة أخرى وأوامر بناء مختلفة لمنصة أخرى. وكل هذا نتيجة لعمارة ملتوية بعض الشيء ، عندما يتم الجزء الأكبر من العمل من قبل "مساعدين" آخرين.

النمل - [النهضة] نوع من استنساخ جافا. بصراحة ، لقد قضيت الكثير من الوقت في التحقق من Ant (وكذلك Maven) كنظام بناء لـ C ++. وشعرت على الفور بأن دعم C ++ هنا هو "محض" تمامًا وليس مطورًا بشكل كافٍ. علاوة على ذلك ، حتى في مشاريع Java ، نادراً ما يتم استخدام Ant. كلغة نصية (وكذلك بالنسبة لـ Maven) يتم اختيار XML هنا - لغة الطيور الدنيئة :). حقيقة التفاؤل هذه لم تضف إليّ أيًا على الإطلاق لمزيد من الانغماس في الموضوع.

SCons هو نظام بناء قائم بذاته [عبر حقبة جديدة] مكتوب في بيثون. SCons بشكل جيد على قدم المساواة مع كل من جافا و C ++ يبني. تعمل تبعيات الرؤوس للتجميع التزايدي بشكل صحيح (كما أفهمها ، يتم إنشاء قاعدة بيانات معينة باستخدام بيانات التعريف الخاصة بالبناء) ، ويعمل Windows MSVC بدون الدف. لغة البناء النصي هي بيثون. نظام لائق للغاية ، وأردت الانتهاء من بحثي حوله ، ولكن كما تعلمون ، لا يوجد حد للكمال ، وكشف فحص أكثر تفصيلًا بعض العيوب في ضوء المتطلبات المذكورة أعلاه.

لا توجد إعدادات مجردة للمترجم ، لذلك ، على سبيل المثال ، إذا كنت بحاجة إلى تغيير سلسلة الأدوات ، فقد تحتاج إلى البحث عن أماكن في البرنامج النصي للبناء لإجراء تغييرات. يجب كتابة وحدات الماكرو نفسها بشروط متداخلة - إذا كان نظام التشغيل Windows ، فقم بذلك ، وإذا كان مجلس التعاون الخليجي يفعل ذلك ، إلخ.

لا يوجد دعم للقطع الأثرية عن بعد والاعتماد رفيع المستوى من جانب واحد على الآخر.

تم تصميم البنية العامة بحيث يكون هناك ما يسمى بالبناة المعرّفين من قِبل المستخدم بشكل شبه معزول ولا توجد طريقة لاستخدام منطق الإنشاء الحالي لاستكماله بمنحك من خلال مكون إضافي بسيط. ولكن بشكل عام هو خيار يستحق للمشاريع الصغيرة.

Gradle [الحالي] - كانت لدي بالفعل تجربة إيجابية باستخدام Gradle لمشاريع Java و Kotlin وكان لدي آمال كبيرة في ذلك.

بالنسبة إلى لغات JVM ، لدى Gradle مفهوم ملائم للغاية للعمل مع المكتبات الضرورية لبناء مشروع (بناء التبعيات):

• يسجل البرنامج النصي عناوين المستودعات بالآثار: مخضرم أو لبلاب - على سبيل المثال. يمكن أن يكون أيضًا مستودعًا لأي نوع / تنسيق آخر - إذا كان هناك مكون إضافي لذلك. يمكن أن يكون مستودعًا عن بُعد أو بعضًا من Maven Central أو الاستضافة الشخصية الخاصة بك في مكان ما على الشبكة أو مجرد مندوب محلي على نظام الملفات.
• أيضًا ، في قسم خاص من البرنامج النصي ، تتم الإشارة إلى التبعيات الخاصة بالبناء مباشرةً - قائمة بالتحف الثنائية اللازمة مع الإصدارات.
• قبل البناء ، يحاول Gradle حل جميع التبعيات والبحث عن القطع الأثرية مع الإصدارات المعطاة في جميع المستودعات. يتم تحميل الثنائيات في ذاكرة التخزين المؤقت وإضافتها تلقائيًا إلى البنية. هذا مريح للغاية وكنت آمل أنه بالنسبة لـ C ++ ، ربما قاموا بشيء مماثل.

في البداية ، قمت بفحص المكون الإضافي "القديم" لدعم C ++ - "cpp" - وخيبة أمل - بنية البرنامج النصي ليست بديهية: النموذج والمكون و nativespec - ونوع من أنواع الميشماش من أنواع مختلفة من الثنائيات: كلاهما قابل للتنفيذ والمكتبات كلها في برنامج نصي واحد. ليس من الواضح مكان إجراء اختبارات الوحدة. كان هذا الهيكل مختلفًا تمامًا عما استخدمته لجافا.

لكن تبين أن هناك مكونات إضافية "جديدة" لدعم C ++: "cpp-application" - للتطبيقات ، "cpp-library" للمكتبات: ثابتة وديناميكية ، وأخيراً "cpp-unit-test" لاختبار الوحدة. وهذا ما كنت أبحث عنه! :)

تشبه بنية مجلد المشروع الافتراضي مشروع Java:

• src / main / cpp - المجلد الجذر لملفات المشروع * .cpp الرئيسية.
• src / main / headers - مجلد لملفات الرأس الداخلية.
• src / main / public - مجلد للرؤوس المصدرة - للمكتبات.
• src / test / cpp - مجلد لملفات * .cpp لوحدة الاختبار.

هذه البنية ليست جامدة - يمكن دائمًا تغييرها في البرنامج النصي ، ولكن لا يزال من غير الضروري القيام بذلك دون حاجة خاصة ، فمن المعقول تمامًا.

بالمناسبة ، عادةً ما يكون البرنامج النصي للبناء build.gradle ، وهو DSL للغة Groovy أو Kotlin ( build.gradle.kts ) للاختيار من بينها. داخل البرنامج النصي ، تتوفر دائمًا واجهة برمجة تطبيقات Gradle وواجهة برمجة التطبيقات للمكونات الإضافية المضافة إلى البرنامج النصي.

بالنسبة للمكتبات ، يمكنك اختيار النوع: ثابت أو ديناميكي (أو يجمع كلا الخيارين).
بشكل افتراضي ، يتم تكوين خيارين بناء: Debug ( تجميع gradle ) و Release ( gradle assembleRelease ).

مبدأ تشغيل اختبار الوحدة هو نفسه الموجود في Java: سيقوم اختبار gradle بإنشاء المكون الرئيسي ، ثم الاختبارات ، إذا كانت موجودة في مجلد src / test / cpp ، ثم قم بتشغيل تطبيق الاختبار.

يمكن تعيين تعريفات سيئة السمعة بطريقة مجردة - Gradle نفسها ستنشئ خيارات المترجم اللازمة. هناك العديد من الإعدادات التجريدية مثل التحسين ، معلومات التصحيح ، إلخ.

من خارج الصندوق ، يتم دعم دول مجلس التعاون الخليجي و Microsoft Visual C ++ و CLang.

تم تطوير نظام المكونات الإضافية بشكل كبير ، كما أن بنية الامتداد مريحة - يمكنك أن تأخذ منطقًا جاهزًا وتزيينه / توسيعه. هناك نوعان من المكونات الإضافية: الديناميكية ، والتي تتم كتابتها مباشرةً في Groovy ويتم تضمينها في برنامج نصي أو مكتوبة بلغة Java (أو بلغة أخرى باستخدام JVM) ويتم تجميعها في قطع أثرية ثنائية. بالنسبة للمكونات الإضافية ، يوجد برنامج Gradle مجاني يُمكن لأي شخص من نشر مكونه الإضافي ، والذي سيكون متاحًا للجميع. الذي تم بنجاح من قبل مؤلف هذا المقال :) ولكن المزيد عن ذلك في وقت لاحق.
أود أن أتناول بمزيد من التفصيل نظام العمل مع المكونات الثنائية في Gradle for C ++: إنه مماثل تقريبا لنظام Java! يبني من التبعيات العمل نفسه تقريبا كما وصفت أعلاه.

خذ على سبيل المثال بناء مركب:

• utils - مجلد المكتبة
• التطبيق هو المجلد الذي يستخدم التطبيق utils.
• settings.gradle - ملف Gradle لدمج هذين المكونين في بنية مركبة.

في ملف build.gradle من مجلد التطبيق ، يكفي كتابة التبعية التالية:

dependencies { implementation project(':utils') } 

سوف Gradle تفعل بقية! أضف مسارًا إلى المحول البرمجي للبحث عن ملفات رأس utils وربط بينار المكتبة.

وكل هذا يعمل بشكل جيد على حد سواء في ظل Linux GCC و Windows MSVC.
يعمل البناء التزايدي ، بالطبع ، بشكل رائع ، وإذا قمت بتغيير الرؤوس في الأدوات ، فسيتم إعادة بناء التطبيق.

كما اتضح فيما بعد ، ذهب Gradle إلى أبعد من ذلك وأدرك القدرة على تحميل أدوات C ++ إلى مستودع Maven! للقيام بذلك ، استخدم المكون الإضافي `maven-publish`.

في البرنامج النصي ، تحتاج إلى تحديد المستودع حيث تريد وضع قطعة أثرية لديك ونشرها (أو نشر gradle publishToMavenLocal للنشر المحلي). سوف Gradle اسقاط المشروع و
وضع في شكل خاص - مع الأخذ في الاعتبار الإصدار ، والنظام الأساسي ، والهندسة المعمارية وخيار البناء.

يتم وضع ملفات المكتبة الثنائية نفسها وملفات الرأس العامة - من المجلد src / main / public .

من الواضح أنه لا يمكنك تحميل عناصر C ++ إلى Maven Cental - لن تجتاز اختبارات النظام الإلزامية. لكن رفع مستودع Maven على الشبكة ليس بالأمر الصعب على الإطلاق ، ولا تحتاج إلى القيام بأي شيء للمستودع المحلي - إنه مجرد مجلد على القرص.

الآن إذا كنت تريد استخدام مكتبة شخص ما في مشروعك ، فيمكنك كتابة شيء مثل هذا في النص البرمجي للبناء:

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

تقول هنا أنه بالنسبة لاختبار الوحدات ، يلزمك استخدام إصدار الأداة gtest 1.8.1 من مستودع Maven .

بالمناسبة ، هذا مستودع حقيقي للغاية يتم فيه نشر اختبار Google الإصدار v1.8.1 الخاص بي ، والذي تم إنشاؤه باستخدام Gradle for Windows و Linux x86_64.

بطبيعة الحال ، يتم تنفيذ جميع الأعمال ذات المستوى المنخفض على تكوين المترجم والرابط للعمل مع المكون الخارجي من Gradle. يكفي أن تعلن عن نيتك في استخدام مثل هذه المكتبة ومثل هذه النسخة ومثل هذا المستودع.

للتكامل مع IDE ، يحتوي Gradle على مكونين إضافيين مدمجين لـ Visual Studio و Xcode. تعمل بشكل جيد ، باستثناء أن البرنامج المساعد Visual Studio يتجاهل رمز اختبار الوحدة من مجلد src / test / cpp وينشئ مشروعًا فقط للرمز الرئيسي.

الآن حان الوقت للحديث عن IDE وكيفية تكوين صداقات مع Gradle

Eclipse CDT (2018-12R) هو منتج ناضج وعالي الجودة. إذا نجح في تحليل مشروعك بنجاح ، فأنت محظوظ - سيكون من المريح التعديل. على الأرجح ، سوف "يفهم" حتى أكثر أنواع السيارات إثارة للحيرة. لكن إن لم يكن ... فحينها سيؤكد بكل عنف كل شيء على التوالي بخط أحمر منقسم وأقسم بكلمات سيئة. على سبيل المثال ، لا يتم هضم ملفات رأس MSVC و Windows SDK القياسية. حتى يتم طباعة printf غير مؤذية تمامًا بخط أحمر منقط ولا يُنظر إليه على أنه شيء مفيد. كان هناك أيضا الأمراض المنقولة جنسيا :: سلسلة. تحت نظام Linux ، مع مجلس التنسيق الخليجي الأصلي ، كل شيء على ما يرام. ولكن حتى عند محاولة دفعه إلى فهرسة المشروع من أخت Android Native ، بدأت المشاكل. في رؤوس الكترونية ، ورفض نقطة فارغة لرؤية تعريف size_t ، جنبا إلى جنب مع جميع الوظائف التي تستخدمها. ربما ، ضمن Windows ، يمكنك تصحيح الموقف عن طريق تمريره ، على سبيل المثال ، مع Cygwin أو MinGW SDK بدلاً من ملفات رأس Microsoft ، ولكن هذه الحيل ليست مثيرة للاهتمام بالنسبة لي ، ما زلت أرغب في البرنامج من هذا المستوى "أكل ما يقدمونه" ، وليس فقط انه "يحب".
إن إمكانيات التنقل ، وإعادة إنشاء ، وتوليد رمز القالب كبيرة ، ولكن هناك أسئلة إلى المساعد عند كتابة الحروف: دعنا نقول أننا نكتب بعض الأحرف من اسم طويل ، لماذا لا نقدم خيارات الإكمال؟ لا ، المساعد ينتظر بصبر حتى يحصل المستخدم على. أو -> أو ::. لا بد لي من الضغط باستمرار على Ctrl + Space - مزعج. في Java ، يمكن إصلاح هذا النقص المزعج عن طريق اختيار الأبجدية بأكملها في CDT كمحرك ، لكنني لم أجد حلاً بسيطًا.





NetBeans 8.1 / 10.0 - اعتدت على استخدام IDE لجافا ، تذكرت كبرنامج جيد وخفيف الوزن مع جميع الوظائف اللازمة. بالنسبة لـ C ++ ، يحتوي على مكون إضافي تم تطويره ليس من قِبل المجتمع ، ولكن مباشرةً بواسطة NetBeans. بالنسبة لمشاريع C ++ ، هناك تبعية صارمة للغاية على صناعة و gcc. محرر الكود مهل. لم أجد شيئًا بسيطًا جدًا في منشئ رمز القالب: نضيف طريقة جديدة في ملف رأس الفئة - تحتاج إلى إنشاء نص الطريقة في ملف cpp - لا يعرف كيف. درجة "فهم" الكود متوسطة ، يبدو أن هناك شيئًا ما يفسر ، لكن شيئًا ما ليس كذلك. على سبيل المثال ، التكرار على خريطة باستخدام أداة التكرار التلقائي أمر صعب بالفعل بالنسبة إليه. يقسم على وحدات الماكرو من اختبار Google. يعد تخصيص أمر build أمرًا مثيرًا للمشاكل - على نظام Linux مع gcc وإتاحته (هذا على الرغم من حقيقة أن نظام بناء آخر قيد الاستخدام بالفعل) سوف يعمل ، على نظام Windows ، سيتطلب MinGW ، ولكن حتى لو كان كذلك ، فسوف يرفض الإنشاء. بشكل عام ، من الممكن العمل في NetBeans باستخدام C ++ ، لكنني لن أسميها بالراحة ؛ ربما أحتاج إلى حب هذه البيئة حقًا حتى لا تلاحظ قروحها المختلفة.





تم تصميم KDevelop 5.3.1 - مرة واحدة كأداة مطورة لـ KDE (Linux) ، ولكن يوجد الآن إصدار لنظام Windows. أنه يحتوي على محرر رمز سريع وممتع مع تسليط الضوء على بناء الجملة (على أساس كيت). لن تعمل على العبث بنظام الإنشاء الأيسر - لأنه نظام بناء CMake الرئيسي. إنه متسامح مع رؤوس MSVC و Windows SDK ، على أي حال ، لا تؤدي printf و std :: string بالضبط إلى ذهول مثل Eclipse CDT. مساعد سريع للغاية لكتابة التعليمات البرمجية - يوفر خيارات إتمام جيدة فورًا تقريبًا أثناء الكتابة. لديه فرصة مثيرة للاهتمام لإنشاء رمز القالب: يمكنك كتابة القالب الخاص بك ووضعه على الإنترنت. عند الإنشاء من قالب ، يمكنك الاتصال بقاعدة بيانات القوالب الجاهزة وتنزيل مفضلتك. الشيء الوحيد الذي أزعج: القالب المدمج لإنشاء فئة جديدة يعمل بشكل متعرج تحت كل من Windows و Linux. يحتوي معالج إنشاء الفصل على العديد من النوافذ التي يمكنك من خلالها تكوين الكثير من الأشياء: أي المنشئات مطلوبة ، وأي أعضاء في الفصل ، إلخ. ولكن في المرحلة النهائية تحت Windows ، ينبثق نوع من الخطأ في الوقت المناسب لإظهار النص المستحيل ويتم إنشاء ملفين h و cpp بحجم 1 بايت. في نظام Linux ، لسبب ما ، لا يمكنك تحديد المنشئات - علامة التبويب فارغة ، ويتم إنشاء ملف الرأس بشكل صحيح في الإخراج. بشكل عام ، تبدو أمراض الطفولة لمثل هذا المنتج الناضج تافهة إلى حد ما.





QtCreator 4.8.1 (إصدار مفتوح المصدر) - على الأرجح ، بعد سماع هذا الاسم ، تشعر بالحيرة حيال كيفية سجن هذا الوحش هنا تحت Qt باستخدام مجموعة توزيع غيغابايت بها خطاف. لكن هذه نسخة "خفيفة" من البيئة للمشاريع العامة. تزن مجموعة التوزيع الخاصة بها حوالي 150 ميغابايت فقط ولا تحمل أشياء خاصة بـ Qt معها: download.qt.io/official_releases/qtcreator/4.8 .
في الواقع ، يمكنه فعل كل شيء تقريبًا كتبته في متطلباتي بسرعة وبشكل صحيح. يقوم بتوزيع الرؤوس القياسية لكل من نظامي التشغيل Windows و Linux ، وتخصيصها لأي نظام بناء ، وتقترح خيارات الإنجاز ، وتولِّد بشكل مريح فصولًا جديدة ، وطرق طريقة ، وتتيح إعادة التسكين وتصفح الكود. إذا كنت ترغب فقط في العمل براحة دون التفكير باستمرار في كيفية التغلب على هذه المشكلة أو تلك ، فمن المنطقي أن ننظر إلى QtCreator.





في الواقع ، يبقى الحديث عن ما لم يكن لدي ما يكفي في Gradle للعمل بشكل كامل: التكامل مع IDE. من أجل قيام النظام بإنشاء ملفات المشروع لـ IDE نفسه ، حيث تتم كتابة أوامر إنشاء المشروع بالفعل ، يتم سرد جميع الملفات المصدر ، وهناك حاجة إلى مسارات للبحث عن ملفات الرأس وتحديدها.

لهذا الغرض ، كتبت مكونًا إضافيًا لـ Gradle `cpp-ide-generator` ونشرته على Gradle Plugin Portal.

لا يمكن استخدام المكون الإضافي إلا مع "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 

إذا تم تعيين معلمة التوليد التلقائي إلى صواب ، فسيتم تلقائيًا إنشاء ملفات المشروع لجميع بيئات IDE المسموح بها أثناء الإنشاء . أيضًا ، في وضع الإنشاء التلقائي ، سيتم حذف ملفات المشروع عند تنظيف البنية : تنظيف المراس .

يتم دعم الجيل التزايدي ، أي سيتم تحديث الملفات التي تتطلب تحديثًا حقيقيًا فقط.

فيما يلي قائمة بالأهداف التي يضيفها البرنامج المساعد:

• ؛ GenerIde - إنشاء ملفات المشروع لجميع IDEs المسموح بها.
• cleanIde - حذف ملفات المشاريع لجميع IDEs المسموح بها.
• إنشاء [اسم] - إنشاء ملفات المشروع لـ IDE بالاسم المحدد (يجب السماح IDE) ، على سبيل المثال createIdeQtCreator.
• الأسماء المتاحة: Eclipse ، NetBeans ، QtCreator ، KDevelop.
• cleanIde [name] - حذف ملفات المشروع لـ IDE بالاسم المحدد ، على سبيل المثال cleanIdeQtCreator.

أثناء التوليد ، يقوم المكون الإضافي "sniffs" بإنشاء واستخراج منه جميع المعلومات اللازمة لإنشاء ملفات المشروع. بعد فتح المشروع في IDE ، يجب أن تكون جميع ملفات المصدر مرئية ، ويجب تسجيل المسارات إلى كل الرؤوس ، وكذلك تكوين أوامر الإنشاء الأساسية - build / clear.

المكوّن الإضافي الثاني الذي كان يجب عليّ فعله يسمى "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 ، لأنه افتراضيًا ، كنتيجة لإنشاء الإصدار ، ستحصل على "غامق" ، وليس جماليًا يحتوي على معلومات bazhdash ومكتبة قياسية مرتبطة بشكل ثابت. أنا "تجسست" جزء من إعدادات MSVC في Visual Studio نفسه ، والتي تضيفها افتراضيًا إلى مشاريع C ++ الخاصة بها. لكل من gcc / CLang و MSVC ، يتم تضمين تحسينات وقت الارتباط في ملف تعريف الإصدار.

ملاحظة: تم اختبار المكونات الإضافية باستخدام أحدث إصدار من Gradle v5.2.1 ولم يتم اختبارها للتوافق مع الإصدارات السابقة.

يمكن الاطلاع على أكواد مصدر المكونات الإضافية ، فضلاً عن أمثلة بسيطة لاستخدام Gradle للمكتبات: ثابتة وديناميكية ، بالإضافة إلى التطبيق الذي يستخدمها: bitbucket.org/akornilov/tools next gradle / cpp.

توضح الأمثلة أيضًا كيفية استخدام اختبار Google لمكتبات اختبار الوحدات.

مستودع مافن مع Google Test v1.8.1 المدمج في Gradle (بدون صور وهمية).

محدث:

إصدارات Windows من QtCreato r الأقدم من 4.6.2 (على الأقل وقت كتابة هذه السطور ، حتى 4.10 ضمنيًا ) "نسيت كيف" لفهم MSVC SDK. كل من std :: space مسطر باللون الأحمر ويرفض الفهرس. لذلك ، في الوقت الحالي ، الإصدار 4.6.2 هو الأنسب للعمل تحت Windows.

تم إصدار نسخة جديدة من البرنامج المساعد 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 Test لاختبارات الوحدات. يتم حاليًا دعم الإصدار 1.8.1 فقط لدول مجلس التعاون الخليجي و MinGW-W64 و MSVC.

المكتبات (الحاوية) - قائمة المكتبات للربط. يوجد داخل الحاوية ثلاثة حقول (قائمة الأسطر): مكتبات عامة لأي نظام أساسي ، windows - فقط لنظام Windows و linux - فقط لنظام Linux.

libDirs (الحاوية) - قائمة المجلدات للبحث في المكتبات باستخدام رابط. بنية الحاوية هي نفسها قائمة المكتبة.

2) أضيفت القدرة على تشغيل التطبيقات لتطبيق cpp-application . يضيف المكوّن الإضافي مهام إضافية إلى المشروع من أجل هذا: run ، runDebug (مثل run ) و runRelease . تعتمد المهام على assemble ، و assembleDebug و assembleRelease على التوالي.
مثل المكون الإضافي Java Application القياسي ، يمكنك تمرير معلمات سطر الأوامر عند بدء التشغيل: 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