Bugzilla – Full Text Bug Listing
| Summary: | No symbol sync between external settings cache and project properties | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Marko Tomljenovic <marko.tomljenovic> | ||||
| Component: | cdt-core | Assignee: | Project Inbox <cdt-core-inbox> | ||||
| Status: | ASSIGNED --- | QA Contact: | Jonah Graham <jonah> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | jamesblackburn+eclipse, zulliger | ||||
| Version: | 7.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Marko Tomljenovic
Can you attach a sample plugin which would allow to demonstrate the issue? ${workspace_loc} should have a severe health warning. It's not possible to safely share a project that uses this as an include path. The workspace_loc bears no relation to the location of projects in the workspace, so isn't safe for shared projects (unlike other workspace_loc relative paths).
This either needs a warning annotation or should be displayed in some other way which distinguishes it from other workspace relative paths.
(In reply to comment #2) > ${workspace_loc} should have a severe health warning. It's not possible to > safely share a project that uses this as an include path. The workspace_loc > bears no relation to the location of projects in the workspace, so isn't safe > for shared projects (unlike other workspace_loc relative paths). > > This either needs a warning annotation or should be displayed in some other way > which distinguishes it from other workspace relative paths. Does this comment relate to this issue? If so then I don't understand it Created attachment 184771 [details]
Example plugin with dummy setting provider
The attachment contains a plugin that implements a dummy setting provider (always returning one macro "name" - "value") and adds a project context menu: project -> Index -> Call Setting Provider.
The bug can be reproduced like this:
1. Create a dummy C project that has no symbols
2. Execute the context menu
3. Now a symbol name -> value is available in the project properties
4. Remove the symbol manually from the project properties and from all languages
5. Call the context menu
6. Open the project properties
7. The symbol has not been added since the setting provider cache has not detected any change.
Sorry, wrong bug -- will teach me to comment from my phone. (In reply to comment #4) > Created an attachment (id=184771) Thanks, I can reproduce that with this description. I suspect the following problem is related to this issue: - Assume you have an external settings provider that provides a macro - Open Properties -> C/C++ Build -> Settings - Press "Restore Defaults" => The macro provided by the external settings provider disappears. For me, this seems to be a quite high-priority issue, because a "normal user" may easily trap into this problem and may not be able to recover from the situation. Therefore, may I ask whether there is some progress being done on that issue or will someone try to have a look at it soon? If not, I could have a look - but it would be great to get some assistance from the community (such as some tips where to start). Ideally, it'd great to have a fix within the next 1 or 2 weeks... I started getting familiar with the mechanism/code related to "external settings provider" vs CLanguageSetting, etc. According to my current understanding, we lack a clear definition of how entries (i.e. macros, inc-path, lib-path) provided "external settings provider" are treated when a user attempts to change or remove them. Assuming that this statement is correct, I think we must now create such a definition in order to fix this issue. Currently, I can think of the following possible definitions: a) entries (i.e. macros, inc-paths, lib-paths) added to the configuration by an "external settings provider" cannot be changed or removed by the user. 1) They can only be changed and removed by the "external settings provider" that provided them 1) They can only be changed and removed by a "external settings provider" b) entries added to the configuration by an "external settings provider" can be changed and removed by the user. Therefore, the user can "override" the entries provided by the "external settings provider" 1) The entries from the "external settings providers" can only be restored by pressing the "Restore Defaults" button or by removing/reading the "external settings provider" 2) The entries from the "external settings providers" can be restored by an explicit "Restore external settings" button or by removing/reading the "external settings provider" 3) There's no default way of how to restore these settings. An "external settings provider" may provide a custom "mechanism" (such as a button, context menu, etc.) that cause restoration of the settings. Moreover, they may be restored by removing/reading the "external settings provider" y) The framework could provide helper functions to simplify such a restoration for the "external settings provider"-implementer z) No additional framework support Other? As far as I understand, the current implementation is "b 3 z". Unfortunately, in "b 3" it's not obvious to the user how his "user changes" to entries provided by "external settings providers" can be undone. The user doesn't even get visual feedback to distinguish an "external setting"-entry from a "normal" one. In short: Depending on the implementation of the external settings provider, there may be no way to restore the settings (for a normal CDT user - you guys could of course :-)). I surely don't know all use cases of these "external settings provider", therefore I can just judge the above definitions from my limited point of view: For our use case, a) would be sufficient. Moreover, I think that a) would cause least implementation/design effort and is easy understandable even for "normal" human beings. Of course, a) is also the most limiting definition, as there's no standard way of how to change or remove those settings. Only the "external settings provider" may decide to provide a mechanism to change the entries. Please let me know about your opinion. Do you agree that such a definition is currently missing and that we need one? Or am I misunderstand things? As I should end up with a solution quite soon, it'd be great to get feedback on that topic as soon as possible. I just created a separate bug entry for the "Restore Defaults" issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=369836 |