¿Cuáles son las diferencias entre Autotools, Cmake y Scons?

¿Cuáles son las diferencias entre Autotools, Cmake y Scons?

En verdad, la única "gracia salvadora" real de Autotools es que es lo que todos los proyectos de GNU están usando en gran medida.

Problemas con Autotools:

• Verdaderamente, la sintaxis de macro ARCANE m4 combinada con scripting verboso y retorcido para pruebas de "compatibilidad", etc.
• Si usted no está prestando atención, que va a estropear la capacidad de compilación cruzada (Debe tenerse en cuenta que claramente Nokia subió con Scratchbox / Scratchbox2 a paso lateral altamente roto Autotools configuraciones de construcción para Maemo / MeeGo.) Si, por cualquier Por lo tanto, tenga rutas fijas y estáticas en sus pruebas, va a romper el soporte de compilación cruzada porque no respetará su especificación sysroot y sacará cosas de su sistema host. Si interrumpe el soporte de compilación cruzada, hace que su código sea inutilizable para cosas como OpenEmbedded y lo hace "divertido" para las distribuciones que intentan construir sus lanzamientos en un compilador cruzado en lugar de en el destino.
• Hace una ENORME cantidad de pruebas para detectar problemas con compiladores antiguos y rotos que NADIE usa actualmente con casi cualquier producción en la actualidad. A menos que esté construyendo algo como glibc, libstdc ++ o GCC en una versión verdaderamente antigua de Solaris, AIX o similar, las pruebas son una pérdida de tiempo y son una fuente de muchas, muchas posibles roturas de cosas como las mencionadas anteriormente.
• Es una experiencia bastante dolorosa obtener una configuración de Autotools para construir código utilizable para un sistema Windows. (Si bien tengo poco uso para Windows, es una gran preocupación si está desarrollando código supuestamente multiplataforma).
• Cuando se rompa, pasarás HORAS persiguiendo tu cola tratando de resolver las cosas que cualquiera que escribió el script se equivocó para resolver tu compilación (De hecho, esto es lo que estoy tratando de hacer (o, más bien, rasgue las herramientas automáticas por completo: dudo que haya suficiente tiempo en el resto de este mes para resolver el problema ...) para el trabajo ahora mismo mientras escribo esto. Apache Thrift tiene uno de esos sistemas de construcción ROTOS que no se cruzarán -compilar.)
• Los usuarios "normales" en realidad NO solo van a hacer "./configure; make" - para muchas cosas, van a sacar un paquete proporcionado por alguien, como un PPA o su proveedor de distribución. Los usuarios "normales" no son desarrolladores y no están agarrando tarballs en muchos casos. Eso es esnobismo por parte de todos por suponer que ese será el caso allí. Los usuarios típicos de los tarballs son los desarrolladores que hacen cosas, por lo que se verán afectados si están allí.

Funciona ... la mayor parte del tiempo ... es todo lo que puedes decir sobre Autotools. Es un sistema que resuelve varios problemas que solo conciernen realmente al proyecto GNU ... para su código de cadena de herramientas base y central. (Editar (24/05/2014): Cabe señalar que este tipo de preocupación es algo potencialmente MAL por el que preocuparse: Heartbleed se deriva parcialmente de este pensamiento y con sistemas correctos y modernos, realmenteno tiene ningún negocio que se ocupe de gran parte de lo que corrige Autotools. GNU probablemente necesita hacer una eliminación cruda de la base de código, a la luz de lo que sucedió con Heartbleed). Puede usarlo para hacer su proyecto y podría funcionar bien para un proyecto pequeño que no espera que funcione en ningún otro lugar, excepto Linux o donde la cadena de herramientas GNU claramente funciona correctamente. La expresión de que "se integra muy bien con Linux" es bastante la declaración audaz y bastante incorrecta . Se integra con el conjunto de herramientas GNU razonablemente bien y resuelve los problemas que TI tiene con sus objetivos.

Esto no quiere decir que no haya problemas con las otras opciones discutidas en el hilo aquí.

SCons es más un reemplazo para Make / GMake / etc. y se ve muy bien, considerando todas las cosas Sin embargo ...

• Todavía es más una herramienta POSIX. Probablemente podría obtener más fácilmente MinGW para construir cosas de Windows con esto que con Autotools, pero todavía está más orientado a hacer cosas POSIX y necesitaría instalar Python y SCons para usarlo.
• Tiene problemas para hacer una compilación cruzada a menos que esté usando algo como Scratchbox2.
• Es cierto que es más lento y menos estable que CMake en su propia comparación. Llegan con poco entusiasmo (el lado POSIX necesita make / gmake para construir ...) negativos para CMake en comparación con SCons. (Por otro lado, si necesita TAN extensibilidad sobre otras soluciones, debería preguntarse si su proyecto es demasiado complicado ...)

Los ejemplos dados para CMake en este hilo son un poco falsos.

Sin embargo...

• Necesitarás aprender un nuevo idioma.
• Hay cosas contra-intuitivas si estás acostumbrado a Make, SCons o Autotools.
• Deberá instalar CMake en el sistema para el que está compilando.
• Necesitará un compilador de C ++ sólido si no tiene binarios precompilados para él.

En verdad, tus objetivos deberían dictar lo que eliges aquí.

