Description Andrey Loskutov 2020-10-27 08:18:20 EDT

AS IS: The code in org.eclipse.core.internal.events.BuildManager.basicBuildLoop(IBuildConfiguration[], IBuildConfiguration[], int, MultiStatus, IProgressMonitor) loops over all known build configs independently if a previous build config has requested a rebuild via org.eclipse.core.resources.IncrementalProjectBuilder.needRebuild() (that would then change rebuildRequested to true and restart the build loop).

We see in our build that projects with many builders (== many build configs) after one of the builders detects a case for a rebuild and we actually want to skip the remaining, the remaining builders still run even if they better would wait for preceding builders to be re-triggered, so at the end they run twice instead of running only once.

To be more concrete: we have projects that are setup to invoke those builders in this order:

java builder
custom builder
xtext builder

So if custom builder detects some broken project config (e.g. missing library or wrong JRE version setting etc), it fixes the config and set rebuildRequested flag via needRebuild().

At that point Xtext builder tries to build something before java builder (which is affected by the config change) has a chance to rebuild the project. Of course that ends up in either extra Xtext build efforts for nothing.

TO BE: the proposal would be to check for rebuildRequested inside the loop, before triggering basicBuild() on single config, and continue with the outer loop. So if one builder requests rebuild, following aren't executed before all predecessors re-triggered again.

The code change seem to be trivial, so I wonder if there was a good reason NOT to implement it as proposed from very beginning. Unfortunately I haven't found any hint in the code...

I will push a gerrit to show what I mean shortly, may be we will see tests failing after that that would explain "why it is like it is".