tools compiler c++ build

tools - c++11 compiler ubuntu



C++ Build Systems-¿Qué usar? (8)

Estoy buscando comenzar un nuevo proyecto en C ++, solo en mi propio tiempo, y estoy investigando los sistemas de compilación que están disponibles. Parece que la respuesta es "Muchos, y todos son horribles".

Las características que específicamente necesito para esto son:

  1. Soporte C ++ 11
  2. Plataforma cruzada (Linux como objetivo principal, pero capaz de construir al menos Windows también)
  3. Soporte de prueba de unidad decente
  4. Soporte para múltiples módulos para separar el código
  5. Soporte para generación de código (usando asn1c o protobuf - no es 100% seguro todavía)
  6. Facil de mantener

Ahora, sé que puedo hacer 1-4 de las personas que usan CMake y Autotools con la suficiente facilidad. Probablemente también con SCons y Waf y los otros también. El problema es que nunca resolví cómo usar correctamente la generación de código, es decir, los archivos fuente que no existen hasta que el proceso de compilación se ejecuta por primera vez, por lo que los archivos fuente que el sistema de compilación debe poder convertir en código ejecutable pero en realidad no se conoce hasta que se inicia la construcción ... (ASN1C en particular genera docenas de archivos de cabecera y fuente que deben poder trabajar juntos, y el conjunto real de archivos que genera depende del contenido de su archivo asn). también el hecho de que ninguno de estos es especialmente fácil de mantener: CMake y Autotools tienen su propio conjunto de scripts que debes gestionar para que funcionen, y Waf y Scons requieren que cualquiera que trabaje con ellos tenga un conocimiento decente de python (I no) para trabajar con ellos ...

Entonces, ¿qué sistemas de construcción se recomiendan para algo como esto? ¿O estaré atascado con make files y scripts de shell por ahora?

+1 por, "Muchos, y son horribles".

Pero, el "más rico" y el "más escalable" es probablemente CMake , que es un generador de Makefile (también genera MSVC ++ *.proj / *.sln *.proj ). Sintaxis extraña, pero una vez que la aprendes, puede permitirte generar compilaciones para diferentes plataformas. Si "comencé-fresh", probablemente usaría CMake . Debería manejar su lista, aunque su "generación de código" podría asumir una "vida propia" más allá del sistema de compilación, dependiendo de lo que quiera hacer. (Vea abajo.)

Para proyectos simples, el generador QMake está bien (no es necesario usar las bibliotecas Qt para usar QMake). Pero no está describiendo la "simple" generación de código y las "extrafases" significa que probablemente quiera CMake o algo con una API rica para sus propias extensiones, como Scons (o Waf ).

Usamos Scons en el trabajo. Produce "construcciones a prueba de balas", pero es muy lento. Ningún otro sistema será tan a prueba de balas como Scons . Pero, es lento. Está escrito en Python y hemos ampliado la interfaz para nuestra "organización de espacio de trabajo" (donde simplemente especificamos dependencias de módulos), y eso forma parte de la intención de diseño de Scons (este tipo de extensión a través de Python). Práctico, pero las construcciones son lentas. Obtiene compilaciones a prueba de balas (cualquier caja de desarrollador puede hacer la versión final), pero es lenta. Y, es lento. No olvide que si usa Scons , es lento. Y, es lento.

Me pone enfermo pensar que una década después del año 2000, todavía no tenemos automóviles voladores. Probablemente tendremos que esperar otros cien años o algo para obtenerlos. Y, entonces, probablemente todos estemos volando en nuestros autos voladores que todavía se están construyendo con sistemas de construcción de mierda.

Sí, todos son horribles

[ACERCA DE LA GENERACIÓN DE CÓDIGOS]

Scons trabaja en "fases" y son "algo estáticas". Puede generar código que se genera como parte de la construcción (las personas lo hacen de dos maneras diferentes), pero esto se ha descrito como "algo muy poco similar a Scons".

