Commit Hash Access in Compiled API

[tylerjereddy]

The recently added version number availability for openblas_get_config() is already proving useful in our project to verify binaries built via linking to openblas (i.e., make sure an old system-level openblas isn't "polluting the build", etc.).

An additional level of disambiguation could be achieved by including the git commit hash in the C extension "API" as well, as @martin-frbg noted.

What do you think about a Makefile level solution that generates a small bit of C code that uses a git command to automatically make the hash available in the compiled binary, similar to this approach maybe?

Presumably, this information could be made available via openblas_get_config() as well, by giving it access to the compile-time generated character pointer containing the commit hash? And, once implemented, I don't imagine a release manager would have to do extra work as long as the git command to retrieve the hash is stable over time?

[martin-frbg]

Thanks for the pointers. The problem I foresee is that we would probably want something that sort-of works with tarballs that do not contain the .git hierarchy, or at least something that does not rely on having git installed on the build host.

[brada4]

First question is why would you want to distribute non-releases around. If you pull a non-release you can tag it in Makefile.rule to your liking. The information like tarball checksum, git hash or svn revision happens right outside openblas commit and there is no universal way to recignize them.

[tylerjereddy]

I think it is pretty common for us to have to use a build from a specific git commit hash rather than right at a release point because of sensitivity to bug fixes and so on. I think this just happened after 0.3.4 for example.

It is mostly for diagnostic purposes rather than distribution -- in continuous integration contexts let's be as sure as possible that we have the openblas version we want linked in to our project.

That said, it sounds like the preference on your end is for downstream projects to handle this themselves.

[brada4]

Present situation with some.release.id-dev popping out of pip leaves us quite helpless sometimes, actualy you can download one from git project front page without any tags inside.

E.G You can plant git hash as version by VERSION=whatever, that should identify problem location in development history, as much as it is concerning here. Probably more sophisticated logic would be hamdy to get real releases out of commit IDs, or simplistic - do not play with version if it is not a RCS tree?

[martin-frbg]

Might "steal" this from Asymptote (vectorgraphics/asymptote):

usinggit = $(shell if test -d ".git"; then echo yes; fi)
ifeq ($(usinggit),yes)
	revision = $(shell LC_ALL="C" git describe --long | \
	sed -e 's/git-\([0-9]\)*-g.*/-\1/' | sed -e 's/-0-g.*//')
	sed -e 's/git-\([0-9]*\)-g.*/-\1/' | sed -e 's/-0-g.*//')
else
	revision = @VERSION@
endif