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

22

A veces compilo aplicaciones de la fuente y he estado usando:

./configure
make
sudo make install

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

¿Qué otros métodos existen para optimizar la compilación C / C ++ / C # (mono)? Hacer parece un poco viejo. ¿Hay nuevas herramientas por ahí? Dada la elección, ¿cuál debo usar?

Louis Salin
fuente
no hay nada como solo 'código'. Por ejemplo, si obtienes código Java, probablemente lo construirás usando maven o ant, si obtienes Python, una buena opción son las herramientas de configuración. No hay formas estándar de compilar nada. Tal vez deberías reformular la pregunta.
diega
Buen punto. En realidad estoy codificando en C # con mono, pero mi pregunta también se aplica a C / C ++.
Louis Salin
Pequeña nota: autogen.sh no ejecuta make para usted, solo configure.
Sandy
@Sandy autogen.shson principalmente scripts personalizados, que generalmente invocan autoreconfpero también pueden invocar ./configuree incluso make. No creo que su comportamiento esté estandarizado de ninguna manera; el objetivo principal es en tener un archivo exetable dentro del proyecto, que la gente puede funcionar (en lugar de tener que saber que necesitan para evocar autoreconf)
Umlaute

Respuestas:

42

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 disty make distcheckprepararí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

miguel.de.icaza
fuente
Solo una cuestión menor: los estándares de GNU exigen el envío de archivos generados en tarballs, para reducir las dependencias de compilación a un mínimo de herramientas disponibles universalmente. Si obtiene una fuente sin procesar (de un sistema de control de versiones, por ejemplo), los archivos generados no estarán allí.
vonbrand
14

Hay dos "Grandes jugadores" en esta área; Cmake y GNU Autotools.

  • GNU Autotools es la forma en que GNU hace 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 tratando de 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 construir su código de una manera que no había diseñado para - bajo * nix.

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

Como se ha mencionado, algunas personas parecen ser aficionadas a Scons. Si está familiarizado con Python, esto podría proporcionar más consistencia en su entorno de trabajo.

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

Eli Frey
fuente
6

Scons es un posible reemplazo, aunque no tengo experiencia personal. También se implementa en Python, lo que podría ser un problema, dependiendo del entorno de compilación.

tsvallender
fuente
2
La portabilidad no es el problema ya que Python está prácticamente en todas partes. La principal queja sobre SCons hasta ahora es que es inaceptablemente lenta. Hay algunos ajustes para sacrificar la precisión de construcción en favor de la velocidad, pero no estoy seguro de si todavía está a la par con Make.
Alex B
3

Si está usando C # / Mono, puede usar msbuild (los archivos .sln / .csproj utilizados por MonoDevelop y Visual Studio) para administrar todo su proceso de compilación.

Luego puede compilar desde MonoDevelop o ejecutar el xbuildcomando en su terminal favorito (funciona mejor en Mono> = 2.6). Esto es extremadamente fácil y no requiere mucho trabajo de su parte, porque MonoDevelop manejará los archivos msbuild por usted, y no necesitará editarlos a menos que quiera modificar más allá de lo que la interfaz de usuario de MonoDevelop puede hacer por usted.

No estoy familiarizado con la forma en que las personas que dependen de msbuild manejan las instalaciones para sus proyectos, pero siempre puedes preguntar eso. ;-)

Arenoso
fuente
Sí, sé sobre xbuild, pero estoy tratando de alejarme de los IDE que solo quieren tomar mi mano. Además, Mono se compila usando Mono y usa autoconf, por lo que quería saber un poco más. ¡Gracias!
Louis Salin
1
Curiosamente, muchos proyectos de Mono están intentando migrar a msbuild ahora que xbuild funciona tan bien. Hace que la compatibilidad con Windows / Mac sea un poco más fácil. Mono tiene tanto código C que no estoy seguro de cuán práctico sería para ellos moverse a xbuild. Pero autoconf funciona muy bien, así que haz lo que sea que funcione para ti. :-)
Sandy
0

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


fuente