Si es simple "preprocesar algunos archivos y generar archivos fuente", entonces no hay problema (hay muchas opciones, y esta es la razón por la qmake se escribió - para el preprocesamiento de *.hpp/*.cpp archivos *.hpp/*.cpp ).

Sin embargo, si estás haciendo esto de una manera "pesada", vas a necesitar crear tu propio script. Por ejemplo, teníamos scripts de una parte de la construcción que consultaban las bases de datos y generaban clases de C ++ para la interfaz entre las "capas" (en el desarrollo tradicional de aplicaciones de 3 niveles). De manera similar, generamos código fuente de servidor / cliente a través de IDL e información de versión incorporada para permitir que varios clientes / servidores se ejecuten simultáneamente con diferentes versiones (para el mismo "cliente" o "servidor"). Un montón de código fuente generado. Podríamos "pretender" que es "el sistema de compilación", pero en realidad, es una infraestructura no trivial para "gestión de configuración", de la cual parte es el "sistema de compilación". Por ejemplo, este sistema tenía que incluir servidores de "extracción" y "puesta en marcha" como parte de este proceso. Del mismo modo, las pruebas de regresión se realizaron como parte de este proceso, con "informes" y "pruebas de diferencias" entre versiones, todo como parte de nuestros "scripts de compilación".

El sistema de compilación de Google es una buena alternativa: http://bazel.io/

Puede usar Gradle ahora: https://docs.gradle.org/current/userguide/native_software.html

Esto parece haber madurado bastante en los años desde que originalmente publiqué esto. La página que dice que el proyecto está "incubando" ha desaparecido, pero no puedo encontrar ningún anuncio oficial que elimine este estado.

Puedes usar Ceedling . Sin embargo, tenga en cuenta que solo admite C en este momento y está estrechamente relacionado con los marcos de prueba Unity y CMock del autor.

Se puede bifurcar y modificar para que funcione con un compilador de C ++ y un marco de pruebas / burlas unitarias con bastante facilidad.

También Tup es una digna mención. Es extremadamente rápido, pero no sabe nada sobre pruebas de marcos, etc., lo que significa que tendrá que escribir su propio sistema de compilación utilizando Tup. Si planeas hacer TDD, Tup es probablemente el camino a seguir.

Recientemente me enteré de estos, aún no los he usado personalmente:

Ninja , un pequeño sistema de construcción enfocado en la velocidad. Google ahora usa Ninja para construir Android en lugar de Make: link .

Shake , un sistema de compilación potente y rápido.

Tup , un sistema de compilación de alto rendimiento. Diseño basado en Algorithmic . Análisis de Tup .

Todos son ahora multiplataforma y admiten Windows. Todavía no estoy seguro sobre el resto de sus requisitos ya que, de nuevo, todavía tengo que probarlos yo mismo. Están siendo utilizados en el desarrollo comercial, CIG recogió Ninja. Los primeros dos son similares a Scons, Ant, etc.

Scons es un sistema muy amigable y flexible, pero tienes razón, Lothar, es realmente lento.

Pero hay una manera de aumentar el rendimiento de los programas escritos en Python. Este uso del JIT. De todos los proyectos conocidos, PyPy es una implementación de Python 2.7 muy potente, de rápido crecimiento y motivada por JIT. La compatibilidad de PyPy con Python 2.7 es simplemente increíble. Sin embargo, Scons declaró como proyecto no compatible en la wiki de compatibilidad PyPy . Waf , por otro lado, modelado como sucessor autotools basado en python, es totalmente compatible con la infraestructura PyPy. En mis proyectos, la velocidad del ensamblaje aumentó 5-7 veces en la transición a PyPy. Puede ver los informes de rendimiento de PyPy .

Para el sistema de construcción moderno y relativamente rápido, Waf es una buena opción.

Utilicé SCons y estoy impresionado por este sistema de compilación. SCons es extensible por python y python; es genial, porque Python tiene todo lo que necesita, solo codifica la lógica, todas las funcionalidades de bajo nivel ya están implementadas en SCons y Python y es crossplatform. Si tiene buenas habilidades de programación, sus scripts de construcción se verán perfectos y fáciles.

Make, CMake y sistemas de compilación similares parecen basura de macros. Waf es SCons analógico. Estoy probando Waf, pero SCons será más amigable y me quedé con SCONS.

Según la opinión de la multitud, SCons es demasiado lento, pero en el medio de un proyecto no vi ninguna diferencia entre make y SCons por velocidad de compilación. En cambio, SCons ha trabajado bien con construcciones paralelas, mientras que make tiene grandes problemas.

Además, SCons le permite: configurar, crear, implementar, generar configuración desde plantillas, ejecutar pruebas y realizar cualquier otra tarea que se pueda hacer para codificar con Python y SCons, todo en uno. Esa es una gran ventaja.

Para un proyecto simple, CMake también es una buena opción.