windows build: re-stamp version.h when the version changes

The rule had version.h as an order-only prerequisite of its output
directory, and nothing else. Order-only means "make this first if it is
missing", so the file was written once and then never again: the
version is derived from `git describe`, not from a file, so no
timestamp on disk ever moves when it goes stale, and make had no reason
to look.

Every Windows binary after the first therefore carried whatever the
version had been the day the build directory was created. The one on
the test box reported 0.1.0-2-gba48db9 -- a commit that no longer
exists, since the rebase rewrote it -- while being built from a tree
six commits later. `--version` was not just stale, it was pointing at
history that had been thrown away, which is worse than saying nothing.

So FORCE, and write through a temp file that replaces the real one only
when the text differs -- the same shape the main Makefile already uses
for build/version.h, and for the same reason. `make` after a commit
rebuilds; `make` twice in a row still does nothing.

Makefile.macos does not generate a version.h of its own -- it takes the
main Makefile's -- so it never had this.

0 files changed, 0 insertions, 0 deletions