2009-12-18 9 views
41

Hace unos años analicé el uso de algún sistema de compilación que no sea Make, y herramientas como CMake y SCons parecían bastante primitivas. Me gustaría averiguar si la situación ha mejorado. Así, bajo los siguientes criterios, lo que es actualmente la mejor herramienta de construcción:¿Cuál es actualmente el mejor sistema de compilación?

  • independiente de la plataforma: debería funcionar en Windows, Linux, Mac
  • lenguaje agnóstico: debería haber incorporado soporte para cosas comunes como el edificio C/C++ y otras langs estáticas. Supongo que no es necesario que sea compatible con el conjunto completo de autotools.
  • extensible: Necesito poder escribir reglas para generar archivos, como restructuredText, latex, formatos personalizados, etc. No me importa en qué idioma tenga que escribir las reglas, pero preferiría un lenguaje real en lugar de que un DSL.
  • Preferiría evitar escribir cualquier XML a mano, lo cual creo que por ejemplo ant requiere.
  • libremente disponibles (fuente abierta de preferencia)

El término "mejor" es un poco subjetivo, pero creo que las respuestas pueden ser valorados objetivamente por los criterios anteriores.

+0

Estoy confundido. Usted dice "no es necesario que admita el conjunto completo de autotools". ¿Esto significa que su pregunta debe reformularse: "¿Cuál es el siguiente mejor sistema de compilación después de autoconf/automake?" –

+0

@William Pursell: No. Estoy dejando de lado explícitamente el requisito de compatibilidad con autoconf y automake, ya que está estrechamente vinculado a Makefiles. –

+1

No veo nada malo con la pregunta original o la discusión resultante. Dado que esta pregunta ahora es el principal motor de búsqueda de "mejor sistema de compilación", esta pregunta debe reabrirse. Podría entender cerrarlo si la discusión hubiera sido realmente obstinada, o si realmente hubiera atraído spam, pero ese no es el caso. – user1110743

Respuesta

23

Definitivamente votaría por premake. Aunque no es tan poderoso como sus hermanos mayores, su principal ventaja es la simplicidad absurda y la facilidad de uso. Hace que escribir código multi-compilador, multiplataforma sea fácil y genera de manera nativa soluciones de Visual Studio, proyectos XCode, Makefiles y otros, sin necesidad de realizar ningún trabajo adicional.

+0

Se ve muy bien. Dicho esto, ¿no parece que admite mucho "fuera de la caja"? –

+2

Y Premake incluye un intérprete de Lua, que es un lenguaje de scripting más potente que el de CMake, en mi opinión. – Splo

+1

Y no necesita descargar un intérprete de Python para Windows como Scons o Waf. – Splo

-1

Final Builder es bien conocido en el mundo de Windows

+3

No pensé mencionar que debería ser libre (preferiblemente como en el habla). He arreglado la pregunta. –

+0

Wow. A pesar de que parece un programa de solo descarga, usan iconos que me recuerdan a la caja de Vista que es imposible de descifrar. – Ken

0

El proyecto selenio se mueve hacia Rake, no porque es el mejor, pero ya que maneja varios idiomas ligeramente mejor que todas las otras herramientas de construcción y es multiplataforma (desarrollado en Ruby).

Todas las herramientas de compilación tienen sus problemas y la gente aprende a convivir con ellas. Algo que se ejecuta en la JVM tiende a ser muy bueno para la creación de aplicaciones de manera Ant, Maven (sé que es horrible), Ivy, Rake

6

CMake

CMake es un extensible, de código abierto sistema que gestiona el proceso de compilación en un sistema operativo y de manera independiente del compilador .

+0

Supongo que tuvo problemas con las ventanas hace unos años. ¿Están arreglados? –

+0

Empecé a usarlo recientemente y no he tenido ningún problema. Teniendo en cuenta que MySQL lo usa para sus compilaciones de Windows, no puedo ver que tenga problemas importantes. –

+2

CMake es mucho mejor que autotools pero aún usa su propia DSL y veo esto como un impedimento: tienes que invertir en aprender un nuevo idioma. Por esta razón, buscaría soluciones como Waf (Python) o Rake (Ruby). – sorin

13

Por lo tanto, a juzgar solo por los criterios establecidos en la pregunta, el sistema de compilación que parece ser el más adecuado probablemente sea waf - Python puro, proporciona compatibilidad con C++ y otros lenguajes, general, poderoso, no DSL.


Sin embargo, desde mi experiencia personal, prefiero CMake para proyectos de C++. (Probé CMake, SCons y waf, y me gustaron más o menos en ese orden). CMake es una solución general, pero tiene soporte integrado para C++ que lo hace más agradable que una solución más genérica cuando en realidad estás haciendo C++.

El modelo de compilación de CMake para C++ es más declarativo y menos imperativo, y por lo tanto, para mí, más fácil de usar.La sintaxis del lenguaje CMake no es excelente, pero una compilación declarativa con una sintaxis impar supera una construcción imperativa en Python. De los tres, CMake también parece tener el mejor soporte para cosas "avanzadas" como encabezados precompilados. La configuración de encabezados precompilados redujo el tiempo de reconstrucción en aproximadamente un 70%.

