You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now there are NClang.Natives/*.cs which are manual bindings for libclang C API. Since we have PInvokeGenerator it should be possible to completely generate these classes from C headers.
There is a work in progress branch generate-natives. So far it already builds, but causes run-time failures.
There is actually little benefit. The clang-c API is quite stable and does not break. There hasn't been a lot of additional API in clang-c. And automatic code generation results in silly hand-bound marshaling.
Is it still worth achieving this goal? Maybe. There should be some mapping support by external sources e.g. to determine which function parameters are mere pointers, arrays, or "out" or "ref" parameters, etc. And it will become a good dogfooding for that.
The text was updated successfully, but these errors were encountered:
split from #11.
Right now there are
NClang.Natives/*.cs
which are manual bindings for libclang C API. Since we have PInvokeGenerator it should be possible to completely generate these classes from C headers.There is a work in progress branch
generate-natives
. So far it already builds, but causes run-time failures.There is actually little benefit. The clang-c API is quite stable and does not break. There hasn't been a lot of additional API in clang-c. And automatic code generation results in silly hand-bound marshaling.
Is it still worth achieving this goal? Maybe. There should be some mapping support by external sources e.g. to determine which function parameters are mere pointers, arrays, or "out" or "ref" parameters, etc. And it will become a good dogfooding for that.
The text was updated successfully, but these errors were encountered: