ModernCppStarter
v0.18.0
La configuración de un nuevo proyecto C ++ generalmente requiere una cantidad significativa de código de preparación y horario, aún más para proyectos modernos de C ++ con pruebas, ejecutables e integración continua. Esta plantilla es el resultado de los aprendizajes de muchos proyectos anteriores y debería ayudar a reducir el trabajo requerido para configurar un proyecto moderno de C ++.
Greeter significa el nombre del proyecto, mientras que greeter se usa en los nombres de los archivos.include/greeter para usar el nombre minúscula de su proyecto y actualizar todos #include S en consecuencia.CODECOV_TOKENEventualmente, puede eliminar cualquier archivo no utilizado, como el directorio independiente o los flujos de trabajo de GitHub irrelevantes para su proyecto. Siéntase libre de reemplazar la licencia con una adecuada para su proyecto.
Para separar limpiamente la biblioteca y el código de subproyectos, el CMakeList.txt OUTER.txt solo define la biblioteca en sí, mientras que las pruebas y otros subproyectos son autónomos en sus propios directorios. Durante el desarrollo, generalmente es conveniente construir todos los subproyectos a la vez.
Use el siguiente comando para construir y ejecutar el objetivo ejecutable.
cmake -S standalone -B build/standalone
cmake --build build/standalone
./build/standalone/Greeter --helpUse los siguientes comandos del directorio raíz del proyecto para ejecutar el conjunto de pruebas.
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 Para recopilar información de cobertura de código, ejecute CMake con la opción -DENABLE_TEST_COVERAGE=1 .
Use los siguientes comandos del directorio raíz del proyecto para verificar y corregir el estilo de origen C ++ y CMake. Esto requiere que se instalará el formato de clang , CMake-format y Pyyaml en el sistema actual.
cmake -S test -B build/test
# view changes
cmake --build build/test --target format
# apply changes
cmake --build build/test --target fix-formatConsulte Format.cmake para más detalles. Estas dependencias se pueden instalar fácilmente utilizando PIP.
pip install clang-format==14.0.6 cmake_format==0.6.11 pyyamlLa documentación se construye y publica automáticamente cada vez que se crea una versión de GitHub. Para construir manualmente la documentación, llame al siguiente comando.
cmake -S documentation -B build/doc
cmake --build build/doc --target GenerateDocs
# view the docs
open build/doc/doxygen/html/index.htmlPara construir la documentación localmente, necesitará Doxygen, Jinja2 y Pygments instalados en su sistema.
El proyecto también incluye un directorio all que permite construir todos los objetivos al mismo tiempo. Esto es útil durante el desarrollo, ya que expone todos los subproyectos a su IDE y evita las construcciones redundantes de la biblioteca.
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 GenerateDocsLa prueba y los subprojects independientes incluyen el archivo Tools.Cmake que se utiliza para importar herramientas adicionales bajo demanda a través de los argumentos de configuración de CMake. Los siguientes son compatibles actualmente.
Los desinfectantes se pueden habilitar configurando cmake con -DUSE_SANITIZER=<Address | Memory | MemoryWithOrigins | Undefined | Thread | Leak | 'Address;Undefined'> .
Los analizadores estáticos se pueden habilitar configurando -DUSE_STATIC_ANALYZER=<clang-tidy | iwyu | cppcheck> , o una combinación de las que se encuentran en comillas, separadas por semicolones. De manera predeterminada, los analizadores encontrarán automáticamente archivos de configuración como .clang-format . Se pueden pasar argumentos adicionales a los analizadores estableciendo las variables CLANG_TIDY_ARGS , IWYU_ARGS o CPPCHECK_ARGS .
Ccache se puede habilitar configurando con -DUSE_CCACHE=<ON | OFF> .
¿Puedo usar esto para bibliotecas de solo encabezado?
Sí, sin embargo, deberá cambiar el tipo de biblioteca a una biblioteca INTERFACE como se documenta en cmakelists.txt. Consulte aquí para obtener una biblioteca de ejemplo solo de encabezado basada en la plantilla.
No necesito un objetivo / documentación independiente. ¿Cómo puedo deshacerme de él?
Simplemente elimine el directorio independiente / de documentación y de acuerdo con el archivo de flujo de trabajo de GitHub.
¿Puedo construir el independiente y las pruebas al mismo tiempo? / ¿Cómo puedo decir mi IDE sobre todos los subproyectos?
Para mantener la plantilla modular, todos los subproyectos derivados de la biblioteca se han separado en sus propios módulos CMake. Este enfoque hace que sea trivial que los proyectos de terceros reutilicen el código de la biblioteca de proyectos. Para permitir que IDES vea el alcance completo del proyecto, la plantilla incluye all el directorio que creará una sola compilación para todos los subproyectos. Use esto como el directorio principal para el mejor soporte IDE.
Veo que está utilizando
GLOBpara agregar archivos fuente en cmakelists.txt. ¿No es eso malvado?
Glob se considera malo porque cualquier cambio en la estructura del archivo fuente podría no ser capturado automáticamente por los constructores de Cmake y deberá invocar manualmente CMake en los cambios. Personalmente, prefiero la solución GLOB por su simplicidad, pero no dude en cambiarla a fuentes enumeradas explícitamente.
Quiero crear objetivos adicionales que dependan de mi biblioteca. ¿Debo modificar las principales cmakelists para incluirlas?
Evite incluir proyectos derivados de las bibliotecas cmakelists (a pesar de que es una vista común en el mundo de C ++), ya que esto invierte efectivamente el árbol de dependencia y hace que el sistema de construcción sea difícil de razonar. En su lugar, cree un nuevo directorio o proyecto con una CMAKELists que agrega la biblioteca como una dependencia (por ejemplo, como el directorio independiente). Dependiendo del tipo, podría dar sentido a mover estos componentes a un repositorios separados y hacer referencia a una confirmación o versión específica de la biblioteca. Esto tiene la ventaja de que las bibliotecas y componentes individuales se pueden mejorar y actualizar de forma independiente.
Recomienda agregar dependencias externas usando CPM.Cmake. ¿Esto obligará a los usuarios de mi biblioteca a usar CPM.Cmake también?
CPM.Cmake debe ser invisible para los usuarios de la biblioteca, ya que es un script de CMake autónomo. Si surgen problemas, los usuarios siempre pueden optar por definir la variable CMAKE o ENV CPM_USE_LOCAL_PACKAGES , que anulará todas las llamadas a CPMAddPackage con la llamada de find_package . Esto también debe permitir a los usuarios usar el proyecto con su administrador de dependencia externo de C ++ favorito, como VCPKG o Conan.
¿Puedo configurar y construir mi proyecto fuera de línea?
No se requiere conexión a Internet para construir el proyecto, sin embargo, cuando se usa dependencias faltantes de CPM, se descargan en el momento de configuración. Para evitar descargas redundantes, se recomienda establecer un directorio de caché CPM.Cmake, por ejemplo: export CPM_SOURCE_CACHE=$HOME/.cache/CPM . Esto habilitará clones poco profundos y permitirá que las dependencias de configuraciones fuera de línea ya estén disponibles en el caché.
¿Puedo usar CPACK para crear un instalador de paquetes para mi proyecto?
Como hay muchas opciones y configuraciones posibles, esto no está (todavía) en el alcance de esta plantilla. Consulte la documentación de CPACK para obtener más información sobre la configuración de los instaladores de CPACK.
Esto es demasiado, solo quiero jugar con el código C ++ y probar algunas bibliotecas.
¡Quizás el MinicPpStarter es algo para ti!
