Autoconf y Automake se propusieron para resolver un problema evolutivo de Unix.
A medida que Unix evolucionó en diferentes direcciones, los desarrolladores que querían código portátil tendían a escribir código como este:
#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif
A medida que Unix se bifurcaba en diferentes implementaciones (BSD, SystemV, muchos tenedores de proveedores y más tarde Linux y otros sistemas similares a Unix), se volvió importante para los desarrolladores que querían escribir código portátil para escribir código que no dependía de una marca particular de sistema operativo , pero en características expuestas por el sistema operativo. Esto es importante porque una versión de Unix introduciría una nueva característica, por ejemplo, la llamada al sistema "enviar", y luego otros sistemas operativos la adoptarían. En lugar de tener un espagueti de código que buscaba marcas y versiones, los desarrolladores comenzaron a probar las características, por lo que el código se convirtió en:
#if HAVE_SEND
Use Send here
#else
Use something else
#endif
La mayoría de los archivos README para compilar el código fuente en los 90 apuntaron a los desarrolladores para editar un archivo config.h y comentar que las características adecuadas están disponibles en el sistema, o enviarían archivos config.h estándar para cada configuración del sistema operativo que se haya probado.
Este proceso fue engorroso y propenso a errores, y así es como surgió Autoconf. Debería pensar en Autoconf como un lenguaje compuesto por comandos de shell con macros especiales que pudieron reemplazar el proceso de edición humana de config.h con una herramienta que probó la funcionalidad del sistema operativo.
Por lo general, escribiría su código de prueba en el archivo configure.ac y luego ejecutaría el comando autoconf que compilaría este archivo en el comando de configuración ejecutable que ha visto utilizado.
Entonces, cuando ejecuta ./configure && make
, estaba investigando las características disponibles en su sistema y luego construía el ejecutable con la configuración que se detectó.
Cuando los proyectos de código abierto comenzaron a usar sistemas de control de código fuente, tenía sentido registrar el archivo configure.ac, pero no el resultado de la compilación (configure). Autogen.sh es simplemente un pequeño script que invoca el compilador autoconf con los argumentos de comando correctos para usted.
-
Automake también surgió de las prácticas existentes en la comunidad. El proyecto GNU estandarizó un conjunto regular de objetivos para Makefiles:
make all
construiría el proyecto
make clean
eliminaría todos los archivos compilados del proyecto
make install
instalaría el software
- cosas como
make dist
y make distcheck
prepararía la fuente para su distribución y verificaría que el resultado fuera un paquete completo de código fuente
- y así...
La construcción de makefiles compatibles se volvió engorrosa porque había muchas repeticiones repetidas una y otra vez. Por lo tanto, Automake era un nuevo compilador que se integraba con autoconf y procesaba Makefile "fuente" (llamado Makefile.am) en Makefiles que luego se podían alimentar a Autoconf.
La cadena de herramientas automake / autoconf en realidad usa una serie de otras herramientas auxiliares y se complementan con otros componentes para otras tareas específicas. A medida que creció la complejidad de ejecutar estos comandos en orden, nació la necesidad de un script listo para ejecutar, y de aquí surgió autogen.sh.
Hasta donde yo sé, Gnome fue un proyecto que introdujo el uso de este script de ayuda autogen.sh