search

esp-rs / esp-idf-sys

Bindings for ESP-IDF (Espressif's IoT Development Framework)
Apache License 2.0
237 stars 113 forks source link

Using custom components introduces a requirement of specifying all components #296

Open torkleyy opened 4 weeks ago

torkleyy commented 4 weeks ago

As documented here, extra components require inclusion into esp_idf_components, but if esp_idf_compoents is present it acts as a filter for all built components. Interestingly, this doesn't apply to remotely managed components.

Ideally, extra components specified in Cargo.toml should be included automatically.

Vollbrecht commented 4 weeks ago

Can you give concrete example, on how you structured your Cargo.toml and what component you were using one? A custom self-written component or one that you sourced yourself from the idf-component library?

Overall its a two step process, we need a) building the component in the first place and make it link into the esp-idf library. b) generating "bindings" to be included so they are available in rust through esp-idf-sys.

When you say extra components should be included automatically - what part do you want to be included automatically? For us the be able to build the component, we need a known format - that works with esp-idf and that we can than run through cmake.

torkleyy commented 3 weeks ago

Can you give concrete example, on how you structured your Cargo.toml and what component you were using one? A custom self-written component or one that you sourced yourself from the idf-component library?

A custom self-written one:

[[package.metadata.esp-idf-sys.extra_components]]
bindings_header = "extra/include/bindings.h"
component_dirs = ["extra"]

If I do just that, the "extra" component won't be built - I have to do this:

esp_idf_components = ["extra"]

Now it will build the "extra" component, but none of the other components 🙃 So I ended up having to do this:

esp_idf_components = [
    "xtensa", "esp_ringbuf", "efuse", "esp_mm", "driver", "esp_pm", "mbedtls", "esp_bootloader_format", "esp_app_format", "bootloader_support", "bootloader", "esptool_py", "partition_table", "esp_partition", "app_update", "spi_flash", "pthread", "esp_system", "esp_rom", "hal", "log", "heap", "soc", "esp_hw_support", "freertos", "newlib", "cxx", "esp_common", "esp_timer", "app_trace", "esp_event", "nvs_flash", "esp_phy", "vfs", "lwip", "esp_netif_stack", "esp_netif", "wpa_supplicant", "esp_coex", "esp_wifi", "bt", "unity", "cmock", "console", "http_parser", "esp-tls", "esp_adc", "esp_eth", "esp_gdbstub", "esp_hid", "tcp_transport", "esp_http_client", "esp_http_server", "esp_https_ota", "esp_https_server", "esp_psram", "esp_lcd", "protobuf-c", "protocomm", "esp_local_ctrl", "espcoredump", "wear_levelling", "sdmmc", "idf_test", "ieee802154", "json", "mqtt", "nvs_sec_provider", "openthread", "perfmon", "spiffs", "ulp", "usb", "wifi_provisioning", "espressif__mdns", "main", "extra"
]
Vollbrecht commented 3 weeks ago

And did you correctly include a CMakeLists file and configured it correctly inside your custom component?

torkleyy commented 3 weeks ago

Yes.

ivmarkov commented 2 days ago

@torkleyy using esp_idf_components has nothing to do with "extra" components. These are ALL esp-idf components, and unless you have a very specific use case, you should not touch it at all.

I would rather concentrate / dig into the direction of what is wrong with the actual, original "extra" components syntax that you tried to use and it did not work for you. There is something wrong there in how you specify it for sure. I know it works actually.

ivmarkov commented 2 days ago

In other words, inclusion of your extra components in the esp_idf_components list will happen automatically, you don't need to touch it / override it at all.

torkleyy commented 2 days ago

Okay, I can try and create a reproducible example.