platform-core-home/documents/3.1/large_scale_builders.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.1 - (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 :     <font size="-1">Last modified: December 13, 2004</font>
13 :     <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 :    
81 :    
82 :    
83 :    
84 :    
85 :     (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=60803">60803</a>).
86 :     </p>
87 :    
88 :    
89 :    
90 :     </body>
91 :     </html>