- This topic has 1 reply, 2 voices, and was last updated 5 months ago by
.
-
Posts
-
Hello,
I have installed/updated the toolchain version to the 5.1 release of esp-idf. I was able to succesfully compile an example project. I have also installed an older toolchain side-by-side for support of our older projects,
In trying conversion an old project to the new release, i get the warnings of missing rules in the CMakeLists.txt of one of our components. this component includes an idf library component. as you can see in the screenshot, the suggestion gives a relative path into the standard component library folder for esp-idf 5.1 .
We have had this cropping up in other older projects as well and I blame it on our general misunderstanding of the CMake tool and component system of esp. However we worked around this, i fear this is our development environmnents not in a sane state
My coworker has this toolchain on a different path so this can already be problematic. Can you help describe the problem and where to look for solving this better?
Hi,
This is to be expected. Different ESP-IDF versions are not 100% backwards-compatible, so the project may need some adjustment. If deleting the temporary subdirectories (build and .visualgdb) doesn’t resolve the problem, the project probably uses some settings that changed between the ESP-IDF releases.
VisualGDB cannot perform this kind of troubleshooting fully automatically. All it does in this case is notices that some header files referenced by sources are not present anywhere in the search path, and tries to automatically locate them and suggest the missing directories. This feature was designed to simplify importing of external projects (see this tutorial) and we do not recommend using it in this case. ESP-IDF projects specify many settings on a higher level, and overriding the include paths manually can create more problems than it would solve.
A good way of solving it would be creating a new project from scratch, checking where the missing include files are usually located and how are these components referenced, and then porting these settings to the broken project. You will likely find that some component names have changed, or some CMake-level statements use slightly different syntax.
- You must be logged in to reply to this topic.