It is funny how things work out. You can let AI tools try to fix a code problem for days, but nothing works until you finally step in and do it yourself.
I was working on my ESP-IDF project and wanted to organize it better. My goal was to move different pieces of code into a folder named components.
Try #1: Gemini 3.6 Flash
I don't pay for AI, so I use the free web versions. I used a tool I built called ReptClip to copy my project files. Then, I asked the AI which files to move and what new code to put inside them.
I did exactly what the AI said without questioning it. Suddenly, red error lines popped up in my code editor. Soon, the whole file was covered in errors. I told the AI about it.
It gave me new steps, and I just followed them again. It still didn't work.
I did this over and over for hours. I got very mad, called the AI stupid, and reset my working directory to start all over from scratch. I do not know why it failed at such an easy job.
Try #2: Gemini 3.1 Pro
I thought the Pro version of the AI would do a better job. I tried the exact same steps and trusted it completely again. But I ended up with the exact same errors.
Tries #3, #4, #5, ... #n
I lost count of how many times I tried this. I tested Gemini Flash Extended, Gemini Pro Extended, DeepSeek v4 Flash, and DeepSeek v4 Pro. For some reason, absolutely nothing worked. I wasted two whole days doing this.
Try #n + 1
Next, I decided to try GitHub Copilot. I gave it instructions, and it spent about 30 minutes on the task. It finally gave me a nice ✅ emoji to say it was done. I thought my problems were over.
I tried to build my project, but it failed. I looked at my code files, and there were error squiggles everywhere, just like before.
I gave up and left the project alone for a few days.
Try #n + 2
After a break, I came back with a new plan.
I went to gemini.google.com and chose the Pro model. I asked the same question. But this time, I stopped blindly pasting the whole file the AI gave me. Instead, I decided to edit the #include parts and type the CMakeLists.txt files by myself.
When I moved my code into the components folder, I noticed errors on the #include lines. I realized right away that the #include paths were the real issue. I told the AI that I could not add those specific headers. The AI said I needed to use the REQUIRES or PRIV_REQUIRES settings. Adding those fixed a few headers, but some specific headers still failed.
Finally, I searched on Google to find out exactly what to put in the REQUIRES section to include those specific headers that were causing the issue. The answer was slightly different there.
I changed that one single line of code, and it finally worked! The ONLY problem was that all the AIs had used the wrong REQUIRES name, and none of them could figure out that was the issue. It is hard to believe I wasted weeks on such a tiny problem.
I skipped over a fair bit of the debugging rabbit hole in this post because I honestly couldn't remember every single twist and turn 😅
Top comments (2)
ESP-IDF build issues usually come down to how CMake resolves component dependencies. When headers live in a separate component, the compiler path needs the component name declared in REQUIRES or PRIV_REQUIRES. If the build fails on headers outside the core framework, that target name is usually what the tool missed.
That makes total sense. I'm still pretty new to ESP-IDF and CMake. Since the root and main CMakeLists.txt files didn't need those REQUIRE fields, I didn't think much of it when individual components needed them 😅