Forma recomendada de utilizar las macros Autoconf Archive y otras macros de terceros

Encontré varias macros útiles en el Archivo de Autoconf, y también un útil file m4 que ayuda a probar el soporte de la biblioteca Boost. El file Autoconf está hospedado por GNU y el auxiliar Boost m4 está alojado como un repository de GitHub. Me gustaría utilizarlos en un proyecto de C ++ que utiliza Autotools y que es administrado por git.

Claramente, es posible downloadlos a mano e insertlos en el repository git de mi proyecto. Pero, ¿hay una forma más recomendada de hacerlo?

Por ejemplo, es posible garantizar que los files de terceros estén en la última versión haciendo que el process de compilation los descargue automáticamente, en lugar de actualizarlos en el repository a mano. También ayuda a separar la fuente de los files externos, ya que los files de terceros no son realmente parte del código fuente puro, sino que son files externos descargados.

Si es algo bueno, ¿debería hacerse a mano a través de autogen.sh? ¿O usando automake.am? O ambos (por ejemplo, download files en autogen.sh y probar la versión + actualizar en automake)?

Creo que mantenerlos en el git repo no es un desastre (al igual que cosas como COPYING, git.mk y otros están ahí), pero aún es útil hacer que el process de compilation los actualice a la última versión de la web.

Por el contrario, los files de macro de autoconf son parte de la fuente correspondiente , lo suficientemente importante como para ser necesarios en el make dist tarball. En realidad, la mayoría de las macros de autoconf no cambian con la frecuencia suficiente como para garantizar algún tipo de característica de actualización en la compilation. Incluso si actualizaran con frecuencia, no hay garantía de que la macro actualizada no rompa su compilation existente.

Mantener las macros bajo control de fuente es una buena idea.

EDITAR: estoy de acuerdo con @delinquentme en que agregar estos como un submodule de git sería bueno (puede bloquear una versión, actualizar fácilmente). Pero veo un par de problemas con este enfoque.

El primero es que git does not (IIUC) admite revisiones parciales incluso con submodules. El file GNU Autoconf (por ejemplo) tiene muchas macros y probablemente solo necesite algunas. El rest de los files y macros que no se usen seguirán allí, sin usar, y se interpondrán en el path.

El segundo problema es que AC_CONFIG_MACRO_DIR solo encuentra macros en un directory sin búsqueda de subdirectorys dentro de ese directory, lo que hace que el uso de varios submodules sea molesto. Podrías hacerlo revisando los submodules en algún lugar discreto y AC_CONFIG_MACRO_DIR simbólicamente a AC_CONFIG_MACRO_DIR .

Para mí, el historial de la macro no es tan importante. Para eso es el VCS de upstream :-).

Tienes varias opciones para una forma más matizada de manejar estas dependencies:

Submodules ( http://git-scm.com/docs/git-submodule )

… [S] los ubmodules están destinados a diferentes proyectos que le gustaría hacer parte de su tree fuente, mientras que el historial de los dos proyectos sigue siendo completamente independiente y no puede modificar el contenido del submodule desde el proyecto principal. [Nota: el hecho de enviar un CD al repository permitirá modificaciones]

  • Muy similar a su enfoque sugerido en repo

  • Especialmente potente para cualquier código guardado en Git (como lo son los files de Autoconf)

  • Congela a una confirmación exacta ( https://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/ ) lo que alivia la posibilidad de romper la construcción

  • Configuración less anticipada que un gancho

Hooks ( http://git-scm.com/book/es/Customizing-Git-Git-Hooks )

Al igual que muchos otros sistemas de control de versiones, Git tiene una forma de activar scripts personalizados cuando ocurren ciertas acciones importantes. Hay dos grupos de estos ganchos: del lado del cliente y del lado del server.

  • Se ejecuta a través de events específicos de git

  • Compatible con Git si está buscando una continuous integration, en lugar de activos inmovilizados

Estoy de acuerdo con @ ldav1s 'en mantenerlos dentro del control de versiones, sin embargo, en lo que respecta a la mantenibilidad, podría ser útil saber dónde se originó el código (mantener el historial). Y con actualizaciones futuras parece ventajoso build el trabajo que otros han hecho …

TLDR: vaya con un submodule, mantenga el historial y hágalo .

 $ git submodule add http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_am_jobserver.m4 

El command anterior submodulará la URL en su base de código dentro del directory actual