O que digitar e como montar um projeto C ++

Depois de fazer essa pergunta, em primeiro lugar, formulei os requisitos: rígido e opcional (mas desejável) para o sistema de montagem e o ambiente de desenvolvimento gráfico.
Quero observar imediatamente que não se trata de escrever código C ++ para alguma plataforma específica, como Android ou uma estrutura, por exemplo, Qt, onde tudo está pronto, tanto na construção quanto na edição de código, mas sobre código genérico que não está vinculado a uma plataforma específica ou para o quadro.

Geral:

• Grátis.
• Plataforma cruzada (pelo menos Windows e Linux).

Sistema de compilação:

• Uma única equipe para construir em diferentes plataformas.
• Montagem incremental com a conta correta de todas as dependências: arquivos de cabeçalho e componentes de terceiros usados ​​para montagem.
• O script de montagem deve conter apenas a configuração mínima necessária específica para um projeto específico. A lógica geral da construção não deve vagar de script para script, mas está localizada no sistema de construção ou em seus plugins.
• Montagem paralela embutida.
• Suporte para várias cadeias de ferramentas (pelo menos gcc, Visual C ++, CLang).
• A capacidade de alterar a cadeia de ferramentas com custo mínimo, sem reescrever todo o script de construção.
• Opções de compilação facilmente selecionáveis: Debug and Release.
• Dependências em algumas ferramentas adicionais de baixo nível, como make, são completamente indesejáveis. Em uma palavra, o sistema de montagem deve ser auto-suficiente.
• A integração do sistema de construção com repositórios de componentes de terceiros, como pkg-config ou Maven Central para a JVM, é altamente desejável.
• O sistema de construção deve ser extensível por plugins, como o procedimento de montagem para cada projeto específico pode ser mais complicado que o conceito de construção padrão (geração de código, por exemplo, ou montagem de alguma imagem não-padrão).
• É conveniente quando o script de construção é algum tipo de linguagem de programação de alto nível ou DSL ainda melhor. Isso permitirá que você não mude muito caro e expressivamente o comportamento da construção diretamente no script.
• Ao configurar o compilador e o vinculador a partir do script de construção, é muito conveniente quando o sistema fornece pelo menos abstrações básicas: por exemplo, eu gostaria de adicionar uma macro - por que pensar qual parâmetro de linha de comando do compilador é responsável por isso? / D no MSVC ou -D no gcc - deixe o sistema de compilação resolver esses detalhes irrelevantes sozinho.
• Boa integração com ambientes de desenvolvimento gráfico (IDEs).

IDE:

• A capacidade do IDE de "entender" corretamente o código C ++. O IDE deve poder indexar todos os arquivos do projeto, bem como todos os arquivos e definições de cabeçalhos de terceiros e do sistema (define macro).
• O IDE deve fornecer a capacidade de personalizar comandos para a construção de um projeto, bem como onde procurar por arquivos e definições de cabeçalho.
• Ele deve ajudar efetivamente na digitação do código, ou seja, ofereça as opções de conclusão mais adequadas, avise sobre erros de sintaxe etc.
• Navegar em um projeto grande deve ser conveniente e encontrar um uso rápido e fácil.
• Ofereça amplas oportunidades para refatoração: renomeação, etc.
• Também é necessária a capacidade de gerar código padrão - criando uma nova estrutura de classe, arquivo de cabeçalho e arquivo de implementação. Geração de getters / setters, definições de métodos, sobrecarregando métodos virtuais, padrões de implementação de classes puramente virtuais (interfaces), etc.
• Destaque e suporte para tags de documentação de código, como Doxygen.

À luz dessas "lista de desejos", considerei vários sistemas de montagem e ambientes de desenvolvimento gráfico. Esta breve revisão não pretende, de forma alguma, estar completa e contém minhas avaliações subjetivas, mas talvez pareça a alguém útil como passo inicial.

