b-em
b-em copied to clipboard
stardot
The version number included in the code (on Linux builds) is unreliable
Building a release for which git log and git describe both have 51fd877 as the current commit produces an executable which claims to be e5adcaf. See also the comments at the end of Issue#156.
FYI, if I delete the autom4te.cache/ directory then re-run autogen.sh the version number in configure is then correct.
Adding -f to autoreconf in autogen.sh caused the version number to be correctly updated when you re-run autogen.sh
I think it would be better if the version was somehow updated as part of the compilation rather than as part of the configuration.
Yes, agreed. I might need to spend some time reading the documentation. If it were a plain Makefile I'd have a file version.h with a build command that got executed each time, or for an optimisation, depended on something in the git directory that gets updated on each commit. I am sure the same must be possible with autoconf, it's just a question of how.
Here's one possible way of fixing that. It seem I can't remove GNU autoconf's idea of a package having a version known at configure time - it's part of the AC_INIT macro. So instead I am setting a different variable, also from git.
https://github.com/stardot/b-em/commit/c38083ad86e22218436105b3a14cccb534804a25
This seems to have created a catch-22. I have added a Makefile rule to Makefile,.am to generate version.h but, because gcc is used for dependency analysis and gcc can't find an existing file of that name, it doesn't get added to the list of dependencies and thus the new rule is not called.