build - como hacer scones clasicos

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

En verdad, el único "ahorro real" de Autotools es que es lo que todos los proyectos de GNU están utilizando en gran medida.

Problemas con Autotools:

La verdadera sintaxis de macros de ARCANE m4 combinada con scripts de shell retorcidos y verbosos para pruebas de "compatibilidad", etc.
Si no estás prestando atención, arruinarás la capacidad de compilación cruzada (se debe tener en cuenta que Nokia creó Scratchbox / Scratchbox2 para realizar configuraciones de compilación de Autotools altamente dañadas para Maemo / Meego). Por lo tanto, tenga rutas fijas y estáticas en sus pruebas, va a interrumpir el soporte de compilación cruzada porque no cumplirá con la especificación de sysroot y sacará cosas de su sistema host. Si rompe 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 objetivo.
Hace una gran cantidad de pruebas para problemas con compiladores antiguos y rotos que NOBODY utiliza actualmente con prácticamente cualquier producción en este día y época. A menos que esté construyendo algo como glibc, libstdc ++ o GCC en una versión verdaderamente antigua de Solaris, AIX o similares, las pruebas son una pérdida de tiempo y son una fuente de muchas, muchas posibles rupturas de cosas como las mencionadas anteriormente.
Es bastante una experiencia 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 preocupación seria si está desarrollando supuestamente un código multiplataforma).
Cuando se rompa, vas a pasar HORAS persiguiendo a tu cola tratando de resolver las cosas en las que quien escribió el guión se equivocó para ordenar tu compilación (de hecho, esto es lo que estoy tratando de hacer (o, mejor dicho, extraiga Autotools por completo: dudo que haya suficiente tiempo en el resto de este mes para solucionar el problema ...) para trabajar ahora mismo mientras escribo esto. Apache Thrift tiene uno de esos sistemas de construcción ROTOS que no se cruzan -compilar.)
Los usuarios "normales" en realidad NO van a hacer simplemente "./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 devs 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 devs que hacen cosas, por lo que se verán afectados por la rotura si está allí.

Funciona ... la mayoría de las veces ... 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 básico de cadena de herramientas. (Edición (24/05/2014): Se debe tener en cuenta que este tipo de inquietud es una cuestión potencialmente MALA de la que preocuparse. Heartbleed se deriva en parte de este pensamiento y con los sistemas correctos y modernos, realmente no tiene ningún negocio se ocupa de gran parte de lo que Autotools corrige. GNU probablemente necesita hacer una eliminación cruzada 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 t espera trabajar en cualquier lugar, excepto en Linux o donde la cadena de herramientas GNU está funcionando correctamente. La afirmación de que "se integra muy bien con Linux" es bastante 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 que se analizan 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 realmente una herramienta única POSIX. Probablemente podría hacer que MinGW construya cosas de Windows con esto más fácilmente que con Autotools, pero todavía está más orientado a hacer cosas de POSIX y tendría que instalar Python y SCons para usarlo.
Tiene problemas para realizar la compilación cruzada a menos que esté utilizando algo como Scratchbox2.
Es cierto que más lento y menos estable que CMake de su propia comparación. Ellos vienen con medios de corazón (el lado de POSIX necesita hacer / gmake para construir ...) negativos para CMake en comparación con SCons. (Dejando de lado, si necesita MUCHA 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 contraintuitivas si estás acostumbrado a hacer, SCons o Autotools.
Tendrá que instalar CMake en el sistema para el que está construyendo.
Necesitará un compilador de C ++ sólido si no tiene binarios precompilados para él.

En verdad, sus metas deben dictar lo que elija aquí.

¿Necesita lidiar con MUCHAS cadenas de herramientas rotas para producir un binario de trabajo válido? Si es así, es posible que desee considerar Autotools, teniendo en cuenta los inconvenientes que mencioné anteriormente. CMake puede hacer frente a mucho de esto, pero se preocupa menos con él que Autotools. Los scons pueden ampliarse para preocuparse por eso, pero no es una respuesta inmediata.
¿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 / 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. ¿ DEBERÍA preocuparse por esto ...)? Si es así, Autotools podría funcionar para usted siempre y cuando no tenga que 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é utilizando 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 la mayor cantidad de preocupaciones sobre fugas de la caja de arena 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 cambiando 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 las partes solo de Windows o solo de OSX al código base. Realmente no puedo esperar que fuera de un proyecto basado en SCons, y espero completamente que la tercera parte o más de los proyectos de Autotools se hayan equivocado ALGO que impide que se pueda construir en cualquier contexto, excepto el de host o el Scratchbox2.

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

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 cumpla con todos los estándares de GNU, Autotools es una excelente herramienta para el trabajo. Si no lo haces, entonces debes 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.

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

Los beneficios actuales de autotools, específicamente cuando se usan con automake, son que se integran muy bien con la construcción de la distribución de Linux.

Con cmake, por ejemplo, siempre es "¿fue eso -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 ya lo tiene.

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

Se debe hacer una distinción importante entre quién usa las herramientas. Cmake es una herramienta que debe ser utilizada por el usuario al crear el software. Los autotools se usan para generar un tarball de distribución que se puede usar para construir el software utilizando solo las herramientas estándar disponibles en cualquier sistema compatible con SuS. En otras palabras, si está instalando software desde un archivo comprimido construido con las autotools, no está utilizando las autotools . 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 los autotools instalados en su caja. Históricamente, se ha generado mucha confusión porque muchos desarrolladores distribuyen archivos comprimidos con formato incorrecto 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 se debe al hecho de que la mayoría de las principales distribuciones de Linux instalan varias versiones de las autotools, 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 archivos comprimidos.

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.

autotools genera un solo archivo de comandos de configuración y todos los archivos para generarlo se envían junto con la distribución. Es fácil de entender y corregir con la ayuda de grep / sed / awk / vi. Compare esto con Cmake, donde se encuentran muchos archivos en / usr / share / cmak * / Modules, que el usuario no puede reparar a menos que tenga acceso de administrador.

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

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