ModernCppStarter
v0.18.0
A configuração de um novo projeto C ++ geralmente requer uma quantidade significativa de preparação e código de caldeira, ainda mais para projetos modernos de C ++ com testes, executáveis e integração contínua. Este modelo é o resultado de aprendizados de muitos projetos anteriores e deve ajudar a reduzir o trabalho necessário para configurar um projeto C ++ moderno.
Greeter significa o nome do projeto, enquanto greeter é usado em nomes de arquivos.include/greeter para usar o nome minúsculo do seu projeto e atualizar todos #include s relevante de acordo.CODECOV_TOKENEventualmente, você pode remover arquivos não utilizados, como o diretório independente ou os fluxos de trabalho irrelevantes do GitHub para o seu projeto. Sinta -se à vontade para substituir a licença por um adequado ao seu projeto.
Para separar de forma limpa do código da biblioteca e do subproject, o CMakeList.txt externo define apenas a própria biblioteca, enquanto os testes e outros subprojetos são independentes em seus próprios diretórios. Durante o desenvolvimento, geralmente é conveniente construir todos os subprojetos de uma só vez.
Use o seguinte comando para construir e executar o destino executável.
cmake -S standalone -B build/standalone
cmake --build build/standalone
./build/standalone/Greeter --helpUse os seguintes comandos do diretório raiz do projeto para executar o conjunto de testes.
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 coletar informações de cobertura de código, execute o cmake com a opção -DENABLE_TEST_COVERAGE=1 .
Use os seguintes comandos do diretório raiz do projeto para verificar e corrigir o estilo de origem C ++ e CMake. Isso requer que o formato de clang , o formato cMake e o pyyaml sejam instalados no sistema atual.
cmake -S test -B build/test
# view changes
cmake --build build/test --target format
# apply changes
cmake --build build/test --target fix-formatConsulte o format.cmake para obter detalhes. Essas dependências podem ser facilmente instaladas usando PIP.
pip install clang-format==14.0.6 cmake_format==0.6.11 pyyamlA documentação é construída e publicada automaticamente sempre que uma versão do GitHub for criada. Para criar documentação manualmente, chame o seguinte comando.
cmake -S documentation -B build/doc
cmake --build build/doc --target GenerateDocs
# view the docs
open build/doc/doxygen/html/index.htmlPara construir a documentação localmente, você precisará de doxygen, Jinja2 e pigmentos instalados no seu sistema.
O projeto também inclui um diretório all que permite a criação de todos os alvos ao mesmo tempo. Isso é útil durante o desenvolvimento, pois expõe todos os subprojetos ao seu IDE e evita construções redundantes da 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 GenerateDocsO teste e os subprojetos independentes incluem o arquivo Tools.cmake, que é usado para importar ferramentas adicionais sob demanda por meio de argumentos de configuração do CMake. Atualmente, o seguinte é suportado.
Os desinfetantes podem ser ativados configurando o cmake com -DUSE_SANITIZER=<Address | Memory | MemoryWithOrigins | Undefined | Thread | Leak | 'Address;Undefined'> .
Os analisadores estáticos podem ser ativados por configuração -DUSE_STATIC_ANALYZER=<clang-tidy | iwyu | cppcheck> , ou uma combinação daqueles que estão em aspas, separados por semicolons. Por padrão, os analisadores encontrarão automaticamente arquivos de configuração como .clang-format . Argumentos adicionais podem ser passados para os analisadores, definindo as variáveis CLANG_TIDY_ARGS , IWYU_ARGS ou CPPCHECK_ARGS .
O CCACHE pode ser ativado configurando com -DUSE_CCACHE=<ON | OFF> .
Posso usar isso para bibliotecas somente para cabeçalho?
Sim, no entanto, você precisará alterar o tipo de biblioteca para uma biblioteca INTERFACE , conforme documentado nos cmakelists.txt. Veja aqui para um exemplo de biblioteca somente cabeçalho com base no modelo.
Não preciso de um alvo / documentação independente. Como posso me livrar disso?
Basta remover o diretório independente / documentação e de acordo com o arquivo de fluxo de trabalho do GitHub.
Posso construir o independente e os testes ao mesmo tempo? / Como posso contar meu IDE sobre todos os subprojetos?
Para manter o modelo modular, todos os subprojetos derivados da biblioteca foram separados em seus próprios módulos CMake. Essa abordagem o torna trivial para projetos de terceiros reutilizarem o código da biblioteca de projetos. Para permitir que o IDES veja o escopo completo do projeto, o modelo inclui o diretório all que criará uma única compilação para todos os subprojetos. Use isso como o diretório principal para obter o melhor suporte do IDE.
Vejo que você está usando
GLOBpara adicionar arquivos de origem no cmakelists.txt. Isso não é mau?
O GLOB é considerado ruim porque quaisquer alterações na estrutura do arquivo de origem podem não ser capturadas automaticamente pelos construtores do CMAKE e você precisará invocar manualmente o cmake sobre as alterações. Pessoalmente, prefiro a solução GLOB para sua simplicidade, mas sinto -me à vontade para alterá -la para listar explicitamente as fontes.
Quero criar metas adicionais que dependem da minha biblioteca. Devo modificar os principais cmakelistas para incluí -los?
Evite a inclusão de projetos derivados dos cmakelistas das bibliotecas (mesmo que seja uma visão comum no mundo C ++), pois isso inverte efetivamente a árvore de dependência e dificulta a base do sistema de construção. Em vez disso, crie um novo diretório ou projeto com um cmakelista que adiciona a biblioteca como uma dependência (por exemplo, como o diretório independente). Dependendo do tipo, pode fazer sentido mover esses componentes para repositórios separados e fazer referência a uma confirmação ou versão específica da biblioteca. Isso tem a vantagem de que bibliotecas e componentes individuais possam ser aprimorados e atualizados de forma independente.
Você recomenda adicionar dependências externas usando o CPM.CMake. Isso forçará os usuários da minha biblioteca a usar o CPM.CMake também?
O CPM.CMake deve ser invisível para os usuários da biblioteca, pois é um script CMake independente. Se surgirem problemas, os usuários sempre poderão optar por não participar da definição do CMake ou Env variável CPM_USE_LOCAL_PACKAGES , o que substituirá todas as chamadas para CPMAddPackage com a chamada de acordo com find_package . Isso também deve permitir que os usuários usem o projeto com seu gerenciador de dependência C ++ externo favorito, como VCPKG ou Conan.
Posso configurar e construir meu projeto offline?
Nenhuma conexão com a Internet é necessária para a criação do projeto, no entanto, ao usar as dependências ausentes do CPM, são baixadas no momento da configuração. Para evitar downloads redundantes, é altamente recomendável definir um diretório de cache do CPM.CMake, por exemplo: export CPM_SOURCE_CACHE=$HOME/.cache/CPM . Isso permitirá clones rasos e permitirá que as dependências offlines já estejam disponíveis no cache.
Posso usar o CPACK para criar um instalador de pacotes para o meu projeto?
Como existem muitas opções e configurações possíveis, isso ainda não está (ainda) no escopo deste modelo. Consulte a documentação do CPACK para obter mais informações sobre como configurar os instaladores do CPACK.
Isso é demais, eu só quero brincar com o código C ++ e testar algumas bibliotecas.
Talvez o Minicppstarter seja algo para você!
