Get cimgui_internal.h to a compileable state

[ZimM-LostPolygon]

Note: this branch is based on https://github.com/dearimgui/dear_bindings/pull/46

This gets the generator to the point where imgui_internal.h can be successfully parsed and the corresponding C bindings are generated and are able to be compiled.

This is highly experimental - the only benchmark so far is that example_null.c is able to compile and use a function from imgui_internal.h.

Some notes:

• I'm not sure what the original idea was, but the way I've made it work, is first generate cimgui.h, then generate cimgui_internal.h while referencing the imgui.h using --config-include.
• With that in mind, --config-include was made appendable, meaning it can be specified multiple times.

Few things that might need to be improved/fixed:

• [ ] ImGuiContext is special-treated as an opaque pointer, with all the struct innards removed. This is because it includes a field of type ImGuiInputTextState, which includes a field of type ImStb::STB_TexteditState, and I'm not sure how to really handle that at the moment. Do we also parse imstb_textedit.h? cimgui seems to be doing that, at least.
• [ ] The resulting JSON output basically combines stuff from cimgui.h and cimgui_internal.h. For me personally, that's nice, but perhaps there's a use-case for internal-only metadata?
• [ ] Should literally everything under cimgui_internal.h be marked is_internal in JSON metadata? Or perhaps the source file is enough to infer that a thing is coming from imgui_internal.h?
• [ ] There's quite a bit of special-case fudging going on based on checking if imgui_internal.h is the main file, which would probably break other generated headers otherwise. Can it be done without checking the file name?
• [ ] Backend headers generation was not tested yet, at all.

At this point, I'll try to use this branch with the new C# wrapper I'm developing, and as I'm bound to find bugs, there will probably be some fixes.

[ocornut]

Really great to make progress on that! I’ll let Ben see how it aligns with his intended design, but some real quick thoughts:

, which includes a field of type ImStb::STB_TexteditState, and I'm not sure how to really handle that at the moment

Would there is a way to get the sizeof() of that structure and temporarily replace it by an opaque buffer, so the outer struct can work?

the resulting JSON output basically combines stuff from cimgui.h and cimgui_internal.h. For me personally, that's nice, but perhaps there's a use-case for internal-only metadata? Should literally everything under cimgui_internal.h be marked is_internal in JSON metadata? Or perhaps the source file is enough to infer that a thing is coming from imgui_internal.h?

My thoughts was that ideally we should generate cimgui.h, cimgui.json and cimgui.json, cimgui_internal.json as separate files. At minimum the .h file should be separate.

[ZimM-LostPolygon]

Would there is a way to get the sizeof() of that structure and temporarily replace it by an opaque buffer, so the outer struct can work?

Not one I can think of, since it's platform dependent, possibly compiler dependent etc. Maybe we can somehow query the compiler for that information, but still, hardcoding it sounds bad.

Another idea I had is basically injects those few STB types into the header, replace the original type reference in ImGuiContext with a reference to a copy, and then it should Just Work ™. Still quite dirty though.

My thoughts was that ideally we should generate cimgui.h, cimgui.json and cimgui.json, cimgui_internal.json as separate files. At minimum the .h file should be separate.

The .h file is fully separate, it's just the cimgui_internal.json that ends up combined at the moment. The simplest way to change this seems to be just filtering elements out based on their source file, but at that point, that can just as easily be done by whatever code is parsing JSON? For my C# wrapper, combined metadata makes perfect sense, since otherwise I'd have to do the combining anyway on my own, to be able to make a graph of all the references and dependencies.

[ShironekoBen]

On the subject of the JSON file, I can see arguments for both combined JSON (you have a self-contained "thing" to parse that contains every definition you need) and separate JSON (more readable, easier to handle if you are emitting imgui.h and imgui_internal.h as separate modules on your own backend)... since the filtering is relatively simple, maybe we should just add a --emit-all-dependencies-in-json switch or something to choose?