Add version.h defining WASI_LIBC_VERSION

[abrown]

This change re-imagines wasi-sdk#487 entirely in wasi-libc. Instead of generating a version.h header late--in wasi-sdk--it is generated immediately when wasi-libc is built. This has the disadvantage that we don't know what wasi-sdk this will be used in... but almost: when releasing wasi-sdk, we should be tagging the wasi-libc repository. If we did that more faithfully (docs), this commit would generate:

// Generated by wasi-lib's `Makefile`.
#ifndef VERSION_H
#define VERSION_H
#define WASI_LIBC_VERSION "wasi-sdk-24"
#endif

Using the magic of git-describe, if someone is using wasi-libc directly, they may see a version like: wasi-sdk-22-19-g5d3c5e9-dirty. This should be read like: <wasi-sdk tag>-<# commits since tag>-<current commit>-<is the repository dirty?>.

[abrown]

CI error should be fixed in #535.

[yamt]

i wonder if the git requirement can make some people unhappy.
ie. you can't build from release tarballs like https://github.com/WebAssembly/wasi-libc/archive/refs/tags/wasi-sdk-22.tar.gz anymore.
i don't have a nice solution though.

[sbc100]

Won't this means that the version reported in the wasi-libc that is embedded in wasi-sdk is always at least one version behind because the building happens before the tagging? Or do we tag and then build (which also would seem odd)?

[sbc100]

i wonder if the git requirement can make some people unhappy. ie. you can't build from release tarballs like https://github.com/WebAssembly/wasi-libc/archive/refs/tags/wasi-sdk-22.tar.gz anymore. i don't have a nice solution though.

Normally with this kind of thing the release source archive would have version.h, and the git repository would have version.h.in. So only git developers would be regenerating version.h and there would be make dist process to go from a git checkout to a source archive.

Sadly in the age of github the automatic source snapshot is often used instead of the output of make dist so there is not (by default) as way to run this.

We could switch to a make dist approach instead of relying on github to automatically create snapshots of the git contents?

[abrown]

Won't this means that the version reported in the wasi-libc that is embedded in wasi-sdk is always at least one version behind because the building happens before the tagging? Or do we tag and then build (which also would seem odd)?

Yeah, that's a good point. I'm just exploring what might work with these PRs. Seems like we probably should do the replacement over in WebAssembly/wasi-sdk#487 but maybe wasi-libc could just contain a token value like #define WASI_LIBC_VERSION "dev".