¿Por qué usar herramientas de compilación como Autotools cuando solo podemos escribir nuestros propios makefiles?

En primer lugar, las herramientas automáticas no son un sistema de compilación opaco, sino una cadena de herramientas acoplada libremente, como ya señaló tinkertim. Permítanme añadir algunas ideas sobre Autoconf y Automake:

Autoconf es el sistema de configuración que crea el script configure basado en comprobaciones de características que se supone que funcionan en todo tipo de plataformas. Una gran cantidad de conocimiento del sistema ha entrado en su base de datos macro m4 durante los 15 años de su existencia. Por un lado, creo que la esta última es la razón principal por la que Autotools no ha sido reemplazado por otra cosa todavía. Por otro lado, Autoconf solía ser mucho más importante cuando las plataformas de destino fueron más heterogéneos y Linux, AIX, HP-UX, SunOS, ..., y una gran variedad de diferentes arquitecturas de procesador tuvo que ser compatible. Realmente no veo su punto si solo desea admitir distribuciones de Linux recientes y procesadores compatibles con Intel.

Automake es una abstracción capa para GNU Make y actúa como un generador de Makefile a partir de plantillas más simples. Varios proyectos finalmente se deshicieron de la abstracción de Automake y volvieron a escribir Makefiles manualmente porque pierdes el control sobre tus Makefiles y es posible que no necesites todos los destinos de compilación enlatados que ofuscan tu Makefile.

Ahora a las alternativas (y sugiero fuertemente una alternativa a Autotools basada en sus requisitos):

CMake's más notables el logro está reemplazando AutoTools en KDE. Probablemente es lo más cercano que puede obtener si desea tener una funcionalidad similar a Autoconf sin idiosincrasias de m4. Trae soporte de Windows a la mesa y ha demostrado ser aplicable en grandes proyectos. Mi problema con CMake es que sigue siendo un generador de archivos Makefile (al menos en Linux) con todos sus problemas inmanentes (por ejemplo, depuración de archivos Makefile, firmas de marca de tiempo, orden de dependencia implícita).

SCons es un reemplazo escrito en Python. Utiliza scripts de Python como archivos de control de compilación que permiten técnicas muy sofisticadas. Desafortunadamente, su sistema de configuración no está a la par con Autoconf. SCons se utiliza a menudo para el desarrollo interno cuando la adaptación a requisitos específicos es más importante que seguir convenciones.

Si realmente quieres seguir con Autotools, te sugiero leer Recursivo Hacer Considerado Perjudicial y escribe tu propio Makefile de GNU configurado a través de Autoconf.

Las respuestas ya proporcionadas aquí son buenas, pero recomiendo encarecidamente no seguir el consejo de escribir su propio makefile si tiene algo parecido a un proyecto estándar de C/C++. Necesitamos autotools en lugar de makefiles escritos a mano porque un makefile compatible con el estándar generado por automake ofrece muchos objetivos útiles bajo nombres conocidos, y proporcionar todos estos objetivos a mano es tedioso y propenso a errores.

En primer lugar, escribir un Makefile a mano parece una gran idea en primero, pero la mayoría de la gente no se molestará en escribir más que las reglas para todos, instalar y tal vez limpiar. automake genera dist, distcheck, clean, distclean, uninstall y todos estos pequeños ayudantes. Estos objetivos adicionales son una gran bendición para el administrador del sistema que eventualmente instalará su software.

En segundo lugar, proporcionar todos estos objetivos de una manera portátil y flexible es bastante propenso a errores. He hecho una gran cantidad de compilación cruzada a los objetivos de Windows recientemente, y las herramientas automáticas se realizaron gran. 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 posible crear un buen Makefile a mano. Pero no te sobreestimes, se necesita mucha experiencia y conocimiento sobre un montón de sistemas diferentes, y automake crea grandes Makefiles para ti desde el primer momento.

Editar: Y no se sienta tentado a usar las "alternativas". CMake y sus amigos son un horror para el deployer porque no lo son interfaz-compatible para configurar y amigos. Cada administrador de sistema o desarrollador competente a medio camino puede hacer grandes cosas como compilación cruzada o cosas simples como establecer un prefijo de su cabeza o con un simple help help con un script configure. Pero estás condenado a pasar una hora o tres cuando tienes que hacer esas cosas con BJam. No me malinterpreten, BJam es probablemente un gran sistema bajo el capó, pero es un dolor en el culo para usar porque casi no hay proyectos que lo utilizan y muy poco y documentación incompleta. autoconf y automake tienen una gran ventaja aquí en términos de conocimiento establecido.

Por lo tanto, aunque estoy un poco tarde con este consejo para esta pregunta: Hágase un favor y use autotools y automake. La sintaxis puede ser un poco extraña, pero hacen un trabajo mucho mejor que el 99% de los desarrolladores por su cuenta.

Para proyectos pequeños o incluso para proyectos grandes que solo se ejecutan en una plataforma, los makefiles escritos a mano son el camino a seguir.

Donde autotools realmente brilla es cuando está compilando para diferentes plataformas que requieren diferentes opciones. Autotools es con frecuencia el cerebro detrás de la

