Build Order
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.
You can change this order on the
General > Workspace > Build Order
preferences page.
Option
|
Description
|
Default
|
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.
|
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 |
Here is what the Build Order preference page looks like:
Builds
Project menu