Otras ventajas para CMake incluyen documentación decente y una comunidad considerable. Muchas bibliotecas de código abierto tienen archivos de compilación CMake en el árbol o proporcionados por la comunidad CMake. Hay proyectos importantes que ya usan CMake (OGRE viene a la mente), y otros proyectos importantes, como Boost y LLVM, están en proceso de mudarse a CMake.

Parte del problema que encontré al experimentar con los sistemas de compilación es que estaba tratando de crear un complemento NPAPI en OS X, y resulta que muy pocos sistemas de compilación están configurados para darle a XCode la combinación exacta de indicadores requerida para hacerlo CMake, reconociendo que XCode es un objetivo complejo y en movimiento, proporciona un gancho para establecer manualmente los comandos en los proyectos XCode generados (y en Visual Studio, creo). Esto es muy inteligente en lo que a mí respecta.

Si está creando una biblioteca o una aplicación también puede determinar qué sistema de compilación es mejor. Boost aún utiliza un sistema basado en mermas, en parte porque brinda el soporte más completo para administrar tipos de compilación que son más complejos que "Depurar" y "Liberar". La mayoría de las bibliotecas de refuerzo tienen cinco o seis versiones diferentes, especialmente en Windows, anticipando que las personas necesitan bibliotecas compatibles que vinculen con diferentes versiones del CRT.

No tuve ningún problema con CMake en Windows, pero por supuesto su kilometraje puede variar. Hay una GUI decente para configurar dependencias de compilación, aunque es complicado utilizarla para las reconstrucciones. Afortunadamente, también hay un cliente de línea de comandos. Lo que he decidido hasta ahora es tener un Makefile de envoltura delgada que invoque a CMake desde un objdir; CMake luego genera Makefiles en el objdir, y el Makefile original los usa para hacer la compilación. Esto garantiza que las personas no invoquen accidentalmente CMake desde el directorio de origen y llenen su repositorio. ¡Combinado con MinGW, este "sándwich CMake" proporciona una experiencia de construcción multiplataforma notablemente consistente!

+0

Tengo que secundar esto. MacOSX y CMake simplemente no son una solución si se tiene en cuenta la calidad (usando herramientas como el soporte de internacionalización). Voy a migrar nuestro sistema de compilación un día, actualmente funciona aceptable para una aplicación más sencilla en inglés – Lothar

+0

WAF es un código abismal de baja calidad. Imposible extender o incluso leer (me preguntaba si fue ofuscado a propósito, pero sea lo que sea, parece ser la única versión que hay). Imposible depurar o predecir lo que va a hacer. Es una broma de un programa de diseño de software wrt, codificación de Python puramente laxa mezclada con grotesca generación de código de tiempo de ejecución donde era absolutamente innecesario. Aaaand ... tiene un libro escrito sobre él * facepalm *. – wvxvw

12

Por supuesto, eso depende de cuáles sean sus prioridades. Si busca principalmente la facilidad de uso, existen al menos dos nuevos sistemas de compilación que se conectan al sistema de archivos para rastrear automáticamente las dependencias de una manera independiente del idioma.

Uno es TUP:

http://gittup.org/tup/

y el otro es fabricar:

http://code.google.com/p/fabricate/

El que parece ser el de mejor rendimiento, portátil y madurar (y la que Lo he usado) es tup. El chico que lo escribió incluso mantiene una distribución de juguetes de Linux donde todo es un submódulo de git, y todo (incluido el kernel) está construido con tup. Por lo que he leído sobre el sistema de compilación del kernel, esto es todo un logro.

Además, Tup limpia objetivos viejas y otros costra, y puede mantener automáticamente sus archivos .gitignore. El resultado es que resulta trivial experimentar con el diseño y los nombres de tus objetivos, y puedes saltar con confianza entre las revisiones de git sin reconstruir todo. Está escrito en C.

Si conoces a Haskell y está buscando algo para los casos de uso muy avanzadas, echa un vistazo a batido:

http://community.haskell.org/~ndm/shake/

Actualización: no he probado, pero esta nueva herramienta "buildsome" también ganchos en el sistema de archivos, y fue inspirado por TUP, por lo que es relevante:

https://github.com/ElastiLotem/buildsome

+0

Según tengo entendido, rehacer no se conecta al sistema de archivos, solo tup y fabricarlo. –

2

Gradle parece coincidir con todos los criterios mencionados anteriormente.

Es un sistema de construcción que combina lo mejor de Maven y Ant. Para mí, eso es lo mejor.

-2

smooth build corresponde a la mayoría de sus requisitos.

  • independiente de la plataforma: sí, está escrito en Java
  • lenguaje agnóstico: no es compatible con C/C++ t sin embargo, sólo el java pero es extensible mediante plugins escritos en Java por lo que añadir más apoyo compiladores no es un problema
  • extensible: sí, puede implementar una función suave mediante el complemento java, también puede crear una función suave definiéndola como una expresión compuesta de otras funciones suaves.
  • yo preferiría evitar escribir cualquier XML: no verá una sola línea de la misma en la acumulación suave
  • libremente disponible: Sí, Apache 2 licencia

divulgación: Soy el autor de construcción lisa

Cuestiones relacionadas