¿Puedo hacer que mi script configure defina la variable VERSION desde un file en lugar de estar codificada?

Estoy buceando en autotools y he conseguido con éxito la mayor parte de mi process de compilation, pero recientemente me he topado con un problema de seguimiento de la variable VERSION . Nos desarrollamos como un grupo usando git, y actualmente tenemos un sistema en funcionamiento que hace parte del hash de commit de git en una cadena de versión que es parte de nuestra biblioteca. De esta forma, cuando comstackmos el código, es fácil verificar de qué compilation se compiló. Por ejemplo, si ejecutamos mything --version , imprime 0.1.1.1f034b7 .

Mi solución actual para hacer esto con autotools implica tener un script version.sh en el repository que testing git para el hash de confirmación y emite la cadena de versión como se muestra arriba. Luego en configure.ac tengo

AC_INIT([example], [m4_esyscmd([./version.sh])], [[email protected]], [], [amazingcode.com])

Con esto puedo ejecutar autoreconf -i , generar un script de configure y hacer lo usual ./configure && make && make install . Al ejecutar ./configure , se crea un file en el proyecto llamado version.cc desde version.cc.in , sustituyendo @[email protected] con la cadena de versión que deseo. Aquí es donde reside la function relevante para mything --version .

Aunque esto funciona, no me gusta el hecho de que cada vez que realizo una confirmación, tengo que volver a ejecutar autoreconf -i , porque con cada confirmación realizada, el script de configure se desactualiza.

Lo que me gustaría hacer es que la secuencia de commands de configure generada sepa que la variable VERSION no es una cadena codificada. En cambio, podría hacer que version.sh guarde la cadena de la versión en un file sin seguimiento que el script configure leerá para determinar qué VERSION debería ser.

¿Es esto posible sin demasiada macro brujería? Quiero configurar las cosas de la versión una vez y olvidarme de eso. También estoy abierto a soluciones alternativas, pero sería bueno no exigir a otros desarrolladores que instalen autotools para contribuir.


Sé que hay algunas opiniones firmes sobre automake y sistemas de construcción en general. Por favor, no me digas cuánto odias las autotools. Soy bastante nuevo y todavía estoy aprendiendo, pero sinceramente no creo que sea malo en absoluto. ¡Gracias!

He hecho algo así antes. Dejé VERSION un número estático en configure.ac , excepto cuando era necesario cambiarlo. Como ha descubierto, el cambio del número de revisión de compromiso por compromiso se vuelve tedioso muy rápidamente.

IIRC, recuerdo en lo que decidí que era agregar un file que tenía la información de la versión como un file EXTRA_DIST (por lo que estaba empaquetado con el tarball). Para hacer ese file tenía otro file como un objective falso que tomaba la información de revisión del VCS (si detectaba que estaba usando uno, opuesto a ser un tarball de fuente extraída) y se copyba a sí mismo (o no, si no había VCS) al file EXTRA_DIST . Ninguna macro brujería estaba involucrada en absoluto.

Entonces, si la version es el objective EXTRA_DIST , algo como:

 mydef_version=`cat version` AC_DEFINE_UNQUOTED([VERSION_GIT],["$mydef_version"]) 

en configure.ac se configuraría una definición para su unidad de traducción C ++:

 const char version_info[] = VERSION "." VERSION_GIT; 

El file EXTRA_DIST también podría ser una unidad de traducción autónoma que solo tenga información de versión.

Estaba usando rpmbuild en mi server de CI, que requiere un tarball para build en lugar de un repository desprotegido, por lo que básicamente la primera etapa de la compilation fue básicamente autoreconf...; ./configure...; make dist; autoreconf...; ./configure...; make dist; y la segunda etapa fue rpmbuild -ta tarball; .