tenders, bindings, mfttool: Embed version information

[mato]

Generate a common include/solo5/solo5_version.h every time make is invoked and the Git version, as defined by the output of git -C . describe --dirty --tags --always changes.

Embed this information and make it available in the tenders (via --version), mfttool (in the help, and in the generated manifest), and during bindings startup.

Results:

$ tenders/hvt/solo5-hvt --version
solo5-hvt v0.4.1-161-gcaa0b1f
$ tenders/hvt/solo5-hvt tests/test_hello/test_hello.hvt
            |      ___|
  __|  _ \  |  _ \ __ \
\__ \ (   | | (   |  ) |
____/\___/ _|\___/____/
Solo5: Bindings version v0.4.1-161-gcaa0b1f
[...]
$ mfttool/solo5-mfttool
usage: solo5-mfttool COMMAND ...
solo5-mfttool version v0.4.1-161-gcaa0b1f

COMMAND is:
[...]
$ head -1 tests/test_hello/manifest.c 
/* Generated by solo5-mfttool version v0.4.1-161-gcaa0b1f, do not edit */

Fixes #323. /cc @ananos @hannesm @ricarkol

[hannesm]

this is nice, one question I have: when there is a release of solo5, the release tarball should include a static include/solo5/solo5_version.h file with the version information, no (this could be achieved by documenting the release steps: (a) create a branch, (b) create that file solo5_version.h (and git add && git commit), (c) tag the release)? it'd imho be greatly appreciated to not depend on git for building solo5 releases.

[mato]

this is nice, one question I have: when there is a release of solo5, the release tarball should include a static include/solo5/solo5_version.h file with the version information, no (this could be achieved by documenting the release steps: (a) create a branch, (b) create that file solo5_version.h (and git add && git commit), (c) tag the release)? it'd imho be greatly appreciated to not depend on git for building solo5 releases.

Good point. I don't want to have generated files in git, even on branches, unless necessary. I'll see what I can come up with.

[hannesm]

@mato what I've seen elsewhere is to pass it around via the build system, i.e. make SOLO5_VERSION=0.42 in the opam file (or whereever else make is invoked) -- at some point I'd expect the solo5 tender to be an operating system (debian/FreeBSD/...) package, which would then need the version information to pass to make.

[mato]

@hannesm Okay, how about 00f2e08? It's a bit roundabout, but at the end of the day provides a make distrib, which magically does the right thing and a release tarball with a pre-generated solo5_version.h.distrib in it pops out. At build time, the script notices it's not in a Git tree and uses that file as its source of truth.

It may still need some tweaking, I'll get to that while making a release.

[hannesm]

@mato that looks fine to me (but now a release is slightly more involved than clicking on github's "draft a release" button -- which is imho fine, but I'd document the steps to make a release)

[mato]

@hannesm I agree that the release process needs documenting, and I'll do that around the time we actually cut the next release.

I've pushed a few more tweaks, cleaning up the release tarballs somewhat and also adding make distrib to CI. Will merge this now, it can be improved later.