Tips for getting the Eclipse Code Analyzer to not complain

[gtjoseph]

I've been using Eclipse since its early days for all my Java, Javascript, C/C++ and Python projects and, like many of you, have been frustrated by Eclipse's inconsistent and sometimes nonsensical Code Analyzer results for files and projects that compile and run just fine. Lately I've been getting flags in source files for issues in different source files. It was so bad earlier this week that I finally had enough and spent an entire day trying to chase down exactly what was causing the Code Analyzer and Indexer to go nuts and I think I now have a working recipe I can share...

1. Open your existing Eclipse instance and export your preferences to a safe place.
2. I'd suggest taking the opportunity to download and the latest production ESP-IDF (v4.4.2 as of today) but this isn't critical. I actually use the v5.0 development version but it has breaking changes from the v4.x versions so don't jump to it if you're not already using it.
3. Download and install the latest Eclipse CDT (2022-06 as of today). Make sure you install it to a location other than your existing installation. This isn't required but it gives you the best chance of success and allows you to keep your current install in case you run into trouble.
4. When asked, create a new workspace for the same reasons.
5. Install the latest version of the ESP-IDF Eclipse Plugin (2.6.0 as of today)
6. From the Espressif menu, run ESP-IDF Install Tools. Don't skip this step even if you're already installed the ESP-IDF from the command line.
7. Do NOT install any other plugins at this time and don't import the preferences you exported earlier yet.
8. Create a new directory into which you'll copy existing projects for import.
9. Copy, don't move or link to, one of your troublesome projects into the new directory. If you're on a Linux distro, rsync is your friend...
   Code: [Select all] [Expand/Collapse]

   1. $ rsync -vaHAXx /home/me/my_projects/my_project/. /home/me/my_new_projects/my_project/

   GeSHi © Codebox Plus Extension
10. In the new project directory, make sure you can build the project from the command line.
11. In the the new project directory, delete the .settings, .project and .cproject directory and files. This will give the project a clean start when you import it into Eclipse. Speaking of which...
12. Back in the new Eclipse instance, do an Import, Existing IDF Project.

At this point you should have a clean install of everything but should still be able to go back to your existing instance if anything gets messed up. Your new project will probably still show bogus errors and warnings, especially since you haven't done a build from Eclipse yet. So first, make sure you can do a build from inside Eclipse. Now the fun begins...

These are the things I had to do to get things consistently working. Most of them are solely to make the Indexer and Code Analyzer less confused.

1. Make sure all C++ header files under your control have the 'hpp' suffix instead of 'h'. Yes, I know it shouldn't matter but it seems to matter to Eclipse.
2. Make sure you have no source or header file name duplicates. I had a setup.h file in my main component and a setup.h file in one of my components which seemed to confuse things.
3. Do NOT rely on header files in one component to supply declarations for things it doesn't own to other components or the main component. I have an ESP_Common_Component component that has a bunch of useful stuff in it so I added system includes like stdint.h, esp_log.h, esp_err.h, etc. to it's public header file so I didn't have to specify those includes in every other component. Big, big mistake. Directly adding the system Includes into every component and the main project cleared up a ton of issues.
4. Don't do a full indexer rebuild unless you absolutely have to. It doesn't know how to rebuild everything from scratch. If you do run it, you'll see more issues than you already had. To get rid of them, just do a build again. The other index options seem to work fine. Speaking of which...
5. If you right click on a source file in the project explorer, you'll find an index option called Create Parser Log File. I'll spit out everything it found and, more importantly, everything it wasn't able to resolve. You can use that as guide to search for more issues.

Once you get everything working, you can import your old preferences, install new plugins, and customize as you like.

The project I'm working on at the moment has some of my own components, some components from the ESP-IDF examples, external components like lvgl and managed components like the json_generator. I'm now going on 3 days without any issues so I'm keeping my fingers crossed.

I'm sure I missed something but if I think of anything else, I'll update this post.

Good luck!!

[martins]

Nice guide, I was deffinitelly doing a full indexer rebuild when something was wrong, good catch.

Out of curiosity, could you explain the step 9. - why copy with rsync? Is it different from, lets say, F5 in Midnight commander or standard copy with other file explorer? Or is the main point of that step to copy the project, so there is original backup left untouched in original place?

[gtjoseph]

Nice guide, I was deffinitelly doing a full indexer rebuild when something was wrong, good catch.

Thanks!

Out of curiosity, could you explain the step 9. - why copy with rsync? Is it different from, lets say, F5 in Midnight commander or standard copy with other file explorer? Or is the main point of that step to copy the project, so there is original backup left untouched in original place?

"Midnight commander" Wow there's an oldie but goodie! Yeah, the main point is to keep the original untouched so if something went wrong, you'd have your original project safe and sound. I just prefer rsync because I know it copies everything recursively including dot-files, permissions, etc. My fingers have 'rsync -vaH' burned into their muscle memory. Actually, 'rsync -vaHAXx' for modern filesystems with attributes, selinux labels, etc.

The new workspace is also a bit important as there are project level settings in the workspace config as well as the project config. Don't ask me why.

[mbratch]

Thanks very much for posting all of those details. I need to read through it again carefully and consider trying it. I've been plagued with the Indexer code analyzer flags in Eclipse for some time now. For a while they almost disappeared, and then one day came back with a vengeance. They make absolutely no sense. Even definitions in my own local headers are sometimes flagged as undefined when some other definitions in exactly the same header and source file are just fine. It's very inconsistent. I've tried full clean, re-indexing, shuffling header includes around, all to no avail.

But, again, thanks for sharing. When I get a chance, I'll give it a go.

[martins]

I just prefer rsync because I know it copies everything recursively including dot-files, permissions, etc.

Gotcha, so I believe MC should be good too as it seems to do simillar. It does copy attributes (there's an option) and dot files, not sure about hradlinks tho.

And yeah, its great tool especially for remote systems without GUI. Its quite user friendly, has simple editor with syntax higlighting, works over SSH, has terminal etc. With ESP I use it for legacy make projects (mainly ESP-MDF), where you have to run menuconfig (sdkconfig) manually outside Eclipse.

That means only some steps from this guide are applicable, but especially the Workspace one seems interesting as I've seen it mentioned in other, non-esp related Eclipse discussions too.

Like, for example, I just tried to switch IDF version for some project. So I changed all necessary path definitions, but Eclipse kept complainig about unresolved ESP_LOG macros. Reason was that the macro was defined in multiple header files - the one from old IDF and the current one. No idea where the old version was left but renaming the folder with old version solved it. That is not the workaround I would prefer so "cleaning" the workspace (by creating new one) worth a try.