Faça - [antiguidade] um mastodonte e um merecido veterano de sistemas de montagem, que todo mundo ainda não quer se aposentar, mas é forçado a assumir mais e mais novos projetos. Esta é uma ferramenta de nível muito baixo com sua própria linguagem específica, onde por um espaço em vez de uma guia você é imediatamente ameaçado de execução no local. Usando make, você pode fazer o que quiser - uma construção de qualquer complexidade, mas terá que pagar por isso com esforços para escrever um script, além de mantê-lo atualizado. Também será caro transferir a lógica da construção de um projeto para outro. Existem alguns substitutos modernos da maquiagem: como ninja e geleia, mas eles não mudam a essência - essas são ferramentas de nível muito baixo. Assim como no assembler, você pode escrever o que quiser, mas vale a pena?

CMake - [Idade Média] a primeira tentativa de fugir dos detalhes de baixo nível da marca. Mas, infelizmente, não foi possível ir longe - o mecanismo aqui é o mesmo para o qual o CMake gera enormes arquivos de criação com base em outro arquivo de texto com uma descrição de compilação de mais alto nível. O Qmake funciona de maneira semelhante. Essa abordagem me lembra a bela fachada de uma antiga casa de madeira, cuidadosamente revestida com plástico fresco. O CMake é um sistema estável e bem comprovado, existe até uma integração interna com o Eclipse, mas, infelizmente, não me agradou porque contradiz parte dos requisitos estabelecidos no início do artigo. No Linux, tudo parece estar bem, mas se você precisar criar o mesmo projeto no Windows usando o MSVC - e eu prefiro o compilador nativo ao MinGW, os arquivos do NMake serão gerados. I.e. dependências em outra ferramenta e comandos de construção diferentes para outra plataforma. E tudo isso é conseqüência de uma arquitetura um pouco torta, quando a maior parte do trabalho é feita por outros "ajudantes".

Ant - [renascimento] é uma espécie de clone de make para Java. Francamente, passei bastante tempo verificando o Ant (assim como o Maven) como um sistema de compilação para C ++. E eu imediatamente senti que o suporte ao C ++ aqui é puramente "para mostrar" e não suficientemente desenvolvido. Além disso, mesmo em projetos Java, o Ant já é raramente usado. Como uma linguagem de script (assim como para o Maven), o XML é escolhido aqui - essa linguagem vil de pássaros :). Esse fato de otimismo não me adicionou nenhuma imersão adicional no tópico.

SCons é um sistema de compilação multiplataforma independente da [nova era] , escrito em Python. Os SCons se saem igualmente bem com as compilações Java e C ++. As dependências dos cabeçalhos para montagem incremental são trabalhadas corretamente (como eu o entendo, um determinado banco de dados é criado com os metadados de compilação) e no Windows MSVC funciona sem um pandeiro. A linguagem do script de construção é Python. Um sistema muito decente, e eu até queria terminar minha pesquisa, mas como você sabe, não há limite para a perfeição, e um exame mais detalhado revelou algumas desvantagens à luz dos requisitos acima.

Não há configurações abstratas para o compilador; portanto, se, por exemplo, você precisar alterar a cadeia de ferramentas, talvez seja necessário procurar lugares no script de construção para fazer alterações. As mesmas macros precisarão ser gravadas com condições aninhadas - se for o Windows, se for o GCC, etc.

Não há suporte para artefatos remotos e dependência de alto nível de uma construção em outra.

A arquitetura geral é projetada para que os chamados construtores definidos pelo usuário existam quase isoladamente e não haja maneira de usar a lógica de construção existente para complementá-la com a sua através de um plug-in simples. Mas, no geral, é uma escolha digna para pequenos projetos.

Gradle [atual] - Eu já tinha uma experiência positiva usando o Gradle para projetos Java e Kotlin e tinha grandes esperanças.

Para linguagens JVM, Gradle tem um conceito muito conveniente de trabalhar com as bibliotecas necessárias para construir um projeto (construir dependências):

• O script registra os endereços dos repositórios com artefatos: maven ou ivy - por exemplo. Também pode ser um repositório de qualquer outro tipo / formato - se houvesse um plugin para ele. Pode ser um repositório remoto, algum Maven Central ou sua hospedagem pessoal em algum lugar da rede ou apenas um representante local no sistema de arquivos.
• Além disso, em uma seção especial do script, as dependências para construção são indicadas diretamente - uma lista dos artefatos binários necessários com versões.
• Antes da construção, Gradle tenta resolver todas as dependências e procura artefatos com as versões fornecidas em todos os repositórios. Os binários são carregados no cache e adicionados automaticamente à compilação. Isso é muito conveniente e eu esperava que, para C ++, talvez eles fizessem algo semelhante.