• ¿Necesita lidiar con MUCHAS cadenas de herramientas rotas para producir un binario de trabajo válido? En caso afirmativo, es posible que desee considerar Autotools, teniendo en cuenta los inconvenientes que mencioné anteriormente. CMake puede hacer frente a mucho de esto, pero le preocupa menos que Autotools. Los SCons se pueden extender para preocuparse por eso, pero no es una respuesta inmediata allí.
• ¿Tienes que preocuparte por los objetivos de Windows? Si es así, Autotools debería estar literalmente fuera de la ejecución. Si es así, SCons puede / puede no ser una buena opción. Si es así, CMake es una opción sólida.
• ¿Tiene que preocuparse por la compilación cruzada (aplicaciones / bibliotecas universales, cosas como Google Protobufs, Apache Thrift, etc. ¿ DEBE preocuparse por esto ...)? Si es así, Autotools podríafunciona para usted siempre y cuando no necesite preocuparse por Windows, pero pasará mucho tiempo manteniendo su sistema de configuración a medida que las cosas cambien. SCons es casi imposible en este momento, a menos que esté usando Scratchbox2; realmente no tiene control sobre la compilación cruzada y tendrá que usar esa extensibilidad y mantenerla de la misma manera que Lo harás con Automake. Si es así, es posible que desee considerar CMake, ya que admite la compilación cruzada sin tantas preocupaciones por la fuga del sandbox y funcionará con / sin algo como Scratchbox2 y se integra muy bien con cosas como OpenEmbedded.

Hay una razón por la que muchos, muchos proyectos están abandonando qmake, Autotools, etc. y se están moviendo a CMake. Hasta ahora, puedo esperar limpiamente que un proyecto basado en CMake caiga en una situación de compilación cruzada o en una configuración de VisualStudio o solo necesite una pequeña cantidad de limpieza porque el proyecto no tuvo en cuenta solo las partes de Windows o OSX a la base de código. Realmente no puedo esperar que de un proyecto basado en SCons, y espero que 1/3 o más proyectos de Autotools se hayan equivocado ALGO que impide que se desarrolle correctamente en cualquier contexto, excepto el host que construye uno o Scratchbox2.

Debe hacerse una distinción importante entre quién usa las herramientas. Cmake es una herramienta que debe ser utilizada por el usuario al construir el software. Las herramientas automáticas se usan para generar un tarball de distribución que se puede usar para construir el software usando solo las herramientas estándar disponibles en cualquier sistema compatible con SuS. En otras palabras, si está instalando software desde un tarball que se creó utilizando las herramientas automáticas, no está utilizando las herramientas automáticas . Por otro lado, si está instalando software que usa Cmake, entonces está usando Cmake y debe tenerlo instalado para construir el software.

La gran mayoría de los usuarios no necesitan tener las herramientas automáticas instaladas en su caja. Históricamente, se ha causado mucha confusión porque muchos desarrolladores distribuyen tarballs malformados que obligan al usuario a ejecutar autoconf para regenerar el script de configuración, y esto es un error de empaquetado. Más confusión ha sido causada por el hecho de que la mayoría de las principales distribuciones de Linux instalan múltiples versiones de las herramientas automáticas, cuando no deberían instalar ninguna de ellas por defecto. Aún más confusión es causada por los desarrolladores que intentan usar un sistema de control de versiones (por ejemplo, cvs, git, svn) para distribuir su software en lugar de construir tarballs.

No se trata de estándares de codificación GNU.

Los beneficios actuales de las herramientas automáticas, específicamente cuando se usan con automake, es que se integran muy bien con la construcción de la distribución de Linux.

Con cmake, por ejemplo, siempre es "¿fue -DCMAKE_CFLAGS o -DCMAKE_C_FLAGS lo que necesito?" No, no es ninguno, es "-DCMAKE_C_FLAGS_RELEASE". O -DCMAKE_C_FLAGS_DEBUG. Es confuso: en autoconf, es solo ./configure CFLAGS = "- O0 -ggdb3" y lo tiene.

En integración con las infraestructuras de compilación, scons tiene el problema que no puede usar make %{?_smp_mflags}, _smp_mflagsen este caso es una macro RPM que se expande aproximadamente a (el administrador puede configurarlo) la potencia del sistema. La gente pone cosas como -jNCPUS aquí a través de su entorno. Con scons que no funciona, entonces los paquetes que usan scons solo pueden ser seriamente integrados en distribuciones.

Lo que es importante saber sobre los Autotools es que no son un sistema de construcción general: implementan los estándares de codificación GNU y nada más. Si desea hacer un paquete que siga todos los estándares GNU, entonces Autotools es una excelente herramienta para el trabajo. Si no lo hace, entonces debe usar Scons o CMake. (Por ejemplo, vea esta pregunta ). Este malentendido común es de donde proviene la mayor parte de la frustración con Autotools.

Si bien desde el punto de vista de los desarrolladores, cmake es actualmente el más fácil de usar, desde la perspectiva del usuario, las herramientas automáticas tienen una gran ventaja

Las herramientas automáticas generan un solo script de configuración de archivo y todos los archivos para generarlo se envían con la distribución. Es fácil de entender y solucionar con la ayuda de grep / sed / awk / vi. Compare esto con Cmake, donde se encuentran muchos archivos en / usr / share / cmak * / Módulos, que el usuario no puede solucionar a menos que tenga acceso de administrador.

Por lo tanto, si algo no funciona del todo, por lo general se puede "arreglar" fácilmente mediante el uso de herramientas estándar de Unix (grep / sed / awk / vi, etc.) en forma de mazo sin tener que comprender el sistema de compilación.

¿Alguna vez ha cavado a través de su directorio de compilación de cmake para descubrir qué está mal? En comparación con el simple shellscript que se puede leer de arriba a abajo, seguir los archivos generados de Cmake para descubrir lo que está sucediendo es bastante difícil. Además, con CMake, la adaptación de los archivos FindFoo.cmake requiere no solo el conocimiento del lenguaje CMake, sino que también puede requerir privilegios de superusuario.