You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi all. I'm working on an issue with ffmpeg-next and ffmpeg-sys-next, which are rust bindings to ffmpeg. I'm seeing build errors for former crate on macos stemming from missing constants in the generated bindings. Curiously, linux does not seem to have this issue. I whittled down a smaller test case I believe represents the problem, however, both Linux and macos bindgen invocations are now producing the same results. I'm a bit at loss, can anyone advise if the behavior I'm seeing from bindgen makes sense?
Curiously, linux does not seem to have this issue.
I am able to reproduce the issue both on macOS and on FreeBSD (I have no Linux hosts immediately available). If you can give evidence of platform-dependency, that would be interesting.
I think this is another case like #316 or #753. The desired AV_CH_FRONT_LEFT constant appears, if the definition is changed to avoid the reference to the AV_CHAN_FRONT_LEFT:
It would not be terribly surprising if bindgen cannot interpolate enums into macros, since bindgen would have to provide the enum values somehow to rust-cexpr's macro evaluation. If you want to look at something concrete, you might be able to estimate how feasible it would be for that to be done.
I do not have a concrete recommendation for you, besides manually coding the constant in your code; maybe @emilio would have one.
kulp
changed the title
Macro not generated
Macro constant referencing an enumerator does not generate a Rust constant
Jun 4, 2022
Hi all. I'm working on an issue with ffmpeg-next and ffmpeg-sys-next, which are rust bindings to ffmpeg. I'm seeing build errors for former crate on macos stemming from missing constants in the generated bindings. Curiously, linux does not seem to have this issue. I whittled down a smaller test case I believe represents the problem, however, both Linux and macos bindgen invocations are now producing the same results. I'm a bit at loss, can anyone advise if the behavior I'm seeing from bindgen makes sense?
Input C/C++ Header
Bindgen Invocation
Actual Results
Expected Results
I'd expect to see a constant for AV_CH_FRONT_LEFT.
The text was updated successfully, but these errors were encountered: