Project

General

Profile

Bug #393

Show git sha1sum as version string

Added by Christoph Junghans almost 10 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Erik Lindahl
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

Created an attachment (id=422)
patch to change versionstring

The version given by configure ,e.g. 4.0.99_development_20090927, is not extremely useful. The attached patch will show the git sha1sum there, if one compiles inside in a git repository.

Everything else (branch names, tags, ...) is not very unique due to the fact that one can pull gromacs master branch into a local branch called retsam or so.

Of course a link like: http://repo.or.cz/w/gromacs.git/commit/<sha1sum> would be still useful.

git-version.patch (1.61 KB) git-version.patch patch to change versionstring Christoph Junghans, 02/05/2010 11:06 AM
git-version.patch (1.61 KB) git-version.patch patch to change versionstring Christoph Junghans, 02/17/2010 06:03 PM
git-version.patch (1.86 KB) git-version.patch reworked patch to change versionstring Christoph Junghans, 02/17/2010 06:51 PM

Associated revisions

Revision 566dcf18 (diff)
Added by Teemu Murtola over 9 years ago

Show git sha1 hash in version string (bug #393).

This makes it much easier to identify development builds. The exact
format may need tweaking; now it shows the previous tag (if any),
followed by the first 20 digits of the sha1 hash of the most recent
commit. If there's no git repository, the VERSION string defined in
configure.ac is used as a fallback. CMake also uses the version string
defined in the top CMakeLists.txt.

Revision 858d8635 (diff)
Added by Teemu Murtola over 9 years ago

Backported git sha1 version string (bugzilla #393).

(backported from commits 566dcf18dcf793369a8b30acfce696823f8e071f and
23c21daedfab7a0a329f2431a15e041a221bb602)

History

#1 Updated by Teemu Murtola almost 10 years ago

I think this would be a good addition. As a further improvement, I think that if one compiles, e.g., the release-4-0-patches branch, it would be useful to have this explicitly visible in the version string somehow. Otherwise, one would always need to use git to check which version the 40-digit string corresponded to (after a while, one could maybe learn the numbers by heart, but that's not optimal).

The easiest way of achieving this would probably be to use git-describe to get the version string, and tag all releases with tags like v4.0.7 (would be useful in its own right as well). In the development branches, one would still get the sha1sum, but in the release branches the version string would become like v4.0.7-ncommits-sha1sum, immediately identifying how the build relates to released versions.

The main reason keeping me from committing this is that it would break cmake builds, in particular on Windows, and I don't know whether there's any easy and portable way around that (I'm no cmake expert). Generating the version.h file only when running cmake would probably be possible so that it works also on Windows, but then there's the risk that the version string gets out of sync with the git version if one does git-pull but cmake is not rerun.

#2 Updated by Christoph Junghans almost 10 years ago

Well, branches are not really useful due to the fact that I can name my local branch as I want:
git checkout --track -b XXX origin/release-4-0-patches
I could even name it master if I like to work on the stable code only, which will lead to massive confusion.

I have not much experience with tags in git, but from brief testing (and what I know from hg) I think it doesn't make much sense as well, because one can remove or set tags later on.

But back to main reason:
(btw. git on windows is already a hard task)
In the first place we could make a define like HAS_GIT_VERSION, which is only exported by autotools and use this in copyrite.c to switch between old and new versioning, so cmake would still work.

However in the cmake case it should be possible to get the sha1sum, when the git support is finished (http://www.cmake.org/Bug/view.php?id=7541) or we have to add the small shell script to do so - Shell under windows?

#3 Updated by Teemu Murtola almost 10 years ago

I agree that a branch name by itself is not of much use, but in my opinion, the pure sha1 hash is not ideal either. If you have several builds (possibly from very different versions), and have to identify them just based on a random sequence of letters, it is bound to take more effort than a simple version number. And if you are accidentally using a wrong version, chances of spotting it from the sha1 string are non-existent unless you specifically look into it.

Although it's possible to redefine or delete tags in git, how often do you think that would happen for release tags? And even if ever does, does it really matter? My whole idea was to make the version string easier to read, not to make it unique using the tag name. We could do, e.g.,
git describe --always --long
or just append the sha1 hash to the version string defined in configure.ac, with a similar effect. That way, the sha1 part would uniquely identify the version, while the tag would likely make it easier to identify the build without memorizing the hashes for the builds one has. For the latter purpose, it doesn't really matter whether the name is exactly the same for different users.

For now, it's probably enough to have the old behavior for CMake, and that's easy to implement. I'll do that in the near future.

As a separate issue, at least GNU make seems to behave a bit weirdly with the attached patch: if the version changes, it requires two invocations of make to actually rebuild copyrite.c (the first invocation just refreshes version.h). This is remedied by moving the commands to the version.h rule, so unless there's a known issue with this, I'll just do that.

#4 Updated by Christoph Junghans almost 10 years ago

Yeah, I think you are right the sha1sum alone is also not useful.
I think to show the tags together with the sha1sum is the best solution, even if there are only tags like "4.0.7", stable and "devel".

As a separate issue, at least GNU make seems to behave a bit weirdly with the
attached patch: if the version changes, it requires two invocations of make
to actually rebuild copyrite.c (the first invocation just refreshes version.h).
This is remedied by moving the commands to the version.h rule, so unless
there's a known issue with this, I'll just do that.

Yes, there is a small mistake inside, it has to be
copyrite.o: version.h
because the object file depend on version.h, see the updated patch

Do NOT move the command to the version.h rule, otherwise make will not run the rule if version.h already exists.

#5 Updated by Christoph Junghans almost 10 years ago

Created an attachment (id=427)
patch to change versionstring

#6 Updated by Teemu Murtola almost 10 years ago

Yes, there is a small mistake inside, it has to be
copyrite.o: version.h
because the object file depend on version.h, see the updated patch

Stupid of me of not noticing that. I fixed that, but it still doesn't seem to work, and I really don't know why. I made a simple test make file with just two input files (dependencies like version.h: update_version and copyrite.o: copyrite.c version.h) to rule out any autoconf magic, and it still doesn't work. Might be a bug or a "feature" in GNU make (I have version 3.81, which I think is the newest).

Do NOT move the command to the version.h rule, otherwise make will not run the
rule if version.h already exists.

I have actually tried, and make does run the rule every time, because it depends on the phony update_version rule. With my test makefile, the only combination that I got to work correctly was to have the commands in the rule for version.h and a phony update_version rule. Otherwise, either copyrite.o gets rebuilt every time (if version.h is phony) or two invocations of make are necessary (if the commands are in the update_version rule).

#7 Updated by Christoph Junghans almost 10 years ago

Created an attachment (id=428)
reworked patch to change versionstring

Now version.h virtually depends on stamp, which is an empty file.
It basically just stores the date, when make was ran the last time.
I guess
.PHONY: stamp
stamp:
touch stamp

would also work, but I am never sure about phony rules...
http://www.gnu.org/software/make/manual/make.html#Phony-Targets

#8 Updated by Teemu Murtola almost 10 years ago

We're getting a bit sidetracked here, but the GNU make seems to behave in a bit strange way. :)

Now version.h virtually depends on stamp, which is an empty file.
It basically just stores the date, when make was ran the last time.

I tried, and it makes the problem more obscure (admittedly, less people would hit it that way). Namely, if I now invoke make, and version.h is remade, the next invocation of make does not remake version.h, no matter what.

I guess
.PHONY: stamp
stamp:
touch stamp

would also work, but I am never sure about phony rules...

That works, but I think it's just the effect of having a phony rule as a dependency of version.h, not the presence of the stamp file.

I ran make with the -d flag for a case where things don't work (for simplicity, for the case without the stamp file), and it seems that there indeed is a "feature" there:

[...]
Considering target file `version.h'.
[...]
Considering target file `update_version'.
File `update_version' does not exist.
Finished prerequisites of target file `update_version'.
Must remake target `update_version'.
[...]
Successfully remade target file `update_version'.
Finished prerequisites of target file `version.h'.
Prerequisite `update_version' of target `version.h' does not exist.
No commands for `version.h' and no prerequisites actually changed.
No need to remake target `version.h'.
Finished prerequisites of target file `copyrite.o'.
Prerequisite `copyrite.c' is older than target `copyrite.o'.
Prerequisite `version.h' is older than target `copyrite.o'.
No need to remake target `copyrite.o'.

So basically, although the update_version rule actually changes version.h, make does not realize this (it might read the modification time of version.h before considering its dependencies, and not update it as it thinks nothing changed). The same sequence of events occurs in the stamp case when version.h is newer than stamp, now just with the stamp and update_stamp rules, and version.h does not get updated.

I think the best solution would simply be to have
version.h: update_version
commands
update_version:
because this seems to work correctly, and it is also documented in the GNU make manual as having the same effect as declaring version.h phony (except that it does not seem trigger unconditional rebuilds of files that depend on version.h). And it does not explicitly have the .PHONY tag, which might not be supported in other versions of Make.

#9 Updated by Christoph Junghans almost 10 years ago

(In reply to comment #8)

We're getting a bit sidetracked here, but the GNU make seems to behave in a bit
strange way. :)

make has its own rules ;-)

I think the best solution would simply be to have
version.h: update_version
commands
update_version:
because this seems to work correctly, and it is also documented in the GNU make
manual as having the same effect as declaring version.h phony (except that it
does not seem trigger unconditional rebuilds of files that depend on
version.h). And it does not explicitly have the .PHONY tag, which might not be
supported in other versions of Make.

Sounds nice to me, but I would rename "update_version" to "dummy" to make the point more clear. Otherwise we think about that issue in a month again.
I never heard of "Empty Commands" rules before, but it seems like make always has something to learn.

#10 Updated by Teemu Murtola over 9 years ago

Should now work with autoconf in git master. The exact format may need tweaking to suit everyones preferences, but that's relatively easy to do.

#11 Updated by Christoph Junghans over 9 years ago

Can you please cherry-pick the patch to the stable branch (add a git-tag like v4.0.7).
Anyway it is much simpler there, because there is no cmake ;-)

Also available in: Atom PDF