Re: RFA: gold version number

[Matt Rice <ratmice at gmail dot com>]

On Thu, Mar 24, 2016 at 5:10 PM, Cary Coutant <ccoutant@gmail.com> wrote:
> I've been neglecting gold's version number, which has been stuck at
> 1.11 for ages. I don't really have significant changes anymore that
> would trigger an obvious version number bump, but a
> consistently-incremented version number would still be useful for
> tracking purposes. I suppose I could just remove it and show only the
> binutils version number, but I think it's probably better to keep a
> version number of its own.
>
> But what strategy should I use for incrementing it? I've thought about
> bumping it just before each binutils release branch is cut, or perhaps
> just after, but I'm not sure how to remind myself to do that at the
> right moment.
>
> How should the version number distinguish between a release branch
> build and a trunk build? Are there any hooks built in to git or
> automake that would allow commit ids or datestamps to be included
> automatically in the version string?
>
> Any advice?

its worth noting that gnulib contains a git-version-gen module:
https://www.gnu.org/software/gnulib/MODULES.html#module=git-version-gen

bison uses it for example in AC_INIT on line 27 currently...
http://git.savannah.gnu.org/cgit/bison.git/tree/configure.ac

AC_INIT([GNU Bison],
        m4_esyscmd([build-aux/git-version-gen .tarball-version]),
        [bug-bison@gnu.org])

where m4_esyscmd() iirc runs at autoreconf time


generating these from the makefile/autoconf is the generally recommended way
e.g. that's how the kernel does it with it's GIT-VERSION-GEN script

however things such as bison's usage of it has caused issues with
distributions that use git as the source package format particularly
in these kinds of development tools that appear early in the
dependency graph, where you can assume that git appears on the
developers machine, but not necessarily on the build machine as they
may just be using the file system resulting from some git checkout...
so it is increasing the needed initial bootstrap image

it may be possible to do so from git hooks using something like a git
smudge/clean filter
http://gilesbowkett.blogspot.com/2013/05/how-gits-smudge-and-clean-filters-work.html
https://git-scm.com/docs/gitattributes

that would work with the above case but goes somewhat off the beaten
path, i'm not sure how well any of the above work with the project
within a project with distinct versioning situation though..

BFD_VERSION_DATE=$(date +"%Y%m%d" --date="@$(git log --pretty=format:"%ct" -1)")
SHA1=$(git rev-parse HEAD)
git describe $SHA1
git tag --points-at $SHA1 | tac | head -n 1

hope that is helpful...