GNU Autotools , también conocido como GNU Build System , es un conjunto de herramientas de automatización de compilación diseñado para facilitar la compilación de código fuente y el empaquetado de los binarios resultantes. Permite compilar código fuente para múltiples sistemas de destino sin necesidad de personalizarlo ni modificarlo . Está disponible en numerosas distribuciones de Linux y entornos tipo Unix .
Autotools forma parte del conjunto de herramientas GNU y se utiliza ampliamente en muchos paquetes de software libre y de código abierto . Sus herramientas componentes son software libre , licenciado bajo la Licencia Pública General GNU con excepciones especiales de licencia [ 1 ] [ 2 ] que permiten su uso con software propietario .
Motivación
Lograr la portabilidad de un programa de software puede ser complicado. Los compiladores varían de un sistema a otro. Algunas funciones de las bibliotecas no están disponibles en ciertos sistemas. Los archivos del compilador (como los encabezados de C) pueden tener nombres diferentes. Las bibliotecas compartidas pueden compilarse e instalarse de distintas maneras. Una forma de gestionar las diferencias entre plataformas es escribir código compilado condicionalmente (por ejemplo, mediante #ifdef), pero debido a la gran variedad de entornos de compilación, este enfoque se vuelve rápidamente inmanejable. Autotools está diseñado para abordar este problema de forma más eficiente.
Componentes
Autotools consta de las utilidades GNU Autoconf , Automake y Libtool . [ 3 ] Otras herramientas relacionadas incluyen GNU make , GNU gettext , pkg-config y la Colección de Compiladores GNU (GCC).
Uso

Autotools ayuda a compartir software multiplataforma con una comunidad de usuarios relativamente amplia. Facilita el intercambio del código fuente al proporcionar un soporte de compilación multiplataforma relativamente robusto para que los consumidores puedan compilar el software ellos mismos. Generalmente, el código fuente se distribuye con un script , llamado configure , que no tiene dependencias más allá de un intérprete de comandos compatible con Bourne . No es necesario que Autotools esté disponible. El consumidor ejecuta que genera varios archivos, incluido un Makefile que el consumidor utiliza ejecutando . [ 4 ] [ 5 ]configuremake
Autotools se puede utilizar tanto para compilar programas nativos en la máquina de compilación como para realizar compilación cruzada a otras arquitecturas. [ 6 ]
También es posible compilar software de forma cruzada para ejecutarlo en un host Windows desde un sistema de compilación Linux u otro similar a Unix, utilizando MinGW; sin embargo, la compilación nativa suele ser preferible en sistemas operativos (como la familia de sistemas Microsoft Windows ) que no pueden ejecutar scripts de Bourne shell por sí solos. Esto hace que compilar dicho software en el sistema operativo Windows sea un poco más difícil que en un sistema similar a Unix que proporciona Bourne shell como componente estándar. 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 la Colección de Compiladores GNU , 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.
El usuario puede regenerar el script de configuración, lo cual podría ser necesario si modifica el código fuente. En ese caso, necesita tener Autotools instalado.
El script de configuración generado por autoconf puede ser lento porque ejecuta programas como un compilador de C varias veces para comprobar si están presentes diversas bibliotecas, archivos de cabecera y características del lenguaje. Esto afecta particularmente a Cygwin , que, debido a la falta de una llamada al sistema fork nativa , puede ejecutar los scripts de configuración considerablemente más lento que en Linux . [ 7 ]
Crítica
En su columna para ACM Queue , el desarrollador de FreeBSD Poul-Henning Kamp criticó el sistema de compilación de GNU: [ 8 ]
La idea es que el script de configuración realice aproximadamente 200 pruebas automatizadas, para que el usuario no tenga que configurar libtool manualmente. Esta es una idea pésima, ya muy criticada en la década de 1980, cuando surgió, ya que permite que el código fuente finja ser portable bajo la apariencia del script de configuración, en lugar de tener realmente portabilidad desde el principio. Es una vergüenza que la idea de la configuración 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 de libtool siguen comprobando si existen <sys/stat.h> y <stdlib.h> , a pesar de que el sistema Unix, que carecía de ellos, no tenía ni memoria suficiente para ejecutar libtool ni discos lo suficientemente grandes para su código fuente de 16 MB.
Aunque los críticos de Autotools frecuentemente abogan por alternativas que brindan mayor simplicidad a sus usuarios, algunos han argumentado que esto no es necesariamente algo bueno. John Calcote, autor [ 9 ] de Autotools, 2.ª edición: Guía práctica de GNU Autoconf, Automake y Libtool , opinó: [ 10 ]
Las herramientas de Autotools son, de hecho, más transparentes que cualquier otra herramienta de compilación disponible. Todas esas otras herramientas ( CMake , Maven , etc.), que pretenden ser mucho más sencillas porque aíslan al usuario de los detalles subyacentes del proceso de compilación, tienen como principal fallo que este aislamiento les impide realizar los cambios necesarios para alcanzar los objetivos de compilación específicos de su proyecto.
Quien solo tenga cosas buenas que decir sobre este aspecto de cmake, maven, gradle o lo que sea, simplemente no ha trabajado en un proyecto que requiera alejarse lo suficiente de la configuración predeterminada. Los he usado todos y he pasado horas frustrado tratando de encontrar la manera de sortear las limitaciones de alguna función de herramienta que lo hace todo (excepto lo que necesito). Esto simplemente no es un problema con Autotools. Como alguien mencionó anteriormente en este hilo, puedes insertar un script de shell en un archivo configure.ac y un script make en un archivo Makefile.am. Esa es la definición misma de transparencia. Ninguna otra herramienta existente ofrece este nivel de flexibilidad.
Véase también
Referencias
- ↑ "Savannah Git Hosting - autoconf.git/blob - COPYING.EXCEPTION" . Git.savannah.gnu.org . Archivado del original el 21/07/2011 . Consultado el 01/04/2016 .
- ↑ "libtool.git - GNU Libtool" . Git.savannah.gnu.org . 8 de enero de 2005. Consultado el 1 de abril de 2016 .
- ↑ "Aprendiendo las herramientas de desarrollo de GNU" . Autotoolset.sourceforge.net . Consultado el 1 de abril de 2016 .
- ↑ "automake: Sistema de compilación GNU" . Gnu.org . 31-12-2014 . Consultado el 01-04-2016 .
- ↑ "El sistema de configuración y compilación de GNU - Introducción" . Airs.com . 1998-07-01 . Consultado el 2016-04-01 .
- ↑ "Compilación cruzada con GNU Autotools" . Archivado del original el 13 de octubre de 2008. Consultado el 24 de septiembre de 2008 .
- ↑ "Robert Ögren - Ejecución lenta de scripts de shell en Cygwin" . Cygwin.com . Consultado el 1 de abril de 2016 .
- ↑ Kamp, Poul-Henning (2012). "Una generación perdida en el bazar" . ACM Queue . 10 (8): 20– 23. doi : 10.1145/2346916.2349257 . S2CID 11656592 .
- ↑ "Autotools, 2.ª edición de John Calcote | Penguin Random House Canada" . Consultado el 22 de enero de 2021 .
- ↑ "Re: Planes futuros para Autotools" . Consultado el 22 de enero de 2021 .
Enlaces externos
- buildconf en SourceForge proporciona el script de shell posix autogen.sh para la preparación automática de la compilación.
- Automatización de compilaciones
- Herramientas de compilación
- Software del Proyecto GNU
- Software que utiliza la Licencia Pública General de GNU.
- Herramientas de programación Unix