No começo, verifiquei o plug-in “antigo” para suporte ao C ++ - `cpp` - e fiquei desapontado - a estrutura do script não é intuitiva: modelo, componente, nativespec - e algum tipo de confusão de vários tipos de binários: executáveis ​​e bibliotecas estão todos em um script. Não está claro onde colocar os testes de unidade. Essa estrutura era muito diferente da que eu usei para Java.

Porém, também existem plugins “novos” para suporte a C ++: `cpp-application` - para aplicativos,` cpp-library` para bibliotecas: estática e dinâmica e, finalmente, `cpp-unit-test` para teste de unidade. E era isso que eu estava procurando! :)

A estrutura de pastas do projeto padrão é semelhante ao projeto Java:

• src / main / cpp - a pasta raiz dos principais arquivos de projeto * .cpp .
• src / main / headers - pasta para arquivos de cabeçalho internos.
• src / main / public - pasta para cabeçalhos exportados - para bibliotecas.
• src / test / cpp - pasta para arquivos * .cpp da unidade de teste.

Essa estrutura não é rígida - sempre pode ser alterada no script, mas ainda não é necessário fazer isso sem necessidade especial, é bastante razoável.

A propósito, o script de construção geralmente é build.gradle , é um DSL da linguagem Groovy ou Kotlin ( build.gradle.kts ) para sua escolha. Dentro do script, a API Gradle e as APIs dos plug-ins adicionados ao script estão sempre disponíveis.

Para bibliotecas, você pode escolher o tipo: estático ou dinâmico (ou coletar as duas opções).
Por padrão, duas opções de compilação são configuradas: Debug ( gradle assemble ) e Release ( gradle assembleRelease ).

O princípio de executar o teste de unidade é o mesmo que em Java: o gradle test criará o componente principal e, em seguida, os testes, se estiverem na pasta src / test / cpp , e executará o aplicativo de teste.

As definições notórias podem ser definidas de maneira abstrata - o próprio Gradle gerará as opções necessárias do compilador. Existem várias outras configurações abstratas, como otimização, informações de depuração etc.

Pronto para uso, GCC, Microsoft Visual C ++, CLang são suportados.

O sistema de plug-in é muito desenvolvido e a arquitetura de extensão é conveniente - você pode pegar a lógica pronta e decorar / expandir. Existem dois tipos de plugins: dinâmico, que são gravados diretamente no Groovy e incorporados em um script ou gravados em Java (ou em outro idioma da JVM) e compilados em artefatos binários. Para plug-ins, existe um artefato Gradle gratuito no qual qualquer pessoa pode postar seu plug-in, que estará disponível para todos. O que foi feito com sucesso pelo autor deste artigo :), mas mais adiante.
Gostaria de me aprofundar mais no sistema de trabalho com componentes binários no Gradle for C ++: é quase o mesmo que em Java! Construções de dependências funcionam quase da mesma maneira que descrevi acima.

Tomemos, por exemplo, uma compilação composta:

• utils - pasta da biblioteca
• app é a pasta com o aplicativo que usa utils.
• settings.gradle - arquivo Gradle para combinar esses dois componentes em uma construção composta.

No arquivo build.gradle da pasta do aplicativo, basta escrever a seguinte dependência:

dependencies { implementation project(':utils') } 

Gradle fará o resto! Adicione um caminho ao compilador para procurar arquivos de cabeçalho de utils e vincular o binário da biblioteca.

E tudo isso funciona igualmente bem no Linux GCC e no Windows MSVC.
A construção incremental, é claro, também funciona muito bem, e se você alterar os cabeçalhos nos utils, o aplicativo será reconstruído.

Como se viu, Gradle foi além e percebeu a capacidade de fazer upload de artefatos C ++ no repositório Maven! Para fazer isso, use o plugin padrão `maven-publish`.

No script, você precisa especificar o repositório onde deseja colocar seu artefato e fazer a publicação gradle (ou gradle publishToMavenLocal para publicação local). Gradle derrubará o projeto e
esquematizar em um formato especial - levando em conta a versão, plataforma, arquitetura e opção de compilação.

