-
On the Build Classes page, click New Build Class.
This opens an empty build class details page.
-
Name the build class.
The build class name identifies the class to eMake for invoking a build.
You must assign the build’s class name through an eMake command-line option when the build is invoked:
--emake-class=<exact build class name>. If no build class is assigned, the Cluster Manager assigns the build to the default class. If the class name typed on the eMake command line does not match a class name already in Cluster Manager, eMake exits. -
Enter the build class tag definition.
To avoid errors, follow standard naming conventions for tag definitions by using numbers, letters, and underscores only without leading or trailing white space. Use a percent sign on either side of any variables used. (For example,
%DATE%.) Use underscores (_) instead of spaces. -
Edit the remaining fields or keep their default values. See Build Classes - Create or Edit a Build Class for field definitions.
-
Click OK when all fields are completed.
When you return to the Build Classes page, you will see the new build class in the table.
Build class examples
Suppose your company has two major product lines: SuperSoftware and MegaSoftware. SuperSoftware runs on Windows and Solaris platforms. MegaSoftware runs on Windows only. You could begin by setting up three classes that include the product name, the platform, and the current version number for each product:
-
You could name the first class
Supersoftware_Win_v.2.1. The tag definition for this class would be:
%BUILD_CLASS%_%LC%_%a%_%b%_%d%_%H%_%M%_%S%
The result would be a series of builds each named, or tagged , with the product name, the platform, the version number, a serial number (unique to the class), and the date for each build, for example:
Supersoftware_Win_v.2.1_12345_WED_AUG_22_14_37_12
-
You could name the second class Supersoftware_Sol_v.1.7. The tag definition can be the same as in our first example because it would be distinguished by the second build class name. Build tags in the second class would look like:
Supersoftware_Sol_v.1.7_12356_WED_AUG_23_11_14_39
-
You could name the third class
MegaSoftware_Win_v.1.3. For this product, the tag definition would be similar to the previous examples, but also could include the name of the user who started the build because the MegaSoftware team is spread over several different locations. For this class, the tag definition might look like:%BUILD_CLASS%%LC%%USER_NAME%_%DATE%
As in the first two examples, the result would be a sequentially numbered series of builds with the product name, platform, version number, name of the user who ran the build, and the date of each build assigned through the build class:
MegaSoftware_Win_v.1.3_12356_JSMITH_20050411100838
Additional classes could be created when the development of SuperSoftware or MegaSoftware entered a new phase, such as a new platform release or a new version release. In this way, the builds for each stage of development can be segmented into logical sets facilitating a more manageable and organized workflow.