sokol-zig

I can show more code examples instead: E.g. notice how here in Rust each nested struct needs a type annotation, even though the compiler could trivially infer the type. Rust also cannot initialize arrays with random access directly, it needs to go through an expression block. Finally Rust requires `..Default::default()`: https://github.com/floooh/sokol-rust/blob/f824cd740d2ac96691... Zig has most of the same issues as Rust, but at least the compiler is able to infer the nested struct types via `.{ }`: https://github.com/floooh/sokol-zig/blob/17beeab59a64b12c307... I don't have C++ code around, but compared to C99 it has the following restrictions: - designators must appear in order (a no-go for any non-trivial struct) - cannot chain designators (e.g. `.a.b.c = 123`) - doesn't have the random array access syntax via `[index]` > ...like a p

When initializing a struct, Zig currently doesn't allow chained designators and also doesn't allow to partially initialize arrays and have the rest of the array filled up with default values (the first one isn't all that important, but the second is). E.g. the closest Zig equivalent to this C99 code: https://github.com/floooh/sokol-samples/blob/b3bc55c4411fa03... ...is this: https://github.com/floooh/sokol-zig/blob/a4b3c287fadd153a504... ...note how part of the initialization had to be moved out into separate assignments, which means the struct can't be created as const. There's a ticket about this here, but it's currently not high-priority: https://github.com/ziglang/zig/issues/6068 Zig also isn't alone in this, I haven't encountered any other programming language yet which has such a flexible struct initialization syntax as C99. Odin is

I maintain auto-generated bindings for my C libraries for Zig and Nim (and Odin and Rust - although the Rust bindings definitely need some love to make them a lot more idiomatic). I think looking at the examples (which is essentially the same code in different languages) gives you a high level idea, but they only scratch the surface when it comes to language features (for instance the Zig examples don't use any comptime features): Zig: https://github.com/floooh/sokol-zig/tree/master/src/examples Nim: https://github.com/floooh/sokol-nim/tree/master/examples Odin: https://github.com/floooh/sokol-odin/tree/main/examples Rust: https://github.com/floooh/sokol-rust/tree/main/examples

At least SDL2 has 'proper' Emscripten support: https://wiki.libsdl.org/SDL2/README/emscripten My own cross-platform headers too: https://github.com/floooh/sokol ...there are also auto-generated Zig bindings btw ;) https://github.com/floooh/sokol-zig

IME you really need a programming language to describe a build, even when it is desired that the result looks 'mostly declarative' in the end. E.g. not sure how Meson handles this, but when I have a project with dozens of similar build targets and platform specific compile options, I really want to do the build description in a loop instead of a data tree. (for example: https://github.com/floooh/sokol-zig/blob/3f978e58712f9eb029b...) PS: apparently Meson build scripts can also have variables, conditions and loops, which I guess makes the difference to an actually Turing complete build system rather esoterical? https://mesonbuild.com/Syntax.html#logical-operations A proper build system is so much more than just describing build targets and their dependencies, you also want to generate source code, copy and process data files, communicate w

> they're nontrivial to bind to from non-C languages This particular library doesn't seem to follow the STB convention where the implementation is inside an #ifdef IMPLEMENTATION block, but that would be trivial to fix. Once you have that it's just as trivial to use from other languages as a regular .h/.c library, just include the implementation into a C source file and compile that into a static link library or DLL, then include the declarations (without IMPLEMENTATION define) into your language (if the language can directly include C headers) or use the header to auto-generate the bindings. For example: - https://github.com/floooh/sokol-zig - https://github.com/floooh/sokol-nim - https://github.com/floooh/sokol-odin These are all auto-generated from STB-style single-file libraries: https://github.com/floooh/sokol

For a somewhat more complete example which runs in browsers, check out my little pacman.zig toy project [0]. This is cheating a bit by using the Emscripten SDK as 'sysroot' (needed for the Emscripten headers to provide the glue to web APIs), and the Emscripten linker to create the additional html and js output file, but the actual code is all compiled with the Zig compiler to WASM, emcc is only used for linking. The interesting part is that the platform abstraction is provided by the sokol C headers [1], with auto-generated Zig bindings [2]. It's interesting because the C headers use "Emscripten magic" (mainly embedding Javascript snippets in the C sources via the EM_JS() macro), and the Zig compiler is able to compile this (when it has access to the Emscripten headers). It would be nice if the "Emscripten platform" could get the same typ

(disclaimer: shameless plug) Here's another cross-platform alternative, auto-generated Zig bindings to the Sokol headers: https://github.com/floooh/sokol-zig This is quite a bit slimmer than using one of the WebGPU libraries like wgpu-rs or Dawn, because sokol-gfx doesn't need an integrated shader cross-compiler (instead translation from a common shader source to the backend-specific shader formats happens offline). Eventually I'd also like to support the Android, iOS and WASM backends from Zig (currently this only works from C/C++, for instance here are the samples compiled to WASM: https://floooh.github.io/sokol-html5/) And finally, I'd also like to become completely independent from system SDKs for easier cross-compilation, but with a different approach: by automatically extracting and directly including only the required declarations

Not quite as "radical", but I did something in that direction, a minimal "starter kit" for developing Dear ImGui applications in C99: https://github.com/floooh/cimgui-sokol-starterkit It needs the system's "default compiler toolchain" and cmake, but other then that, there are no external dependencies, and I tried to keep everything as simple as possible (even the CMakeLists.txt file). All the dependencies (Dear ImGui, cimgui and the Sokol headers for cross-platform wrapping of the platform-specific window systems and 3D-APIs) are bundled right in the git repo. Zig and Nim are sort-of "in progress" (for instance, see the sokol-zig bindings here: https://github.com/floooh/sokol-zig/)

I'm tackling this issue from two sides: (1) Change the C-API to make it more "binding-generator-friendly", for instance by adding a range/slice-struct to th C-API which bundles a pointer and associated size, or specially named typedefs that only exist to give the binding generator hints for special case handling. By adding a C-type which represents a range/slice, it's easier to connect high level languages to the C API, and as a nice side effect, the C-API also becomes safer and more "correct", because pointers and associated sizes can be passed around as one item. (2) Make the bindings-generator configurable on a per-language and per-API basis, this can be as simple as a map which overrides type- and function-names, or injects manually written code into the generated bindings. The goal is to make the generated bindings more idiomatic to

If you do, definitely ping flohofwoe, who a) maintains a Zig port of his lightweight Sokol graphics API and b) has a penchant for retro consoles. https://github.com/floooh/sokol-zig