ModernCppStarter
v0.18.0
عادةً ما يتطلب إعداد مشروع C ++ جديدًا قدرًا كبيرًا من الاستعداد ورمز BoilerPlate ، أكثر من ذلك بالنسبة لمشاريع C ++ الحديثة مع الاختبارات والإنجازات التنفيذية والتكامل المستمر. هذا القالب هو نتيجة للتعلم من العديد من المشاريع السابقة ويجب أن يساعد في تقليل العمل المطلوب لإعداد مشروع C ++ الحديث.
Greeter اسم المشروع ، بينما يتم استخدام greeter في أسماء الملفات.include/greeter لاستخدام الاسم الصغير لمشروعك وتحديث جميع #include S وفقًا لذلك.CODECOV_TOKENفي النهاية ، يمكنك إزالة أي ملفات غير مستخدمة ، مثل الدليل المستقل أو سير عمل GitHub غير ذي صلة لمشروعك. لا تتردد في استبدال الترخيص بواحد مناسب لمشروعك.
لفصل كود المكتبة ورمز المشاريع الفرعية بشكل نظيف ، يحدد CMakeList.txt الخارجي فقط المكتبة نفسها بينما تكون الاختبارات وغيرها من المشروعات الفرعية قائمة بذاتها في أدلةها الخاصة. أثناء التطوير ، عادة ما يكون من المناسب بناء جميع المشروعات الفرعية في وقت واحد.
استخدم الأمر التالي لإنشاء وتشغيل الهدف القابل للتنفيذ.
cmake -S standalone -B build/standalone
cmake --build build/standalone
./build/standalone/Greeter --helpاستخدم الأوامر التالية من دليل الجذر للمشروع لتشغيل مجموعة الاختبار.
cmake -S test -B build/test
cmake --build build/test
CTEST_OUTPUT_ON_FAILURE=1 cmake --build build/test --target test
# or simply call the executable:
./build/test/GreeterTests لجمع معلومات تغطية التعليمات البرمجية ، قم بتشغيل Cmake باستخدام خيار -DENABLE_TEST_COVERAGE=1 .
استخدم الأوامر التالية من دليل الجذر للمشروع للتحقق من نمط مصدر C ++ و Cmake. وهذا يتطلب تثبيت clang-format و cmake-format و pyyaml على النظام الحالي.
cmake -S test -B build/test
# view changes
cmake --build build/test --target format
# apply changes
cmake --build build/test --target fix-formatانظر format.cmake للحصول على التفاصيل. يمكن تثبيت هذه التبعيات بسهولة باستخدام PIP.
pip install clang-format==14.0.6 cmake_format==0.6.11 pyyamlتم تصميم الوثائق ونشرها تلقائيًا عند إنشاء إصدار GitHub. لإنشاء الوثائق يدويًا ، اتصل بالأمر التالي.
cmake -S documentation -B build/doc
cmake --build build/doc --target GenerateDocs
# view the docs
open build/doc/doxygen/html/index.htmlلإنشاء الوثائق محليًا ، ستحتاج إلى تثبيت Doxygen و Jinja2 و Pygments على نظامك.
يتضمن المشروع أيضًا all يسمح ببناء جميع الأهداف في نفس الوقت. هذا مفيد أثناء التطوير ، لأنه يعرض جميع المشروعات الفرعية إلى IDE الخاص بك ويتجنب بنيات المكتبة الزائدة عن الحاجة.
cmake -S all -B build
cmake --build build
# run tests
./build/test/GreeterTests
# format code
cmake --build build --target fix-format
# run standalone
./build/standalone/Greeter --help
# build docs
cmake --build build --target GenerateDocsتتضمن المشاريع الفرعية للاختبار وملف الأدوات. ملف Cmake الذي يتم استخدامه لاستيراد أدوات إضافية عند الطلب من خلال وسيطات تكوين CMAKE. فيما يلي مدعوم حاليا.
يمكن تمكين المطهرات من خلال تكوين cmake مع -DUSE_SANITIZER=<Address | Memory | MemoryWithOrigins | Undefined | Thread | Leak | 'Address;Undefined'> .
يمكن تمكين المحللات الثابتة عن طريق الإعداد -DUSE_STATIC_ANALYZER=<clang-tidy | iwyu | cppcheck> ، أو مجموعة من تلك الموجودة في علامات اقتباس ، مفصولة بواسطة انتقائية. بشكل افتراضي ، سيجد المحللون تلقائيًا ملفات التكوين مثل .clang-format . يمكن تمرير الوسائط الإضافية إلى المحللين عن طريق تعيين متغيرات CLANG_TIDY_ARGS أو IWYU_ARGS أو CPPCHECK_ARGS .
يمكن تمكين CCache من خلال التكوين باستخدام -DUSE_CCACHE=<ON | OFF> .
هل يمكنني استخدام هذا لمكتبات الرأس فقط؟
نعم ، ومع ذلك ستحتاج إلى تغيير نوع المكتبة إلى مكتبة INTERFACE كما هو موثق في cmakelists.txt. انظر هنا للحصول على مثال على مكتبة رأس فقط بناءً على القالب.
لا أحتاج إلى هدف / وثائق مستقلة. كيف يمكنني التخلص منه؟
ما عليك سوى إزالة دليل المستقلة / الوثائق ووفقًا ملف سير عمل GitHub.
هل يمكنني بناء المستقلة والاختبارات في نفس الوقت؟ / كيف يمكنني إخبار IDE عن جميع المشروعات الفرعية؟
للحفاظ على نموذج القالب ، تم فصل جميع المشروعات الفرعية المستمدة من المكتبة إلى وحدات CMAKE الخاصة بها. هذا النهج يجعله تافهًا لمشاريع الطرف الثالث لإعادة استخدام رمز مكتبة المشاريع. للسماح لـ IDES برؤية النطاق الكامل للمشروع ، يتضمن القالب all الذي سيقوم بإنشاء بناء واحد لجميع المشروعات الفرعية. استخدم هذا كدليل رئيسي لأفضل دعم IDE.
أرى أنك تستخدم
GLOBلإضافة ملفات مصدر في cmakelists.txt. أليس هذا الشر؟
يعتبر GLOB سيئًا لأن أي تغييرات على بنية الملف المصدر قد لا يتم اكتشافها تلقائيًا من قبل شركات بناء CMAKE وستحتاج إلى استدعاء CMAKE يدويًا على التغييرات. أنا شخصياً أفضل حل GLOB لبساطته ، لكن لا تتردد في تغييره إلى مصادر سرد بشكل صريح.
أريد إنشاء أهداف إضافية تعتمد على مكتبتي. هل يجب علي تعديل cmakelists الرئيسية لتضمينهم؟
تجنب تضمين المشاريع المشتقة من المكتبات cmakelists (على الرغم من أنها مشهد شائع في عالم C ++) ، لأن هذا يزداد بشكل فعال شجرة التبعية ويجعل نظام البناء صعبًا. بدلاً من ذلك ، قم بإنشاء دليل أو مشروع جديد مع cmakelists يضيف المكتبة كاعتماد (مثل الدليل المستقل). اعتمادًا على النوع ، قد يكون من المنطقي نقل هذه المكونات إلى مستودعات منفصلة وتشير إلى التزام أو إصدار محدد من المكتبة. هذا له ميزة أنه يمكن تحسين وتحديث المكتبات الفردية وتحديثها بشكل مستقل.
تنصح بإضافة تبعيات خارجية باستخدام CPM.Cmake. هل سيجبر مستخدمي مكتبتي على استخدام CPM.Cmake أيضًا؟
يجب أن يكون CPM.Cmake غير مرئي لمستخدمي المكتبة لأنه نص CMAKE القائم بذاته. في حالة ظهور المشكلات ، يمكن للمستخدمين دائمًا إلغاء الاشتراك عن طريق تحديد CMAKE أو ENV Variable CPM_USE_LOCAL_PACKAGES ، والتي ستجاوز جميع المكالمات إلى CPMAddPackage مع استدعاء find_package . يجب أن يمكّن ذلك المستخدمين من استخدام المشروع مع مدير التبعية الخارجي المفضل لديهم ، مثل VCPKG أو Conan.
هل يمكنني تكوين وإنشاء مشروعي في وضع عدم الاتصال؟
لا يلزم وجود اتصال بالإنترنت لبناء المشروع ، ولكن عند استخدام التبعيات المفقودة في CPM يتم تنزيلها في تكوين الوقت. لتجنب التنزيلات الزائدة ، يوصى بشدة بتعيين دليل ذاكرة التخزين المؤقت CPM.Cmake ، على سبيل المثال: export CPM_SOURCE_CACHE=$HOME/.cache/CPM . سيمكن هذا من استنساخ الضحل والسماح بتماهي التكوينات في وضع عدم الاتصال المتاحة بالفعل في ذاكرة التخزين المؤقت.
هل يمكنني استخدام CPACK لإنشاء تثبيت حزمة لمشروعي؟
نظرًا لوجود الكثير من الخيارات والتكوينات الممكنة ، فإن هذا ليس (بعد) في نطاق هذا القالب. راجع وثائق CPACK لمزيد من المعلومات حول إعداد مثبتات CPACK.
هذا أكثر من اللازم ، أريد فقط أن ألعب برمز C ++ واختبار بعض المكتبات.
ربما يكون minicppstarter شيء بالنسبة لك!
