Puis-je faire en sorte que mon script configure définisse la variable VERSION à partir d'un fichier au lieu d'être codé en dur?

Question

Je suis en train de plonger dans autotools et j'ai réussi à réduire la plus grande partie de mon processus de construction, mais j'ai récemment trouvé une trace de la variable VERSION. Nous développons en tant que groupe utilisant git, et avons actuellement un système en place qui transforme une partie du hachage git commit en une chaîne de version faisant partie de notre bibliothèque. De cette façon, lorsque nous avons compilé du code, il est facile de vérifier de quel commit il a été compilé. Par exemple, si nous exécutons mything --version, il imprime 0.1.1.1f034b7. Ma solution actuelle pour faire cela avec autotools implique d'avoir un script version.sh dans le dépôt qui sonde git pour le hachage de commit et qui sort la chaîne de version comme montré ci-dessus. Puis, en configure.ac j'ai

AC_INIT([example], [m4_esyscmd([./version.sh])], [myphonyaddress@me.com], [], [amazingcode.com])

Avec cela, je peux courir autoreconf -i, générer un script configure et faire la ./configure && make && make install habituelle. En exécutant ./configure, un fichier dans le projet appelé version.cc est créé à partir de version.cc.in, en remplaçant @VERSION@ par la chaîne de version que je veux. C'est ici que réside la fonction correspondant à mything --version. Bien que cela fonctionne, je n'aime pas le fait que chaque fois que je fais un commit, je dois relancer autoreconf -i, car à chaque validation, le script configure est obsolète.

Ce que je voudrais faire, c'est que le script configure généré sache que la variable VERSION n'est pas une chaîne codée en dur. Au lieu de cela, je pourrais avoir version.sh enregistrer la chaîne de version dans un fichier non suivi que le script configure lirait pour déterminer ce que devrait être VERSION.

Est-ce possible sans aussi beaucoup de sorcellerie macro? Je veux mettre une fois la version de la version et l'oublier. Je suis également ouvert aux solutions alternatives, mais ce serait bien de ne pas demander à d'autres développeurs d'installer des autotools pour contribuer.

---

Je sais qu'il y a des opinions bien arrêtées sur les systèmes automake et build en général. Merci de ne pas me dire combien vous détestez les autotools. Je suis assez nouveau et j'apprends encore, mais honnêtement, je ne pense pas que ce soit mauvais du tout. Je vous remercie!

Answer 1

J'ai déjà fait quelque chose comme ça. J'ai laissé VERSION un nombre statique dans configure.ac, sauf quand il devait être changé. Comme vous l'avez découvert, le changement de numéro de révision par commit-by-commit devient très vite fastidieux. IIRC, ce dont je me souviens avoir décidé était d'ajouter un fichier qui avait l'information de version comme un fichier EXTRA_DIST (donc il était livré avec l'archive). Afin de faire ce fichier j'avais un autre fichier comme phony target qui saisissait les informations de révision du VCS (s'il détectait qu'il en utilisait un, contrairement à un archive source extraite) et copiait lui-même (ou pas, s'il n'y avait pas de VCS) au fichier EXTRA_DIST. Aucune sorcellerie macro n'était impliquée du tout.

Donc, si version est la cible EXTRA_DIST, quelque chose comme:

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

dans configure.ac établiraient une définition pour votre unité de traduction C++:

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

Le fichier EXTRA_DIST pourrait aussi être un auto unité de traduction contenue aussi qui a juste des informations de version.

j'utilisais rpmbuild sur mon serveur CI qui nécessite un tarball de construire au lieu d'un check-out repo, donc en gros la première étape de la construction était essentiellement autoreconf...; ./configure...; make dist; et la deuxième étape était rpmbuild -ta tarball;.