External component

[YOxan]

Hey, guys! Thanks for building such a great library! I just have a quick question - is there a way to use external (custom) ESP-IDF component in building this crate? Like importing with some env variable or anything else? For a moment I see that all of framework components and their headers are hardcoded in binding.h for bindgen and without modification of sources I won't be able to integrate smth. Thanks in advance!

[MabezDev]

AFAIK there is no way to do this yet. Perhaps adding an env variable, or something in the Cargo.toml to allow specifying more header files? Instead of hardcoded to binding.h.

An alternative option is to move your custom component into a -sys crate itself, and manage the bindings from your side. esp-idf-sys exports the esp-idf include paths so it should be pretty easy to build the two crates together.

[YOxan]

I've tried to go in an other way, just with creating a wrapper around this component based on esp-idf-sys repo. But in that case linker is going crazy and I should add component to both esp-idf repo and created in wrapper crate to fix that. Will try to go with "include paths" as you suggested, but it would be really helpful if sometime esp-idf-sys could support this case.

[N3xed]

There is currently no esp-idf-native way to do this, but you can do this with a sys-crate.

We actually propagate all esp-idf gcc include arguments here. They can then be retrieved in all dependent build scripts with:

embuild::build::CInclArgs::try_from_env("ESP_IDF")

With this and the compiler you can use embuild::cmake or the cc crate to compile your C library and embuild::bindgen to generate the Rust bindings.

The compiler path you can get using embuild::espidf::Installer::install(), which will give you the exported PATH (among other things) containing all the tools used (note: see this as an example). From the exported PATH the compiler binary can then be retrieved for example using the which crate.

[YOxan]

Awesome! Thanks for assistant, will try that