GNU Autotools , también conocido como GNU Build System , es un conjunto de herramientas de programación diseñadas para ayudar a que los paquetes de código fuente sean portables a muchos sistemas tipo Unix .
Puede resultar difícil hacer que un programa de software sea portable: el compilador de C difiere de un sistema a otro; en algunos sistemas faltan ciertas funciones de biblioteca; los archivos de encabezado pueden tener nombres diferentes; las bibliotecas compartidas pueden compilarse e instalarse de diferentes maneras. Una forma de manejar las diferencias entre plataformas es escribir código condicional, con bloques de código seleccionados por medio de directivas de preprocesador ( #ifdef); pero debido a la amplia variedad de entornos de compilación, este enfoque rápidamente se vuelve inmanejable. Autotools está diseñado para abordar este problema de manera más manejable.
Autotools es parte de la cadena de herramientas GNU y se usa ampliamente en muchos paquetes de software libre y de código abierto . Las herramientas que lo componen son software libre , licenciado bajo la Licencia Pública General GNU con excepciones de licencia especiales [1] [2] que permiten su uso con software propietario .
El sistema de compilación GNU permite compilar muchos programas mediante un proceso de dos pasos: configure seguido de make . [3]
Autotools consta de las utilidades GNU Autoconf , Automake y Libtool . [4] Otras herramientas relacionadas que se utilizan frecuentemente junto con él incluyen GNU make , GNU gettext , pkg-config y GNU Compiler Collection (GCC).
Autoconf genera un configurescript basado en el contenido de un configure.acarchivo, que caracteriza un cuerpo particular de código fuente. El configurescript, cuando se ejecuta, escanea el entorno de compilación y genera un config.statusscript subordinado que, a su vez, convierte otros archivos de entrada y, más comúnmente, Makefile.inarchivos de salida ( Makefile), que son apropiados para ese entorno de compilación. Finalmente, el makeprograma utiliza Makefilepara generar programas ejecutables a partir del código fuente.
La complejidad de Autotools refleja la variedad de circunstancias bajo las cuales se puede construir un cuerpo de código fuente.
make, que solo vuelve a compilar la parte del cuerpo del código fuente afectada por el cambio..inarchivo ha cambiado entonces basta con volver a config.statusejecutarlo make.configure(que ejecuta config.status) y make. (Por este motivo, el código fuente que utiliza Autotools normalmente se distribuye sin los archivos que configuregenera).configure.aclos archivos y seguir todos los pasos subsiguientes..inPara procesar archivos, autoconf utiliza la implementación GNU del sistema de macros m4 .
Autoconf viene con varios programas auxiliares como autoheader, que se utiliza para ayudar a administrar los archivos de encabezado de C ; , que puede crear un archivo de entrada inicial para Autoconf; y , que puede enumerar los identificadores de preprocesador de C utilizados en el programa.autoscanifnames
Automake ayuda a crear Makefilearchivos portables, que a su vez se procesan con la utilidad make . Toma su entrada como Makefile.amy la convierte en Makefile.in, que es utilizada por el script configure para generar la Makefilesalida del archivo. También realiza un seguimiento automático de dependencias; cada vez que se compila un archivo fuente, se registra la lista de dependencias (por ejemplo, archivos de encabezado C). Más tarde, cada vez que se ejecuta make y parece que una dependencia ha cambiado, se reconstruirán los archivos dependientes.
Libtool ayuda a gestionar la creación de bibliotecas estáticas y dinámicas en varios sistemas operativos tipo Unix . Libtool logra esto abstrayendo el proceso de creación de bibliotecas, ocultando las diferencias entre los distintos sistemas (por ejemplo, sistemas Linux vs. Solaris ).
Autotools ayuda a los desarrolladores de software a escribir software multiplataforma y ponerlo a disposición de una comunidad de usuarios mucho más amplia, incluso en su forma de código fuente para aquellos usuarios que deseen crear el software ellos mismos. En la mayoría de los casos, los usuarios simplemente ejecutan el configurescript proporcionado (que no tiene dependencias más allá de la presencia de un shell compatible con Bourne ) y luego un programa. [5] No necesitan tener las propias herramientas Autotools instaladas en la computadora.make
Se puede utilizar tanto para crear programas nativos en la máquina de compilación como también para la compilación cruzada con otras arquitecturas. [6]
También es posible compilar software de forma cruzada para ejecutarlo en un host Windows desde un sistema Linux u otro sistema de compilación similar a Unix, utilizando MinGW, sin embargo, la compilación nativa suele ser deseable en sistemas operativos (como la familia de sistemas Microsoft Windows ) que no pueden ejecutar scripts de Bourne Shell por sí solos. Esto hace que la compilación de dicho software en el sistema operativo Windows sea un poco más difícil que en un sistema similar a Unix que proporciona el Bourne Shell como un componente estándar. Sin embargo, se puede instalar el sistema Cygwin o MSYS sobre Windows para proporcionar una capa de compatibilidad similar a Unix , lo que permite ejecutar scripts de configuración . Cygwin también proporciona GNU Compiler Collection , GNU make y otro software que proporciona un sistema similar a Unix casi completo dentro de Windows; MSYS también proporciona GNU make y otras herramientas diseñadas para funcionar con la versión MinGW de GCC.
Aunque se espera que el desarrollador proporcione un script de configuración para el usuario final, en ocasiones el usuario puede desear volver a generar el script de configuración. Tal trabajo puede ser necesario si el usuario desea modificar el código fuente. Dichos usuarios deben tener instalado Autotools y utilizar componentes como su autoreconf .
El autoconf-generated configurepuede ser lento porque ejecuta programas como un compilador de C muchas veces para probar si están presentes varias bibliotecas, archivos de encabezado y características del lenguaje. Esto afecta particularmente a Cygwin , que, debido a su falta de una llamada al sistema fork nativa , puede ejecutar scripts de configuración considerablemente más lento que Linux . [7]
En su columna para ACM Queue , el desarrollador de FreeBSD Poul-Henning Kamp criticó el sistema de compilación GNU: [8]
La idea es que el script de configuración realice aproximadamente 200 pruebas automatizadas, de modo que el usuario no tenga que configurar libtool manualmente. Esta es una idea terriblemente mala, que ya fue muy criticada en los años 80 cuando apareció, ya que permite que el código fuente pretenda ser portable detrás de la apariencia del script de configuración, en lugar de tener realmente la cualidad de la portabilidad para empezar. Es una farsa que la idea de configurar haya sobrevivido.
Kamp esboza la historia del sistema de compilación en los problemas de portabilidad inherentes a la multitud de variantes de Unix de la década de 1980 , y lamenta la necesidad de que existan tales sistemas de compilación:
Las 31.085 líneas de configuración para libtool todavía comprueban si <sys/stat.h> y <stdlib.h> existen, aunque Unixen, que carecía de ellos, no tenía memoria suficiente para ejecutar libtool ni discos lo suficientemente grandes para su código fuente de 16 MB.
Aunque los críticos de Autotools con frecuencia abogan por alternativas que proporcionen una mayor simplicidad a sus usuarios, algunos han argumentado que esto no es necesariamente algo bueno. John Calcote, autor [9] de Autotools, 2nd Edition: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool , opinó: [10]
Las herramientas automáticas son, en realidad, más transparentes que cualquier otra herramienta de compilación existente. Todas estas otras herramientas (cmake, maven, etc.) que pretenden ser mucho más simples porque aíslan al usuario de los detalles subyacentes del proceso de compilación, tienen como principal defecto que este mismo aislamiento impide que los usuarios puedan realizar los cambios que necesitan para lograr sus objetivos de compilación específicos del proyecto.
Cualquiera que no tenga nada más que cosas buenas que decir sobre este aspecto de cmake, maven, gradle o lo que sea, simplemente no ha trabajado en un proyecto que requiera que se alejen lo suficiente de los valores predeterminados. Los he usado todos y he pasado horas frustrado tratando de determinar cómo solucionar las deficiencias de alguna función de herramienta que "hace todo" (excepto lo que yo quiero). Esto simplemente no es un problema con las herramientas automáticas. Como alguien mencionó anteriormente en este hilo, puede colocar un script de shell en un archivo configure.ac y un script de make en un archivo Makefile.am. Esa es la definición misma de transparencia. Ninguna otra herramienta existente permite este nivel de flexibilidad.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}