My jni folder in Eclipse looks like this:
It is grayed out and has a diagonal line across it. What does it mean? I can still edit my native C++ code in this folder and see the changes as I test the application.
It means the directory is being filtered from the source locations. It seems you can use this to exclude files that are not source from a source folder, although I've never used it.
I got rid of this irritation in Eclipse Indigo CDT by:
(Project) Properties ->C/C++ General ->Paths and Symbols ->Source Location Tab ->Edit Filter... ->Remove
You probably have something in the folder that is deprecated.
http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/ref-icons.htm
Related
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.
I had a problem with finding Java docs in Eclipse. I seem to have fixed the problem, but I'm posting this for two reasons: I would like to know why I had the problem in the first place and perhaps my method of fixing it might be useful to someone else having a similar problem.
I created a simple Java project in Eclipse (Helios on Windows 7) and selected the JavaSE-1.6 JRE. Then I created a source file and imported java.util.GregorianCalendar. When I hovered over GregorianCalendar, I was getting the message:
This element has no attached source and the Javadoc could not be found in the attached Javadoc
None of the methods of GregorianCalendar seemed to have any Javadoc, either. Other standard Java classes (even others in java.util, like ArrayList) didn't have this problem; only GregorianCalendar. Everything seemed set up properly in the project settings. The Javadoc location set in the Java Build Path was http://java.sun.com/javase/6/docs/api/.
I managed to restore correct behavior by temporarily switching to JavaSE-1.7 and then back. Evidently something got reset and all is well. While I'm happy that things are now working, I don't like being clueless as to how they got messed up in the first place.
Can anyone provide any insights into this?
I think general support relies on the presence of a src.zip in your JDK directory, which is detected when you autosearch a directory for Java installations. It could be missing. Not sure if online Javadocs are used.
I'm using Eclipse Juno on a Windows 7 64-bit (with a 32-bit JDK) but i think it will also apply to your Eclipse version:
Download JDK docs zip file to your Desktop folder;
Right-click on the file, choose Properties and unblock it;
Move the file to a location of your choice. I normally move it to the JDK folder;
Open Eclipse and go to Window->Preferences->Java->Installed JREs;
Select your JDK installation and press Edit;
Select the rt.jar file and click "Javadoc Location..." button;
Select the "Javadoc in archive" radio button;
Set the archive path by browsing to the JDK docs zip file;
Set the "Path within archive" to "docs/api" (without the quotes).
Enjoy! ;)
I have a rather large project which contains a number of third-party dependencies which are linked via svn:externals. These include tomcat and blazeDS, which are packaged by our installer via ant. The problem is that these projects contain dozens of sample JSP pages, and eclipse chokes on them when trying to build the project, producing hundreds of errors.
Our project setup is something like this:
src/
main/
test/
third-party/
blazeDS/
tomcat/
etc.
Now, in eclipse, my project's build path is set to only include subfolders in src/main and src/test. Yet, for some reason, it still tries to build everything beneath third-party. I have clicked on third-party and selected "remove from build path", but this had no effect. I even tried adding the third-party folder to the build path, and then excluding "", "/*", and "**/*.jsp", but again, to no effect.
What is going on here?
Edit: Thanks for the suggestions, though unfortunately, they don't seem to fix the issue. I don't have the CheckStyle plugin installed (I'm using Eclipse 3.4.1 with the only custom plugins being subclipse and flex builder), and I tried disabling all extra builders except for Java, but the errors are still being thrown.
I usually have this kind of issue with CheckStyle plugin, where you need to specify in its properties (right-click on project -> Properties -> CheckStyle):
"Exclude from check Files non located in a source directory"
Otherwise it does analyze (and reports warning/errors on) files which are not candidate to be compiled in the first place.
Couple of other suggestions:
try restarting your eclipse with the -clean option (eclipse software version of 'did you reboot it ?' ;) ). Beware it can reset your workspace perspectives, so you may want to try that with a copy of your workspace instead.
try deleting your project (your workspace reference of your project, not its actual content), and reimporting it (beware of your custom launchers, they may get removed in the process).
check if you do not have any linked directory within src or test, which would point to thirdparty(/**): that would explain the unwanted compilation.
It could be that your eclipse project is configured to have extra Builders. You can check that in the project's properties (right-click on project -> Properties -> Builders).
In my case it was because there was a reference to the file (which I had excluded from the build path) in another file which was in the build path. I wanted to exclude SegModel.hpp from the build path, but in another file, I had specified template short K::KEstimate<SegModel>(SegModel& m, short stepCode);
The obvious thing to do would be to:
Right-click on the folder that you wish to format.
Source > Format
Expected results:
- All java code in the directory and subdirectories are formatted (using the project specific formatting settings)
Actual results:
- None of the java is formatted.
While we're at it, how can we do a batch clean up operation in Eclipse?
From editor, I Right-click > Source > Clean Up, but I can only do one file at a time.
I faced the same issue. I had to switch to packaged Explorer to use the formatter. Under Navigator it does not work. Hope this help.
As mentioned in this thread, this (format all Java source files within a folder) should work since eclipse3.0.
Do you see some kind of error message in the "errors view" ?
I did exactly as you suggested you would like to do, and it did exactly what you suggested was expected. I selected Source | Format for a directory in my src tree and it reformatted all the units within.
EDIT: ...with 3.4.1 Ganymede.
If your code isn't checked out from source control or isn't writable, doing a group operation like this won't check them out or make them writable.
I have the same problem using SpringSource Tool Suite 2.5.1
I am using the package explorer
The project is in a SVN repository that is checked out
In the progress dialog I can see that only the XML files are modified
When I press Ctrl+Shift+F into a file, it gets reformatted (therefore is writable) but when after a reverse I do a right-click Source > Format on its folder nothing happens
I know it's been 2 years but I was wondering if #LES2 has found a workaround to correct this
EDIT :
Okay, despite I was really in the package explorer as written before, my java code was interpreted only as text files. I re-ran the full repository check-out of my project and a package-tree (squares for packages instead of folders) appeared giving me the ability to mass-format even Java files.
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?