[m-rev.] for review: record the git revision the Mercury compiler was compiled with

[Julien Fischer]

On Fri, 17 Apr 2015, Paul Bone wrote:

> On Fri, Apr 17, 2015 at 11:33:58AM +0800, Sebastian Godelet wrote:
>> On 17/04/2015 09:44, Julien Fischer wrote:
>>> On Sat, 4 Apr 2015, Sebastian Godelet wrote:
>>>>
>>>> I think this functionality would be nice to have as I've seen it
>>>> already in some other tools which are configured and build from git
>>>> repositories.
>>>
>>> Is it all that useful?  For my current workspace (on the master branch),
>>> 'git describe --tags' gives:
>> I think it is useful sometimes, for example several month ago there was
>> a rather involved rebuilding step required (something like 3 steps), and
>> I'd to remember if I already build after a certain date (with the
>> correct commit compiled in).
>> Maybe my work-flow is a little bit different since I'm working only on a
>> fork with specific branches for not yet submitted/unmerged patches, but
>> sometimes it is helpful to check which exact revision the compiler is
>> build with, especially after not having recompiled for some time.
>> Having a git commit number helps when looking into the git graph log.
>
> It is definitly useful.  If a bug is fixed in git I want to know easily
> if that fix has appeard in a particular build.
>
> The alternative is to tag the repository each time we release an ROTD, but
> that doesn't help users building from a git checkout.  Ideally we should do
> both.
>
>>>
>>>      version-14_01_1-493-g9acc9db
>> Actually that does seem confusing. I think that comes from merging the
>> git tagged version branches, and then 493 following commits.
>> Maybe it would be better to use `git rev-parse --short HEAD`,
>> yielding g9acc9db only.
>>
>> An alternative could then be:
>> Mercury Compiler, version DEV-g9acc9db, on i686-pc-mingw32
>
> The git revision (hash) should always be stored somewhere in a build.
> Making it part of the version number for DEV and rotd builds would also
> help because then it appears in the filenames of the tarballs and such.

The ROTD tarballs already have the date in them.  I don't think making
the file names of the tarballs even longer is all that useful.

> It shouldn't appear in the version number for numbered releases.

My problem with the above was that the tag name is nothing to do with
the actual branch I was building from.  Looking at that id in isolation
I would think it was something to do with the version-14_01 branch.

Cheers,
Julien.