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

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

./configure make sudo make install 

Pero recientemente, me encontré con ./autogen.sh que genera la configuration y ./autogen.sh scripts para mí y los ejecuta.

¿Qué otros methods para optimizar la compilation C / C ++ / C # (mono) existen? Haz parece un poco viejo. ¿Hay nuevas herramientas por ahí? Dada la elección, ¿cuál debería usar?

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 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 

Como Unix se bifurcó en diferentes implementaciones (BSD, SystemV, muchas bifurcaciones de proveedores y más tarde Linux y otros sistemas similares a Unix) se hizo importante para los desarrolladores que querían escribir código portátil escribir código que no dependía de una marca particular de sistema operativo , pero en las 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 spaghetti 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 files README para comstackr el código fuente en los años 90 indicaron a los desarrolladores que editen un file config.h y comenten las características adecuadas disponibles en el sistema, o que envíen files config.h estándar para cada configuration del sistema operativo que se haya probado.

Este process fue engorroso y propenso a errores, y así es como llegó Autoconf. Debería pensar en Autoconf como un lenguaje compuesto por commands de shell con macros especiales que podían replace el process de edición humana de config.h con una herramienta que probaba el sistema operativo para la funcionalidad.

Normalmente, escribiría su código de testing en el file configure.ac y luego ejecutaría el command autoconf, que comstackría este file en el command de configuration ejecutable que haya visto utilizado.

Por lo tanto, cuando ejecuta ./configure && make , busca las funciones disponibles en su sistema y luego crea el ejecutable con la configuration que se detectó.

Cuando los proyectos de código abierto comenzaron a usar sistemas de control de código fuente, era lógico verificar el file configure.ac, pero no el resultado de la compilation (configurar). Autogen.sh es simplemente un pequeño script que invoca el comstackdor de autoconf con los arguments de command correctos para usted.

Automake también creció fuera de las prácticas existentes en la comunidad. El proyecto GNU estandarizó un set regular de objectives para Makefiles:

  • make all construyan el proyecto
  • make clean eliminaría todos los files comstackdos del proyecto
  • make install instalaría el software
  • cosas como make dist y make distcheck prepararían la fuente de distribución y verificaría que el resultado fuera un package de código fuente completo
  • y así…

Construir makefiles obedientes se volvió oneroso porque había muchas repeticiones repetidas una y otra vez. De modo que Automake era un nuevo comstackdor que se integraba con el autoconf y procesaba los "Makefile" de origen (llamados Makefile.am) en Makefiles que luego podían alimentar a Autoconf.

La cadena de herramientas automake / autoconf en realidad usa una cantidad de otras herramientas de ayuda y se complementan con otros componentes para otras tareas específicas. A medida que creció la complejidad de ejecutar estos commands en order, nació la necesidad de un script listo para ejecutar, y de ahí surgió autgen.sh.

Por lo que sé, Gnome fue un proyecto que introdujo el uso de este script de ayuda autogen.sh

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

  • GNU Autotools es la forma de GNU de hacer las cosas, y se centra bastante en * nix. Es una especie de sistema meta-build, que proporciona un set de herramientas que generan configuraciones específicas y crean files 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 compilation, y ayuda a otros a comstackr su código de forms para las cuales 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 está interesado en la portabilidad de su código base, este es el path 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 meta-build llamado Rake, que es muy bueno por sí mismo, y es muy útil para aquellos que ya están familiarizados con Ruby.

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

Si está utilizando C # / Mono, puede usar msbuild (los files .sln / .csproj utilizados por MonoDevelop y Visual Studio) para administrar todo el process de compilation.

Luego puede comstackr desde MonoDevelop o ejecutar el command xbuild en su terminal favorito (funciona mejor en Mono> = 2.6). Esto es extremadamente fácil y no requiere prácticamente ningún trabajo de su parte, porque MonoDevelop manejará los files de msbuild por usted, y no necesitará editarlos a less que desee ajustar cosas más allá de lo que la IU 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 se puede preguntar eso. 😉

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