Broken include when given imgui_internal.h

[Ldash4]

Hi,

I'm finally trying to get imgui_internal.h working for my Odin bindings. When running dear_bindings however, I get a malformed include. Here is a repro .sh:

#!/bin/bash

rm -rf dear_bindings imgui temp

git clone https://github.com/dearimgui/dear_bindings.git dear_bindings
git checkout -C dear_bindings 81c906b # latest commit at time of writing

git clone https://github.com/ocornut/imgui.git imgui
git checkout -C imgui v1.91.8-docking # latest tag at time of writing. But bug doesn't seem to depend on the imgui commit

mkdir -p temp
python "dear_bindings\dear_bindings.py" -o "temp\c_imgui" --include "imgui\imgui.h" "imgui\imgui_internal.h"

# See that `temp/c_imgui.cpp:20` is now `#include ".h"`

(ignore the mixed forwards and back slashes. This is apparently what running python through git bash wants)

I suspect that this has something to do with the folder layout of my bindings, which is a bit different to the example given in the README.

[Ldash4]

Found an additional maybe related bug. I'll create a separated issue if you'd like/it ends up being a different problem:

I was confused by the order of the given imgui.h file as well as the --include. Feels more like it is the imgui_internal.h file which is the "additional" include. So I tried reversing the order of the two includes. This caused a Python exception:

> python "dear_bindings\dear_bindings.py" -o "temp\c_imgui" --include "imgui\imgui_internal.h" "imgui\imgui.h"

  File "C:\Users\L4\Desktop\dear_bindings_repro\dear_bindings\dear_bindings.py", line 772, in <module>
    convert_header(
  File "C:\Users\L4\Desktop\dear_bindings_repro\dear_bindings\dear_bindings.py", line 263, in convert_header
    mod_calculate_enum_values.apply(dom_root)
  File "C:\Users\L4\Desktop\dear_bindings_repro\dear_bindings\src\modifiers\mod_calculate_enum_values.py", line 38, in apply
    raise Exception("Enum " + enum.name + " element " + enum_element.name + " references " +
Exception: Enum ImGuiDataTypePrivate_ element ImGuiDataType_Pointer references ImGuiDataType_COUNT in expression ImGuiDataType_COUNT+1, which is not a known enum value

[ShironekoBen]

Hi,
Thanks for the report!

And, sorry, that's the consequence of a rather-badly-thought-out design decision on my part.
The code currently assumes that if you are converting imgui_internal.h then the output filename will be the same as your normal imgui.h output name but with _internal on it, and thus that it can just strip the _internal part to get the path to the regular imgui.h file. So in this instance because the output file name is c_imgui that results in a blank filename. If you change that to c_imgui_internal then you should get a file that references c_imgui.h and c_imgui_internal.h correctly and everything should work.

Also just to note in case - unlike (IIRC) cimgui, Dear Bindings converts imgui.h and imgui_internal.h as separate headers, so you'll need to run two conversion steps (one for each) to get a full set of bindings for both.

But, yeah, that's a bit of an unusual assumption to be making, and doubly so as it isn't really documented anywhere! I'll have a look at at least adding some notes and maybe thinking of a better way to handle the file specification.

As for your second point, from Dear Binding's perspective I think imgui.h being the "include" is correct - basically what that's saying is that you want to convert imgui_internal.h, but in order to do that Dear Bindings will need to know about the contents of imgui.h first, hence treating it as a "pseudo-include". In an ideal world it would pick that up from the #include directives in the file it was processing, but in practice that's a little fiddly as it's hard to know what is relevant there and what is going to just give the parser a headache, so for the moment it is manual!

Sorry again about the confusion - hopefully that should fix things but if not let me know and I'll take another look at it!

[Ldash4]

Right, that explains things. So to be clear - I should be calling dear_bindings twice? This seems to make sense, except for that this ends up giving me redundant json files for imconfig and imgui "from the perspective" of imgui_internal. Am I meant to just ignore those?

[ShironekoBen]

Yep, you should be calling dear_bindings twice. You can use --emit-combined-json-metadata to emit a single combined metadata file for the current target file instead of one per header, although then you'll have duplicate information inside those files as the imgui_internal.json file will contain all the type information for imgui.h etc (as the idea is that the JSON should be self-contained in that situation and include everything you need to comprehend the types).

Normally though I'd imagine you should be able to omit that flag and just either ignore the redundant files or put them all in one directory and let them overwrite each other (as the contents should be identical).