Community
Participate
Working Groups
1. Create new workspace 2. Create a new project: C/C++ > C Project > Executable > Hello World ANSI C Project. Call it "p1" 3. Open the Executables view 4. Build the project Note p1 appears in the Executables view. 5. Select p1.exe Executables view Note the right pane shows a single file: p1.c. This is expected. 6. Add a second file to the project (foo.c, e.g.,) 7. Build the project Note the right pane of the Executables view still shows only p1.c. This is unexpected. foo.c should also appear in the list 8. Hit the Executables view refresh button. Note the right pane still shows only p1.c. 9. Delete p1.exe in the Project Explorer Note p1.exe disappears from the Executables view. This is expected. 10. Build the project Note p1.exe reappears in the Executables view. This is expected. Select p1.exe and note the right pane of the Executables view now correctly shows both files (p1.c and foo.c) Interestingly, the code in ExecutablesManager.resourceChanged(IResourceChangeEvent) seem like it would drive the Executables view to update after a build, however, the code no-ops because event.getSource() is not an instance of IProject. The fix for this problem needs to also work when the executable changes outside of Eclipse. In other words, doing a 'touch' of p1.exe at the command line and then telling the Eclipse Project Explorer to refresh should also cause the Executables view to update. Support for this case seems to be missing altogether.
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?
