The problem I'm seeing is that under preferences, C/C++ Defined symbols for different Configurations/targets aren't showing up in the code coloring.
When I change the active build configuration in the project menu, I would expect the editor & code coloring to pick up the symbols from the project settings, but it only seems to be picking up the symbols for one of the targets.
Is there any way to have the code coloring for ifdef'ed code follow the active build configuration?
I solved this problem on my system by setting 'Window->Preferences->C/C++->Indexer->Use active build configuration'
In response to phord's comment. After changing the indexer setting to "Use Active Configuration" you need to change the active conf of the project to something else and then back. Then it picks up the changes.
just a small addition to the symbols option:
give it value 1
what worked for me is this:
copy the define name to clipboard(lets say we have: #ifdef DBG_TYP_1)
select the project in project explorer
go to - Project->Properties->C/C++ General->Path and Symbols
in the "# Symbols" tab
add symbol DBG_TYP_1 with value 1
thanks for the tips !
Try playing around with your project's Discovery Options. (Right-click on the project, choose Properties, go under C/C++ Build, and choose Discovery Options.)
You may need to rebuild your project after changing its build configuration in order for Eclipse to rerun its discovery, or you may need to change the discovery options for each configuration to cause them to generate different results. (Sorry, this isn't an area of the CDT that I've played much with.)
Related
I use customized syntax coloring for my Eclipse editor and it has reverted back to the default settings. This is the second time in a couple weeks that it has happened. Any ideas as to why this is happening or how I can get my custom settings back? I have a very specific coloring scheme that I like to use and it takes forever to manually set!
Are you switching across workspaces? As I understand eclipse preferences are stored in .settings/ present in workspace's root directory.
I export eclipse preferences and import it when I switch workspaces. Another cool trick I found is to close projects when I do not use them.
Eclipse official link on how to export preferences:
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftimpandexp.htm
Sometimes simply import/export would not be enough, so you may need a list of .pref files where the syntax coloring settings are stored. What I have here is not complete and I just list what I use and I hope it helps.
(I process .java, .jsp, .xml, js and .properties files.)
You can find them by searching .pref files in your workspace. Remember to adjust your searching options to look into subfolders.
org.eclipse.ui.editors.prefs
org.eclipse.jdt.ui.prefs
org.eclipse.ui.workbench.prefs
org.eclipse.wst.xml.ui.prefs
org.eclipse.jst.jsp.ui.prefs
org.eclipse.wst.html.ui.prefs
org.eclipse.wst.jsdt.ui.prefs
org.eclipse.ant.ui.prefs
org.eclipse.datatools.sqltools.sqleditor.prefs
org.eclipse.debug.ui.prefs
org.eclipse.php.ui.prefs
com.adobe.flexide.mxml.core.prefs
org.python.pydev.prefs
com.adobe.flexide.as.core.prefs
com.adobe.flexide.css.core.prefs
org.codehaus.groovy.eclipse.ui.prefs
org.epic.perleditor.prefs
org.eclipse.cdt.ui.prefs
You may copy them when you finish adjusting your syntax coloring settings. When needed, search .pref again to get access to their locations, and restore your settings by copying the lines with color code, in order to avoid unpredictable side effect. As I can see this is the only way, inconvenient buy effective.
The momentics IDe for BB10 has encountered a problem or at least I believe that al my inclusions appears as unsolved. when I compile the app it compile correctly and everything works pretty well. But the problem is that I need to import some libraryes like #include and as long as this libreries are shown as insolved inclusion I cannot declare any object of those types.
Does any one know what can be this and how to solve it.
Things done berofe:
I've tried cleaning the workspace and creating a new project and also the new project works perfectly, also I've tried going to configure add and and some libraries. this works but only works for specific libraries, not at all for libraries.
Edit 1: As I saw on other posts, I've reinstalled the 10.1 sdk that is the one I need, but no luck
In the Workspace's Project Explorer pane, right click the project, and then select Build Configurations -> Set Active -> Simulator-Debug (Just to be sure.)
From menus, Window -> Preferences. In the Preferences dialog's left pane choose C/C++ -> Indexer.
To get intellisense to work when authoring well before making builds, under Indexer options, check boxes Index source files not included in the build, index unused headers, index source and header files opened in editor. And under indexing strategy check both boxes, automatic update and update after every file save.
Finally, under Build configuration for the indexer select the Use active build configuration option (Just to be sure.).
For class declaration in header file, the erratic feedback from IDE will disappear (as of Momentics 2.1.2) only after cpp file for implementation, that includes the header is saved.
If modifying header, after setting up as above, right-clicking on the project in Workspace pane -> Index -> Rebuild should work.
my iphone app builds fine in debug configuration, but when i change it to release, i get hundreds of errors, starting with "CoreServices/CoreServices.h: No such file or directory" in AudioFileComponent.h - part of the AudioToolbox framework.
i can't find where in the project/build settings is responsible for this.. thanks for any help.
I would recommend the following:
Open up your debug target's build settings by right-clicking on the target, hitting "Get Info", and selecting the Build tab.
Select All (Command-A) so the entire contents of the Build setting panel is selected, then copy it to the clipboard.
Paste the contents of the clipboard to an empty text document
Repeat steps 1-3 for the release target of the same project
From there you can use a diff utility or some other method to compare the contents of the two files, which will show you the settings that differ between the two configurations. Some of them will make sense (e.g., optimization settings) whereas others will not. Most likely there is a setting that differs between the two that will resolve your problem.
Another thing you can do is build one of your source files in debug mode, and in the Build Results window copy the contents of the command line to a text editor. Repeat for release mode. Then, replace each space in the command line with a newline (\r). From there you should be able to do a rough side-by-side evaluation of the differences between the two compile instructions, and may be able to figure out what's missing from that.
In general this helps you get a better feel for exactly what XCode is doing under the hood to build your project, which is a good strategy to practice no matter what tool you are using for development.
i think the problem was because i had the audiotoolbox package in the wrong place, it wasnt in system/library/frameworks like it should have been. (this doesnt explain why it built ok in debug though)
I have the (mis)fortune of having a large project source-base in which I am working primarily on PHP and JavaScript. I have to have the full project area as the project root in Eclipse, but unfortunately this includes several directories that drive the validation built into WST/DLTK/etc. nuts.
I have tried disabling all validators in the project properties. I have gone into the validators one at a time and added rules to the "Exclude Group" set to exclude the specific folders. I have removed the folders from the PHP build path in the project properties. And yet, my Problems view/tab is still littered with thousands of red flags that stem mostly from a folder that we use to keep copies of external elements (Apache, PHP, etc.). You know, typical "have a copy of the specific versions we currently use" sort of thing.
The signal-to-noise ratio is so bad that I'm unable to use the view at all, which is a shame. If I'm not going to have the benefits of the IDE, I might as well be using vim for this (I use it for other stuff, but for this codebase a good IDE is a better choice, providing I can get it to work). It seems to me that it would be an obvious feature to be able to right-click a folder in a project and select "Exclude from Validation", but alas there is no such feature. Is there another way to get the validators (PHP, HTML, etc.) to ignore the folders I need ignored?
Tried solution;
Right click project
Select properties
Select validation
Check Enable Project specific settings
On the XML Validator row, click the '...' button
Select Exclude Gruop
Click Add rule
Select 'Folder or file name'
Click Next
Select files or folder which are not validated.
Click Finish
Click OK
Click OK
This solved my problem. Because eclipse validation gives error for generated GWT files.
Best regards.
I came upon this question while looking for the same answer. I will list the steps I did here and hopefully it will help someone in the future.
I am using Eclipse 4.1 and I do the following to exclude validation for specific xml files. I am sure if you configure the different validators it will work for other files as well.
Go to Preferences -> Validation
Find the Validator you wish to change and select settings (not all of the validators have settings, hopefully yours do).
In the settings you can add an Exclude Group where you can add a rule to specify to exclude the validator for specific extensions, folder or file name, project nature, facet or content type.
I have Eclipse for PHP Developers and I was dealing with the same issue.
In addition tot he excellent answers above, I have one more suggestion.
My first recommendation is not to use Aptana unless you actually want those validators (as they are nearly impossible to turn off from my experience).
Beyond that, go to File -> Properties -> Builders, and deselect "Validation" and "Script Builder" and "JavaScript Validator".
So far it's helped speed up some operations tremendously.
I also recommend disabling "Automatic Build". Because you're using PHP, the odds that you actually need it to build anything if you don't want validation is slim.
In the main menu, go to Project and uncheck "Build Automatically". You will want to build your project every now and then by right clicking on the project and selecting "Build Project".
All the above steps have helped me get the basic editor, which is exactly what I wanted.
I used to exclude resources from validation via project specific Exclude Group (as the most answer here suggests). But in case anyone is still having problems with disabling validation for a specified folder in 2014 - just mark the folder resource as Derived:
This should disable validation for that folder.
If you are using EGIT you might also want to disable automatic inclusion of derived resources in .gitignore:
It is not really possible to select a directory, at least under Windows.
After having pressed Preferences->Validation->Settings->Add Exclude Group->Add Rule->Folder or filename->Browse Folder->(selecting some directory)->[OK]
The "Browse for folder" dialog is being closed, with the "File or folder" field staying empty.
I had the same problem with the web app i'm developping.
I ended up disabling automatic build, and building once a day (Project->Build automatically), that way i still get the benefits of code completion from libraries, while speeding up the program on older computers.
I found in the project properties there is a Builders category. In the list of builders I had a JavaScript Builder. I deselected this builder and all my annoying javascript validation woes went away.
this worked for me:
Properties > Builders section and unchecking the corresponding box. https://bugs.eclipse.org/bugs/show_bug.cgi?id=317833
seems to be a bug in some versions of eclipse.
There are more gloabal validation parameters. You can suspend all validation (or only the ones you don't need) by going to:
Window > Preferences > Validation.
Here, check the box "Suspend all validators".
Alternatively, uncheck the validators you don't need from the list below.
A full build will be requested which might take some time. But Eclipse will run a lot faster afterwards [But without validation of course]
http://www.flickr.com/photos/jesuspresley/5094048124/
Solution.
Go configure what's displayed in the Problems View like lothar proposed, create new custom filter and in "Scope" area choose "On working set". Now press the button right below this option to configure what working set would it be: in working set selection pop-up hit the "New" button and mark all your project files EXCEPT those you want to exclude from validation. You might want to save this working set under convenient name, like "No_Validation_Set".
Summary:
1) working set excluding problematic files.
2) custom Problems View filter to operate on this set.
Issues:
when adding new files to project you need to update your working set, so they are validated too.
When I excluded files from validation for the project, my setting didn't seem to be recognised until I restarted Eclipse and cleaned the project.
I spend some time customizing the colors for syntax highlighting in Eclipse (Java, JSP, HTML, CSS, etc.) but whenever I try to export these settings via File|Export|General|Preferences and reimport them, the settings never completely get imported back. Some colors are restored and others are left unchanged, leaving me in an 'in between' state - very frustrating.
I'm using Eclipse 3.4 Ganymede, by the way.
Has anyone found a reliable way to save and restore Eclipse syntax highlighting settings?
I finally figured out how to do this.
I just wanted to mention beforehand that I did try to start with a fresh Eclipse install, export the preferences to a .epf file, change just one single setting, export again, and compare the files. To my surprise, trying to import settings from a minimal .epf file did not work reliably either.
The solution that worked for me was to copy these files: {Eclipse workspace directory}/.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs
I tried a fresh Eclipse install on another machine and after copying those files over, all my settings were restored perfectly.
The solution was to copy SOME - not all - of the files from {workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs into my other workspace.
In particular (per the https://stackoverflow.com/questions/96981/color-themes-for-eclipse thread):
org.eclipse.jdt.ui.prefs = Syntax Coloring
org.eclipse.ui.editors.prefs = Text Editors
Copying other files caused things to break.
There are a couple of notes to add:
I had to copy the aforementioned pair of files several times before I got the correct syntax coloring.
Be sure to close the workspace, if it's open in Eclipse, before copying the files.
This worked with Eclipse Helios.
If you want to be a little more fine grained on what you migrate, the syntax highlighting rules are the lines starting with semanticHighlighting on workspace-indigo/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
Doing this, I was able to migrate my syntax highlighting from Helios to Indigo
I'm using JBoss Developer Studio 10 with the Eclipse Neon 4.6 engine.
All .prefs files are inside this path:
/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings
Update: I found a similar structure on this path too:
\RedHat\JBossDev\studio\configuration\.settings
It's my IDE folder plus \configuration\.settings
I recommend search for org.eclipse.*ui*.prefs instead *.prefs to refine your result.
The principal config files are:
org.eclipse.jdt.ui.prefs
Java Syntax Color Settings
org.eclipse.ui.editors.prefs
Text Editor Settings
org.eclipse.cdt.ui.prefs
Formatter Settings
org.eclipse.wst.jsdt.ui.prefs
JavaScript Syntax Color Settings
org.eclipse.jst.jsp.ui.prefs
org.eclipse.wst.css.ui.prefs
org.eclipse.wst.html.ui.prefs
org.eclipse.wst.json.ui.prefs
org.eclipse.wst.dtd.ui.prefs
org.eclipse.wst.xml.ui.prefs
org.eclipse.wst.xsl.ui.prefs
If have a problematic workspace:
Copy the files above
Create a new workspace
Copy and Replace that files in your new workspace
This will recover perfectly your custom editors color settings. For me worked very well.
Eclipse CDT stores 'Syntax coloring' in the file org.eclipse.cdt.ui.prefs
This is located for example here: C:\eclipse\workspace.metadata.plugins\org.eclipse.core.runtime.settings\
Copy and paste over the top of the one in your new eclipse instance. This worked for me when moving from 3.4 to 3.5
I would export the preference before modifying the color, and then after.
That way, you would be able to isolate the specific rules of an eclipse preference file into one smaller file and:
check if some colors not restored are indeed represented by a rule
the import of a smaller preference has any effect on the previously unchanged settings.
That kind of strategy can be further refined into several small settings files (one for Java, one for JSP, HTML, CSS, ...), in order to better analyzing the potential side-effects when re-importing those settings.
I have had success in importing Eclipse Helios's syntax highlighting rules by copying the file:
.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
from the source workspace to the target workspace. It seems this file also contains Eclipse's code formatter profiles and code templates.
Environment:
Version: Helios Release
Build id: 20100617-1415
(on linux)
Once Michael Bosworth's answer helped me to some extend and I voted up. But now I see some obligation to answer it myself, because copying these two files are not enough. Let me explain why.
First, these files contains lines irrevelente to syntax coloring.
Second, syntax coloring for other editors are located elsewhere, for example, those of XML files are in
org.eclipse.wst.xml.ui.prefs
and those of HTML files:
org.eclipse.wst.html.ui.prefs
JSP pages?
org.eclipse.jst.jsp.ui.prefs
, etc.
Third, when we change font colors, usually we change background colors, line highlighting colors, etc. to get a clearer view of codes. This involves more files.
If we search *.pref files in path
/workspace/.metadata/.plugins
we can find all preferences files where we can locate all lines of coloring settings. But by copy-pasting all these files to another workspace can also trigger problems, for they are not exclusively syntax-coloring-related. Moreover, when we are switching between two versions of Eclipse, unexpected problems may arise.
So, the safest way is:
Create a new workspace if you don't have one.
Open all *.pref files we find in the workspace one by one,
Copy those lines containing color codes,
Find the same file in your new workspace,
Replace the color part by existing one. Or, set the colors in Eclipse, by assuming the corresponding options according to properties' name. All color codes are RGB based.
EDIT: (2017.02.24)
Eclipse Mars has a plugin Oomph, which can record your preference settings to provide seamless transmission of your preferences. When you activate it, every time you change a value, it prompts to ask you if you want to record it in Oomph, providing you the exact line in the corresponding file where your new value is stored. So, when you install Oomph, you can:
Change the settings of your font face, font size, background color, etc.
In the prompt windows of Oomph, take note of the location of your new settings. (Because if you tell Oomph to remember your settings, it will not prompt never again, so you may only see this windows once.)
I have deleted recently changed *.prefs file from the following dreictory \myworkspace.metadata.plugins\org.eclipse.core.runtime.settings\ and imported existing exported preference.
I am the first person, who answer for this question as per my knowledge :), Cause even I struggled lot.
Thanks
I faced the same problem few days ago.
The easiest way to restore the defaults is to import the default theme again, which you can find under:
http://eclipsecolorthemes.org/?view=theme&id=790