Qué escribir y cómo ensamblar un proyecto C ++

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 { // Library specific parameters } // Configuration block of plugin: ide { autoGenerate = false eclipse = true qtCreator = true netBeans = true kdevelop = true } 

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 ..." .

UPD

En 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.io

Documentación:
sourceforge.net/p/gradle-cpp/wiki/cpp-build-tuner
sourceforge.net/p/gradle-cpp/wiki/cpp-ide-generator

Source: https://habr.com/ru/post/442682/


All Articles