Reconsider `bindgen` as direct build dependency. (#14) · Issues · Astro / rust-card10

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.

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

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.