Related
When opening project's Properties dialog, I see a list of reference projects under C/C++ General -> Paths and Symbols -> References. Immediately below that, there is an entry named Project References containing a similar list.
What is the difference between the lists?
The main difference the C++ Development Environment Guide states is this:
Unlike the Eclipse Common References page, this page allows setting
references to specific configurations.
So you can e.g. tell Eclipse to create the Release build of a referenced project before building the project which references it.
Read more here: C/C++ Project Properties, Paths and Symbols, Project References
I'm having trouble getting Eclipse to index my source code. I'm using Eclipse Helios on Windows XP at the moment.
I have a directory called src. Within it, I have a bunch of dirs, something like this:
src
-include (common headers)
-lib
-libIO (source code for this library)
-libGUI (source code for this library)
-pgms
-pgm1 (source code and headers for this pgm)
-pgm2 (source code and headers for this pgm)
Each leaf has its own Makefile. There is no top-level Makefile in src. pgm1 can and does include files from include and lib/libIO and lib/libGUI.
Basically, I want Eclipse to index my entire src directory, without having to set up a C/C++ project for every leaf in my tree. I can't seem to find a way to make this happen.
Here's my symptoms; what I'm trying to solve for:
When editing source in the pgm1 dir, it references functions that are declared in my include dir header files and defined in source files found in lib/libIO.
However, when I press F3 to get to the declaration of a function, Eclipse says "Could not find symbol 'X' in index". I can't seem to get Eclipse to find either the header declaration or the source definition for the method under my cursor (like the Java module does perfectly). Is this possible?
I had exactly same issue as OP but for some reason the menus in Eclipse I was using (Helios Service Release 2) were not "Go to Properties -> C/C++ General -> Paths and Symbols -> Source Location.".
The way I fixed the issue was :
in C/C++ view, right-click on top project name;
in the menu, select New->C++ Project;
in the window that appears, select Convert to and then select C++ project;
click OK to close the window.
Eclipse will start indexing right away. Depending on the size of source tree it may take a while but you will have the indexing working finally after that.
I faced similar situation. I solved it in this way: right-click the project in project View-->select Index-->rebuild.
I managed to solve this thanks to comments here.... I ended up recreating my project. I used the Import method to download a project from CVS, and told it to use the New Project wizard to do so. When I got the New Project dialog, I told it this was a C++ Project, and the indexing now works fine.
I still wish I could index files without having to attach a specific project type to it, but at least I found an answer.
Thanks for the help all.
Exit Eclipse. In workspace go to ".metadata/.plugins/org.eclipse.cdt.core" and delete everything in there.
in the project explorer panel, right click the project you want to re-index, then select index, then select the action you want
Indexing of files and variables under different flags is always complicated when we have a huge project, lot of files and more importantly lot of different build options. I prefer playing around with the Indexer option to help me browse the entire code.
You can find it : Project Properties>C/C++ General/Indexer.
You can choose "Enable project specific settings"
Then it's up to you to choose the options you want for your project.
For a particular build we can choose "Use active build configuration" so that only the files and MACROS are considered which are used by the build script.
Or Index all source files in the entire project.
I am using Eclipse Neon 3, here's the solution that worked for me :
go to File
New
Convert to C/C++ Autotools project
then select your project and finish.
It can take some time to finish indexing, it depends on your project size.
I have experienced problems with the indexer of Eclipse Luna when there was an unresolved friend declaration in the class declaration - it seems then that the indexer skipped indexing the rest of that class, and all references to it was shown as unresolved by the indexer.
Solution: removed the unresolved friend declaration (in my case, it was legacy code that was no longer needed).
Please try the following (my project is set up differently, so I am not sure this will work for you).
Go to Properties -> C/C++ General -> Paths and Symbols -> Source Location.
Do you see your source folder there?
I observe this behavior:
When I add a source folder and then exclude it from build, it disappears from the above list. After that the folder is no longer indexed. Re-adding it to "Source Location" solves the problem: the folder is now indexed; remains excluded from build (as intended); is visible among source locations.
I believe it is a bug -- excluding a source folder from build should not remove it from source locations list.
In Coocox IDE (Eclipse + gcc) the problem is resolved by going from file menu
Edit > Preferences > C/C++ / Indexer > Build configuration for Indexer set to Active build configuration and the rebuild the project (Ctrl R).
If the project is already converted to C/C++ and still the index is not working you can right click on the project and Index and rebuild. The project will start indexing right away.
I am using
Eclipse IDE for C/C++ Linux Developers
Version: Helios Service Release 2
Build id: 20110218-0911
I followed the suggestions above and in addition I had to mark all referenced projects (with in the work space) using project properties->Project references
The following has worked for me in Eclipse Neon:
New Project -> C/C++ -> Makefile project with existing code -> Next. Then Navigate to the code and finish the project creation. Indexing starts automatically.
What does the red exclamation point icon in Eclipse mean? There are lots of different search results on the Internet about "red exclamation point icons" and "red exclamation mark decorators" and "red bang icons," no doubt because lots of plugins and programming-related tools use red exclamation point icons. So, to be clear, this is the one I mean:
It appears as a decorator on projects in the Package Explorer view.
In my case, the icon went away when a missing build path variable was filled in. I'm using MyEclipse 9.0, but I don't think this is MyEclipse-specific. Other people on the Internet have reported that it has to do with other issues, including Subclipse, the .svn folder and moving files between working copies.
According to the documentation:
Decorates Java projects and working
sets that contain build path errors
In practice, I've found that a "build path error" may be caused by any number of reasons, depending on what plugins are active. Check the "Problems" view for more information.
It means there is a problem with the build path in your project. If it is an android project then it mostly means the target value specified in project.properties file cannot be found. This can also be caused because of other kinds of built problems. But it is shown mostly for built problems only. See here for more details. It is about built error decorater seen in eclipse.
An extract from that page:
Build path problems are sometimes easy to miss among other problems in a project. The Package Explorer and Project Explorer views now show a new decorator on Java projects and working sets that contain build path errors:
The concrete errors can be seen in the Problems view, and if you open the view menu and select Group By > Java Problem Type, they all show up in the Build Path category:
I also faced a similar problem when i tried to import Source file and JAR file from one machine to another machine. The path of the JAR was different on new machine compared to old machine. I resolved it as belows
Right click on the "Project name"
Select "Build path"
Then select "Configure Build Path"
Click on "Libraries"
Remove all the libraries which were referring to old path
Then, the exclamation symbol on the "Project name" was removed.
There can be several reasons. Most of the times it may be some of the below reasons ,
You have deleted some of the .jar files from your /lib folder
You have added new .jar files
you have added new .jar files which may be conflict with others
So what to do is we have to resolve those missing / updating / newly_added jar files.
right click on the project and go to properties
Select Java Build Path
go to the Libraries tab
Remove the jar file references which you have removed already. There will be a red mark near them so you can identify them easily.
Add the references to the newly added .jar files by using Add JARs
Refresh the project
This will solve the problem if it's because one of the above reasons.
I found another scenario in which the red exclamation mark might appear. I copied a directory from one project to another. This directory included a hidden .svn directory (the original project had been committed to version control). When I checked my new project into SVN, the copied directory still contained the old SVN information, incorrectly identifying itself as an element in its original project.
I discovered the problem by looking at the Properties for the directory, selecting SVN Info, and reviewing the Resource URL. I fixed the problem by deleting the hidden .svn directory for my copied directory and refreshing my project. The red exclamation mark disappeared, and I was able to check in the directory and its contents correctly.
What I did was peculiar but somehow it fixed the problem. Pick any project and perform a fake edit of the build.properties file (e.g., add and remove a space and then save the file). Clean and rebuild the projects in your workspace.
Hope this solve some of your problems.
Make sure you don't have any undefined classpath variables (like M2_REPO).
I had the same problem and Andrew is correct. Check your classpath variable "M2_REPO". It probably points to an invalid location of your local maven repo.
In my case I was using mvn eclipse:eclipse on the command line and this plugin was setting the M2_REPO classpath variable. Eclipse couldn't find my maven settings.xml in my home directory and as a result was incorrectly the M2_REPO classpath variable. My solution was to restart eclipse and it picked up my settings.xml and removed the red exclamation on my projects.
I got some more information from this guy:
http://www.mkyong.com/maven/how-to-configure-m2_repo-variable-in-eclipse-ide/
The solution that worked for me is the following one given by Steve Hansen Smythe. I am just pasting it here. Thanks Steve.
"I found another scenario in which the red exclamation mark might appear. I copied a directory from one project to another. This directory included a hidden .svn directory (the original project had been committed to version control). When I checked my new project into SVN, the copied directory still contained the old SVN information, incorrectly identifying itself as an element in its original project.
I discovered the problem by looking at the Properties for the directory, selecting SVN Info, and reviewing the Resource URL. I fixed the problem by deleting the hidden .svn directory for my copied directory and refreshing my project. The red exclamation mark disappeared, and I was able to check in the directory and its contents correctly."
Also be sure you dont have any closed project in the Projects tab ->
https://i.stack.imgur.com/StGEu.png
The solution that worked for me is the following one given..
I selected the particular project> right click >Build path>configure Build path> Libraries> I noticed that JRE system Library was showing(Unbound) hence..
selected that Library>click on Remove>click on Apply>click on add Library>JRE system Library>next>workspace default JRE>click on Finish>Apply>ok.
now you will not see these exclamation icon in your project.
I have imported a project with Mercurial (hg clone ...).
When opening it with Eclipse, a red exclamation mark appears by the project's name in the Project Explorer, and it cannot be built. Silly messages like "import java.util cannot be resolved" appear, and errors in files are not marked in the Package Explorer.
How can I resolve this?
Check the problem view. By exclamation it is usually means a problem with build path
Check the Build Path of the project by right clicking the project and select Build Path -> Configure Build Path.
One problem I often encountered is different people using different Java SDK and so when the exact SDK is not available in your machine, you need to change to your Java SDK (via JRE System Library -> Alternate JRE). A better way to avoid this problem is to always select the JRE System Library from Workspace default JRE or Execution Environment.
I solved the problem by adding the external .jar file in to my project.
RightClick on the project -> Properties -> Java Build path -> libraries tab -> Add jar
Select your jar file and added it
Thats it the red ! mark gone.
Some times it happens that you have added a jar file earlier but currently not using it. Then after some time you delete the jar file from your system. But since you are not using the library file, so you will not get any error.But then you will see the red exclamation mark for the project. So all you need is to remove the added jar from the Build Path.
Done.....
The Java Runtime Library was defined wrong for the pulled project.
It had to be reset under Project | Properties | Java Build Path | Libraries.
It means there is a problem with the build path in your project. If it is an android project then it mostly means the target value specified in project.properties file cannot be found. This can also be caused because of other kinds of built problems. But it is shown mostly for built problems only. See here for more details. It is about built error decorater seen in eclipse.
An extract from that page:
Build path problems are sometimes easy to miss among other problems in a project. The Package Explorer and Project Explorer views now show a new decorator on Java projects and working sets that contain build path errors:
The concrete errors can be seen in the Problems view, and if you open the view menu and select Group By > Java Problem Type, they all show up in the Build Path category:
I figured out each time i am trying to import a library into my android project, i have a red exclamation mark with both ActionBarSherlock and Facebook libraries
This is how i solved it:
After adding the library into your project "project properties->Android->Librairy->add"
If you are using Eclipse, all you have to do is to clean your project and build all your workspace:
"project -> clean... -> "clean selected project" -> build the entire workspace
For me, the problem was a simple one - the reference project was compiled in 1.5 and my project 1.6. Matching the two solved the issue.
Right-hand-click on the project, select properties, select java compiler.
This is how I solved this problem:- Right-Click to project->properties->Java Build Path->Libraries(tab)->Remove the Jar which is already present there with a Path given along.
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 wants me to do. I would like to disable this warning and continue with my life.
My application compiles and runs fine, with not a single warning except this one. Being a conscientious developer I am keen to fix this problem so I have the warm fuzzies only a clean build can bring.
This worked for me with Eclipse 3.7.2 and CDT 8.0.2:
Open the project properties | C/C++ Build | Discovery Options.
Click the button by Clear discovered entries now:.
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.
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. =)
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
Using Eclipse Luna and CDT 8.5
I fixed the issue by
Open the project properties | C/C++ General | Paths and Symbols
Look at the Source Location tab, I had renamed a directory and it was not updated in this list.
Rebuild
Here I just found another way to re-detect the path automatically:
Open "Workspace Settings-> C/C++ -> Build -> Settings -> Discovery"
Find "CDT Build-in Compiler Settings [Shard]"
Click "Clear Entries" and "Reset" button on the right
Rebuild projects and Done
Hope this will help.
Reference:
http://qing.blog.sina.com.cn/1802712302/6b7334ee33004def.html
It seems like a bug in CDT.
If you really want to get rid of it, you should try getting rid of the spaces in the project path; this was suggested in a search result for the error. If that doesn't work, you can try to open the .cproject file -it's where all the CDT settings lie- and check for an actual path with duplicate entries.
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.
No needs to remove .metadata guys, just delete all path located in C/C++ General -> Paths and Symbols -> Symbols and replace them on using click buttom but don't give the path manually
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?