| Summary: | Types sometimes considered "not compatible" when using project cycles | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Justin Spadea <jspadea> | ||||
| Component: | EDT | Assignee: | Justin Spadea <jspadea> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | ||||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Modified Builder.java to stop clearing the project's binding cache when not cleaning the project. Verified in latest CVS |
Created attachment 197957 [details] Projects with a cycle This was originally found and fixed in RBD. EDT doesn't support project cycles yet, but it's probably going to be added at some point so we should put this fix in before we forget about it. To reproduce: modify EGLVAGCompatibilitySetting.isVAGCompatibility() to return true (this allows the cycle), then set BuildManager.MAX_PART_CHANGE to 1 (will force a full build), and import the attachment into the runtime workspace. The problem has to do with the builder clearing caches, then rebuilding a project that was already rebuilt because of the project cycle. The binding in project 2 has a reference to the original binding from project 1, but when project 1 is rebuilt it gets new instances of the bindings. An identity check is used on the bindings during validation, so it fails on the assignment statement, thinking they're different. The fix is to stop dumping the binding caches on incremental builds and forced full builds.