Os arquivos da biblioteca binária e os arquivos de cabeçalho público são apresentados - na pasta src / main / public .

É claro que você não pode fazer upload de artefatos C ++ no Maven Cental - ele não passará nas verificações obrigatórias do sistema. Mas aumentar o repositório Maven na rede não é nada difícil, e você não precisa fazer nada pelo repositório local - é apenas uma pasta no disco.

Agora, se você quiser usar a biblioteca de alguém em seu projeto, escreva algo assim no script de construção:

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

Ele diz aqui que, para teste de unidade, você precisa usar o artefato gtest versão 1.8.1 do repositório Maven .

A propósito, este é um repositório muito real no qual meu teste de compilação do Google Test v1.8.1 é publicado, criado usando o Gradle para Windows e Linux x86_64.

Naturalmente, todo o trabalho de baixo nível na configuração do compilador e vinculador para trabalhar com o componente externo do Gradle é realizado. Basta você declarar suas intenções de usar tal e qual biblioteca com tal e qual versão de tal e tal repositório.

Para integração com o IDE, o Gradle possui dois plugins internos para o Visual Studio e o Xcode. Eles funcionam bem, exceto que o plug-in do Visual Studio ignora o código de teste de unidade da pasta src / test / cpp e gera um projeto apenas para o código principal.

Agora é hora de falar sobre o IDE e como fazer amizade com Gradle

O Eclipse CDT (2018-12R) é um produto maduro e de qualidade. Se ele conseguiu analisar com sucesso o seu projeto, você tem sorte - será fácil editar. Muito provavelmente, ele até "entenderá" os tipos de automóveis mais confusos. Mas se não ... Então ele enfatizará violentamente tudo em uma fileira com uma linha pontilhada vermelha e xingará com palavrões. Por exemplo, ele não digere os arquivos de cabeçalho padrão do MSVC e do Windows SDK. Mesmo uma impressão completamente inofensiva é sublinhada com uma linha pontilhada vermelha e não é percebida como algo significativo. Também havia std :: string. No Linux, com seu gcc nativo, está tudo bem. Mas, mesmo ao tentar fazer com que ele indexasse o projeto de uma irmã nativa do Android, os problemas começaram. Nos cabeçalhos biônicos, ele se recusou a ver a definição de size_t, além de todas as funções que a usavam. Provavelmente, no Windows, você pode corrigir a situação se, em vez dos arquivos de cabeçalho da Microsoft, o escorregarem, por exemplo, Cygwin ou MinGW SDK, mas esses truques não são muito interessantes para mim, eu ainda gostaria que um software desse nível "coma o que eles dão" e não apenas que ele "ama".
As possibilidades de navegação, refatoração e geração de código de modelo são grandes, mas há perguntas para o auxiliar ao digitar letras: digamos que digitemos alguns caracteres de um nome longo, por que não oferecer opções de conclusão? Não, o assistente espera pacientemente até que o usuário chegue. ou -> ou ::. Eu tenho que pressionar constantemente Ctrl + Space - irritante. Em Java, essa deficiência irritante pode ser corrigida selecionando o alfabeto inteiro no CDT como um gatilho, mas não encontrei uma solução simples.





NetBeans 8.1 / 10.0 - Eu costumava usar esse IDE para Java, fui lembrado como um software bom e leve, com todas as funcionalidades necessárias. Para C ++, ele possui um plugin desenvolvido não pela comunidade, mas diretamente pelo NetBeans. Para projetos em C ++, existe uma dependência bastante difícil do make e do gcc. O editor de código é agradável. Não encontrei uma coisa muito simples no gerador de código do modelo: adicionamos um novo método no arquivo de cabeçalho da classe - você precisa gerar o corpo do método em um arquivo cpp - não sabe como. O grau de "entendimento" do código é médio, parece que algo está analisando, mas algo não está. Por exemplo, iterar em um mapa com um iterador automático já é difícil para ele. Ele xinga macros do Google Test. Personalizar o comando build é problemático - no Linux com gcc e disponibilizar (isso apesar do fato de que outro sistema de build já está em uso), ele funcionará, no Windows exigirá MinGW, mas mesmo se o fizer, ele se recusará a compilar. Em geral, é possível trabalhar no NetBeans com C ++, mas eu não diria que é confortável; provavelmente preciso realmente amar esse ambiente para não notar suas várias feridas.





