SDL3 Feature Requests: XML-Based API Specification and Automated C++ Bindings Generation

SDL Development
1

I’ve been using the beta version of SDL3 in a recent project. It’s really great. Here are my feature requests:

  • Specify the C API in an XML document (see Vulkans vk.xml) and generate the C headers from the XML document.

  • Write a python script that uses the XML document to generate a C++ binding for the C API (see vulkan.hpp and friends)

  • Write a python script that generates a C++ module for the C++ bindings (see vulkan.cppm)

If you are interested in this feel free to give me a shout on andrewtomazos@gmail.com and I can lend you a hand.

2

Do you mean something like gir in glib and gtk?

3

Yes, it’s quite similar in spirit to GIR (GObject Introspection) from the GLib/GTK world—both involve generating a machine-readable description of a C library’s API to help produce bindings in other languages. However, SDL’s needs are simpler compared to a GObject-based library, because:

  1. No GObject Overhead: GIR is deeply tied to GLib’s object system (classes, signals, properties). SDL, by contrast, is a straightforward C library without that layer, so it wouldn’t need all of GIR’s features.

  2. C-Focused API: SDL’s API is mostly “plain C”—structs, functions, pointers—so an XML (or similar) spec would only need to capture function signatures, enums, and basic types, not an object-oriented hierarchy.

  3. Cross-Language Flexibility: While GIR is tailored heavily for languages that integrate well with GObject (like Python, JavaScript, etc.), an SDL-specific approach could be more flexible for lower-level or systems-focused languages (like C#, Zig, Rust, D, etc.).

In short, the concept is indeed the same—having a single authoritative source of metadata for the API so that language bindings and docs can be generated automatically. It’s basically a “GIR-lite” model, adapted to SDL’s lightweight C interface rather than GObject’s more complex ecosystem.