platform-core-home/documents/3.1/large_scale_builders.html
Parent Directory
| 
Revision Log
Revision 1.2 - (view) (download) (as text)
| 1 : | johna | 1.1 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| 2 : | <html> | ||
| 3 : | <head> | ||
| 4 : | <title>Large-scale builder issues</title> | ||
| 5 : | <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css"> | ||
| 6 : | </head> | ||
| 7 : | <body text="#000000" bgcolor="#FFFFFF"> | ||
| 8 : | |||
| 9 : | <table width="100%"> | ||
| 10 : | <tr><td style="background:#0080C0"><b><span style="color:white">Large-scale builder issues</span></b></td></tr> | ||
| 11 : | </table> | ||
| 12 : | johna | 1.2 | <font size="-1">Last modified: December 22, 2004</font> |
| 13 : | johna | 1.1 | <p> |
| 14 : | The workspace builder infrastructure is designed primarily with efficient | ||
| 15 : | incremental compilers in mind. Eclipse exposes just two fundamental build | ||
| 16 : | modes: auto-build and manual build. This simplifies the user experience, | ||
| 17 : | but is not sufficient when a workspace has a mixture of fast and slow builders, | ||
| 18 : | and/or a mixture of small and large projects. The working set build concept | ||
| 19 : | introduced in Eclipse 3.0 improves the situation, but is still not flexible enough | ||
| 20 : | in some cases. | ||
| 21 : | </p> | ||
| 22 : | <h3>Problem Overview</h3> | ||
| 23 : | <p> | ||
| 24 : | Eclipse-based builders currently provide a number of configuration options | ||
| 25 : | that are not part of the platform builder infrastructure: | ||
| 26 : | <ul> | ||
| 27 : | <li>Each Ant builder instance allows the user to specify if the builder runs | ||
| 28 : | on autobuild, manual build, clean build, or any combination thereof.</li> | ||
| 29 : | <li>CDT provides a per-project setting to specify whether C builders respond | ||
| 30 : | to autobuild ("Build on Resource Save"). This is turned off by default.</li> | ||
| 31 : | <li>The external tools plug-in provides a property page that allows the user | ||
| 32 : | to turn *any* builder on or off completely.</li> | ||
| 33 : | </ul> | ||
| 34 : | These approaches have some problems: | ||
| 35 : | <ul> | ||
| 36 : | <li> | ||
| 37 : | Out of the box, CDT projects cannot be built. The workspace auto-build setting | ||
| 38 : | is on by default, which causes the manual build commands to be disabled in the UI. | ||
| 39 : | The per-project auto-build setting for C builders is off by default. Thus there is | ||
| 40 : | no UI command available to run them, except for the "Clean" command which is | ||
| 41 : | always available. This command is not appropriate because it requests that <b>all</b> | ||
| 42 : | builders discard their built state, preventing them from running incrementally on the | ||
| 43 : | next build. If Ant builders are configured to not run on auto-build, they have the same problem. | ||
| 44 : | </li><li> | ||
| 45 : | Both CDT and Ant builders have per-project auto-build settings, but the | ||
| 46 : | options have different names and are found in different places. There is no cohesive | ||
| 47 : | user experience for these settings. | ||
| 48 : | </li><li> | ||
| 49 : | Not all plug-ins behave well when they are disabled by the user. Thus the external | ||
| 50 : | tool plug-in's "Builders" property page gives the user more control than it should. | ||
| 51 : | </li> | ||
| 52 : | </ul> | ||
| 53 : | <p> | ||
| 54 : | The platform needs to introduce more flexibility in how and when builders are | ||
| 55 : | run. This support needs to have the following characteristics: | ||
| 56 : | <ul> | ||
| 57 : | <li> | ||
| 58 : | The end-user experience out of the box must continue to be simple. Autobuild | ||
| 59 : | should still be on by default when all existing builders are truly incremental, | ||
| 60 : | and manual build commands should be disabled. | ||
| 61 : | </li> | ||
| 62 : | <li> | ||
| 63 : | Flexibility must be controlled. Plug-ins that implement builders must be able | ||
| 64 : | to specify what kind of flexibility they want to expose to their users. Builders | ||
| 65 : | should be able to specify what their out of box behaviour is. | ||
| 66 : | </li> | ||
| 67 : | <li> | ||
| 68 : | Flexibility, when available, must be presented consistently. The flexibility | ||
| 69 : | should also not be prominent since it is an advanced feature that shouldn't | ||
| 70 : | clutter and confuse the UI for basic users. | ||
| 71 : | </li> | ||
| 72 : | <li> | ||
| 73 : | Build commands in the Project menu and Navigator context menu should | ||
| 74 : | be available only when appropriate. Build All should be enabled when | ||
| 75 : | there are one or more builders in the workspace that do not respond to | ||
| 76 : | automatic build but do respond to manual builds. Build Project should only be | ||
| 77 : | available when one or more projects in the current selection has that characteristic. | ||
| 78 : | </li> | ||
| 79 : | </ul> | ||
| 80 : | johna | 1.2 | <h3>Proposed Solution</h3> |
| 81 : | <p> | ||
| 82 : | The builders extension point will introduce an "isConfigurable" attribute that | ||
| 83 : | specifies whether a builder allows configuration of what build triggers it responds | ||
| 84 : | to. Here is an example of a builder definition using this new attribute: | ||
| 85 : | <pre> | ||
| 86 : | <extension point="org.eclipse.core.resources.builders" id="flexbuilder" name="Flexible Builder"> | ||
| 87 : | <builder <b>isConfigurable="true"</b>> | ||
| 88 : | <run class="org.eclipse.core.tests.internal.builders.FlexibleBuilder"/> | ||
| 89 : | </builder> | ||
| 90 : | </extension> | ||
| 91 : | </pre> | ||
| 92 : | Builders that don't specify this attribute will never be configurable. | ||
| 93 : | <p> | ||
| 94 : | For configurable builders, new API on <tt>ICommand</tt> will allow a client | ||
| 95 : | to programmatically specify what triggers that command responds to. The new | ||
| 96 : | methods on <tt>ICommand</tt> are: | ||
| 97 : | <ul> | ||
| 98 : | <li><tt><b>isConfigurable</b>()</tt> - returns the value of the <tt>isConfigurable</tt> attribute | ||
| 99 : | in the builder extension definition.</li> | ||
| 100 : | <li><tt><b>isBuilding</b>(int trigger)</tt> - Indicates if a build command is currently | ||
| 101 : | responding to a given build trigger. Triggers are represented by the | ||
| 102 : | <tt>IncrementalProjectBuilder.*_BUILD</tt> constants.</li> | ||
| 103 : | <li><tt><b>setBuilding</b>(int trigger, boolean value)</tt> - Changes whether a build | ||
| 104 : | command responds to a given build trigger. This method has no effect for builders | ||
| 105 : | that are not configurable.</li> | ||
| 106 : | </ul> | ||
| 107 : | <p> | ||
| 108 : | When a builder's triggers are configured, the result will be persisted in the | ||
| 109 : | <tt>.project</tt> file. This allows sharing of the custom build triggers with | ||
| 110 : | other team members. Here is an example of the build spec from a project description | ||
| 111 : | file with a builder that does not respond to the autobuild trigger. The new | ||
| 112 : | <tt>triggers</tt> element specifies the active triggers for the command: | ||
| 113 : | <pre> | ||
| 114 : | <buildSpec> | ||
| 115 : | <buildCommand> | ||
| 116 : | <name>org.eclipse.core.tests.resources.flexbuilder</name> | ||
| 117 : | <b><triggers>incremental,clean,full</triggers></b> | ||
| 118 : | <arguments> | ||
| 119 : | </arguments> | ||
| 120 : | </buildCommand> | ||
| 121 : | </buildSpec> | ||
| 122 : | </pre> | ||
| 123 : | <p> | ||
| 124 : | The build infrastructure will consult the build command each time build API is called | ||
| 125 : | (<tt>IWorkspace.build</tt> and <tt>IProject.build</tt>). Builders will not be | ||
| 126 : | called on build triggers that they are configured to not respond to. | ||
| 127 : | <p> | ||
| 128 : | The UI build actions will use the <tt>isBuilding</tt> method to determine | ||
| 129 : | whether various build commands are enabled for a particular selection. For example, | ||
| 130 : | if the selected project responds to the incremental build trigger, but not the | ||
| 131 : | autobuild trigger, then the <b>Build Project</b> command will remain enabled | ||
| 132 : | even when autobuild is turned on. This will allow the user to manually trigger "non-incremental" | ||
| 133 : | builders that are too slow to efficiently respond to the autobuild trigger, but allow | ||
| 134 : | autobuild to continue triggering other builders in the workspace. | ||
| 135 : | <p> | ||
| 136 : | <h3>References</h3> | ||
| 137 : | Bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=60803">60803</a>. | ||
| 138 : | johna | 1.1 | </p> |
| 139 : | </body> | ||
| 140 : | </html> |
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |