Hi aknabi,
I'm sorry you've had such a frustrating experience with ESP-IDF so far. I'm hoping we can help resolve some of these problems.
projects more than a few weeks old run the risk of not building anymore... tools just don't work... a project that builds fine on the latest with VS-Code doesn't build with idf.py... on and on... I've done 5 serious projects on the ESP32 and in each case about 90% of the effort is trying to figure out how esp-idf has changed or screwed up or is buggy...
Do you mean things break when you update ESP-IDF, or are you finding code in your project breaks without updating ESP-IDF? For low risk updates of ESP-IDF, we recommend working with
stable releases instead of the ESP-IDF master branch. We try very hard not to break compatibility between releases (following Semantic Versioning, and if there are unavoidable breaking changes we note them in the release notes). We try also not to break things on master branch, but there are occasional regressions. There is a trade-off between updating fast (bleeding edge, master branch) and updating slow (stable releases). The link to the docs above has some more info about it.
If you find something breaks on ESP-IDF master branch and it looks like a breaking change in ESP-IDF, please open a GitHub issue to let us know about it.
Examples... I have perfectly valid code that compiles and runs great on PlatformIO... but for CI need esp-idf...
I took a quick look at what I'm guessing is the project you're referring to (looks like a really neat project, BTW!) The
build is failing here with:
Code: Select all
CMake Error at /opt/esp/idf/tools/cmake/component.cmake:305 (message):
Include directory '/github/workspace/components/wifi/include' is not a
directory.
The project has a "wifi" component that tells the build system to add an "include" directory, but the "include" directory is not in the repo so it's not found when CMake goes to build it in CI:
https://github.com/aknabi/smalltalkje/b ... sts.txt#L5
I'm guessing this directory exists on your local computer, which is why the build is happy there.
One way to fix this is to remove the "placeholder" CMakeLists.txt file from this otherwise empty component, and re-add it when adding this functionality back.
same code barfs on some structs and need to use useless indirection and refactored with complexity and potential defects to make esp-idf happy... don't even get me started on app_main not found.
I'm not sure what this is, but I'd like to help you fix it - and to also fix any regression in ESP-IDF if that's what has caused it. If you want to start another thread with more details, then very happy to take a look.
EDIT: One thing that may be relevant, it seems like platform.io encourages using SRC_DIRS in ESP-IDF CMakeLists.txt files. This is discouraged in ESP-IDF (because it's also discouraged in CMake itself), in
favour of listing the source file names with SRCS. The ESP-IDF examples and internal components use SRCS not SRC_DIRS for this reason. Using SRC_DIRS, you may find that new source files in the project aren't immediately built by ESP-IDF unless you force a clean build (possibly platform.io has added a workaround for this, I don't know.)
- I remember deving some stuff with IDF back in v3.1 with Eclipse. Now on VSCode I can not imagine ever going back.