Each Rust file generated by bindgen starts with:
/* automatically generated by rust-bindgen */
I would find it helpful if that was changed into
/* automatically generated by rust-bindgen 0.54.0 */
Or whatever the currently used version happens to be.
Currently I always solve this myself by having the following in all my generate_bindings.sh scripts:
#!/usr/bin/env bash
BINDGEN_VERSION="$(bindgen --version)"
...
bindgen ... --raw-line "// Generated using $BINDGEN_VERSION" \
When coming back to a library you created a while back and you want to re-generate the headers for some reason. Maybe because the underlying C library changed or because you need to expose more/less types or whatever. Then it can help to know what version of bindgen was used last time. For example if you get inconsistent results or have other trouble, having this piece of information available can help track down the problem.
The zeroth-order approximation is probably just to insert env!(CARGO_PKG_VERSION) into https://github.com/rust-lang/rust-bindgen/blob/d2e0407563156ed6c2449474c6f8a35389e7171e/src/lib.rs#L2164
but then one would have to figure out how to make the dozens of expectations tests work ...
https://github.com/rust-lang/rust-bindgen/blob/d2e0407563156ed6c2449474c6f8a35389e7171e/tests/expectations/tests/i128.rs#L1
It feels like there should be a single test that tests if the comment generation works. No other test should care about the comment. But that's of course more idealistic than practical.
Yeah, adding either:
Should be relatively straight forward. Keeping the tests doing what they're doing now seems easy with any of those two.
@emilio, I agree. I will look into adding an option in the coming week.
- An opt-in flag to include the version, or to override the current string.
- An opt-out flag to not include the autogenerated warning.
I tried to implement option 1 first, but ran out of patience with clap and was not sure what the API should look like. I have drafted option 2 in #1814.
I recognize now that I did not actually implement option 2, but rather some third thing that restores the original behavior rather than suppressing the comment entirely.
I think @emilio's original option 2 is probably better than what I did, so I will change my implementation soon.
I do not know what Emilio meant by "warning", what part of this is a warning? Is this entire comment the warning?
I don't see any reason to want exactly /* automatically generated by rust-bindgen */ at the start of the file. For any use case I can imagine you can have the comment with the version or no comment at all.
The tests would probably be better off with no comment at all. That means that this same string does not have to be repeated at all in every test. The tests become more focused on testing the actual code generation.
The tests would probably be better off with no comment at all. That means that this same string does not have to be repeated at all in every test. The tests become more focused on testing the actual code generation.
@faern, I am pretty sure @emilio meant to say "comment" instead of "warning", which suggests that he agrees with you. I agree with you too -- I just implemented something else by mistake before I caught myself. As I said, I will change it soon, to what you and @emilio are both describing.