General > Workspace >
Build preferences page, you can configure how the projects inside the workspace will be built.On the
General > Workspace >
Build preferences page, you can configure how the projects inside the workspace will be built.
|
Option |
Description |
Default |
|---|---|---|
| Build automatically | If this option is turned on, then the Workbench will perform an automatic build whenever a modified resource is saved. | On |
| Save automatically before build | If this option is selected, when a manual build is performed the Workbench will automatically save all
resources that have been modified since the last build was performed. |
Off |
|
Use default builder order |
This option allows the platform to computes the build ordering. Turning off this option enables access to the projects list, the ordering of which can be manipulated. Often the order in which projects are built is important. For example, if one project requires the Java classes which were defined in another project, the first project must be built after its prerequisite classes have been built. The Workbench allows users to explicitly define the order in which projects are built. Alternatively, users can let the platform compute the build order by interpreting project references as prerequisite relationships. The build order is applied for both building the entire workspace or for a group of projects. |
On |
|
Project build order |
This option allows you to select projects and use the Up and Down buttons to change the build order. Add and remove projects in the build order using the Add Project and Remove Project buttons. Projects removed from the build order will be built, but they will be built after all projects in the build order are built. |
|
|
Max iterations when building with cycles |
This preference allows you to deal with build orders that contain cycles. Ideally, you should avoid cyclic references between projects. Projects with cycles really logically belong to a single project, and so they should be collapsed into a single project if possible. However, if you absolutely must have cycles, it may take several iterations of the build order to correctly build everything. Changing this preference will alter the maximum number of times the workbench will attempt to iterate over the build order before giving up. |
10 |
| Max simultaneous project builds |
Under some safe circumstances, the workspace can chose to build independent projects in parallel. In such
case, this preference controls the maximum amount of jobs/threads that will be running builds in parallel. A
value of 1 indicates that build won't be parallelized and keeps the legacy behavior.
The optimal value depends on your machine and workspace projects specificities. We do recommend to try
relatively low values (such as |
1 |