Version flag

[danielchasehooper]

It would be useful if sokol-shdc had a --version/-v flag to print its version number and exit.

background:
I've integrated sokol-shdc into the build system for our project and it relies on the developer having sokol-shdc installed. I want the build script to check that it's at least some minimum version so that developers are building with the most recent version that we've tested with. For release builds we might even force it to be a specific version.

[floooh]

I need to think a bit about tracking a version number, I'm not opposed to it though.

[danielchasehooper]

The recent sokol-shdc update to stay in sync with the webGPU changes is a good example of why a version flag would be useful: we updated to the latest sokol_gfx, and now all previous versions of sokol-shdc cause builds to fail because they continue to output SG_SAMPLERTYPE_SAMPLE, which no longer exists. We are having to save the hash of each sokol-shdc (one for each os), and have the build system check the installed tool's hash against those known-supported hashes. If we didn't do that, developers would have the build fail, ask someone why it's not working, and be told to update sokol-shdc.

if you're opposed to manually maintaining a version number, any type of identifier would do: the commit id from which the binary was built, or a timestamp of the build time.

[danielchasehooper]

The lack of versions is getting increasingly annoying. It's hard to know what version of shdc you have, or what version of sokol_gfx.h you have, or if they are compatible with each other, or how to find one or the other that is compatible with what you already have.

In situations that you don't want to update your code to account for changes made in sokol_gfx.h, getting the most recent of both shdc and soko_gfx.h isn't doable.

[floooh]

Agreed. For sokol-shdc I have a fix in mind (basically adding a ./fips release or ./fips publish command which does similar things as release-it in the npm ecosystem (bump a version number in a local header file, which is also compiled into the exe, then create a git-tag which triggers a special deploy CI pipeline).

For the sokol headers I still don't have a good idea how to deal with what would need to be one version number per header.