Eclipse CDT Invalid Project Path

Question

I have a C project that is built using a makefile, Eclipse constantly warns about \"Invalid project path: Duplicate path entries\", but I cannot figure out what the hell it

Answer 1

This problem is a real pain to deal with. It doesn't work very well.

This is applicable to Eclipse 3.4.1 / CDT 5.0.1

From what I can tell, when you create a "C/C++ Project" within CDT, it will try to auto-detect your include paths. Great idea, but the implementation is horrid.

If you delete or rename a directory, the old directory is leftover. If you rename the project, the old directory is leftover. When Eclipse can't find that old directory, it gives you that warning.

My solution is turning the automated discovery off entirely and managing my include paths manually. You need this list of include paths for things like ctrl-click (auto-navigate to defines/functions/files/etc) and shading out #define blocks. It builds the index off this list.

Here's what you need to do: Right click on your project in the project explorer and go to properties. Go to C/C++ Build -> Discovery Options Uncheck "Automate discovery of paths and symbols"

Now go to C/C++ General -> Paths and Symbols You'll see under the Includes tab Assembly, C and C++ languages with corresponding auto-discovered include directories. Go to all 3 languages and delete everything. Open your makefile and transcribe your includes into the corresponding language. A project rename will still cause the indexer to break. ${project_name} and other globals do not seem to work. If you're having trouble, use the "Workspace" button to browse to the directory you want to include, as that seems to always work but entering it manually does NOT. Hit apply, then OK. Right click your project, go to index->rebuild Restart eclipse.

This should fix things forever. Any time something improperly is shaded out due to a #define or #ifdef block, it's because that list of files is outdated. You'll also know that list is outdated if you get "unresolved inclusions" on #include lines.

Doug Schaefer, hopefully Google indexes this, you find your name, and you fix this awful implementation. =)

Answer 2

I found this bug report to help my problem. I had moved some include paths and couldn't get rid of the old paths.

I've seen this problem too, old paths are never deleted. To manually fix the file you need to move/delete the ${projectname}.sc file found under ${workspace}/.metadata/.plugins/org.eclipse.cdt.make.core

https://bugs.eclipse.org/bugs/show_bug.cgi?id=206372

Answer 3

Here's a late answer for Eclipse 4.4 (which does not have a Discovery option).

Delete the project's infoPath file. Eclipse or the ADT plugin (not sure which) will recreate it, and populate it with the correct paths.

You can find the project's infoPath file at <Eclipse workspace>/.metadata/.plugins/com.android.ide.eclipse.ndk/<project>.pathInfo.

I think Eclipse or the ADT plugin determines the new paths from two places: (1) the NDK directory set under Eclipse preferences, and (2) paths in Application.mk. All those paths become "Built-in" paths under Eclipse.

Also see How to change built-in C/C++ paths pointing to a deleted android-ndk-r9 installation?

Answer 4

Using Eclipse Luna and CDT 8.5

I fixed the issue by

1. Open the project properties | C/C++ General | Paths and Symbols
2. Look at the Source Location tab, I had renamed a directory and it was not updated in this list.
3. Rebuild

Answer 5

This worked for me with Eclipse 3.7.2 and CDT 8.0.2:

1. Open the project properties | C/C++ Build | Discovery Options.
2. Click the button by Clear discovered entries now:.
3. Rebuild.

It is seems to be a new feature in CDT 8. I have had this "Invalid project path: Duplicate path entries" problem for years, and this is apparently the newly provided solution.

Before doing this there were duplicate paths under C/C++ General | Paths and Symbols | Includes tab. I could not get rid of these. They only appear when Show built-in values is checked, so they are apparently generated somehow. After doing the above they were replaced with a set that did not have duplicates. The only difference is that the same settings appeared under Assembly, GNU C, and GNU C++. Previously they were different sets. The ones for Assembly were empty, for example.

So far the problem has not returned.

Answer 6

You should check if you have manually defined a symbol that eclipse can figure out from your makefile. I have a project that has a manually written makefile and the problem was solved by removing symbols that I had manually added to C/C++ General -> Paths and Symbols -> Symbols.