Bugzilla – Full Text Bug Listing
| Summary: | IncrementalProjectBuilder.FULL_BUILD is misleading for some builders like CDT | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Andrew Gvozdev <angvoz.dev> | ||||
| Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | jamesblackburn+eclipse | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Andrew Gvozdev
Created attachment 167169 [details]
patch
Here is a patch with the suggested wording. I hope for a review and even more accurate description is appreciated.
Let me also copy the suggested wording in a comment: * Build kind constant (value 6) indicating a build request when resource * delta is not known. On this request all previously built state for the * purpose of incremental builds is discarded and resource delta is invalidated. * Incremental builders which rely on platform to track resource changes * treat this request as request to build all resources again from scratch. * * @see IProject#build(int, IProgressMonitor) * @see IProject#build(int, String, Map, IProgressMonitor) public static final int FULL_BUILD = 6; There are two contexts in which a build kind is used Andrew. I think you've only looked at the first. 1) An IncrementalProjectBuilder receives a build kind as part of the build call 2) An API user calls IProject#build(kind, ...) In the first case, kind == FULL_BUILD if there is no delta from the build manager, or an API user called #build(FULL_BUILD,...). Builders which rely on this delta need to build from scratch. There's no UI for users to directly call FULL_BUILD, but if an API user calls this, the platform forgets the delta which leads to a completely fresh build from behaving builders. As a result the API is confusing, and the JavaDoc deliberately unclear, because it's used in two contexts with subtly different semantics. As there's an explicit CLEAN_BUILD kind, it would be good if the API was clear on what API users should do, and what Builders can expect. An approache might be to: 1) Request that API users don't call FULL_BUILD (which behaves differently with different builders) rather do an explicit CLEAN_BUILD followed by INCREMENTAL_BUILD 2) For a builder kind is only FULL_BUILD iff #getDelta() == null (as it is today) As it stands, you're right there isn't an intuitive difference between FULL and INCREMENTAL, and it only make sense by looking at the implementation... (In reply to comment #3) > An approache might be to: > 1) Request that API users don't call FULL_BUILD (which behaves differently > with different builders) rather do an explicit CLEAN_BUILD followed by > INCREMENTAL_BUILD It looks to me that FULL_BUILD != CLEAN_BUILD + INCREMENTAL_BUILD. Some builders may be capable to rebuild all resources without cleaning. In this case extra CLEAN_BUILD would result in inefficient processing at the very least. Also, what delta would be supplied on the incremental build? Wouldn't the platform convert it to FULL_BUILD again? (In reply to comment #4) > It looks to me that FULL_BUILD != CLEAN_BUILD + INCREMENTAL_BUILD. Some > builders may be capable to rebuild all resources without cleaning. In this case > extra CLEAN_BUILD would result in inefficient processing at the very least. The current _definition_ of FULL_BUILD is that every resource is rebuilt: "A full build discards all previously built state". Existing builders which expect FULL_BUILD to mean that (and follow the JavaDoc) will treat it as a CLEAN followed by INCREMENTAL, as CDT does - or, put another way, will re-compile every source file irrespective of whether a derived file already exists with a newer timestamp. > Also, what delta would be supplied on the incremental build? Wouldn't the > platform convert it to FULL_BUILD again? None. Yes the current platform implementation would promote INCREMENTAL to FULL, but that's an implementation detail. Note that an incremental build, having removed all derived resources after a clean, is a full build. (In reply to comment #5) > (In reply to comment #4) > > It looks to me that FULL_BUILD != CLEAN_BUILD + INCREMENTAL_BUILD. Some > > builders may be capable to rebuild all resources without cleaning. In this case > > extra CLEAN_BUILD would result in inefficient processing at the very least. The point I was trying to make is that you can't just re-write the API to say something different and incompatible to what it says today. Any API caller which explicitly requests FULL_BUILD might expect every resource to be rebuilt. This won't work with builders that ignore this. For CDT builders it's neither here-nor-there, as we might deem it too expensive and just ignore the FULL_BUILD request and treat it as incremental. I was just pointing out that if the API doc is to be changed, it should be made clear to an API user what they need to do to fully rebuild a project. The only sensible way (and what the UI does) is to do a CLEAN followed by INCREMENTAL, rather than calling project.build(FULL_BUILD,...). I think that the JavaDoc need to be honest about what the platform itself does and leave the builder behavior to builders. CDT builders do have a need for more sophisticated behavior then the platform could possibly prescribe. They would build a specific configuration or a set of configurations. MakeTarget builder could build a not related target. FULL_BUILD event just discards build state for the current CDT configuration but doesn't for others. The current API documentation as well just misleads API callers on relying on things some builders won't do. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |