Community
Participate
Working Groups
hi, at the moment, a custom builder will not receive build requests (i.e. via Project -> Build project) when it can be determined that no project resources have changed for some project types, receiving all user-originating build requests, independent of whether any project resources have changed, is necessary in order to correctly respond by building a motivating example is detailed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=142470 Since some project builders will probably depend on the current behaviour, and if this is agreed upon as being a legitimate request, possible solutions might be to (1) allow some project natures to mark themselves as needing to receive all build events or (2) define a marker interface that builders can additionally implement, which marks them as needing to receive all build events thanks, Andrew
Does your builder make use of resource deltas at all in the incremental build case? If not, then your builder could call forgetLastBuiltState at the start of each build. This would result in your builder being called on every build request regardless of whether there are any changes (because without storing the last built state, we would be unable to compute whether the project had changed since the previous build). Background: This code to skip builders in unchanged projects is an important optimization. The optimization is mainly of interest when autobuild is turned on. Typically when autobuild is turned on, an autobuild is invariably invoked during startup. This optimization prevents builders from being called unless there are changes, so this avoids unnecesary plugin activations and builder initialization when it is not needed. I'm guessing in CDT autobuild is rarely used, so this platform-level optimization isn't as important.
hi John, > Does your builder make use of resource deltas at all in the incremental build case? yes, it does (or will - I think there may be a bug open on the makefile generating builder right now). There is also a second builder (non-make based) in the pipeline that certainly uses the incremental builder. > This optimization prevents builders from being called unless > there are changes, so this avoids unnecesary plugin activations and builder > initialization when it is not needed. I'm guessing in CDT autobuild is rarely > used, so this platform-level optimization isn't as important. thanks for the background info, thats good to know. I think plenty of people do turn off auto-build with CDT, but for smaller projects I know people do leave it on. This sounds as though it would need dealing with. For example, I don't think user's with autobuild selected would want a build to occur on startup. is there any distinction between builds invoked by the user directly, and builds that are implicitly invoked as a side-effect of other activity? thanks, Andrew
Within the platform we can distinguish manual build (hitting Ctrl+B or invoking "Build Project") from autobuild. When autobuild is on, we can't distinguish between a change explicitly triggered by a user action versus some implicit thing like a changed metadata file or marker.
I just realized I had been following up in a different bug... see bug 142470 for related discussion. Here is what I am thinking we should do: - Add a boolean attribute to the builder extension (not sure of a good name yet) that allows a builder to indicate that it always wants to be called. This is better than a marker interface, because that would require potentially activating the builder's plugin unnecessarily if it does not need to be called. - On *incremental* builds, check this attribute and ignore the empty delta optimization if requested. This is the build that is invoked via Ctrl+B, or Project > Build Project and Project > Build All. - For auto-build, continue to use the empty delta optimization in all cases. My rationale for this is that autobuild is by definition triggered only by resource changes. Changes to external files and other circumstances cannot affect whether autobuild is run. I.e., even if we eliminated the empty delta optiimzation, the problem would remain for builders such as those in CDT that autobuild will only run when resources in the workspace change. This also avoids the problem of unnecessary plugin activation on startup mentioned in comment #1.
Created attachment 44982 [details] suggested javadoc additions for IncrementalProjectBuilder constants hi John, these suggestions make sense to me :) one question though - if an AUTO_BUILD is by definition triggered by resource changes, how can an AUTO_BUILD have an empty delta associated with it? also, slightly off-topic but I've attached a patch with some suggested javadoc additions for the IncrementalProjectBuilder constants, since I realized I had misinterpreted what some of these mean, and I guess other might too. thanks, Andrew
> if an AUTO_BUILD is by definition triggered by resource > changes, how can an AUTO_BUILD have an empty delta associated with it? If any resource changes, an autobuild is invoked. Any builder that is affected by that change will be invoked. Other builders that are not affected by that change are not invoked. So, currently, a builder will never be called on AUTO_BUILD with an empty delta. This is a slight simplification - for more info see "Gory details about the build process" in this article: http://www.eclipse.org/articles/Article-Builders/builders.html
By the way, I have released your suggested changes to the javadoc with some minor edits. In particular, "triggered by the user" is not accurate at the core level - it is really triggered by someone calling the IProject#build or IWorkspace#build API methods. One client that invokes those methods is the Eclipse IDE, but there could be others.
Done. The builder extension point now has an optional attribute "callOnEmptyDelta". When this is "true", then that builder will be called on incremental build even when the resource deltas for its projects are empty. The behaviour of autobuild, manual build, and clean build are unaffected. See the builder extension point doc in upcoming builds for more details. Automated tests added: EmptyDeltaBuilder/EmptyDeltaTest.
