In the build settings I have it define DEBUG when in the debug build configuration, so that I may make my code do separate things depending on which type of build it is.
However in Eclipse it darkens out the parts of the code which are excluded by the preprocessor, and this doesn't keep up when I change the setting (whether I'm currently building debug or release). So, I have a bunch of code which is perpetually darkened out, and the Eclipse indexer and other helpful features don't work inside of those areas.
How to fix? Has anyone else encountered this?
Update: Still having this issue. I eventually abandoned my unit-test build configs and simply put that functionality into a command-line switch. Just so that I could get indexing to work while I write my unit tests.
You have to set the option "Build configuration for the indexer" to "Use active build configuration" in the projects C/C++ indexer preferences. Open the properties panel for the project, go to c/C++ General and Indexer and enable project specific settings and change the radiobutton on the bottom to "Use Active build configuration".
Of course you can also set this in the global properties panel of Eclipse to change this setting for all projects.
Go to your project's Properties, then go to C/C++ General -> Paths and Symbols -> Symbols. Add your defines there and it will work.
If you want to change the defines for your system based on build configuration, you need to do as dgrant said here: "Project properties and select C/C++ General -> Paths and Symbols then select the Symbols tab", but you need to make sure you have the correct configuration selected at the top of your window. Also be sure when you add the symbol to the list that you DON'T check the "add to all configurations" checkbox.
If you want your correct set of symbols to be parsed by CDT in your editor, you'll also need to make sure you have the correct build configuration active as well. To do that, right-click on your project and select Build Configurations -> Set Active -> and select the build configuration you want to make active. CDT will now parse all the files as if this build configuration were active instead, using the global symbols you defined in the last step.
There is a problem I've seen with every version of Eclipse where it doesn't always decide to rebuild your index files immediately. To get it to do so, you can either start a build (the build doesn't actually have to complete), or you can right-click on your project and go to Index -> Rebuild. Both cause an immediate re-indexing to occur. You shouldn't need this, however. I can confirm that simply changing the build configuration as described in step 2 above will cause an #ifdef I have in my code which checks for a symbol defined only in one of my build configurations to immediately become greyed-out or un-greyed-out, as it should.
Check provider: -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers -> CDT Managed Build Settings Entries. It should be enabled.
Check if defined symbol is in entries of this provider.
Indexer is optional.
My satisfactory solution has been to move away from Eclipse to editors with a working libclang plugin: Sublime Text, Vim.
For an intelligent IDE for C/C++, one probably can't go wrong with XCode or MSVC.
Related
I'd like eclipse to only run make in the directory the current file belongs to, not for the entire project. This becomes more important since the project is very big and make on the top level takes around 20 minutes. most of it is entering-leaving directories and checking if build is needed etc. So I have to manually open the directory in cmd and run make. So I'd like eclipse to do this in its build automatically process. Is that possible?
Try to play with Build directory option found in project properties -> C/C++ Build -> Builder Settings tab. The default value there is ${workspace_loc:/your_project}. However Eclipse provides rich set of predefined variables (see under Variables... button). Probably most interesting for you are these ones:
build_files
Returns the set of absolute file system paths whose modification caused the current build. A list of the characters, 'a' (added), 'c' (changed), 'r' (removed), 'f' (files only), 'd' (directories only), can be supplied as an argument to limit the file list to just those types of deltas. Defaults to all deltas.
selected_resource_loc
Returns the absolute file system path of the selected resource.
Other places where you could try to use these variables are Make build target options in Behaviour tab.
If you can add your build step to the External tools configuration, you could create a manual builder from that.
The External tools configurations are set similarly as the Run configurations, but allow executing different kind of steps (e.g. shell, Ant - I am reasonably sure, make-files can also be supported, but I don't use them - if not, then you can add a shell script that runs the make-file).
To set this up you have to go to the project properties (Right click on the project, select Properties), then go to the Builders page, and add a new builder, that is created from an External tool configuration.
I hope I was clear enough for this to work.
Select your project, open Properties -> Builders. Uncheck the builders that you don't want to run automatically anymore. Hit "New..." and select "External Program".
Now you can specify what command shall be run automatically each time the project is built. To have the parent directory of the currently selected file as an argument for your build command, you may use ${selected_resource_loc}\... See the Variables button for more such place holders that can be resolved at runtime.
Afterwards you may want to configure the "refresh" tab, if you also want to see newly created files in your project explorer. And if everything works well after some trial and error, you may also want to look at the "Build Options" tab to have it run in the background.
I have installed Eclipse Indigo for C/C++ Linux developers on Ubuntu 10.04 x86.
When I use common predefined macro __BASE_FILE__ Eclipse says Symbol '__BASE_FILE__' could not be resolved, but compilation is OK. I have to use it so often in my code and Eclipse fills my screen with red lines and bug icons :)
How can I fix this?
Not sure if this addresses your specific problem, but I also had semantic errors. They just came out of the blue after having a working project.
Anyway, I fixed it with a single option in workspace settings by setting:
"Build configuration for indexer: Use active build configuration"
The other option was "Use the build configuration specified in the project's indexer settings" and this is the one that wasn't working. I think it may have been corrupted after an eclipse crash.
Window -> Preferences -> C/C++ -> Code Analysis -> Syntax and Semantic Errors: OFF
This won't solve the cause of the problem but at least will stop the false errors from being shown.
The simplest solution is to reset the indexer:
Window / Preferences / C/C++ / Indexer.
uncheck "Enable indexer" ->>OK
rebuild all, may show lots of errors
check "Enable indexer" ->>OK
rebuild all
This error can be produced by forced closing of eclipse by power failure.
You need to rebuild the index of your project.
Right-click on the project, then Index->Rebuild.
Deleting the .metadata folder , and then Import project .
This way is OK!
Updated:
You have to add proper paths to Project->Propoerties->C/C++ General->Paths and Symbols. If it does not help, you can configure Eclipse Code Analyser (which generates the 'errors') in Project->Properties->C/C++ General->Code Analysis. Under the error description you have problem with, try Customize Selected->Scope->Exclusion Patterns.
IMO the correct solution is to define the symbol in Project -> Properties->C/C++ General -> Paths and Symbols -> Symbols tab. Since you can assume the symbol will always be supplied by the compiler, you just tell Eclipse to consider it defined.
I had the same problem just recently, where Eclipse complained about undefined macro, that i always supply using -D<MACRO_NAME> compiler option.
I think it has something to do with the workspace/.metadata.
I had the problem of semantic errors reported but Hello World compiles and runs.
I deleted the project, created another one, same error reporting. Reinstalled CDT, same thing. Deleted the workspace, shut down Eclipse, restarted, created new hello world, same thing. Deleted the workspace again, shut down Eclipse again, this time noticed that Eclipse had recreated the workspace folder during shutdown when it couldn't find it. Deleted the workspace with Eclipse shut down. Restarted Eclipse, created HW project, errors show for about a second and then gone. Deleted project, created another one, errors show for a sec, then poof.
If you actually had projects in your workspace (mine was a clean install), I bet that you could just delete the .metadata folder within the workspace, and it would fix it.
I personally agree with compostus' answer.
It's good to solve the real problem that eclipse's code analyzer have.
But when I try this steps:
define the symbol in Project -> Properties->C/C++ General -> Paths and Symbols
I don't find symbol tab or any place to add a symbol. what I want to do is putting macros like -DANDROID or #define ANDROID 1 to eclipse so that the code analyzer can find this definition.
I'm under Mac OSX mountain lion.
adding as another answer, hopefully this will help someone.
I have a ~simple workspace (1 c++ shared-object (linux's version of a DLL, 3 c++ executables, and a pydev python project)
I checked out all the code to a new machine, and it builds fine but had numerous 'semantic errors' on std-c and std-C++ code and includes.. I went through all the discovery / indexer setting to no avail.
==> deleting the entire .metadata folder fixed this.
Since i had nothing non-trivial set up in the workspace (all in the project files / makefiles), eclipse happily created a fresh workspace, and i simply had to do a file->import-> existing projects
If on Ubuntu, go to Window > Preferences > In Search box type "Indexer" > Select Indexer in left column.
Under heading "Indexer Options" tick the following options (all but those involving the skipping of files):
Index files source files not included in project
Index unused Headers Index all header variants
Index source and header files openend in editor
Allow heuristic resolution of includes
Under heading "Indexing Strategy" tick both options which are:
Automatically update the index
Update index immediately after every file-save
Under heading "Build Configuration for the indexer" select the following option:
User active build configuration
try this:
Preferences --> c/c++ --> Indexer --> Index all header variants
check this option.
This is a file indexing issue.
Solution - Right click on the project, Index->Freshen all files.
(Applies to Eclipse CDT.Oxygen)
In my case, I eventually discovered that the indexer was having problems because a colleague had “helpfully” duplicated a whole load of declarations in two header files that were only included together in a small subset of C files in the project. Removing the duplications (and making one header include the other) allowed the indexer to function correctly again.
It was particularly a problem with duplicated enumerations, for some reason. I do not know why this is so.
I used #pragma once in my code. This configuration caused me to have the problem:
---fileA.h---
#pragma once
#define MYMACRO(X) func(X)
---fileB.h---
#include "fileA.h"
---fileB.cpp---
#include "fileB.h"
MYMACRO(5) <---- warning here
I replaced #pragma once with #ifndef #define HEADER_FILE_H #endif, and that fixed the problem.
Not sure if this works for the OPs issue, but I had semantic errors in eclipse Luna and was able to resolve them by following instructions in this thread: Eclipse shows unresolved inclusion but it compiles
The compiler finds the header, but Eclipse not.
You could help Eclipse and set the path to the header files under:
Project -> Properties -> C/C++ Build -> Settings -> Compiler ->
Includes
In my situation, eclipse had determined one of my include directories, but did not determine that there were sub-include directories within it.
I had a similar issue but my compile was fine but Eclipse showed errors on lines that used a #define from another include file. I fixed by checking "Index all header variants". I think the classis #ifndef FILENAME in include file was process multiple times in Indexer and so 2nd time the FILENAME was defined so all #defines in .h file were not "seen" by the preprocessor. Go to Window | Preferences | C/C++ | Indexer.
I have the same problem. Compiler preprocesses ok, but static analyzer doesn't. In my source file:
#define PLATFORM_INC_FILES
#include <platform.h>
int coflags=O_BINARY; // Undefined symbol
In platform.h (an OS dependent header to help creating portable code):
#ifdef PLATFORM_INC_FILES
#include <stdio.h>
...
It looks like static analyzer doesn't take the .c #define statements into account when preprocessing included headers. By defining it at the symbols dialog, errors dissapear, but that is a project scope symbol definition, resulting in every source to include every system header in my case.
Hope it gets fixed soon...
Using Eclipse Mars and MinGW on MSIS2.
The problem occurs this way: I insert a new variable name into the code somewhere e.g. "newone" in this example:
int a;
foo()
{
a=17;
newone=23;
}
The file is saved (so the indexer is reindexing).
Then I added the definition:
int a, newone;
foo1()
{
newone=0;
}
foo()
{
a=17;
newone=23;
}
The indexer will still shows the error at the line " newone=23;" but not at the other lines of code containing "newone".
Solution: first define your variables, then use it.
M.
In the past, I would define the ANDROID symbol in:
Project -> Properties->C/C++ General -> Paths and Symbols -> #Symbols tab
However, the latest version of Eclipse no longer has a # Symbols there, or anywhere else.
It seems there is no longer any way of defining symbols in Eclipse.
Eclipse has so many bugs and problems.
I finally gave up and switched to using Gedit and the terminal to compile.
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 have noticed that autocomplete is not working in some of java files in Eclipse.
Also, the files where autocomplete is not working, display a hollow "J" as the icon for the Java file. The files where autocomplete is working, icon for java file is a filled "J"
I am wondering if someone can point out what went wrong all of suddent, why the change in icons and why autocomplete and syntax highlighting is turned-off in the files with a hollow "J" icon?
Thanks.
update
Basically, I was doing what VonC has suggested but Eclipse was not refreshing that it why I was thinking that VonC's suggestion isn't working, after doing a refresh, the problem resolved.
Since this question is highly ranked on Google, I will add a solution to fix general auto complete issue, not for 'hollow J' ones.
Try Window (Windows/Linux) or Eclipse (OS X) -> Preferences -> Java -> Editor -> Content Assist -> Restore Defaults
also
Content Assist -> Advanced -> Restore Defaults
some answers (restore defaults) above do not work for some adt bundle installs as of jan '13.
in those cases, go to
Window -> Preferences -> Java -> Editor -> Content Assist -> Advanced
and tick on the JAVA PROPOSAL options.
In this following picture, MyClass.java has a hollow J, because it is explicitly excluded from the sources to build:
Could you go to the properties of the project, "Java Build Path" Section, "Source" tab and see if some exclusion filter has been set ?
It is usual for instance to define:
**/Test*.java
to exclude at first building any unit-test class (when you have a large set of sources and do not want to be presented with Test classes during auto-completion, or do not want them considered during source searches).
Those with a hollow J aren't part of the build path of the project, so they can't participate in the normal build process and therefore auto-complete won't be enabled for these files (and other Java editor features!). You must add the folders with the Java files to be built to the build path using the 'source path' section of the project properties. This can be accessed by right clicking on a project in the project navigator / package explorer and going to Properties. See http://www.informit.com/articles/article.aspx?p=367962 for details.
Additionally, if the files aren't part of a Java project in the first place, you must create a project and move the files in, or put the files in an existing one. Again, make sure these file are under a source directory as described by that section of the project properties.
(source: teradata.com)
I cope with the issue by deleting the file if autocomplete does not work. Just before copying the source code. Then I have recreated the java file with the same name. Pasted the source code previously copied.
As an addendum to the #VonC answer, make sure that the Java files are part of the Inclusion pattern. I had a case where a build process was creating the project while only including .js files and not the Java files:
You can manually edit the inclusions via the Edit button. In my case, a fix was made to the build script to make it permanent.
Neither Restoring Defaults or my build path (file was already in package directory w/other files where auto-complete was working) fixed problem. Fix for me was to close the file explicitly (right click on file name in tab) and re-open. Interestingly, just re-starting Eclipse didn't work either.
Make sure you have the right directory structure. I believe that:
Hollow J icon beside Java file - will not be build
Normal J icon beside Java file - is a file to be build.
I made a mistake when I created webapp artefact. By default it does not create folder for Java, but for resources. I mistakenly put my sources there.
Have a look - see the difference.
I was able to get this fixed in Visual Studio Code, VSCode but entering crtl-shift-p and typing in clean. When I did that I ran the "Java: Clean Java Language Sever Workspace" command. This fixed my autocomplete issue for me.
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?