Bugzilla – Full Text Bug Listing
| Summary: | Executables view shows stale file list after executable change | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | John Cortell <john.cortell> |
| Component: | cdt-debug | Assignee: | cdt-debug-inbox <cdt-debug-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | Ken Ryall <ken.ryall> |
| Severity: | normal | ||
| Priority: | P3 | CC: | cdtdoug, jamesblackburn+eclipse, pawel.1.piech, stasik0 |
| Version: | 8.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
John Cortell
Preliminary investigation points to a change in the platform that is causing the POST_BULD event to be sent with the workspace context instead of the project context. I've pinged James Blackburn to see what's going on... However, this has no bearing on the second failing use case I pointed out. (In reply to comment #1) > Preliminary investigation points to a change in the platform that is causing > the POST_BULD event to be sent with the workspace context instead of the > project context. I've pinged James Blackburn to see what's going on... Yes, this is interesting, and I believe this listener is not correct. To be precise, a project may be built in one of 4 ways: - top-level Workspace.build() - top-level workspace auto-build - top-level build of project build configurations + references (new in 3.7) - project level build IProject.build() The first 3 have resource delta who's #getSource is the IWorkspaceRoot. Only the last one has the project as source. The result is that if there are many valid ways to build a project, and when more than one project is built simultaneously, the change notification will be batched with the workspace root as source. In general the only way to tell if something was done as part of a workspace build is to look at the resource delta. CDT, for example (currently) builds references as part of the project level build -- this is entirely non-standard and part of the reason why the existing build model works so badly... Checking the resource change event's delta is the only way to know for sure whether anything's changed... (In reply to comment #2) > Yes, this is interesting, and I believe this listener is not correct. To be > precise, a project may be built in one of 4 ways: > - top-level Workspace.build() > - top-level workspace auto-build > - top-level build of project build configurations + references (new in 3.7) > - project level build IProject.build() > > The first 3 have resource delta who's #getSource is the IWorkspaceRoot. Only > the last one has the project as source. > > The result is that if there are many valid ways to build a project, and when > more than one project is built simultaneously, the change notification will be > batched with the workspace root as source. In general the only way to tell if > something was done as part of a workspace build is to look at the resource > delta. CDT, for example (currently) builds references as part of the project > level build -- this is entirely non-standard and part of the reason why the > existing build model works so badly... > > Checking the resource change event's delta is the only way to know for sure > whether anything's changed... Good point, James. The Executables view listener thus has a bug that it will not detect changed executables if a workspace build is done (or any of the other two types of builds you mentioned). I'll work on improving the listener to handle all four cases by not relying on the source object of the event. Thanks! *** This bug has been marked as a duplicate of bug 342141 *** (In reply to comment #2) > (In reply to comment #1) > > Preliminary investigation points to a change in the platform that is causing > > the POST_BULD event to be sent with the workspace context instead of the > > project context. I've pinged James Blackburn to see what's going on... > > Yes, this is interesting, and I believe this listener is not correct. To be > precise, a project may be built in one of 4 ways: > - top-level Workspace.build() > - top-level workspace auto-build > - top-level build of project build configurations + references (new in 3.7) > - project level build IProject.build() > > The first 3 have resource delta who's #getSource is the IWorkspaceRoot. Only > the last one has the project as source. > > The result is that if there are many valid ways to build a project, and when > more than one project is built simultaneously, the change notification will be > batched with the workspace root as source. In general the only way to tell if > something was done as part of a workspace build is to look at the resource > delta. CDT, for example (currently) builds references as part of the project > level build -- this is entirely non-standard and part of the reason why the > existing build model works so badly... > > Checking the resource change event's delta is the only way to know for sure > whether anything's changed... Well, then how do I find what projects are actually built by having a PRE_BUILD or a POST_BUILD event? |