On 9/30/20 8:41 AM, Zack Weinberg wrote: >> 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. Less of a bug and more an intentional thing. When developing autoconf, you don't want to have to frequently regenerate the world just because of a version number change. So the documented procedures for maintainers is that you have to autoreconf twice: the first time to get an autoconf that learns a version number for future output, but where generated files still have a version number inherited from whatever version of autoconf you bootstrapped with; the second time with the just-built autoconf so that all version numbers appear the same (both in generated comments and in what the second-built autoconf will produce). Ideas on streamlining that are welcome, but as we at least have a documented procedure (even if it is multi-step), it's not essential to fix before 2.70. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
