Reconsider `bindgen` as direct build dependency.
Current State
Currently bindgen
is a direct build dependency of card10-sys
as the build automatically generates bindings.rs
. This is easy to maintain but it might lead to some strange compilation errors.
Issue
The underlying problem is a quite old issue in cargo (https://github.com/rust-lang/cargo/issues/4866) which comes in many shapes but in the end results in a state where cargo combines all the expected features for any dependency or subdependency regardless of the category the crate was originally defined in.
In case of bindgen
the most obvious problem is that it indirectly enables the std
feature for failure
and therefore tries to inject backtrace
and backtrace-sys
into the dependency tree. Its also includes some other crates and their default features and all of them might or might not be no_std
compatible.
Any additional direct dependency, even if it has a no_std
compatible feature set, might come with an additional feature (most likely std
) which contains failure
or another crate which is part of the dependency tree of bindgen
.
I assume we did not encounter any issues until now because the lto
saved us again and removed all parts of the build dependency sub dependency tree from the the final compilation as we do not depend on them. This won't work anymore if they one of them is actually required.
Potential Solution
As bindings.rs
is direct related to the current version of the firmware in use it should be quite easy to remove it from the build script and just call it manually if the firmware is updated.
Maybe also add a note about it into README.md
and provide a update-bindings.sh
script.