Настройка нового проекта C ++ обычно требует значительного количества кода подготовки и шаблона, тем более для современных проектов C ++ с тестами, исполняемыми файлами и непрерывной интеграцией. Этот шаблон является результатом обучения многих предыдущих проектов и должен помочь сократить работу, необходимую для создания современного проекта C ++.
Greeter означает название проекта, в то время как greeter используется в именах файлов.include/greeter чтобы использовать имя вашего проекта и обновить все соответствующие соответствующие #include .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 , Cmake-формат и 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Чтобы создать документацию на местном уровне, вам понадобятся доксиген, Jinja2 и пигменты, установленные в вашей системе.
Проект также включает в себя 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 CPM_USE_LOCAL_PACKAGES , которая будет переоценить все вызовы в CPMAddPackage с помощью вызова find_package . Это также должно позволить пользователям использовать проект с их любимым внешним C ++ -менеджером зависимостей, такого как VCPKG или CONAN.
Могу ли я настроить и создать свой проект в автономном режиме?
Для создания проекта не требуется подключение к Интернету, однако при использовании CPM -отсутствующие зависимости загружаются во время настройки. Чтобы избежать избыточных загрузок, настоятельно рекомендуется установить каталог CPM.Cmake Cache, например: export CPM_SOURCE_CACHE=$HOME/.cache/CPM . Это обеспечит мелкие клоны и позволит в кэше уже доступны зависимости от автономных конфигураций.
Могу ли я использовать Cpack для создания установщика пакета для моего проекта?
Поскольку существует множество возможных вариантов и конфигураций, это не (пока) в объеме этого шаблона. См. Документацию CPACK для получения дополнительной информации о настройке установщиков CPACK.
Это слишком много, я просто хочу играть с кодом C ++ и проверить некоторые библиотеки.
Возможно, Minicppstarter - это что -то для вас!