¿Por qué utilizar herramientas de compilación como Autotools cuando podemos escribir nuestros propios archivos MAKE?

Question

Recientemente, cambié mi entorno de desarrollo de Windows a Linux.Hasta ahora, solo he usado Visual Studio para el desarrollo de C++, por lo que muchos conceptos, como hacer y Autoherramientas, son nuevos para mí.Leí la documentación del archivo MAKE de GNU y casi tengo una idea al respecto.Pero estoy un poco confundido acerca de Autotools.

Hasta donde yo sé, los archivos MAKE se utilizan para facilitar el proceso de compilación.

1. ¿Por qué necesitamos herramientas como Autoherramientas ¿Solo para crear los archivos MAKE?Como todos saben cómo crear un archivo MAKE, no obtengo el uso real de Autotools.
2. ¿Cuál es el estándar?¿Necesitamos utilizar herramientas como esta o bastaría con archivos MAKE escritos a mano?

Answer 1

Usted está hablando de dos cosas distintas pero entrelazadas aquí:

• Autotools
• GNU normas de codificación

Dentro Autotools, tiene varios proyectos:

• Autoconf
• Automake
• Libtool

Veamos cada uno de ellos individualmente.

Autoconf

Autoconf escanea fácilmente un árbol existente para encontrar sus dependencias y crear un script de configuración que se ejecutará bajo casi cualquier tipo de concha. El script de configuración permite al usuario controlar el comportamiento de compilación (es decir --with-foo, --without-foo, --prefix, --sysconfdir, etc ..), así como hacer comprobaciones para asegurar que el sistema puede compilar el programa.

Configurar genera un archivo config.h (de una plantilla), que pueden incluir programas para evitar problemas de portabilidad. Por ejemplo, si no se define HAVE_LIBPTHREAD, utilizar horquillas en su lugar.

Yo personalmente uso Autoconf en muchos proyectos. Por lo general toma la gente un poco de tiempo para acostumbrarse a m4 . Sin embargo, lo hace ahorrar tiempo.

Puede tener archivos make heredan algunos de los valores que configure encuentra sin utilizar automake.

Automake

Al proporcionar una plantilla corta que describe lo que los programas se construirán y qué objetos deben estar vinculados a construirlos, Makefiles que se adhieren a los estándares de codificación de GNU pueden ser creados de forma automática. Esto incluye el manejo dependencia y todos los objetivos requeridos GNU.

Algunas personas encuentran más fácil. Yo prefiero escribir mis propios archivos make.

Libtool

Libtool es una herramienta muy fresco para simplificar la construcción e instalación de bibliotecas compartidas en cualquier sistema Unix. A veces lo uso; otras veces (especialmente cuando sólo la construcción de objetos de vínculos estáticos) Lo hago con la mano.

Hay otras opciones también, véase la pregunta StackOverflow Alternativas a autoconf y Autotools? .

Construir estándares de automatización y GNU codificación

En resumen, que realmente debería utilizar algunos tipo de sistema de configuración de generación portátil Si se quita el código para las masas. Lo que se utiliza depende de usted. software de GNU es conocido para generar y ejecutar en casi cualquier cosa. Sin embargo, es posible que no tenga que cumplir con tales (y, a veces extremadamente pedante) estándares.

En todo caso, le recomiendo dar Autoconf un intento si usted está escribiendo software para sistemas POSIX. El hecho de que Autotools producen parte de un entorno de desarrollo que sea compatible con las normas de GNU no significa que tenga que seguir esas normas (muchos no lo hacen!) :) Hay un montón de otras opciones, también.

Editar

No temas m4 :) Siempre existe la Autoconf macro archivo . Un montón de ejemplos, o caída de cheques. Escriba su propio uso o lo que está probado. Autoconf es demasiado a menudo confundido con Automake . Son dos cosas separadas.

Answer 2

En primer lugar, los Autotools no son un sistema de construcción opaco pero a-cadena de herramientas débilmente acoplado, como tinkertim ya se ha señalado. Quisiera añadir algunas reflexiones sobre autoconf y automake:

Autoconf es el sistema de configuración que crea el script de configuración a partir de controles de características que se suponen para trabajar en todo tipo de plataformas. Una gran cantidad de datos sobre el sistema ha entrado en su m4 base de datos macro durante los 15 años de su existencia. Por un lado, creo que éste es el principal motivo Autotools no han sido sustituidos por algo más todavía. Por otro lado, Autoconf solía ser mucho más importante cuando las plataformas de destino eran más heterogéneas y Linux, AIX , HP-UX , SunOS , ..., y una gran variedad de arquitectura de procesador diferente tuvo que ser apoyado. Realmente no veo su punto si sólo desea apoyar las distribuciones recientes de Linux y los procesadores compatibles con Intel.

Automake es una capa de abstracción para GNU Make y actúa como un generador Makefile a partir de plantillas más simples. Una serie de proyectos, finalmente se deshizo de la abstracción Automake y volvió a escribir Makefiles manualmente porque se pierde el control sobre los archivos MAKE y puede que no necesite todos los tipos de generación enlatados que ofuscar su Makefile.

