Last modified: December 22, 2004
|Large-scale builder issues|
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.
Eclipse-based builders currently provide a number of configuration options
that are not part of the platform builder infrastructure:
These approaches have some problems:
- 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.
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">
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:
- isConfigurable() - returns the value of the isConfigurable attribute
in the builder extension definition.
- isBuilding(int trigger) - Indicates if a build command is currently
responding to a given build trigger. Triggers are represented by the
- setBuilding(int trigger, boolean value) - Changes whether a build
command responds to a given build trigger. This method has no effect for builders
that are not configurable.
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:
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.