Bugzilla – Full Text Bug Listing
| Summary: | CDT caches error parsers in the workspace metadata so doesn't notice changes in plugin.xml | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | James Blackburn <jamesblackburn+eclipse> |
| Component: | cdt-core | Assignee: | Project Inbox <cdt-core-inbox> |
| Status: | NEW --- | QA Contact: | Jonah Graham <jonah> |
| Severity: | normal | ||
| Priority: | P3 | CC: | adrian.ashley, pmason |
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
James Blackburn
(In reply to comment #0) > ErrorParserExtensionManager stashes the full set of error parsers under > .metadata/.plugins/org.eclipse.cdt.core/model.extensions.xml. This file gets > created if the user ever visits 'Window > Preferences > C/C++ > Build' and > presses OK on the preferences dialog. > If this cache is present it overrides any error parser settings derived in the > plugin.xml. Right, that's too coarse. > This behaviour means users may not pick up fixes to the error parser regexps. > As these error parser definitions are per workspace (and can't currently be > stored in project metadata) this leads to issues with users seeing different > errors for the same project being built. I agree with that partially, with the part of too coarse settings and the problem with updates to the parsers. But if a user chooses to modify settings in her workspace it follows that different users have different settings, nothing wrong with that. > I think the configuration provided error parsers should be 'fixed-in-stone'. The > user should be free to customise and add additional error parser based on the > built-ins - though usually this would be done at the project scope, not > workspace scope. I think in many cases a user wants to do just a little tweak. And if they change it to use the new one instead the old one becomes a clatter. It is reasonable to know that it was modified, what if we add a decorator indicating that the settings are overridden? And an ability to reset it, for example [Reset] button in place of [Delete]? I do not agree that workspace scope would be less common than project scope. Normally a user would want to apply the "better" parser settings right away to all the projects, that is the whole point of workspace settings. I suppose your use case is just different and fits the project scope concept. There's nothing inherently wrong with workspace scoped settings. However bear in mind that they last just for the lifetime of the workspace. The user, or another user, checks out or imports the projects into a different workspace and the settings are lost. There's no way to synchronize settings between workspaces. Error parsers could behave like code style. You can't change the built-ins, but you can derive parsers based on the builtins. The alternative is that as you say, every user has tweaked error parsers which don't inter-operate with the rest of the team. I'd argue that error parsers _must_ be consistent at the project level. The alternative is that different users see different errors which could lead to all sorts of problems. Moreover the parser regular expressions are pretty strongly tied to the toolchain... From my POV workspace scope is only useful to single developer projects, and shouldn't be needed if the toolchain correctly defines the error parsers. |