Bindgen not behaving; cwd-dependent wrong output

help
1

(Reported on the issue tracker, but I'm also looking for any way to coerce bindgen into doing the right thing.)

I have a very weird situation in this repository where if I run

/crates/fmod-studio-sys>     bindgen inc/fmod_studio.h -o inc/bindings.rs --no-prepend-enum-name \
    --blocklist-file inc/fmod.h \
    --blocklist-file inc/fmod_codec.h \
    --blocklist-file inc/fmod_common.h \
    --blocklist-file inc/fmod_dsp.h \
    --blocklist-file inc/fmod_dsp_effects.h \
    --blocklist-file inc/fmod_errors.h \
    --blocklist-file inc/fmod_output.h

then bindgen outputs code for an old rust-target (e.g. __BindgenUnionField and not union), and if I run

/crates/fmod-studio-sys/inc> bindgen     fmod_studio.h -o     bindings.rs --no-prepend-enum-name \
    --blocklist-file     fmod.h \
    --blocklist-file     fmod_codec.h \
    --blocklist-file     fmod_common.h \
    --blocklist-file     fmod_dsp.h \
    --blocklist-file     fmod_dsp_effects.h \
    --blocklist-file     fmod_errors.h \
    --blocklist-file     fmod_output.h

(i.e. what should be the same command in a different cwd), bindgen outputs code for the current rust-target (i.e. using union) but doesn't blocklist items from the blocklisted files.

Am I doing something wrong / understanding bindgen wrong, or is this just busted behavior? Does anyone have suggestions on how to get the desirable behavior out of bindgen (that is, use current rust-target idioms and block the items from the blocklisted files)?

2

Manually applying the blocklist turned out to be fairly trivial (as it is a prefix of the post-#include-expanded headers, and provided separately), so the immediate need is solved by doing that. I still want to fix bindgen, though, so I can update the headers in the future without having to do the blocklist manually again...

3

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.