./ configure

Make

Make install

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

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

Se necesitan herramientas automáticas porque no se garantiza que los Makefiles funcionen igual en diferentes plataformas. Si escribes a mano un Makefile, y funciona en tu máquina, hay una buena probabilidad de que no lo haga en la mía.

¿Sabes qué unix usarán tus usuarios? ¿O incluso qué distribución de Linux? ¿Sabes dónde quieren que se instale el software? ¿Sabes 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 paisaje multiplataforma, y sus herramientas de compilación e instalación deben lidiar con eso.

Tenga en cuenta que las herramientas auto * datan de una época anterior, y hay muchas quejas válidas sobre ellos, pero los varios proyectos para reemplazarlos con alternativas más modernas están teniendo problemas para desarrollar mucho impulso.

Muchas cosas son así en el mundo *nix.

Autotools es un desastre.

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

Correr ./configure toma mucho tiempo. Aunque las CPU de servidor modernas pueden tener incluso docenas de núcleos, y puede haber varias de estas CPU por servidor, ./configure es de un solo subproceso. Todavía nos quedan suficientes años de la ley de Moore que el número de núcleos de CPU subirá en función de tiempo. Por lo tanto, el tiempo ./configure se mantendrá aproximadamente constante, mientras que los tiempos de construcción paralela se reducen en un factor de 2 cada 2 años debido a la ley de Moore. O en realidad, yo diría que el tiempo ./configure toma incluso podría aumentar debido al aumento de la complejidad del software aprovechando el hardware mejorado.

El mero hecho de añadir un solo archivo a tu proyecto requiere que ejecutes automake, autoconf y ./configure que tomará años, y luego probablemente encontrará que ya que algunos archivos importantes tienen cambiado, todo será recompilado. Así que agrega solo un archivo, y make -j${CPUCOUNT} recompila todo.

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

Luego, cuando instale el software que ha sido compilado, encontrará que no funciona. (¿Quieres pruebas? Clonar protobuf repositorio de Github, echa un vistazo commit 9f80df026933901883da1d556b38292e14836612, instalarlo en un sistema Debian o Ubuntu, y hey presto: protoc: error while loading shared libraries: libprotoc.so.15: cannot open shared object file: No such file or directory since ya que está en /usr/local/lib y no en /usr/lib; la solución es hacer export LD_RUN_PATH=/usr/local/lib antes de escribir make).

La teoría es que usando autotools, usted podría crear un paquete de software que pueda ser compilado en Linux, FreeBSD, NetBSD, OpenBSD, DragonFlyBSD y otros sistemas operativos. El hecho? Cada sistema que no sea Linux para construir paquetes desde el código fuente tiene numerosos archivos de parches en su repositorio para evitar errores de autotools. Basta con echar un vistazo a, por ejemplo, FreeBSD /usr/ports: está lleno de parches. Tan, habría sido tan fácil crear un pequeño parche para un sistema de compilación que no sea autotools por proyecto que crear un pequeño parche para un sistema de compilación autotools por proyecto. O tal vez incluso más fácil, ya que el estándar make es mucho más fácil de usar que autotools.

El hecho es que, si crea su propio sistema de compilación basado en el estándar make (y lo hace inclusivo y no recursivo, siguiendo las recomendaciones del documento "Recursive make considered harmful"), las cosas funcionan en un mucho mejor manera. Además, su tiempo de compilación se reduce en un orden de magnitud, tal vez incluso dos órdenes de magnitud si su proyecto es un proyecto muy pequeño de 10-100 archivos de lenguaje C y tiene docenas de núcleos por CPU y varias CPU. También es mucho más fácil interactuar con herramientas personalizadas de generación automática de código con un sistema de compilación personalizado basado en el estándar make en lugar de lidiar con el desorden m4 de autotools. Con standard make, puede al menos escribir un comando de shell en el Makefile.

Entonces, para responder a su pregunta: ¿por qué usar autotools? Respuesta: no hay razón para hacerlo. Autotools ha estado obsoleto desde que Unix comercial se ha vuelto obsoleto. Y el advenimiento de CPU multinúcleo ha hecho que autotools sea aún más obsoleto. Por qué los programadores no se han dado cuenta de eso todavía, es un misterio. Con mucho gusto usaré standard 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 del lenguaje C, pero la cantidad de el trabajo se guarda al no tener que luchar con autotools.

No siento que soy un experto para responder a esto, pero aún así te doy una pequeña analogía con mi experiencia.

Porque hasta cierto punto es similar a por qué deberíamos escribir Códigos Incrustados en lenguaje C(Lenguaje de Alto Nivel) en lugar de escribir en Lenguaje Ensamblador. Ambos resuelven el mismo propósito, pero este último es más largo, tedioso, consume mucho tiempo y es más propenso a errores(a menos que conozca ISA del procesador muy bien) . Lo mismo ocurre con la herramienta Automake y escribiendo su propio makefile. Escritura Makefile.am y configure.ac es bastante simple que escribir Makefile de proyecto individual.