Bindgen not behaving; cwd-dependent wrong output

(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/ --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 --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)?

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...

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.