Large-scale builder issues
Last modified: December 22, 2004

The workspace builder infrastructure is designed primarily with efficient incremental compilers in mind. Eclipse exposes just two fundamental build modes: auto-build and manual build. This simplifies the user experience, but is not sufficient when a workspace has a mixture of fast and slow builders, and/or a mixture of small and large projects. The working set build concept introduced in Eclipse 3.0 improves the situation, but is still not flexible enough in some cases.

Problem Overview

Eclipse-based builders currently provide a number of configuration options that are not part of the platform builder infrastructure:

These approaches have some problems:

The platform needs to introduce more flexibility in how and when builders are run. This support needs to have the following characteristics:

Proposed Solution

The builders extension point will introduce an "isConfigurable" attribute that specifies whether a builder allows configuration of what build triggers it responds to. Here is an example of a builder definition using this new attribute:

  <extension point="org.eclipse.core.resources.builders" id="flexbuilder" name="Flexible Builder">
    <builder isConfigurable="true">
      <run class="org.eclipse.core.tests.internal.builders.FlexibleBuilder"/>
    </builder>
  </extension>
Builders that don't specify this attribute will never be configurable.

For configurable builders, new API on ICommand will allow a client to programmatically specify what triggers that command responds to. The new methods on ICommand are:

When a builder's triggers are configured, the result will be persisted in the .project file. This allows sharing of the custom build triggers with other team members. Here is an example of the build spec from a project description file with a builder that does not respond to the autobuild trigger. The new triggers element specifies the active triggers for the command:

  <buildSpec>
    <buildCommand>
      <name>org.eclipse.core.tests.resources.flexbuilder</name>
      <triggers>incremental,clean,full</triggers>
      <arguments>
      </arguments>
    </buildCommand>
  </buildSpec>

The build infrastructure will consult the build command each time build API is called (IWorkspace.build and IProject.build). Builders will not be called on build triggers that they are configured to not respond to.

The UI build actions will use the isBuilding method to determine whether various build commands are enabled for a particular selection. For example, if the selected project responds to the incremental build trigger, but not the autobuild trigger, then the Build Project command will remain enabled even when autobuild is turned on. This will allow the user to manually trigger "non-incremental" builders that are too slow to efficiently respond to the autobuild trigger, but allow autobuild to continue triggering other builders in the workspace.

References

Bug 60803.