Re: autoconf-2.69c released [beta]

[Zack Weinberg]

On Sun, Sep 27, 2020 at 7:10 PM Bruno Haible <bruno@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