Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • R rust-card10
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 6
    • Issues 6
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 2
    • Merge requests 2
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • External wiki
    • External wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Astro
  • rust-card10
  • Issues
  • #14
Closed
Open
Created Sep 10, 2019 by rnd@rndContributor

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.

Assignee
Assign to
Time tracking