Auto Generated C Bindings #1879
Comments
|
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? 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 |
|
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>
.
|
Thanks Jari for this feedback (link https://github.com/jarikomppa/soloud/tree/master/scripts) |
|
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. 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. |
|
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>
.
|
|
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. 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). |
|
@ocornut I am now working on preserve comments in .h file |
|
@ocornut https://github.com/sonoro1234/cimgui/blob/master_auto2/cimgui/cimgui.h |
|
Better. I'm not the user but I think various things could be improved:
Right now as is the file is quite unwelcoming to the user, we should aim toward something that looks very close to imgui.h. |
|
the problem is generated in 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. |
|
@ocornut the script that generates the c header and data, would you like to to be in this repo or on an external repo? |
|
https://github.com/sonoro1234/cimgui/blob/master_auto2/cimgui/cimgui.h |
|
@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. |
|
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 |
|
I think ideally we shouldn't have a "gcc -E phase", especially as this create an external dependency to run the script. |
|
Yes but it is a dependency that almost everybody has. |
|
I am surprised but it worked without gcc, perhaps because imgui.h is simple enough for that: all code between #if and #endif is droped except for two typedefs: ImDrawIdx and ImTextureID The only caveat is that all the stuff generated by gcc preprocessor wont be automatically adapted by generator.lua from imgui.h but needs to be hardcoded in generator.lua https://github.com/sonoro1234/cimgui/blob/master_auto2/cimgui/cimgui.h it works on imgui.dll compilation and in my lua binding generation please review |
|
Now I have updated not also cimgui (branch master_auto2) but also the automatic lua binding that can be used as a model for other bindings this is the cimgui auto2 repo this is the luajit-imgui repo to adapt to other bindings: comments are welcome |
|
@jarikomppa after some test lua table can be also saved in json format if this is better for anyone. |
|
I would make that json an option because it's usable from basically any
language with relative ease.
…On Sun, Jun 17, 2018 at 3:33 PM Victor Bombi ***@***.***> wrote:
@jarikomppa <https://github.com/jarikomppa> after some test lua table can
be also saved in json format if this is better for anyone.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1879 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEQ_R3HNglwbiaN6xRmJhz8-k0QFIryqks5t9kyVgaJpZM4Umpz5>
.
|
|
After making modifications mentioned in #1888 and #1887 I have used the gcc -E phase by the moment to avoid preprocesor complications Here cimgui |
|
I have added structs_and_enums.lua generation than althought is not necessary for LuaJIT ffi binding (which just use the C header) will be usefull for other bindings that need struct and enums information. Until #1888 is not solved example/implementations are temporally disabled. |
|
Implementations are enabled now and build samples provided in LuaJIT-ImGui. |
|
Json saving incorporated |
|
Some suggestions on the project setup:
|
|
All except: Need to see one example for that. As for the gcc, now it is used in generator_preprocess.bat which is more robust than without preprocess and could be reworked for using other compilers if someone helps with that |
|
You can just drag .gif/.png file anywhere in any issue (even here) to get the file hosted by github. No need to get big files in a GIT repo. You can create a wiki on your repo (Github has the option) and add the files there, the Wiki is just a separate GIT repo. I'll add a link to your repository if this isn't going to be merged in the existing known cimgui repository. Maybe see with extrawurst what plans you guys have. |
|
I have tried to put image in the wiki but it asks for a link (and they suggest link to the repository!!) I feel unsecure about generation without gcc because all I do is droping everything between #if.. and #endif The solution adopted is generate cimgui.cpp and cimgui.h without gcc but also generate cimgui_auto.cpp and cimgui_auto.h (which remain in generated folder) if gcc is available As for the gcc alternatives it seems that |
|
Another way could be to commit the generated code as part of the release process, then users will not need to use the generator scripts at all. |
|
Thanks, the CMakeLists file is very helpful. When I build the project in a 64-bit configuration, I get these warnings, which I'm not familiar with. I was also getting these same warnings with the project I manually created, but the one generated via CMake also has them. As far as I can tell, they have something to do with the constructor definition for ImVec2. When I call any of these functions, I get an access violation. Any idea what's causing that? |
|
After thinking about it, it occurs to me that the functions should return their result through a pointer, as "mainline" cimgui does:
If that is necessary, perhaps the json file can describe this transformation somehow. E.g. it could contain: Which would let the binding layers switch the parameter back to a return value. |
|
This is an important decission. |
|
I think it is reasonable to return those small structures as value, especially considering ImVec2, the most commonly used structure, is 8 bytes. It would be worth investigating the issue instead of writing back through the pointer argument. |
Is access violation happening when you use the ImVec2 returned value or just by calling igGetMousePos? Also: Did you compile the cimgui DLL and the DLL client with the same compiler? Also: Can you somehow check what ImGuiNative.igGetMousePos(); is returning? Also: Also: I am getting 8 as return (and 16 with ImVec4) Could you check that? |
|
I can have both functions as where nonUDT in ov_cimguiname tell us the situation. But I am still very interested about the questions above. Please answer as much as you are able to. |
The AV is happening inside
I'm loading cimgui.dll from C#.
I haven't tried it yet, but it's a good idea. I will try to do that tomorrow.
Yeah, that's a good catch. It doesn't make a difference here, unfortunately. It fails either way.
Nothing special is done for ImVec2/Vector2, since it's a simple blittable struct with an identical format on both sides.
The problem seems to be specific to return types. By the way, the warning is also generated for Interestingly, calling |
|
Does it happen with the /clr option of msvc compiler? Support for UDT returning functions is done!! (ImVec2, ImVec4, ImColor) |
|
I still get UDT warnings warnings when compiling the library? |
|
UDT warnings are expected (in MSVC) but not harmful. You can still try to use this functions, but with MSVC (is this your compiler?) use better the ones with name ended with _nonUDT. |
|
Exploring a bit more tonight. Like I mentioned earlier, I think these UDT warnings can be avoided if the return types are plain structs without any constructors/operators/functions/etc. For example, if I change struct ImVec2_Simple { float x; float y; };
CIMGUI_API ImVec2_Simple igGetMousePos()
{
ImVec2 pos = ImGui::GetMousePos();
ImVec2_Simple result;
result.x = pos.x;
result.y = pos.y;
return result;
}I'm able to build without any warnings, and I'm able to call this function successfully from C#. Not sure if there's some way we can easily accomplish this for all of the affected functions without generating a bunch of wrapper code like the above. Some way to conditionally define the structs so that they are POD types for the exported C functions? |
|
To the function_nonUDT already existent I have added function_nonUDT2 which returns simple types for ImVec2, ImVec4 and ImColor. In function definitions nonUDT field is 1 for _nonUDT (pointer in args) or 2 for _nonUDT2 returning UDT_Simple |
|
@pragmascript has pointed out that the Line 1005 in 781a795 |
They should be -1,0,1,2,3...? |
|
@sonoro1234 Yep, that's exactly it. Thanks for the quick fix! |
|
now moved to https://github.com/cimgui/cimgui |
|
Excellent! What is the state and it and usability for e.g. ImGui.Net? (PS: Small suggestion, don't store images in the git repo, instead you can upload to issue and link to those images, or upload on the wiki which itself is another git repo. Also updating that oooooold screenshot would be nice) |
|
@mellinoe should answer about usability in ImGui.Net Yes, you could link to cimgui/cimgui as it is the same as sonoro1234/cimgui now. I will take care of screenshot also ;-) |
|
I'm still working on polishing up the autogen branch of ImGui.NET, but as far as I can tell, the current state of cimgui is good for my purposes. My branch already includes function imports for everything that cimgui exports, but those are just the direct, unsafe functions. They aren't very convenient to use directly because they involve pointers, etc. I'm currently working on generating a safe wrapper layer with some convenience features (e.g. the ability to use a C# String and wrapping raw pointers in safe helper types). |
|
Closing this as this work by @sonoro1234 is now released and available at Various links updated to point to this repository. |
|
Sorry for bumping such an old issue, but the user-defined data types thing became an issue again for consumers via interop with the new docking branch now that ImGui has a bunch of callbacks for us to implement now. I dug into this more and found out exactly why it's an issue (on Windows, anyway.) Disclaimers up front:
I've also uploaded a repository with non-ImGui test code for .NET Core on both Windows and Linux.
This is actually the root of the issue. On x64 Windows, user-defined types are only returned by value in very specific circumstances, and ImGui is not meeting those circumstances. (The specific requirements are outlined here, TL;DR: Anything with constructors, etc are not returned via register.) On x64 Windows (and seemingly, x86 Windows), a function like this: ImVec2 GetWindowPos(ImGuiViewport* viewport)
{
printf("GetWindowPos(%d)\n", viewport->ID);
return ImVec2(1879.f, 3226.f);
}is effectively rewritten to look like this: ImVec2* GetWindowPos(ImVec2* ret, ImGuiViewport* viewport)
{
printf("GetWindowPos(%d)\n", viewport->ID);
*ret = ImVec2(1879.f, 3226.f);
return ret;
}So as an example in C# interop land, this is how you can install the using ImGuiNET;
using System;
using System.Collections.Generic;
using System.Numerics;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
public class ImGuiSupport
{
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
private unsafe delegate void* PlatformGetWindowPositionDelegate(out Vector2 vector, ImGuiViewportPtr viewport);
// Delegates must be cached to ensure they aren't garbage collected while ImGui holds a pointer to them.
private readonly List<Delegate> MarshaledDelegateCache = new List<Delegate>();
public ImGuiSupport()
{
PlatformGetWindowPositionDelegate platformGetWindowPosition = PlatformGetWindowPosition;
MarshaledDelegateCache.Add(platformGetWindowPosition);
ImGui.GetPlatformIO().Platform_GetWindowPos = Marshal.GetFunctionPointerForDelegate(platformGetWindowPosition);
}
private unsafe void* PlatformGetWindowPosition(out Vector2 ret, ImGuiViewportPtr viewport)
{
Console.WriteLine($"Getting window position for {(ulong)Unsafe.As<ImGuiViewportPtr, IntPtr>(ref viewport):X}");
ret = new Vector2(1879f, 3226f);
return Unsafe.AsPointer(ref ret);
}
} |
|
@ocornut Since the docking branch is still young, can we change the callbacks to return their I can make a PR if you're OK with the change. |
|
Another viable alternative would be to make the non-data members of |
|
@PathogenDavid There is quite a bit more discussion about the viewport branch's new "Platform" function pointers over in the cimgui repo: cimgui/cimgui#71 (comment). The solution to that ABI mismatch is a little bit onerous, but nothing about it should require platform-specific or compiler-specific code. It basically just involves creating a native "thunk" that shuffles around the parameter/return value from the user-provided callback. I've tested the EDIT: Somehow it slipped my mind that the "nonUDT2" overloads are already a part of cimgui for some time, and they have normal C-compatible return values like the suggestion above. Disregard this second part. |
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.
The text was updated successfully, but these errors were encountered: