On Sun, Sep 27, 2020 at 7:10 PM Bruno Haible <br...@clisp.org> wrote: > > Paul Eggert wrote: > > > I don't know where you got this magic number 301-14265 from. > > > > I got it by checking out the then-current commit of Autoconf from Savannah > > git, > > and building from that. > > > > Presumably doing the right thing here would mean a fix to Autoconf's > > m4_version_prereq macro, not to Gnulib. m4_version_prereq should do the > > right > > thing for the per-commit version numbers that Autoconf itself uses. > > But m4_version_prereq can not know whether version 2.69.345 is before or > after the prerelease 2.69e. > > I think the real fix is therefore to change the Autoconf build system > so that instead of 2.69.301-14265 it would produce 2.69b.67-14265. > Then m4_version_prereq would know that this was between 2.69b and 2.69c. > > Most probably either 'git-version-gen' or some use of 'git describe' > can achieve this.
I just built autoconf (the program) from a completely clean checkout of git trunk, which is currently two commits after the v2.69c tag, and it identified itself as "autoconf (GNU Autoconf) 2.69c.2-04d14". So it appears to me that what you suggest, already happens. However, then I checked out git commit 14265094af1614d9e359550ca4a4939e590a5dba and rebuilt the tree, and it continued to identify itself as version 2.69c.2-04d14. I had to run `git clean -xdf` and re-autoreconf before it would start identifying itself as 2.69b.67-14265. So there *is* a bug somewhere in the build process, where it fails to notice that the value of @VERSION@ ought to change. Perhaps that's how Paul got 2.69.301-14265. zw
