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.
La sección que menciona Heartbleed resta valor a esta queja frustrada. El problema era que OpenSSL NO usaba un paquete de tipo configurador para detectar malloc roto, sino que re-implementaba las bibliotecas del sistema y derrotaba a los desarrolladores de plataformas que producían bibliotecas que habrían detectado fallas mucho antes. Una de las razones de programas de puertos es que se conviertan en una mayor calidad, ya que son menos dependientes de esas pequeñas suposiciones que no se da cuenta de evcen está haciendo
Rob11311
9
Lo que pasa es que no le resta nada de nada. Con Autotools, te preocupas por compensar cosas como esas: esas reimplementaciones son una EXPANSIÓN de ese pensamiento. Llevándolo al siguiente nivel por así decirlo. Debería ver eso desde ese telón de fondo ... en cuyo punto no le resta nada. No identificó la causa raíz en su razonamiento, solo lo que sucedió. Estoy señalando el PENSAMIENTO exacto que lo llevó a eso junto con Shellshock y algunos otros como él. Si está roto, debe FIJARLO. Si no puede, debe preguntar por qué sigue así.
Svartalf
55
No dudo que las herramientas automáticas y los scons apestan, pero esta respuesta hace un mal trabajo al notar las desventajas de CMake (mi sistema de compilación preferido, solo por el muy, muy triste estado de los sistemas de compilación). Básicamente, CMake es un fractal de inconsistencia con soporte incorporado para casos límite individuales en lugar de alguna abstracción central que maneja la mayoría de las cosas. Definitivamente es la cinta adhesiva y el cable de la programación. Estoy seguro de que estoy haciendo algo mal, pero no es compatible con VisualStudio a menos que encuentre un proyecto VS por CMakeLists.txt aceptable (no soy un usuario VS, pero mis Winfriends me dicen que es malo).
@JAB Los usuarios de VS me dicen que esto no es idiomático. De hecho, CMake fue reemplazado como el sistema de compilación de nuestro proyecto porque nadie podía descubrir cómo producir dichos archivos VS Project "idiomáticos".
weberc2
73
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.
Es cierto, aunque parezca que es malo usar un VCS para distribuir software. Si el contenido de un pago o clon es el mismo que el contenido de un tarball, ¿por qué recomendaría tarballs?
d -_- b
55
@Toor No entiendo tu pregunta. Todos los proyectos en los que trabajo producen un tarball que es distinto del pago de VCS. Mantener las dos ayudas distintas con una distribución confiable.
William Pursell
13
Es cierto que muchos proyectos piden a las personas que usen el VCS para obtener la última versión, pero eso solo es apropiado para los desarrolladores. Desafortunadamente, muchos usuarios no entienden la distinción entre el lanzamiento de tarball y el VCS. Intentar construir desde el VCS impone más dependencias. El usuario puede necesitar asciidoco help2mano doxygen, lo que es más importante, la combinación correcta de herramientas automáticas. Este ha sido un gran problema de marketing para las herramientas automáticas. Los usuarios piensan erróneamente que necesitan instalar autoconf porque no entienden la diferencia entre el tarball y el VCS.
William Pursell
3
¿Por qué un proyecto no puede distribuir la salida de Cmake, los archivos de proyecto y los Makefiles para plataformas comunes, por ejemplo, Win, Linux y MacOSX? Parece la misma situación que con las herramientas lex / yacc, incluye el código C genarado para que pueda construirse en plataformas sin las herramientas
Rob11311
3
Si bien creo que los puntos mencionados en esta discusión son correctos, creo que esta discusión está perdiendo el punto. El usuario necesita instalar un montón de otras cosas y si necesita o no instalar cmake no debería ser un gran problema. Me preocuparía más por las bibliotecas, la cadena de herramientas del compilador y otras herramientas necesarias para construir el software.
lanoxx
24
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.
+1, y el mundo sería un lugar mejor si esto fuera cierto. Lamentablemente, a ./configure CFLAGS=-O0menudo falla con los paquetes que sobrescriben CFLAGS en el archivo MAKE y requieren en su lugar que el usuario se ejecute ./configure --enable-debug. (por ejemplo tmux)
William Pursell
2
No es más confuso que Autotools y, como señala acertadamente William, se lleva al infierno con un CFLAGS = "<foo>" incorrectamente enmarcado en el archivo MAKE. Simplemente, este es otro de esos artículos de "sierra antigua". Y los ejemplos de CMake son falsos ... otra vez ... Puede hacer el primero si no está especificando RELEASE o DEBUG. FALLAR.
Svartalf
17
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.
Los estándares GNU se pueden deshabilitar en Automake con AUTOMAKE_OPTIONS = -foreignsu Makefile.am. (O -foreignen tu autogen.sh. Creo que casi todos usan esto.)
Dietrich Epp
9
Sí, pero eso solo controla si Automake aplica reglas GNU superficiales como si se requiere un archivo README. No cambia la premisa básica de construir un tarball de estilo GNU con reglas como installchecky distclean. Si intentas cambiar ese tipo de comportamiento mientras sigues usando Autotools, entonces estás perdiendo el tiempo.
ptomato
1
Ellos (en teoría) permiten que todos los paquetes de software se construyan e instalen exactamente de la misma manera.
ptomato
Ellos, en teoría, le permiten tratar con compiladores ROTOS y SOs más apropiadamente que con otras herramientas y aplicar reglas superficiales como @ptomato resaltadas allí. Si está utilizando una herramienta moderna (por ejemplo, GCC o clang ... en un sistema operativo moderno sin nada realmente tonto, por ejemplo, Linux o BSD actual *, no NECESITA las "reglas" allí. En realidad, hacen mucho, mucho más trabajo para usted y no pueden ayudar, sinceramente para la compilación cruzada. Casi la mitad de todos los usos en estos días son para Linux embebido y * BSD. ¿POR QUÉ vas con cosas que no pueden ayudarte allí?
Svartalf
¿No está seguro de por qué rechazó la respuesta, ya que parece reconocerla en su comentario ...?
ptomato
9
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.
No creo que los problemas con Autotools sean "fáciles de solucionar" en comparación con CMake ...
sleske
77
Porque autotools es un sistema complejo (como CMake). Si cree que las herramientas automáticas se "arreglan fácilmente" (puede haber razones para pensar esto), sería bueno en mi humilde opinión explicar en la respuesta de qué manera los problemas son más fáciles de solucionar.
sleske
55
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. ¿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
surgió el
2
Sí, eso tiene sentido, gracias. Me tomé la libertad de agregarlo a tu respuesta. Siéntase libre de revertir :-).
sleske
1
Siempre puede usar su propia versión local de cmake; no hay razón para usar lo que está instalado a nivel del sistema. Para cualquiera que haga trabajo multiplataforma, eso es completamente normal; Ciertamente es la forma en que uso cmake la mayor parte del tiempo.
Respuestas:
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:
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 ...
Los ejemplos dados para CMake en este hilo son un poco falsos.
Sin embargo...
En verdad, tus objetivos deberían dictar lo que eliges aquí.
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.
fuente
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.
fuente
asciidocohelp2manodoxygen, lo que es más importante, la combinación correcta de herramientas automáticas. Este ha sido un gran problema de marketing para las herramientas automáticas. Los usuarios piensan erróneamente que necesitan instalar autoconf porque no entienden la diferencia entre el tarball y el VCS.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.fuente
./configure CFLAGS=-O0menudo falla con los paquetes que sobrescriben CFLAGS en el archivo MAKE y requieren en su lugar que el usuario se ejecute./configure --enable-debug. (por ejemplotmux)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.
fuente
AUTOMAKE_OPTIONS = -foreignsuMakefile.am. (O-foreignen tuautogen.sh. Creo que casi todos usan esto.)installcheckydistclean. Si intentas cambiar ese tipo de comportamiento mientras sigues usando Autotools, entonces estás perdiendo el tiempo.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.
fuente