¿Automake y autoconf son la forma estándar de compilar código?

¿Automake y autoconf son la forma estándar de compilar código?

A veces compilo aplicaciones desde el código fuente y he estado usando:

./configure
make
sudo make install

Pero recientemente, me encontré con ./autogen.shque genera la configuración y crea scripts para mí y los ejecuta.

¿Qué otros métodos existen para optimizar la compilación de C/C++/C#(mono)? Parece un poco viejo. ¿Existen nuevas herramientas por ahí? Si tengo la opción, ¿cuál debo usar?

Respuesta1

Autoconf y Automake se propusieron resolver un problema evolutivo de Unix.

A medida que Unix evolucionó en diferentes direcciones, los desarrolladores que querían código portátil tendieron 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 bifurcó en diferentes implementaciones (BSD, SystemV, muchas bifurcaciones 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 escribir código que no dependiera de una marca particular de sistema operativo. , sino 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 más tarde otros sistemas operativos la adoptarían. En lugar de tener un espagueti de código que buscaba marcas y versiones, los desarrolladores comenzaron a investigar por 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 años 90 indicaban a los desarrolladores editar un archivo config.h y comentar las características adecuadas disponibles en el sistema, o enviarían archivos config.h estándar para cada configuración del sistema operativo que se había probado.

Este proceso era 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 fue capaz de reemplazar el proceso de edición humana de config.h con una herramienta que probó la funcionalidad del sistema operativo.

Por lo general, escribirá su código de sondeo en el archivo configure.ac y luego ejecutará el comando autoconf que compilará este archivo en el comando de configuración ejecutable que ha visto utilizado.

Entonces, cuando ejecutaba, ./configure && makebuscaba las funciones disponibles en su sistema y luego creaba el ejecutable con la configuración que se detectó.

Cuando los proyectos de código abierto comenzaron a utilizar sistemas de control de código fuente, tenía sentido verificar 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 allconstruiría el proyecto
  • make cleaneliminaría todos los archivos compilados del proyecto
  • make installinstalaría el software
  • cosas como make disty make distcheckprepararía la fuente para su distribución y verificaría que el resultado fuera un paquete de código fuente completo
  • etcétera...

La creación de archivos MAKE compatibles se volvió engorrosa porque había muchos textos repetitivos que se repetían una y otra vez. Entonces, Automake era un nuevo compilador que se integraba con autoconf y procesaba los Makefile "fuente" (llamado Makefile.am) en Makefiles que luego podían enviarse a Autoconf.

La cadena de herramientas automake/autoconf en realidad utiliza 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 ahí surgió autogen.sh.

Hasta donde yo sé, Gnome fue un proyecto que introdujo el uso de este script auxiliar autogen.sh.

Respuesta2

Hay dos "grandes actores" en esta área; Cmake y GNU Autotools.

  • GNU Autotools es la forma GNU de hacer las cosas y está bastante centrado en *nix. Es una especie de sistema de metaconstrucción, que proporciona un conjunto de herramientas que generan configuraciones específicas y crean archivos para lo que estás intentando hacer. Esto le ayuda a realizar más cambios en su código sin tener que manipular directamente su sistema de compilación, y ayuda a otros a compilar su código de formas para las que usted no había diseñado, bajo *nix.

  • Cmake es la forma multiplataforma de hacer las cosas. El equipo de Cmake crea software de muchas maneras diferentes, con GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU/Linux, lo que sea. Si le preocupa la portabilidad de su código base, este es el camino a seguir.

Como ya se ha mencionado, a algunas personas parece gustarles los Scons. Si está familiarizado con Python, esto podría proporcionar más coherencia en su entorno de trabajo.

Ruby también tiene una especie de sistema de metaconstrucción llamado Rake, que es bastante bueno en sí mismo y muy útil para aquellos que ya están familiarizados con Ruby.

Respuesta3

sconses un posible reemplazo, aunque no tengo experiencia personal. También está implementado en Python, lo que podría ser un problema dependiendo del entorno de compilación.

Respuesta4

Para C# puedes usar xbuild (y msbuild en Windows), que construirá el proyecto a partir de tus archivos de proyecto.

información relacionada