nimporter VS ClangSharp

Nimporter

Erg looks fun for small programs. Though Erg's syntax choices seem less Pythonic than I'd expected. Interesting though, some of the idioms seem handy.

Though Nim definitely can be described as a statically typed Python-compatible language! I haven't used them but https://github.com/Pebaz/nimporter https://github.com/yglukhov/nimpy both seem great. Nimporter in particular looks fantastic for writing fast python libraries.

Actually come to think of it that might be the easiest way to write fast KiCad 6 plugins.. I really want to try making a native KiCad autorouter. But I don't want to figure out the C++ plugin setup and since KiCad 6 the Python APIs seem better documented and supported anyways. Problem is that Python would likely be too slow. Nimporter could be perfect. It looks really simple to setup.

nimpy + nimporter is getting fairly mature. I've had my eye on the libraries for awhile now and I'm starting to seriously consider adding Nim to the build pipeline at werk.

c2nim is a tool to translate ANSI C code to Nim. The output is human-readable Nim code that is meant to be tweaked by hand after the translation process. If you are tired of wrapping C library, you can try futhark which supports "simply import C header files directly into Nim". Similar to futhark, cinterop allows one to interop with C/C++ code without having to create wrappers. nimLUA is a glue code generator to bind Nim and Lua together using Nim's powerful macro. nimpy and nimporter is a bridge between Nim and Python. rnim is a bridge between R and Nim. nimjl is a bridge between Nim and Julia! Last but not least, genny generates a shared library and bindings for many languages such as Python, Node.js, C.

For the specific case of Python executing Nim code you might be interested in [nimporter](https://github.com/Pebaz/nimporter) instead. Genny would definitely work for you as well, but it seems to be more geared towards creating libraries in Nim that can be imported by multiple languages.

One of the most surprising things I learned about "clang" was how relatively poor the "libClang" capabilities are.

I wanted to write a codegen tool that would auto-generate bindings for C++ code, and it turns out that "libTooling" is the only reasonable way to get access to the proper info you need from C++.

Another alternative is "libClangSharp", from Tanner Gooding who works on C# at Microsoft.

https://github.com/dotnet/ClangSharp

Bindings for C++ are tricky due to function name mangling and also due to ABI compat, it's basically impossible to interop with a std::vector for example. Afaik the most common approach is to PInvoke thin C wrappers around the C++ functions. There are tons of binding generators for this but they aren't without problems (not worth if you have a small API surface).

3: Throwing my work away and using ClangSharpto create the bindings, unfortunately the header file for the shared library lists other C library's that I can not find online such as > #include

I've found this to be true, with the exception that a few people have taken to "augmenting" libclang with extra bindings to libTooling functions or other C++-only methods.

Most notably is Tanner Gooding & Co's "libClangSharp" from the Microsoft "ClangSharp" project, and PathogenDavid's "Biohazrd" libraries (which again are a sort of enhanced fork based on ClangSharp):

  https://github.com/microsoft/ClangSharp  # See "/sources/libClangSharp"

If you want to go down that route, clangsharp can do this for you.