KDevelop 5.3.1 - já foi concebido como uma ferramenta de desenvolvedor para o KDE (Linux), mas agora existe uma versão para Windows. Possui um editor de código rápido e agradável, com belo destaque de sintaxe (baseado no Kate). Não funcionará para adulterar o sistema de compilação esquerdo - para ele, o principal sistema de compilação é o CMake. É tolerante aos cabeçalhos MSVC e Windows SDK, em qualquer caso, printf e std :: string não levam exatamente a um estupor como um CDT do Eclipse. Um auxiliar muito rápido para escrever código - oferece boas opções de conclusão quase imediatamente durante a digitação. Tem uma oportunidade interessante para gerar código de modelo: você pode escrever seu próprio modelo e colocá-lo online. Ao criar a partir de um modelo, você pode conectar-se ao banco de dados de modelos prontos e fazer o download do que desejar. A única coisa que incomoda: o modelo interno para criar uma nova classe funciona de maneira torta no Windows e no Linux. O assistente para criar uma classe possui várias janelas nas quais você pode configurar muitas coisas: quais construtores são necessários, quais membros da classe etc. Mas, na fase final do Windows, algum tipo de erro aparece a tempo de tornar o texto impossível e dois arquivos he cpp são criados no tamanho de 1 byte. No Linux, por algum motivo, você não pode selecionar construtores - a guia está vazia e apenas o arquivo de cabeçalho é gerado corretamente na saída. Em geral, as doenças da infância por um produto tão maduro parecem, de alguma forma, frívolas.





QtCreator 4.8.1 (edição de código aberto) - provavelmente, tendo ouvido esse nome, você está perplexo com a forma como esse monstro foi preso aqui no Qt com um kit de distribuição de gigabytes com um gancho. Mas esta é uma versão "leve" do ambiente para projetos genéricos. Seu kit de distribuição pesa apenas cerca de 150 MB e não contém itens específicos do Qt: download.qt.io/official_releases/qtcreator/4.8 .
Na verdade, ele pode fazer quase tudo o que escrevi nos meus requisitos, de maneira rápida e correta. Ele analisa os cabeçalhos padrão do Windows e Linux, personaliza-o para qualquer sistema de compilação, sugere opções de conclusão, gera convenientemente novas classes, corpos de métodos, permite refatoração e navegação de código. Se você quer trabalhar confortavelmente sem pensar constantemente em como superar esse ou aquele problema, faz sentido olhar para o QtCreator.





Na verdade, resta falar sobre o que eu não tinha o suficiente em Gradle para funcionar totalmente: integração com o IDE. Para que o sistema gere arquivos de projeto para o próprio IDE, nos quais os comandos para a construção do projeto já estejam gravados, todos os arquivos de origem são listados, são necessários caminhos para procurar arquivos de cabeçalho e determinar.

Para esse propósito, escrevi um plugin para o Gradle `cpp-ide-generator` e publiquei no Gradle Plugin Portal.

O plugin só pode ser usado com `cpp-application`,` cpp-library` e `cpp-unit-test`.
Aqui está um exemplo de seu uso em 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 } 

O plugin suporta a integração com todos os ambientes de desenvolvimento gráfico acima, mas no bloco de configuração do plugin, você pode desativar o suporte a IDEs desnecessários:

  kdevelop = false 

Se o parâmetro autoGenerate estiver definido como true, os arquivos do projeto para todos os IDEs permitidos serão gerados automaticamente durante a construção. Além disso, no modo de geração automática, os arquivos do projeto serão excluídos quando a compilação for limpa: gradle clean .

A geração incremental é suportada, ou seja, somente os arquivos que exigem uma atualização real serão atualizados.

Aqui está uma lista de objetivos que o plug-in adiciona:

• generateIde - gera arquivos de projeto para todos os IDEs permitidos.
• cleanIde - exclua os arquivos do projeto para todos os IDEs permitidos.
• generateIde [name] - gera arquivos de projeto para o IDE com o nome fornecido (o IDE deve ser permitido), por exemplo generateIdeQtCreator.
• Nomes disponíveis: Eclipse, NetBeans, QtCreator, KDevelop.
• cleanIde [nome] - exclua os arquivos do projeto para o IDE com o nome fornecido, por exemplo, cleanIdeQtCreator.

