Community
Participate
Working Groups
Build ID: M20070921-1145 Steps To Reproduce: 1. Start eclipse with a new workspace 2. Create a new C Project, Hello World ANSI C Project 3. Keep the default settings in the wizard (just specify a project name and the author) 4. Open the project properties dialog, and select the C/C++ General->Indexer page 5. Check the "Enable project specific settings" check-box and select "Use active build configuration" as the Build configuration for the indexer. 6. Finally hit OK 7. Close the project, then open it again 8. Open the project C/C++ General->Indexer properties page again: the Build configuration for the indexer is now set to the default "Use a fixed build configuration" More information: Note that the preference value is also lost when the workbench is restarted. This bug was produced with following configuration: - eclipse 3.3.1 M20070921-1145 - CDT 4.0.1.200709241202 - debian linux
Observing the same issue, eclipse 3.4 Release + CDT 5.0.0 Final, WinXP ...
see bug 215197, looks like the same problem
*** Bug 215197 has been marked as a duplicate of this bug. ***
Andrew Ferguson provided brief but accurate first look in the description of bug 215197: CProjectDescriptionPreferences.serialize(ICStorageElement) is only being called to provide serialization on workspace level, not a project level. I made some serialization to a randomly chosen property file and it seems to solve the problem. There is only one variable - configRelations being serialized by CProjectDescriptionPreferences. The whole class looks like a wrapper around this one variable. Hopefully we can see more of these in the class in future. Now, what is the correct place to serialize this class to? I observe a rich choice of property files stored in all kinds of formats. Some choices here, and I won't bet the list is complete: - CProjectDescriptionPreferences is stored as XML in .metadata/.plugins/org.eclipse.cdt.core/preferences. Again, this is workspace-level settings. - IndexerPreferences - which co-locate with the setting in question on Indexer page - are being stored in these places (naked property file format): -- Scope ("preferenceScope") is always being kept in .metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.cdt.core.prj-PROJECT.prefs -- If scope is SCOPE_PROJECT_PRIVATE, then indexer settings are kept along with the scope -- If scope is SCOPE_PROJECT_SHARED then indexer settings are in project folder, PROJECT/.settings/org.eclipse.cdt.core.prefs. Scope is still kept in the other file, along with the other indexer settings which are ignored in this case. If I digress with the scope - sorry. -- Workspace level indexer settings are in .metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.cdt.core.prefs but we don't really care for the purpose of this task. - Active configuration, and more importantly settingConfiguration which is represented by "Use a fixed build configuration" is being stored AFAICG in .metadata\.plugins\org.eclipse.core.resources\.projects\PROJECT\.indexes\properties.index in binary format. So, which one to choose? Still, there is always a choice of: - Create totally brand new property file with preferable fancier path/name and keep the only parameter of CProjectDescriptionPreferences there. Pick XML format for consistency. It would also beef up contents of the file with <storageModule> and other tags and all XML stuff to look cool.
Created attachment 111359 [details] proposed patch It seems that any functionality to save/load CProjectDescription project specific properties has not been developed yet. I've been thinking also about storing this parameter (which is the only property of CProjectDescription for now) in .cproject along with all the other data of CProjectDescription. But it is probably not so good idea because .cproject - being intended to be kept under source control - is not supposed to store user preferences. The last most recent idea I came up with is to manage it using ProjectScope class similarly as it is done by UserDefinedEnvironmentSupplier. Here is the proposed patch. If any of more knowledgeable in this area developers could review and provide any insight how to tackle this the most consistently - any guidance is appreciated.
(In reply to comment #4) Storing project specific preferences in the <proj>/.settings directory is an eclipse standard supported through the class ProjectScope. A team can put such preferences under source control, in which case all team-members have to use the same settings. I have created LocalProjectScope which works similar to ProjectScope but stores the preferences somewhere in .metadata/... Doing that I allow for detaching from the possibly team-shared project-preferences to workspace private settings, in case a team member does not agree with what's checked into source control.
(In reply to comment #6) Thanks for that comment. It makes it a bit more clear to me. I saw your solution for IndexerPreferences and thought that that class could be used to store configRelation variable - considering that it is being set on the indexer preference page. Which raises a question if this is appropriate place since configRelation belongs to ProjectDescription and not to indexer. Should be there a special ProjectDecription preference page (or at least a bit more distinct "ProjectDescription box" on one of pages)? Or this is probably taking it too far for the sake of one variable. I actually like the wording and it looks relevant on the indexer page - from user perspective.
We had a discussion on this in bug 172919 and decided that the user would expect the setting on the indexer page. I quickly looked at your patch. It stores the setting in the project directory. I think the setting is more a user-specific choice that should be stored in .metadata?
(In reply to comment #8) > We had a discussion on this in bug 172919 and decided that the user would expect > the setting on the indexer page. Looks like a sound discussion, alright. > > I quickly looked at your patch. It stores the setting in the project directory. > I think the setting is more a user-specific choice that should be stored in > .metadata? I guess you are right. So, you suggest using LocalProjectScope instead of ProjectScope. What about that checkbox "Store settings with project"? I bet we'll run into a user who would expect it to be applicable to "Build configuration for the indexer" pane - absolutely rightly. If going that route, CProjectDescription becomes dependent on IndexerPreferences (which keeps the "preferenceScope"). Not good. Another way is to duplicate "preferenceScope" in CProjectDescriptionPreferences. But assigning 2 preferences to one control could lead to some subtle and not so subtle problems. Strike that. Any other suggestion? I think the difficulty partially stems from "team-shared project-preferences" being special for Indexer. I think that kind should be applied either in centralized fashion to all (applicable) settings or to none. I mean, maybe "preferenceScope" should be promoted from being indexer-specific - to project level. It could be easily applicable to other properties like environment variables, code style, even compiler flags (warning level as example) etc.
(In reply to comment #10) Hmm, looks like the shared responsibility - project model provides a setting that has to be altered by the indexer preference page - is a problem. Maybe we have to move the ui for these settings to the dialog that appears when you select 'Manage Configuration' (e.g from the Path & Symbol page). On the indexer preference page we could display the configuration that is currently used for the indexer and provide a button to Manage the configuration, where you could changes?
(In reply to comment #11) On the workspace preference Indexer page there is "Use the build configuration specified in the project's indexer settings". The way how it works makes me as a user a little schizophrenic. If the build configuration is specified in project settings why don't just use project settings? I realize that it is "Automatic" mode discussed in bug 172919 (comment #12). I believe it is set by default. Then when unsuspecting user goes to project Indexer setting - Enable project settings is disabled and everything is grayed as the unsuspecting user could expect - except choice of indexer configuration. It looks funky and if I were unsuspecting user I would think that it is a bug. I think it would be more natural for end user to get rid of the setting on the workspace level and just use Active as a default. Heck, it is natural to think that indexer indexes the configuration a user just switched to - if no indexer setting were changed. And if you change them you would do fine changing in the project properties. Sorry to be late to the discussion. More relevant to the case, the fixed build configuration in combo box does not go to shared settings. It is being persisted somewhere though. Maybe you know where? I did not dig far enough to tell for sure. > (In reply to comment #10) > Hmm, looks like the shared responsibility - project model provides a setting > that has to be altered by the indexer preference page - is a problem. > > Maybe we have to move the ui for these settings to the dialog that appears when > you select 'Manage Configuration' (e.g from the Path & Symbol page). On the > indexer preference page we could display the configuration that is currently > used for the indexer and provide a button to Manage the configuration, where you > could changes? I think this would be acceptable and there could be a checkbox "Indexed configuration" against the settings configuration. I just dislike moving it away from Indexer page where it was so naturally placed... And what do you think of idea of moving "team-shared project-preferences" from Indexer setting somewhere up to project level? Am I totally off the line here?
(In reply to comment #12) The workspace setting is important. If you have a larger amount of projects it is otherwise hard to switch from one to the other mode. All theses settings were supposed to be persisted by the project model, which includes the chosen configuration. I don't know where it is acutally saved to. We could also move these settings to a separate property page, below the current indexer page. This way it would be close to the indexer preferences and is still separated.
*** Bug 256126 has been marked as a duplicate of this bug. ***
*** Bug 304962 has been marked as a duplicate of this bug. ***
*** Bug 340209 has been marked as a duplicate of this bug. ***
i can observe the same bug in indigo and cdt 9 rc4, is the proposed patch not working?
(In reply to comment #10) > I guess you are right. So, you suggest using LocalProjectScope instead of > ProjectScope. What about that checkbox "Store settings with project"? I bet > we'll run into a user who would expect it to be applicable to "Build > configuration for the indexer" pane - absolutely rightly. Like me. As a workaround for Bug 197989 I would like to define a build configuration for the indexer that includes the necessary guard macros to parse the files correctly. But this should be stored with the project to support project transfer with the indexer build configuration selected as the configuration to use for the indexer. Maybe it's possible to add the preference manually in PROJECT/.settings/org.eclipse.cdt.core.prefs like indexer/fixedBuildConfiguration=<name of my build configuration> ??
Created attachment 220239 [details] Modification to store "settingConfiguration" in ProjectScope The preference for the indexer configuration is accessed and used in org.eclipse.cdt.core/src/org/eclipse/cdt/internal/core/settings/model/CProjectDescription The setting key is "settingConfiguration" and it's realized via the internal class CProjectDescription.CfgIdPair We expect that this preference is stored and shared with the project data if "Enable project specific settings" is enabled. I tried to store the setting to ProjectScope in CProjectDescription.CfgIdPair. Storing is not the problem. Loading the setting is not possible due faults in accessing the settings. Maybe it's accessed to early when the project is created (import) or there are concurrent accesses, i don't know. I added a hack: Open the setting file directly via file IO. That works. Take this as a report what we expect and it seems to be difficult to realize it ;) I've attached the patched class based on 5.1.2.201004122116.
I was able to get the project to save the settings by doing the following: * Go to Window->Preferences * Under C/C++ ->Indexer * Select "Use active build configuration" It seems that this global setting forces the settings over the project specific setting.
*** Bug 401667 has been marked as a duplicate of this bug. ***
The reason this is confusing is because the project properties dialog does nothing to inform the user that changes to this group will be ignored. In fact, changes to the value will be used until the next time the project is opened. How about removing the 'Build configuration for the index' group from the project properties dialog when the workspace setting is 'use active'?
Instead of removing the group completely, what about adding a message when the workspace setting is overriding the setting. E.g., "Workspace settings are currently overriding the project-specific selection. The workspace option must be change to allow project-specific indexer settings." And include a link to those workspace preferences. There is already a link at the top of the dialog, but I think it would be a good idea to repeat it right within that sentence. The UI group would be completely greyed out unless the workspace setting has been changed. This would make the UI match the current behaviour.
The indexer settings in the workspace preference page and the project property dialog interact in non-obvious ways. WS: The workspace preferences 'Window - Preferences - C/C++ - Indexer' PS: The project properties 'Properties - C/C++ General - Indexer' There are two possible settings for WS: - 'Use the active build configuration' - 'Use the build configuration specified in the project's indexer settings' There are two areas of the PS that are significant: - PS-enable: a checkbox, 'Enable project specific settings' - 'Build configuration for the indexer' - 'Use the active build configuration' - specify a specific build configuration The value of WS changes the interpretation of PS in non-obvious ways. WS == active: 1) PS-enable == false: Things work in the expected way. The project is always indexed using the active build configuration. 2) PS-enable -- true: Confusing. A fixed configuration can be selected, and the indexer will use that configuration until the workbench is restarted. After the restart behaviour reverts to using the active build configuration. WS == use project settings: 3) PS-enable == false: Confusing. The entire page of properties is disabled EXCEPT for the combo that lists the build configurations. This property can be changed and will be used in the current and all future workbench sessions. It took me awhile to even notice that the combo was not disabled. The behaviour for most pages like this is that the checkbox at the top disables the entire page. 4) PS-enable && 'use active == true': Confusing. This is the inverse of the confusing case #2. The 'use active == true' checkbox can be selected and the indexer will use the active build configuration for the rest of the workbench session. When the workbench is restarted, the indexer changes to whatever was specified in the specific configuration combo. 5) PS-enable && 'use specific config': Works as expected. The indexer will use the configuration that is listed in the drop down and the specified configuration will be used in the current and all future workbench sessions. Cases 1 and 5 work as could be expected. Cases 2, 3, and 4 need to be addressed. For cases 2 and 4 the problem is that changes to the property are not persisted. There are probably reasons for this behaviour so for these cases I think we should just fix the UI to match what actually happens. I think we should keep the current behaviour and change the UI so that the values cannot be changed. 2) Do not display the 'Build configuration for the indexer' group. Instead include a message that says: "A workspace preference is currently set so that Projects are not able to use a specific build configuration during indexing. The active build configuration will always be used." The "workspace preference" would be a link to the appropriate page in the workspace preferences dialog. 4) Do not display either radio button. Provide only the drop-down with a label that says: "Use a fixed build configuration" I think that for the last case 3, we should change the behaviour. The drop- down will be disabled unless 'Enable project specific settings' is true. There is a bit of lost functionality, but I think it is better to be consistent with the behaviour of most other Eclipse property pages.
*** Bug 432595 has been marked as a duplicate of this bug. ***
Issue occurs under various circumstances in Neon MS1. Test configuration: * Ubuntu Precise * java-8-openjdk-amd64 or oracle jre1.8.0_60 * Build id: 20150820-1211 * CDT-Version: 8.8.0.201508171545 Steps for reproduction: * clean workspace * new makefile project with existing code (typically with > 10000 files, so that indexing takes a while) * default workspace settings -> C/C++ -> Indexer -> Use the build configuration specified in the projects indexer settings * Change project settings -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers * Apply settings (OK) * Indexing is triggered Issue 1) If a resource filter is configured after that (project settings -> Resource -> Resource Filters) then the providers settings are reset Issue 2) If the Indexing takes very long and the project is closed before it has finished, then the provider settings are also reset
Issue also occurs in Neon MS3
In Oxygen.2 still present (CDT 9.4.0)
