Output either release version or commit hash

[vesalvojdani]

This should be fairly non-controversial, but it needs review because I'm not 100% this would actually do what I want for a release version... Also, I started to doubt the idea of either showing the proper release version or the git hash (never both): is there a need somewhere (e.g. sv-comp) where displaying both would be good to precisely identify the competing version?

[sim642]

Also, I started to doubt the idea of either showing the proper release version or the git hash (never both): is there a need somewhere (e.g. sv-comp) where displaying both would be good to precisely identify the competing version?

Having both for any kind of release is very much useful to avoid mixups. For example, all the SV-COMP submissions are locally tagged with svcomp22 such that it would be contained in the version output, but if there's need for an updated SV-COMP submission, then that tag is moved. Without the commit hash anywhere in the version output, it would be much harder to verify which binary was compiled from which sources, since both just report as svcomp22.
The same goes for opam releases where you might locally tag it multiple times only to find out problems in the release process that need to be fixed and tagged again.

[vesalvojdani]

Okay, I agree with svcomp having a precise version id printed is useful, but having the hashes in our opam releases is like admitting we don't trust our release process.

[sim642]

I suspect installing directly from opam without out repository won't even have the commit hash because it doesn't use the git repository for getting the sources, but a source archive, and using our git describe script stuff to fill that in. I tried at some point in a fresh switch, but I don't remember anymore, I think it said something like 1.1.1 (unknown).

This could be avoided if we didn't use our script (or even a shell command in a dune rule), but also another substitution like %%VCS_COMMIT_ID%%. But that of course does nothing during development strictly in the repo and not installing (ocaml/dune#1539).

There's also another difference. Our script uses git describe --all --long --dirty while there's a substitution VERSION, but that uses git describe --always --dirty. The difference is that our custom thing includes branch names, while the normal describe doesn't. The ugly downside of ours is that it prefixes everything with heads/ or tags/.

I've found a third way of doing this: https://dune.readthedocs.io/en/stable/dune-libs.html#build-info. According to that description, it works for both releases (just containing the version number, no commit hash) and development (git describe --always --dirty). But again, that differs from our script.
There's a bunch of open dune issues related to having more control over dune-build-info: ocaml/dune#4453, ocaml/dune#3856 and ocaml/dune#3523.
Also, it doesn't work for Gobview until dune 3.0 is released: ocaml/dune#4444.

In conclusion, there's no good way to do it exactly as we might want right now. I'll have to rethink this for 2.0 by maybe combining some of the above to get everything to work in all the possible build and install scenarios.