Habiendo formulado esta pregunta, en primer lugar formulé los requisitos: rígidos y opcionales (pero deseables) para el sistema de ensamblaje y el entorno de desarrollo gráfico.
Quiero señalar de inmediato que no se trata de escribir código C ++ para alguna plataforma específica como Android o un marco, por ejemplo Qt, donde todo está listo, tanto con código de construcción como de edición, sino con código genérico que no está vinculado a una plataforma específica o al marco.
General:
- Gratis
- Multiplataforma (al menos Windows y Linux).
Sistema de construcción:
- Un solo equipo para construir en diferentes plataformas.
- Ensamblaje incremental con la cuenta correcta de todas las dependencias: archivos de encabezado y componentes de terceros utilizados para el ensamblaje.
- El script de ensamblaje debe contener solo la configuración mínima necesaria específica para un proyecto en particular. La lógica general de la compilación no debe pasar de un guión a otro, sino que se encuentra en el sistema de compilación o en sus complementos.
- Montaje en paralelo incorporado.
- Soporte para varias cadenas de herramientas (al menos gcc, Visual C ++, CLang).
- La capacidad de cambiar la cadena de herramientas con un costo mínimo, sin reescribir todo el script de compilación.
- Opciones de compilación fácilmente intercambiables: depuración y liberación.
- Las dependencias de algunas herramientas adicionales de bajo nivel como make son completamente indeseables. En una palabra, el sistema de ensamblaje debería ser autosuficiente.
- La integración del sistema de compilación con repositorios de componentes de terceros como pkg-config o Maven Central para JVM es altamente deseable.
- El sistema de compilación debe ser extensible por complementos, como El procedimiento de ensamblaje para cada proyecto específico puede ser más complicado que el concepto de construcción estándar (generación de código, por ejemplo, o el ensamblaje de alguna imagen no estándar).
- Es conveniente cuando el script de compilación es algún tipo de lenguaje de programación de alto nivel o incluso mejor DSL. Esto le permitirá cambiar de manera no muy costosa y expresiva el comportamiento de la construcción directamente en el script.
- Al configurar el compilador y el enlazador desde el script de compilación, es muy conveniente cuando el sistema proporciona al menos abstracciones básicas: por ejemplo, me gustaría agregar una macro: ¿por qué pensar qué parámetro de línea de comando del compilador es responsable de esto? / D en MSVC o -D en gcc: deje que el sistema de compilación resuelva estos detalles intrascendentes por sí mismo.
- Buena integración con entornos de desarrollo gráfico (IDEs).
IDE:
- La capacidad del IDE para "comprender" correctamente el código C ++. El IDE debe poder indexar todos los archivos de proyecto, así como todos los archivos y definiciones de terceros y del encabezado del sistema (define, macro).
- El IDE debería proporcionar la capacidad de personalizar comandos para construir un proyecto, así como dónde buscar archivos de encabezado y definiciones.
- Debería ayudar efectivamente a escribir código, es decir ofrece las opciones de finalización más adecuadas, advierte sobre errores de sintaxis, etc.
- Navegar por un proyecto grande debería ser conveniente, y encontrar el uso rápido y fácil.
- Brinde amplias oportunidades para refactorizar: renombrar, etc.
- También es necesaria la capacidad de generar código repetitivo, creando un nuevo marco de clase, archivo de encabezado y archivo de implementación. Generación de getters / setters, definiciones de métodos, sobrecarga de métodos virtuales, patrones de implementación de clases puramente virtuales (interfaces), etc.
- Destacado y soporte para etiquetas de documentación de código como Doxygen.
A la luz de estas "Lista de deseos", he considerado varios sistemas de ensamblaje y entornos de desarrollo gráfico. Esta breve revisión no pretende de ninguna manera ser completa y contiene mis evaluaciones subjetivas, pero quizás a alguien le parezca útil como paso inicial.
Haga que [la antigüedad] sea un mastodonte y un veterano bien merecido de los sistemas de ensamblaje, que todos aún no quieren retirarse, pero se ven obligados a asumir más y más proyectos nuevos. Esta es una herramienta de muy bajo nivel con su propio lenguaje específico, donde para un espacio en lugar de una pestaña, se lo amenaza inmediatamente con la ejecución en el acto. Con make, puede hacer lo que quiera: una compilación de cualquier complejidad, pero tendrá que pagar con esfuerzos para escribir un guión y mantenerlo actualizado. También será costoso transferir la lógica de la compilación de un proyecto a otro. Hay algunos sustitutos modernos del maquillaje: como ninja y jam, pero no cambian la esencia: son herramientas de muy bajo nivel. Al igual que en el ensamblador, puedes escribir lo que quieras, pero ¿vale la pena?
CMake -
[Edad Media] el primer intento de alejarse de los detalles de bajo nivel de la marca. Pero, desafortunadamente, no fue posible llegar lejos: el motor aquí es la misma marca para la que CMake genera enormes archivos de creación basados en otro archivo de texto con una descripción de compilación de más alto nivel. Qmake funciona de manera similar. Este enfoque me recuerda la hermosa fachada de una vieja casa de madera, cuidadosamente revestida con plástico fresco. CMake es un sistema estable y bien probado, incluso hay una integración integrada con Eclipse, pero, desafortunadamente, no me convenía porque contradice parte de los requisitos establecidos al comienzo del artículo. En Linux, todo parece estar bien, pero si necesita construir el mismo proyecto en Windows usando MSVC, y prefiero el compilador nativo a MinGW, se generarán los archivos para NMake. Es decir dependencias de otra herramienta y diferentes comandos de compilación para otra plataforma. Y todo esto es consecuencia de una arquitectura un poco torcida, cuando la mayor parte del trabajo es realizado por otros "ayudantes".
Ant -
[renacimiento] una especie de make clone para Java. Francamente, pasé bastante tiempo comprobando Ant (así como Maven) como un sistema de compilación para C ++. E inmediatamente tuve la sensación de que el soporte de C ++ aquí es puramente "para mostrar" y no lo suficientemente desarrollado. Además, incluso en proyectos Java, Ant ya no se usa con frecuencia. Como lenguaje de script (así como para Maven), aquí se elige XML: este vil lenguaje de aves :). Este hecho de optimismo no me aportó nada para una mayor inmersión en el tema.
SCons es un sistema de compilación multiplataforma autónomo
[de la nueva era] escrito en Python. SCons funciona igualmente bien con las compilaciones Java y C ++. Las dependencias de los encabezados para el ensamblaje incremental se resuelven correctamente (según tengo entendido, se crea una determinada base de datos con los metadatos de compilación), y en Windows MSVC funciona sin pandereta. El lenguaje de script de compilación es Python. Un sistema muy decente, e incluso quería terminar mi investigación sobre él, pero como saben, no hay límite para la perfección, y un examen más detallado reveló algunas desventajas a la luz de los requisitos anteriores.
No hay configuraciones abstractas para el compilador, por lo que si, por ejemplo, necesita cambiar la cadena de herramientas, es posible que deba buscar lugares en el script de compilación para realizar cambios. Las mismas macros deberán escribirse con condiciones anidadas: si es Windows, hágalo, si es GCC, etc.
No hay soporte para artefactos remotos y dependencias de alto nivel de una compilación sobre otra.
La arquitectura general está diseñada para que los llamados constructores definidos por el usuario existan casi de forma aislada y no hay forma de utilizar la lógica de compilación existente para complementarla con la suya a través de un simple complemento. Pero en general es una opción digna para pequeños proyectos.
Gradle [presente] : ya tenía una experiencia positiva al usar Gradle para proyectos Java y Kotlin y tenía muchas esperanzas en ello.
Para los lenguajes JVM, Gradle tiene un concepto muy conveniente de trabajar con las bibliotecas necesarias para construir un proyecto (dependencias de construcción):
- El script registra las direcciones de los repositorios con artefactos: maven o hiedra, por ejemplo. También puede ser un repositorio de cualquier otro tipo / formato, si solo hubiera un complemento para él. Puede ser un repositorio remoto, algunos Maven Central o su alojamiento personal en algún lugar de la red o simplemente un representante local en el sistema de archivos.
- Además, en una sección especial del script, las dependencias para la construcción se indican directamente: una lista de los artefactos binarios necesarios con versiones.
- Antes de compilar, Gradle intenta resolver todas las dependencias y busca artefactos con las versiones dadas en todos los repositorios. Los binarios se cargan en el caché y se agregan automáticamente a la compilación. Esto es muy conveniente y esperaba que para C ++, tal vez hicieran algo similar.
Al principio, revisé el complemento "antiguo" para el soporte de C ++ - `cpp` - y me decepcionó: la estructura del script no es intuitiva: modelo, componente, nativespec - y algún tipo de mishmash de varios tipos de binarios: tanto ejecutables como bibliotecas, todo en un solo script. No está claro dónde colocar las pruebas unitarias. Esta estructura era muy diferente de la que usaba para Java.
Pero resultó que también hay complementos "nuevos" para el soporte de C ++: `cpp-application` - para aplicaciones,` cpp-library` para bibliotecas: estáticas y dinámicas, y finalmente `cpp-unit-test` para pruebas unitarias. ¡Y eso era lo que estaba buscando! :)
La estructura predeterminada de la carpeta del proyecto es similar al proyecto Java:
- src / main / cpp : la carpeta raíz para los archivos de proyecto principales * .cpp .
- src / main / headers - carpeta para archivos de encabezado internos.
- src / main / public - carpeta para encabezados exportados - para bibliotecas.
- src / test / cpp : carpeta para archivos * .cpp de la unidad de prueba.
Dicha estructura no es rígida: siempre se puede cambiar en el script, pero aún así no es necesario hacerlo sin una necesidad especial, es bastante razonable.
Por cierto, el script de compilación generalmente es
build.gradle , es un DSL del lenguaje Groovy o Kotlin (
build.gradle.kts ) para elegir. Dentro del script, la API de Gradle y las API de los complementos agregados al script siempre están disponibles.
Para las bibliotecas, puede elegir el tipo: estático o dinámico (o recopilar ambas opciones).
De manera predeterminada, se configuran dos opciones de compilación: depuración (
ensamblaje de gradle ) y liberación (
liberación de ensamblaje de gradle ).
El principio de ejecutar pruebas unitarias es el mismo que en Java: gradle test construirá el componente principal, luego las pruebas, si están en la carpeta
src / test / cpp , y luego ejecutará la aplicación de prueba.
Las definiciones notorias se pueden configurar de manera abstracta: Gradle generará las opciones de compilación necesarias. Hay varias configuraciones abstractas más, como la optimización, la información de depuración, etc.
Fuera de la caja, GCC, Microsoft Visual C ++, CLang son compatibles.
El sistema de complementos está muy desarrollado y la arquitectura de extensión es conveniente: puede tomar la lógica ya hecha y decorarla / expandirla. Hay dos tipos de complementos: dinámicos, que se escriben directamente en Groovy y se incrustan en un script o en Java (o en otro idioma con la JVM) y se compilan en artefactos binarios. Para los complementos, hay un artefacto gratuito de Gradle en el que cualquiera puede publicar su complemento, que estará disponible para todos. Lo cual fue realizado con éxito por el autor de este artículo :) pero más sobre eso más adelante.
Me gustaría profundizar más en el sistema de trabajo con componentes binarios en Gradle para C ++: ¡es casi lo mismo que en Java! Las compilaciones de dependencias funcionan casi igual que lo que describí anteriormente.
Tomemos, por ejemplo, una compilación compuesta:
- utils - carpeta de la biblioteca
- app es la carpeta con la aplicación que usa utils.
- settings.gradle: archivo Gradle para combinar estos dos componentes en una compilación compuesta.
En el archivo
build.gradle de la carpeta de la aplicación, es suficiente escribir la siguiente dependencia:
dependencies { implementation project(':utils') }
¡Gradle hará el resto! Agregue una ruta al compilador para buscar archivos de encabezado de utilidades y vincule el binario de la biblioteca.
Y todo esto funciona igualmente bien tanto bajo Linux GCC como bajo Windows MSVC.
La construcción incremental, por supuesto, también funciona muy bien, y si cambia los encabezados en las utilidades, la aplicación se reconstruirá.
Al final resultó que, Gradle fue más allá y se dio cuenta de la capacidad de cargar artefactos de C ++ en el repositorio de Maven. Para hacer esto, use el complemento estándar `maven-publishing`.
En la secuencia de comandos, debe especificar el repositorio donde desea colocar su artefacto y hacer que Gradle publique (o gradle publishingToMavenLocal para publicación local). Gradle derribará el proyecto y
Diseñe en un formato especial, teniendo en cuenta la versión, la plataforma, la arquitectura y la opción de compilación.
Los propios archivos de la biblioteca binaria y los archivos de encabezado públicos se presentan desde la carpeta
src / main / public .
Está claro que no puede cargar artefactos de C ++ en Maven Cental; no pasará las verificaciones obligatorias del sistema. Pero aumentar el repositorio de Maven en la red no es difícil en absoluto, y no necesita hacer nada para el repositorio local: es solo una carpeta en el disco.
Ahora, si desea utilizar la biblioteca de alguien en su proyecto, puede escribir algo como esto en el script de compilación:
repositories { maven { url = 'https://akornilov.bitbucket.io/maven' } } unitTest { dependencies { implementation 'org.bitbucket.akornilov.tools:gtest:1.8.1' } }
Aquí dice que para las pruebas unitarias debe usar la versión 1.8.1 de gtest artifact del
repositorio de Maven .
Por cierto, este es un repositorio muy real en el que se publica mi versión de prueba Google Test v1.8.1, creada usando Gradle para Windows y Linux x86_64.
Naturalmente, se lleva a cabo todo el trabajo de bajo nivel para configurar el compilador y el enlazador para trabajar con el componente externo de Gradle. Es suficiente que declare sus intenciones de usar tal y tal biblioteca con tal y tal versión de tal y tal repositorio.
Para la integración con el IDE, Gradle tiene dos complementos integrados para Visual Studio y Xcode. Funcionan bien, excepto que el complemento de Visual Studio ignora el código de prueba de unidad de la carpeta
src / test / cpp y genera un proyecto solo para el código principal.
Ahora es el momento de hablar sobre el IDE y cómo hacerlos amigos de Gradle.
Eclipse CDT (2018-12R) es un producto maduro y de calidad. Si logró analizar con éxito su proyecto, entonces tiene suerte: será cómodo editarlo. Lo más probable es que incluso "entienda" los tipos de automóviles más confusos. Pero si no ... Entonces enfatizará violentamente todo en una fila con una línea roja punteada y maldecirá con malas palabras. Por ejemplo, no digiere los archivos de encabezado estándar de MSVC y Windows SDK. Incluso una impresión completamente inofensiva está subrayada con una línea punteada roja y no se percibe como algo significativo. También había std :: string. Bajo Linux, con su gcc nativo, todo está bien. Pero incluso cuando intentaba que indexara el proyecto de un hermano nativo de Android, comenzaron los problemas. En los encabezados biónicos, él se negaba a ver la definición de size_t, y junto con todas las funciones que la usaban. Probablemente, en Windows, puede corregir la situación si, en lugar de los archivos de encabezado de Microsoft, se deslizan, por ejemplo, Cygwin o MinGW SDK, pero estos trucos no son muy interesantes para mí, todavía me gustaría que el software de este nivel "coma lo que dan", y no solo que él "ama".
Las posibilidades de navegar, refactorizar y generar código de plantilla son maravillosas, pero hay preguntas para el ayudante al escribir letras: digamos que escribimos algunos caracteres de un nombre largo, ¿por qué no ofrecer opciones de finalización? No, el asistente espera pacientemente hasta que llega el usuario. o -> o ::. Tengo que presionar constantemente Ctrl + Espacio - molesto. En Java, esta deficiencia molesta podría solucionarse seleccionando todo el alfabeto en el CDT como desencadenante, pero no encontré una solución simple.
NetBeans 8.1 / 10.0 - Solía usar este IDE para Java, me recordaban como un software bueno y liviano con toda la funcionalidad necesaria. Para C ++, tiene un complemento desarrollado no por la comunidad, sino directamente por NetBeans. Para proyectos de C ++, hay una dependencia bastante difícil en make y gcc. El editor de código es pausado. No encontré una cosa muy simple en el generador de código de plantilla: agregamos un nuevo método en el archivo de encabezado de la clase; debe generar el cuerpo del método en un archivo cpp; no sabe cómo. El grado de "comprensión" del código es promedio, parece que algo está analizando, pero algo no. Por ejemplo, iterar en un mapa con un iterador automático ya es difícil para él. Él jura en macros de Google Test. Personalizar el comando de compilación es problemático: en Linux con gcc y poner a disposición (esto a pesar del hecho de que otro sistema de compilación ya está en uso) funcionará, en Windows requerirá MinGW, pero incluso si lo hace, se negará a compilar. En general, es posible trabajar en NetBeans con C ++, pero no lo llamaría cómodo; probablemente necesito realmente amar este entorno para no notar sus diversas llagas.
KDevelop 5.3.1 : una vez fue concebido como una herramienta de desarrollo para KDE (Linux), pero ahora hay una versión para Windows. Tiene un editor de código rápido y agradable con un hermoso resaltado de sintaxis (basado en Kate). No funcionará alterar el sistema de compilación izquierdo; para él, el sistema de compilación principal es CMake. Es tolerante a los encabezados del SDK de MSVC y Windows, en cualquier caso, printf y std :: string no conducen exactamente a un estupor como un CDT de Eclipse. Un ayudante muy rápido para escribir código: ofrece buenas opciones de finalización casi inmediatamente mientras escribe. Tiene una oportunidad interesante para generar código de plantilla: puede escribir su propia plantilla y ponerla en línea. Al crear desde una plantilla, puede conectarse a la base de datos de plantillas preparadas y descargar la que desee. Lo único que molesta: la plantilla incorporada para crear una nueva clase funciona de forma torcida tanto en Windows como en Linux. El asistente para crear una clase tiene varias ventanas en las que puede configurar muchas cosas: qué constructores son necesarios, qué miembros de la clase, etc. Pero en la etapa final en Windows, aparece algún tipo de error a tiempo para que el texto sea imposible y se crean dos archivos h y cpp en el tamaño de 1 byte. En Linux, por alguna razón, no puede seleccionar constructores: la pestaña está vacía y solo el archivo de encabezado se genera correctamente en la salida. En general, las enfermedades infantiles de un producto tan maduro parecen de alguna manera frívolas.
QtCreator 4.8.1 (edición de código abierto) : probablemente, al haber escuchado este nombre, está perplejo de cómo este monstruo fue encarcelado aquí bajo Qt con un kit de distribución de gigabytes con un gancho. Pero esta es una versión "ligera" del entorno para proyectos genéricos. Su kit de distribución pesa solo unos 150 MB y no lleva elementos específicos de Qt:
download.qt.io/official_releases/qtcreator/4.8 .
En realidad, puede hacer casi todo lo que escribí sobre mis requisitos de forma rápida y correcta. Analiza los encabezados estándar de Windows y Linux, lo personaliza para cualquier sistema de compilación, sugiere opciones de finalización, genera convenientemente nuevas clases, cuerpos de métodos, permite la refactorización y la navegación de código. Si solo desea trabajar cómodamente sin pensar constantemente en cómo superar este o aquel problema, tiene sentido mirar QtCreator.
En realidad, queda por hablar sobre lo que no tenía suficiente en Gradle para funcionar por completo: integración con el IDE. Para que el sistema de compilación genere archivos de proyecto para el IDE, que ya contendría comandos para construir el proyecto, se enumeran todos los archivos de origen y se necesitan rutas para buscar archivos de encabezado y determinarlos.
Para este propósito, escribí un
complemento para Gradle `cpp-ide-generator` y lo publiqué en el portal de complementos de Gradle.
El complemento solo se puede usar con `cpp-application`,` cpp-library` y `cpp-unit-test`.
Aquí hay un ejemplo de su uso en
build.gradle :
plugins { id 'cpp-library' id 'maven-publish' id 'cpp-unit-test' id 'org.bitbucket.akornilov.cpp-ide-generator' version '0.3' } library {
El complemento admite la integración con todos los entornos de desarrollo gráfico anteriores, pero en el bloque de configuración del complemento, puede desactivar la compatibilidad con IDE innecesarios:
kdevelop = false
Si el parámetro
autoGenerate se establece en verdadero, los archivos de proyecto para todos los IDE permitidos se generarán automáticamente durante la compilación. Además, en el modo de generación automática, los archivos del proyecto se eliminarán cuando se limpie la compilación:
gradle clean .
Se admite la generación incremental, es decir solo se actualizarán los archivos que requieren una actualización real.
Aquí hay una lista de objetivos que agrega el complemento:
- generateIde: genera archivos de proyecto para todos los IDE permitidos.
- cleanIde: elimina los archivos de proyecto para todos los IDE permitidos.
- generateIde [nombre]: genera archivos de proyecto para el IDE con el nombre dado (se debe permitir IDE), por ejemplo generateIdeQtCreator.
- Nombres disponibles: Eclipse, NetBeans, QtCreator, KDevelop.
- cleanIde [nombre]: elimina los archivos de proyecto para el IDE con el nombre dado, por ejemplo cleanIdeQtCreator.
Durante la generación, el complemento "olfatea" la compilación y extrae de él toda la información necesaria para crear archivos de proyecto. Después de abrir el proyecto, todos los archivos de origen deben estar visibles en el IDE, las rutas a todos los encabezados deben registrarse y los comandos de compilación básicos para configurar / compilar / borrar también deben configurarse.
El segundo complemento que tuve que hacer se llama
`cpp-build-tuner` y también funciona en conjunto con cpp-application`,` cpp-library` y `cpp-unit-test`.
El complemento no tiene configuración, es suficiente para cargarlo:
plugins { id 'cpp-library' id 'maven-publish' id 'cpp-unit-test' id 'org.bitbucket.akornilov.cpp-build-tuner' version '0.5' }
El complemento realiza pequeñas manipulaciones con la configuración de las cadenas de herramientas (compilador y enlazador) para diferentes opciones de compilación: depuración y lanzamiento. MSVC, gcc, CLang son compatibles.
Esto es especialmente cierto para MSVC, porque de manera predeterminada, como resultado de la compilación de lanzamiento, obtendrá un binario "audaz", no estético, con información de bazhe y una biblioteca estándar estáticamente vinculada. "Espiaba" parte de la configuración de MSVC en Visual Studio, que por defecto agrega a sus proyectos en C ++. Tanto para gcc / CLang como para MSVC, las optimizaciones de tiempo de enlace se incluyen en el perfil de lanzamiento.
Nota: Los complementos se probaron con la última versión de Gradle v5.2.1 y no se comprobó la compatibilidad con versiones anteriores.Los códigos fuente de los complementos, así como ejemplos simples del uso de Gradle para bibliotecas: estáticos y dinámicos, así como la aplicación que los utiliza, se pueden ver:
bitbucket.org/akornilov/tools next gradle / cpp.
Los ejemplos también muestran cómo usar Google Test para bibliotecas de pruebas unitarias.
Repositorio Maven con Google Test v1.8.1 integrado en Gradle (sin simulacro).UPD:Las versiones de Windows de
QtCreato r anteriores a
4.6.2 (y al menos al momento de escribir estas líneas, hasta
4.10 inclusive) han "olvidado cómo" entender el SDK de MSVC. Todo el std :: space está subrayado en rojo y se niega a indexar. Por lo tanto, en este momento, la versión 4.6.2 es más adecuada para trabajar con Windows.
Se ha lanzado una nueva versión del complemento
cpp-build-tuner v1.0 (y
cpp-ide-generator v0.5 son mejoras menores).
1) Se agregó un bloque de configuración a
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 (boolean): activa o desactiva LTO para la compilación de lanzamiento. Habilitado por defecto.
gtest (string): agrega compatibilidad con Google Test para pruebas unitarias. Actualmente, solo la versión 1.8.1 es compatible con GCC, MinGW-W64 y MSVC.
bibliotecas (contenedor): una lista de bibliotecas para vincular. Dentro del contenedor hay tres campos (lista de líneas):
common : bibliotecas para cualquier plataforma,
windows , solo para Windows y
linux , solo para Linux.
libDirs (contenedor): una lista de carpetas para buscar bibliotecas con un vinculador. La estructura del contenedor es la misma que la lista de la biblioteca.
2) Se agregó la capacidad de ejecutar aplicaciones para
cpp-application . El complemento agrega tareas adicionales al proyecto para esto:
run ,
runDebug (lo mismo que
run ) y
runRelease . Las tareas dependen de
assemble ,
assembleDebug y
assembleRelease respectivamente.
Al igual que el complemento de aplicación Java estándar, puede pasar parámetros de línea de comandos al inicio:
gradle run --args="arg1 arg2 ..." .
UPDEn relación con el cambio de complementos de alojamiento, el grupo cambió:
plugins { id 'loggersoft.cpp-build-tuner' version '1.1' id 'loggersoft.cpp-ide-generator' version '0.5' }
Nueva dirección del proyecto:
gradle-cpp.sourceforge.ioDocumentación:
sourceforge.net/p/gradle-cpp/wiki/cpp-build-tunersourceforge.net/p/gradle-cpp/wiki/cpp-ide-generator