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:

• Each Ant builder instance allows the user to specify if the builder runs on autobuild, manual build, clean build, or any combination thereof.
• CDT provides a per-project setting to specify whether C builders respond to autobuild ("Build on Resource Save"). This is turned off by default.
• The external tools plug-in provides a property page that allows the user to turn *any* builder on or off completely.

• Out of the box, CDT projects cannot be built. The workspace auto-build setting is on by default, which causes the manual build commands to be disabled in the UI. The per-project auto-build setting for C builders is off by default. Thus there is no UI command available to run them, except for the "Clean" command which is always available. This command is not appropriate because it requests that all builders discard their built state, preventing them from running incrementally on the next build. If Ant builders are configured to not run on auto-build, they have the same problem.
• Both CDT and Ant builders have per-project auto-build settings, but the options have different names and are found in different places. There is no cohesive user experience for these settings.
• Not all plug-ins behave well when they are disabled by the user. Thus the external tool plug-in's "Builders" property page gives the user more control than it should.

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

• The end-user experience out of the box must continue to be simple. Autobuild should still be on by default when all existing builders are truly incremental, and manual build commands should be disabled.
• Flexibility must be controlled. Plug-ins that implement builders must be able to specify what kind of flexibility they want to expose to their users. Builders should be able to specify what their out of box behaviour is.
• Flexibility, when available, must be presented consistently. The flexibility should also not be prominent since it is an advanced feature that shouldn't clutter and confuse the UI for basic users.
• Build commands in the Project menu and Navigator context menu should be available only when appropriate. Build All should be enabled when there are one or more builders in the workspace that do not respond to automatic build but do respond to manual builds. Build Project should only be available when one or more projects in the current selection has that characteristic.