Auto Generated C Bindings

[lmariscal]

Hi, I was wondering your perspective on what would be the ideal c bindings.
Something that resembles cimgui, the main issue with cimgui is that it is not able to compile with a pure C compiler, making a DynamicLibrary a most to be able to link at runtime. I just want to know your thoughts and find a way to help with this task.

[ocornut]

Hello @cavariux,

I'm not a C user so I'm not sure I understand the constraint you mention with dynamic library being a must.

I think the cimgui base is fine + recent work on a generator e.g. #1782, but mostly this needs mostly to be streamlined, maintained and polished. Currently we often run into situation where people who are reliant on 2-levels of bindings (sometimes C++ > C > Some language) are forced to stay with old versions. As of today cimgui is on 1.53 only and Stephan appears to be busy to maintain it.

My vision is ideally we should have an official generator framework (in a format/language that most people can easily run). It would be able to emit the C bindings but also eventually be used to emit different bindings (e.g. people could just it to create the code/data required for other languages including custom languages). The code in #1782 is the closest we've got to that for C. It's not perfect, e.g. it doesn't emit a .h file that has the comments and formatting of the original imgui.h but can probably be a good base.

There's a similar situation with LUA bindings, there's at least two variants of generators with different features. The one in love-imgui had improvement pertaining to using multiple return values. And I hear users of LuaJIT + FFI may want a different solution that the raw LUA. Perhaps this could be handled by an officially maintained generator that could leverage the code/parsing used for a C generator?
https://github.com/patrickriordan/imgui_lua_bindings
https://github.com/slages/love-imgui/tree/master/

None of that is very hard problem to solve, but devil is in the details and most attempts are tackling the first 90% and never the remaining 90% because people are doing it for their own use. Perhaps having a clean, centralized solution for it would allow us to reach 100% and a situation where most bindings can be automated?

Omar

[jarikomppa]

I have similar thing built into SoLoud, where I've written a c++ header parser in c++ which spits out the structure which can then be used to generate other interfaces (like c, c#, python, etc). The gotcha there is that the header parser is not a generic one, but depends on the way I write the headers (so if you use a bunch of template stuff or even preparser things in a header, the parser wouldn't be able to figure it out). The different wrapper generators I have in SoLoud then use the target language features to create interfaces, so for python for example everything is wrapped inside a class again, whereas some other inetrfaces are closer to the raw 'c' api. Generation is, in my opinion, the way to go, but there are a lot of things that may break as things get developed further..

…

On Wed, Jun 13, 2018 at 9:55 PM omar ***@***.***> wrote: Hello @cavariux <https://github.com/cavariux>, I'm not a C user so I'm not sure I understand the constraint you mention with dynamic library being a must. I think the cimgui base is fine + recent work on a generator e.g. #1782 <#1782>, but mostly this needs mostly to be streamlined, maintained and polished. Currently we often run into situation where people who are reliant on 2-levels of bindings (sometimes C++ > C > Some language) are forced to stay with old versions. As of today cimgui is on 1.53 only and Stephan appears to be busy to maintain it. My vision is ideally we should have an official generator framework (in a format/language that most people can easily run). It would be able to emit the C bindings but also eventually be used to emit different bindings (e.g. people could just it to create the code/data required for other languages including custom languages). The code in #1782 <#1782> is the closest we've got to that for C. It's not perfect, e.g. it doesn't emit a .h file that has the comments and formatting of the original imgui.h but can probably be a good base. There's a similar situation with LUA bindings, there's at least two variants of generators with different features. The one in love-imgui had improvement pertaining to using multiple return values. And I hear users of LuaJIT + FFI may want a different solution that the raw LUA. Perhaps this could be handled by an officially maintained generator that could leverage the code/parsing used for a C generator? https://github.com/patrickriordan/imgui_lua_bindings https://github.com/slages/love-imgui/tree/master/ None of that is very hard problem to solve, but devil is in the details and most attempts are tackling the first 90% and never the remaining 90% because people are doing it for their own use. Perhaps having a clean, centralized solution for it would allow us to reach 100% and a situation where most bindings can be automated? Omar — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1879 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEQ_R9EHSZZYHWTe76LgNwU9PkiuOegeks5t8WALgaJpZM4Umpz5> .

[ocornut]

