This is a bit controversial, but in my opinion, just manually write bindings for the API surface you care about. There are tools to help automate the process ([c2nim](https://github.com/nim-lang/c2nim), [futhark](https://github.com/PMunch/futhark)), but these tools are mostly for C.
Theoretically if you want to import a large C++ API (e.g. if you were importing Google's C++ codebase*), you could do so with libclang. I was working on an alternative to c2nim that supported Objective-c and C++, which used libclang, but it's currently in my project graveyard. If you're expecting a @cImport from Zig, then the closest you have to that is tools mentioned above to help with the process.
* to be clear, I understand why Google does not want to use Nim instead of creating a new language (Carbon). i.e. readable code output, full control of the compiler and language design, etc.
The amount of manual work to write bindings is minimal, i.e. you can do so simply by declaring a prototype for a procedure and then appending `{.importcpp, header: "<path>".}`, the same for types. And then compile with `nim cpp`.
Compare the way you wrap libraries in Python, Nim requires so much less work - and yet the Python community wraps every C/C++ library you can think of. Again, in my opinion, if you really want a library: wrap it yourself (ideally the subset you need) or rewrite it in Nim.
Also, most of the libraries you have listed have bindings already:
Theoretically if you want to import a large C++ API (e.g. if you were importing Google's C++ codebase*), you could do so with libclang. I was working on an alternative to c2nim that supported Objective-c and C++, which used libclang, but it's currently in my project graveyard. If you're expecting a @cImport from Zig, then the closest you have to that is tools mentioned above to help with the process.
* to be clear, I understand why Google does not want to use Nim instead of creating a new language (Carbon). i.e. readable code output, full control of the compiler and language design, etc.
The amount of manual work to write bindings is minimal, i.e. you can do so simply by declaring a prototype for a procedure and then appending `{.importcpp, header: "<path>".}`, the same for types. And then compile with `nim cpp`.
Compare the way you wrap libraries in Python, Nim requires so much less work - and yet the Python community wraps every C/C++ library you can think of. Again, in my opinion, if you really want a library: wrap it yourself (ideally the subset you need) or rewrite it in Nim.
Also, most of the libraries you have listed have bindings already:
- Qt: https://github.com/jerous86/nimqt or [seaqt](https://forum.nim-lang.org/t/12709)
- ImGUI: https://github.com/nimgl/imgui
- SFML: https://github.com/oprypin/nim-csfml
- SDL: https://github.com/nim-lang/sdl2
- sokol: https://github.com/floooh/sokol-nim
If there's a popular enough C or C++ library, it's probably already wrapped, especially within the gamedev community.