Durante a geração, o plug-in "fareja" a compilação e extrai dela todas as informações necessárias para criar arquivos de projeto. Após abrir o projeto no IDE, todos os arquivos de origem devem estar visíveis, os caminhos para todos os cabeçalhos devem ser registrados, bem como os comandos básicos de construção - build / clear, são configurados.

O segundo plugin que eu tive que fazer é chamado `cpp-build-tuner` e também funciona em conjunto com cpp-application`,` cpp-library` e `cpp-unit-test`.

O plug-in não possui configurações, basta apenas enviá-lo:

  plugins { id 'cpp-library' id 'maven-publish' id 'cpp-unit-test' id 'org.bitbucket.akornilov.cpp-build-tuner' version '0.5' } 

O plug-in realiza pequenas manipulações com as configurações das cadeias de ferramentas (compilador e vinculador) para diferentes opções de compilação - Debug and Release. MSVC, gcc, CLang são suportados.

Isso é especialmente verdadeiro para o MSVC, porque, por padrão, como resultado da compilação do release, você obtém um binário "arrojado" e não estético com informações do bazhdash e uma biblioteca padrão vinculada estaticamente. Eu “espiei” parte das configurações do MSVC no Visual Studio, que por padrão ele adiciona aos seus projetos C ++. Para o gcc / CLang e o MSVC, as otimizações de tempo do link estão incluídas no perfil de Liberação.

Nota: Os plug-ins foram testados com a versão mais recente do Gradle v5.2.1 e não foram testados quanto à compatibilidade com versões anteriores.

Os códigos-fonte dos plug-ins, bem como exemplos simples de uso do Gradle para bibliotecas: estática e dinâmica, bem como o aplicativo que os utiliza, podem ser visualizados: bitbucket.org/akornilov/tools next gradle / cpp.

Os exemplos também mostram como usar o Google Test para bibliotecas de testes de unidade.

Repositório Maven com o Google Test v1.8.1, construído em Gradle (sem simulação).

UPD:

As versões para Windows do QtCrear anteriores à 4.6.2 (e pelo menos no momento em que escrevíamos essas linhas, inclusive a 4.10 ) esqueceram como entender o MSVC SDK. Todo o std :: space está sublinhado em vermelho e se recusa a indexar. Portanto, no momento, a versão 4.6.2 é mais adequada para trabalhar no Windows.

Uma nova versão do plugin cpp-build-tuner v1.0 foi lançada (e o cpp-ide-generator v0.5 são pequenas melhorias).
1) Adicionado bloco de configuração ao 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 (booleano) - habilita ou desabilita o LTO para a compilação do release. Ativado por padrão.

gtest (string) - adiciona suporte ao Google Test para testes de unidade. Atualmente, apenas a versão 1.8.1 é suportada para GCC, MinGW-W64 e MSVC.

bibliotecas (contêiner) - uma lista de bibliotecas para vinculação. Dentro do contêiner, existem três campos (lista de linhas): common - bibliotecas para qualquer plataforma, windows - apenas para Windows e linux - apenas para Linux.

libDirs (container) - uma lista de pastas para pesquisar bibliotecas com um vinculador. A estrutura do contêiner é igual à lista da biblioteca.

2) Adicionada a capacidade de executar aplicativos para o aplicativo cpp-application . O plug-in adiciona tarefas adicionais ao projeto para isso: run , runDebug (o mesmo que run ) e runRelease . As tarefas dependem de assemble , assembleDebug e assembleRelease respectivamente.
Como o plug-in Java Application padrão, você pode passar parâmetros de linha de comando na inicialização: gradle run --args="arg1 arg2 ..." .

UPD

Em conexão com a mudança de plugins de hospedagem, o grupo foi alterado:

 plugins { id 'loggersoft.cpp-build-tuner' version '1.1' id 'loggersoft.cpp-ide-generator' version '0.5' } 

Novo endereço do projeto: gradle-cpp.sourceforge.io

Documentação:
sourceforge.net/p/gradle-cpp/wiki/cpp-build-tuner
sourceforge.net/p/gradle-cpp/wiki/cpp-ide-generator