The gotcha there is that the header parser is not a generic one, but depends on the way I write the headers (so if you use a bunch of template stuff or even preparser things in a header, the parser wouldn't be able to figure it out).

Thanks Jari for this feedback (link https://github.com/jarikomppa/soloud/tree/master/scripts)
I think we'd be fine with that constraint too. It's much simpler to do a text-oriented parser with those constraints rather than an actual generic C++ parser.

[sonoro1234]

Correct me if I am wrong, but I thing it is imposible to do a C binding to be compiled with a pure C compiler because the imgui part will always be C++ and has to be compiled also.
What cimgui does is just export the C interface (with extern C and __declspec(dllexport)) from a C++ compilation.

My proposal for a generic generator would be to parse imgui.h as done in my generator but instead of just generating the C binding, save also the parsed data (function name, return value, arguments and default values, structure it belongs to ...) in a Lua file that can then be used to generate various bindings.

[jarikomppa]

Instead of Lua I suggest using something more general, like json. And yes, some kind of glue code may be needed to map c++ to c, see for example: https://github.com/jarikomppa/soloud/blob/master/src/c_api/soloud_c.cpp

…

On Fri, Jun 15, 2018 at 10:59 AM Victor Bombi ***@***.***> wrote: Correct me if I am wrong, but I thing it is imposible to do a C binding to be compiled with a pure C compiler because the imgui part will always be C++ and has to be compiled also. What cimgui does is just export the C interface (with extern C and __declspec(dllexport)) from a C++ compilation. My proposal for a generic generator would be to parse imgui.h as done in my generator but instead of just generating the C binding, save also the parsed data (function name, return value, arguments and default values, structure it belongs to ...) in a Lua file that can then be used to generate various bindings. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1879 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEQ_R6Uinw1QMzLNRgQMB2Un09nyv7mXks5t82lFgaJpZM4Umpz5> .

[dpethes]

Most of the pascal bindings was generated by scripts from heavily hand-edited source, which was a tedious step and it complicates updates a lot. If I could skip it, it would simplify things a lot.
I don't have a particular preference for format, if it can be easily dealt with.

As an example, Glad https://github.com/Dav1dde/glad generates opengl bindings from xml spec, maybe that can be an inspiration for the data structure (not format).

[sonoro1234]

@ocornut I am now working on preserve comments in .h file
@jarikomppa I dont know json and my Lua work is already done. I would provide an example of how to use it for generating lua bindings so that, I expect, it could be easy to adapt to other languages

[sonoro1234]

@ocornut https://github.com/sonoro1234/cimgui/blob/master_auto2/cimgui/cimgui.h
is the generated .h file with comments
Is that ok?

[ocornut]

Better. I'm not the user but I think various things could be improved:

• One-liner comments could be all aligned with each others. Various other alignments using spaces.
• Comments that are not on function lines are missing.
• Moving all typedefs at the top.
• Spacing between each structures.
• Member function in xxxx_xxxx formats could be changed to XxxxxXxxx to be consistent. They are only in this format when they are types matching std:: types.

Right now as is the file is quite unwelcoming to the user, we should aim toward something that looks very close to imgui.h.

[sonoro1234]

One-liner comments could be all aligned with each others. Various other alignments using spaces.

the problem is generated in gcc -E -C -DIMGUI_DISABLE_OBSOLETE_FUNCTIONS ../../imgui/imgui.h output, as the multiple spaces are trimmed to one space

solution would be to avoid gcc parsing phase and parse imgui.h directly, but this parsing expands macros and defines so it is not desirable.

[lmariscal]

@ocornut the script that generates the c header and data, would you like to to be in this repo or on an external repo?

[sonoro1234]

https://github.com/sonoro1234/cimgui/blob/master_auto2/cimgui/cimgui.h
now with typedefs at the begining and comments inside structs lie in a multiple of 10

[ocornut]

@cavariux If it's good enough and it's not much of a maintenance/responsibility for me I think it could be in the main repo. Otherwise we could also perfectly create an official secondary repo for this script + all the additional "per-language" scripts. The location doesn't matter so much as long as it feels officially supported.

[sonoro1234]

https://github.com/sonoro1234/cimgui/blob/master_auto2/cimgui/cimgui.h

now respects comments out code lines and also empty lines(for getting "Spacing between each structures")

I feel that respecting empty lines adds a lot of them that were generated in the gcc -E phase
What do you think about "respecting empty lines"?