Ahora a los alternativas, (y yo recomiendo una alternativa a Autotools en función de sus necesidades):

CMake logro más notable 's está reemplazando Auto Herramientas en KDE . Es probablemente el más cercano que puede obtener si usted quiere tener una funcionalidad similar a Autoconf sin idiosincrasias m4. Trae soporte para Windows a la mesa y ha demostrado ser aplicable en grandes proyectos. Mi carne con CMake es que todavía es un Makefile-generador (al menos en Linux) con todos sus problemas inmanentes (por ejemplo Makefile depuración, las firmas de marca de tiempo, el orden de dependencia implícita).

SCons es un reemplazo de realizar escritos en Python. Se utiliza scripts de Python como archivos de control que permiten la acumulación técnicas muy sofisticadas. Desafortunadamente, su sistema de configuración no está a la par con Autoconf. SCons a menudo se utiliza para el desarrollo de la casa cuando la adaptación a las necesidades específicas es más importante que seguir las convenciones.

Si realmente quiere quedarse con Autotools, sugiero que lea Hacer recursiva consideran perjudiciales y escribir su propio Makefile de GNU configura a través de Autoconf.

Answer 3

Las respuestas ya proporcionadas aquí son buenos, pero lo recomiendo encarecidamente no tomar el consejo de escribir su propio makefile si tiene algo parecido a un proyecto estándar C C / ++. Necesitamos las autotools en lugar de archivos make escritas a mano porque un archivo MAKE compatible con el estándar generada por automake ofrece una gran cantidad de objetivos útiles bajo nombres bien conocidos, y la disponibilidad de todos estos objetivos a mano es tedioso y propenso a errores.

En primer lugar, escribir un Makefile a mano parece una gran idea al principio, pero la mayoría de la gente no se molestará en escribir más de las reglas para todo, instalar y tal vez limpio. automake genera dist, distcheck, limpio, distclean, desinstale y todos estos pequeños ayudantes. Estos objetivos adicionales son una gran ayuda para el administrador de sistemas que eventualmente instalar el software.

En segundo lugar, proporcionar todos estos objetivos de una manera portátil y flexible es muy propenso a errores. He hecho un montón de compilación cruzada para objetivos Windows recientemente, y las autotools realicé simplemente genial. En contraste con la mayoría de los archivos escritos a mano, que eran en su mayoría un dolor en el culo para compilar. Eso sí, es es posible crear un buen Makefile a mano. Pero no sobrestimar a sí mismo, se necesita una gran cantidad de experiencia y conocimiento acerca de un montón de diferentes sistemas, y automake crea grandes Makefile para que sacarlo de la caja.

Edit: Y no tener la tentación de utilizar las "alternativas" . CMake y los amigos son un horror al desplegador porque no son compatibles interfaz para configurar y amigos. Cada administrador de sistemas competente a mitad de camino o desarrollador puede hacer grandes cosas como la compilación cruzada o cosas sencillas, como configurar un prefijo de la cabeza o con un simple --help con un script de configuración. Sin embargo, estás condenado a pasar una hora o tres cuando se tiene que hacer este tipo de cosas con bjam. No me malinterpreten, bjam es probablemente un gran sistema bajo el capó, pero es un dolor en el culo de usar, ya casi no hay proyectos de usarlo y muy poco e incompleta la documentación. autoconf y automake tienen una enorme ventaja aquí en términos de conocimiento establecido.

Así que, a pesar de que yo soy un poco tarde con este consejo para esta pregunta: Hágase un favor y utilizar las autotools y automake. La sintaxis podría ser un poco extraño, pero lo hacen de una manera mejor trabajo del 99% de los desarrolladores hacer por su cuenta.

Answer 4

Para proyectos pequeños o incluso para grandes proyectos que sólo se ejecutan en una plataforma, archivos make escritas a mano son el camino a seguir.

Cuando autotools realmente brillan es cuando se está compilando para diferentes plataformas que requieren diferentes opciones. Autotools es frecuentemente el cerebro detrás de la típica

./ configure

make

make install

compilación e instalación de pasos para bibliotecas y aplicaciones de Linux.

Dicho esto, me parece autotools a ser un dolor y he estado buscando un sistema mejor. Últimamente he estado usando bjam, pero que también tiene sus inconvenientes. Buena suerte para encontrar lo que funciona para usted.

Answer 5

Se necesitan Autotools porque Makefile no están garantizados para funcionar de la misma a través de diferentes plataformas. Si escribir a mano un Makefile, y funciona en su máquina, hay una buena probabilidad de que no lo hará en la mía.

Answer 6

¿Sabes qué Unix usarán tus usuarios?¿O incluso qué distribución de Linux?¿Sabes dónde quieren que se instale el software?¿Sabe qué herramientas tienen, en qué arquitectura quieren compilar, cuántas CPU tienen, cuánta RAM y disco podrían estar disponibles para ellos?

El mundo *nix es un panorama multiplataforma y sus herramientas de construcción e instalación deben lidiar con eso.

---

Eso sí, las herramientas automáticas* datan de una época anterior y hay muchas quejas válidas sobre ellas, pero los diversos proyectos para reemplazarlas con alternativas más modernas están teniendo problemas para desarrollar mucho impulso.

Muchas cosas son así en el mundo *nix.

Answer 7

Autotools es un desastre.

el generado ./configure El script busca características que no han estado presentes en ningún sistema Unix durante los últimos 20 años aproximadamente.Se dedica una gran cantidad de tiempo a esto.

Correr ./configure lleva años.Aunque las CPU de servidor modernas pueden tener incluso docenas de núcleos y puede haber varias CPU de este tipo por servidor, la ./configure es de un solo hilo.Todavía nos quedan suficientes años de la ley de Moore para que la cantidad de núcleos de CPU aumente considerablemente en función del tiempo.Entonces, el tiempo ./configure Los tiempos de construcción se mantendrán aproximadamente constantes, mientras que los tiempos de construcción en paralelo se reducirán en un factor de 2 cada 2 años debido a la ley de Moore.O mejor dicho, diría que la hora ./configure Las tomas podrían incluso aumentar debido a la creciente complejidad del software que aprovecha el hardware mejorado.

El mero hecho de agregar solo un archivo a su proyecto requiere que ejecute automake, autoconf y ./configure lo cual llevará mucho tiempo, y luego probablemente descubrirá que, dado que algunos archivos importantes han cambiado, todo se volverá a compilar.Así que agregue solo un archivo y make -j${CPUCOUNT} vuelve a compilar todo.

y sobre make -j${CPUCOUNT}.El sistema de compilación generado es recursivo. La creación recursiva se ha considerado perjudicial durante mucho tiempo.

Luego, cuando instales el software que ha sido compilado, encontrarás que no funciona.(¿Quieres pruebas?Clon protobuf repositorio de Github, consulte el compromiso 9f80df026933901883da1d556b38292e14836612, instálalo en un sistema Debian o Ubuntu y listo: protoc: error while loading shared libraries: libprotoc.so.15: cannot open shared object file: No such file or directory -- ya que está en /usr/local/lib y no /usr/lib;la solución es hacer export LD_RUN_PATH=/usr/local/lib antes de escribir make).

La teoría es que al utilizar herramientas automáticas, se podría crear un paquete de software que se pueda compilar en Linux, FreeBSD, NetBSD, OpenBSD, DragonflyBSD y otros sistemas operativos.¿El hecho?Cada sistema que no es Linux para crear paquetes desde el código fuente tiene numerosos archivos de parche en su repositorio para solucionar errores de autotools.Basta con echar un vistazo, por ejemplo.FreeBSD /usr/ports:está lleno de parches.Por lo tanto, habría sido tan fácil crear un pequeño parche para un sistema de compilación que no sea de Autotools por proyecto que crear un pequeño parche para un sistema de compilación de Autotools por proyecto.O quizás incluso más fácil, de serie make Es mucho más fácil de usar que las herramientas automáticas.

El hecho es que si crea su propio sistema de compilación basado en estándares make (y hacerlo inclusivo y no recursivo, siguiendo las recomendaciones del documento "Lo recursivo se considera dañino"), las cosas funcionan mucho mejor.Además, su tiempo de construcción se reduce en un orden de magnitud, tal vez incluso dos órdenes de magnitud si su proyecto es muy pequeño de 10 a 100 archivos en lenguaje C y tiene docenas de núcleos por CPU y múltiples CPU.También es mucho más fácil interconectar herramientas de generación automática de código personalizadas con un sistema de compilación personalizado basado en estándar. make en lugar de tratar con el m4 lío de herramientas automáticas.Con estándar make, al menos puedes escribir un comando de shell en el Makefile.

Entonces, para responder a tu pregunta:¿Por qué utilizar herramientas automáticas?Respuesta:no hay ninguna razón para hacerlo.Autotools ha quedado obsoleto desde que Unix comercial quedó obsoleto.Y la llegada de las CPU multinúcleo ha hecho que las herramientas automáticas sean aún más obsoletas.Por qué los programadores aún no se han dado cuenta de esto es un misterio.Felizmente usaré estándar make en mis sistemas de compilación, gracias.Sí, se necesita cierta cantidad de trabajo para generar los archivos de dependencia para la inclusión del encabezado en lenguaje C, pero la cantidad de trabajo se ahorra al no tener que luchar con las herramientas automáticas.

Answer 8

No me siento que soy un experto para responder a esto, pero todavía le dan una analogía poco con mi experiencia.

Debido a que hasta cierto punto es similar a la razón por la que debemos escribir códigos incrustados en lenguaje C (lenguaje de alto nivel) en lugar de escribir en lenguaje ensamblador. Tanto resuelve el mismo propósito, pero este último es más lenghty, tedioso, lento y propenso a errores más (a menos que sepa ISA del procesador muy bien). Igual es el caso con la herramienta de Automake y escribir su propio makefile. Escribiendo Makefile.am y configure.ac es bastante simple que escribir Makefile proyecto individual.