platform-espressif32
platform-espressif32 copied to clipboard
Readout KConfig from ESP-IDF libraries added via lib_deps, too
See thread at https://community.platformio.org/t/how-to-add-kconfig-for-library/17856/.
When using a reference project like https://github.com/platformio/platform-espressif32/tree/develop/examples/espidf-aws-iot one can execute the Project Tasks -> Platform -> Menuconfig target and see the AWS-IoT component configuration options in the the "Component Config" configuration option.
When using a library from the PlatformIO registry like https://platformio.org/lib/show/10785/esp32-camera with lib_deps and which also has a Kconfig file, the configuration isn't picked up automatically. The project has an explicit paragraph (https://github.com/espressif/esp32-camera#platformio-kconfig) which states that the Kconfig of the library should be written to or appended to src/Kconfig of the project.
Can PlatformIO be extended to work better with the Kconfig files of ESP-IDF libraries added via lib_deps to pick this up automatically?
This is my current workaround. Just add the following to CMakeLists.txt
get_filename_component(configName "${CMAKE_BINARY_DIR}" NAME)
list(APPEND kconfigs "${CMAKE_SOURCE_DIR}/.pio/libdeps/${configName}/esp32-camera/Kconfig")
This is a pretty longstanding issue with Platformio and ESP-IDF, and it likely resulting in a pretty bad developer experience for anyone using PlatformIO for this purpose. I know that I was extremely confused when I installed a component via lib_deps, saw that the files were installed correctly, yet still couldn't build as the headers wouldn't resolve. Copying the component into components directory entirely is not a great solution, as the code isn't really an external dependency at that point, and can't be managed like a dependency. Adding the EXTRA_COMPONENT_DIRS workaround similarly isn't great, since it seems like something that could simply be integral to the PlatformIO integration rather than anything a developer should need to mess with. If ESP-IDF is supported, it should be supported all the way.
From my point of view, the whole issue is that ESP-IDF framework (CMake actually) is not hinted that the lib_deps components exist.
Making CMake aware is actually easy:
https://github.com/MiguelBarro/platform-espressif32/blob/932752a273187340edbbcd84726f0f6feb5d8b4a/builder/frameworks/espidf.py#L1344-L1348
but in order for it to work two preconditions are required:
idf_component_register()calls must require the dependent component. This is an ESP-IDF framework requirement that many platformio users overlook.- the actual dependent component must have a structure recognizable by the ESP-IDF framework. There are many repos around whose components are in subdirectories and would fail to be recognized by the framework. This is so true that the IDF Component Manager introduced a mechanism to identify the subdir where the component is located.
I think it is a tradeoff and the developers decided to sacrifice the KConfig integration for the sake of simplicity.
Right now, dependencies are not built using the ESP-IDF framework but directly using the built-in Scons one. Allowing the users to set up them via ESP-IDF framework would make no sense at all (those settings would be disregarded).
As a workaround I would suggest don't manage the dependencies from PlatformIO but use IDF Component Manager directly.