Request for Tagged Releases

[WillisMedwell]

As a widely used product, eventually people will start using incompatible versions with outdated support etc. It would make sense to have releases tagged with versions e.g 0.0.1 so that projects can manage dependencies via version numbers from the releases tags.

For example, glm math You never have to worry about your project breaking because of its tagged releases.

pls

[floooh]

I'm aware of the problem, but don't have a good solution to the question of "what makes a new release", mainly because the sokol repository is a collection of libraries, each progressing at a different rate. E.g. sokol_app.h could have an important breaking change, but at the same time sokol_gfx.h would be unchanged. So for people who use sokol_gfx.h without sokol_app.h, a global major version bump for the whole repository would be misleading since sokol_gfx.h hasn't changed.

On the other hand, maintaining a separate version for each library is also awkward for git tags (you would have tags like sokol-gfx-v1.2.3 mixed with tags like sokol-app-v3.1.3).

I guess the most realistic option is to do the same as the STB headers: each header tracks its own version, with a local changelog embedded right in the header of what has changed between versions, but the repository isn't tagged (since people are supposed to copy the headers into their project anyway). For instance see:

https://github.com/nothings/stb/blob/master/stb_image.h

vs

https://github.com/nothings/stb/blob/master/stb_dxt.h

[WillisMedwell]

I suppose, but i think the majority* of consumers of the repo would be using a collection of the libraries so tracking a group wide collection where all libs are verified and not experimental is more "welcoming"

I don't think theres really any downside for having it tho coz you can do all those techniques on top of tags. And tags allow:

• signals to users when a noteworthy overall release with cool new features is around to update their headers
• It also provides the option for users to fallback to pervious versions they like more

[WillisMedwell]

Also will cmake support be a thing? Especially considering emscripten and all that

[WillisMedwell]

Also c++ bindings to allow for constexpr shader translation?

(I think c is getting more and more constexpr support as well, so will be applicable eventually)

[floooh]

Also c++ bindings to allow for constexpr shader translation?

Shouldn't it be possible already to do such a constexpr shader translation into an constexpr-populated sg_shader_desc struct and then pass this struct into sg_make_shader() as runtime code? sokol-shdc also needs to run fxc (later maybe dxc) and the Metal shader compiler as external tools in order to generate shader bytecode. I would be surprised if C++ compilers can run external command line tools from inside constexpr code.

But 'constexpr shader translation' sounds ambitious, you would need to run glsangvalidator, SPIRVTools, SPIRVCross and optionally Tint (all wildly complex C++ projects) as constexpr.

I think c is getting more and more constexpr support as well

C23 constexpr is only for expressions, not for running code. It would be interesting for Zig, but that also shouldn't need any special features in the Zig bindings.

I've been considering C++ bindings for a while, but mainly for adding builder-pattern code for the desc-struct initialization (since C++20's designated initialization is unfortunately quite useless for that).

[floooh]

Also will cmake support be a thing? Especially considering emscripten and all that

PS: Not having build system files in the sokol repo is a conscious decision, because there are so many options in the C/C++ world (and the best way to integrate the sokol headers into a project is still to just copy them into the project).

For an example of a standalone cross-platform cmake file, see https://github.com/floooh/pacman.c