This is the mail archive of the
mailing list for the binutils project.
Re: RFA: gold version number
- From: Matt Rice <ratmice at gmail dot com>
- To: Cary Coutant <ccoutant at gmail dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Nick Clifton <nickc at redhat dot com>, Alan Modra <amodra at gmail dot com>, Binutils <binutils at sourceware dot org>
- Date: Sun, 27 Mar 2016 10:58:55 -0700
- Subject: Re: RFA: gold version number
- Authentication-results: sourceware.org; auth=none
- References: <CAJimCsG=7Ro1stj8d8Phzi1oFVS+5TOZ0eTFd+t1RS_HYoiS9Q at mail dot gmail dot com>
On Thu, Mar 24, 2016 at 5:10 PM, Cary Coutant <firstname.lastname@example.org> 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:
bison uses it for example in AC_INIT on line 27 currently...
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
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...