z88dk: printed version information for zcc, sccz80, z80asm, appmake does not reflect source code version

[aralbrec]

The version information that these tools print with, eg, "zcc --version" are showing the build date and do not reflect the version of the software itself.

Some people are trying to use the printed version number to determine how up to date they are but this won't work.

We probably need some value that auto-increments with each commit (and perhaps includes a github hash so you could check out a zcc package at that number) so that people can accurately determine how up to date they are.

sdcc has something like this:

zsdcc -v
Build ... 9918

The 9918 is incremented each time there is a commit in their svn codebase.

[suborb]

We can get that info using git rev-list --count HEAD so I'll add that into the version - it already has the git hash

[aralbrec]

Is there any way to get git to create a file that contains count and hash on each commit so that there are no dependencies on git binaries? Or maybe fill in a field someplace each time a text file is checked out?

[suborb]

It might be possible with a commit hook. I'll investigate. In the mean time the revision count is now in the version string.

[aralbrec]

As always, the issue is windows. There's no guarantee any git tools are in the path (or even installed) so I can't see a way to compile in version information unless it's available through a commit hook or similar.

[suborb]

Well, the same goes for any os to be honest.

How do most windows users work? Download the nightly binaries or compile themselves?

I think VS2015 has git available, so adding similar magic into the pre-build step of the solution should also be viable.

[pauloscustodio]

I work on a windows cmd prompt with the cygwin tools in the path. It works for work on the assembler, but to build the whole tree I open a cygwin bash shell at the top of the directory and call ./build.sh

[pauloscustodio]

Implemented in z80asm by a Makefile hack (#259), see 4e78b06

[aralbrec]

I'm guessing most windows users are going to be win32. That's what I'm using so I build the binaries with VS2015. The newlib can also be built from win32 but the classic lib cannot. For the classic lib I have to use msys2; most windows users will not be able to build the classic lib. I think most windows users get the nightly build where everything has already been built.

If we can remove the requirement that git is present I think that's best. There are many ways to get a z88dk package that does not depend on git, including a zip package from github itself.

z80asm currently compiles as version 0 with vs2015.

[pauloscustodio]

The z80asm version defaults to zero if git is not present. The main objective is that the versions compiled in the nightly process have the correct version defined, so that users downloading the nightly build can report bugs with a version.

The build with VS2015 is good for development (code-compile-debug cycle) but does not make the whole build. For that we still need a POSIX environment; I use cygwin for that.

[aralbrec]

The only users that can get pre-built packages are win32 and mac osx. Everyone else has to build it and the source code can come from either the nightly build or github. If you use git to get z88dk, you definitely have git installed. However you can use the web interface to download a zip package too. So if you get the source code via nightly build or via github zip there is no git dependency. These people, when building, do not have to have git installed and will get a version 0 out of it. Granted linux users are more likely to have git installed but it's not a foregone conclusion. I think the ideal solution would be a commit hook that writes git count and hash into a file that can be picked up during compile.

[pauloscustodio]

Ok. I can change the version code in z80asm after that file exists.

[suborb]

I've tightened up the nightly so that the source package there will have a version.h in it and won't override when a make is called.

Thinking about it, you can't easily write a file during the commit that will contain the hash, because the act of writing that file will change the hash.

So that still leaves the GitHub zip download as the only one without a proper version, because of the above I don't think the commit hook will work for this use case.