ClearCase build utility - maintain, update, and regenerate groups of programs
Product | Command Type |
---|---|
ClearCase | command |
ClearCase LT | command |
Platform |
---|
Windows |
omake is a ClearCase utility for making (building) software. It includes many of the configuration management (CM) facilities provided by the clearmake utility. It also features emulation modes, which enable you to use omake with makefiles that were constructed for use with other popular make variants, including Microsoft NMAKE, Borland Make and the PVCS Configuration Builder (Polymake).
NOTE: omake is intended for use in dynamic views. You can use omake in a snapshot view, but none of the features that distinguish it from ordinary make programs - build avoidance, build auditing, derived object sharing, and so on - works in snapshot views. The rest of the information in this reference page assumes you are using omake in a dynamic view.
omake features a number of ClearCase extensions:
Configuration Lookup - a build-avoidance scheme that is more sophisticated than the standard scheme based on the time-modified stamps of built objects. For example, this guarantees correct build behavior as C-language header files change, even if the header files are not listed as dependencies in the makefile.
Derived Object Sharing - developers working in different views can share the files created by omake builds.
Creation of Configuration Records - software bill-of-materials records that fully document a build and support rebuildability; also includes automatic dependency detection.
The following reference pages include information related to omake operations and results:
clearmake | Alternative make utility - provides the same functionality as the clearmake tool in the UNIX version of ClearCase. |
Alternative to make utilities, for performing audited builds without makefiles. | |
cleartool subcommand to list derived objects created by omake or clearaudit. | |
cleartool subcommands to display and compare configuration records created by omake or clearaudit. | |
cleartool subcommand to remove a derived object from a VOB. |
For a build that uses the data in one or more VOBs, the command interpreter from which you invoke omake must have a view context-you must be on a drive assigned to a view or the dynamic-views drive (default: M:\). If you want derived objects to be shared among views, you should be on a drive assigned to a view.
You can build objects in a standard directory, without a view context, but this disables many of omake's special features.
omake is designed to read makefiles in a way that is compatible with other make variants. For details, see the OMAKE Guide.
omake supports the options below. In general, standard make options are lowercase characters; omake extensions are uppercase. Options that do not take arguments can be ganged on the command line (for example, -rOi).
omake -n nt does a cd nt.dir
, then a recursive make with omake -n
. Without the .MAKE attribute, omake would display but not execute the (cd nt.dir & $(MAKE) $(MFLAGS) line.
|
|
"
-"
, the error messages are redirected to standard output.
|
|
String-valued variables called make macros can be used anywhere in a makefile: in target lists, in dependency lists, and/or in build scripts. For example, the value of make macro CFLAGS can be incorporated into a build script as follows:
cl $(CFLAGS) msg.c
Conflicts can occur in specifications of make macros and environment variables. For example, the same make macro might be specified both in a makefile and on the command line; or the same name might be specified both as a make macro and as an environment variable.
omake resolves such conflicts similarly to other make variants:
Make macros specified on the command line override any other settings.
Make macros specified in a makefile or make.ini file have the next highest priority.
Builtin macros override EVs, which in turn have the lowest priority.
Using the -e option changes the precedence rules - EVs get higher priority than make macros specified in a makefile.
CONFLICT RESOLUTION DETAILS. The following discussion treats this topic more precisely (but less concisely).
omake starts by converting all EVs in its environment to make macros. These EVs will also be placed in the environment of the command interpreter process in which a build script executes. Then, it adds in the make macros declared in the makefile. If this produces name conflicts, they are resolved as follows:
If omake was not invoked with the -e option, the make macro wins: the macro value overwrites the EV value in the environment.
If omake was invoked with the -e option, the EV wins: the EV value becomes the value of the make macro.
Finally, omake adds make macros specified on the command line; these settings are also added to the environment. These assignments always override any others that conflict.
omake reads the following environment variable at startup:
%
tmp%
. All temporary files are deleted when omake exits. CCASE_AUDIT_TMPDIR must not name a directory under a VOB-tag; if it does, omake prints an error message and exits.omake takes into account the fact that software builds are not instantaneous. As your build progresses, other developers can continue to work on their files, and may check in new versions of elements that your build uses. If your build takes an hour to complete, you would not want build scripts executed early in the build to use version 6 of a header file, and scripts executed later to use version 7 or 8. To prevent such inconsistencies, omake locks out any version that meets both these conditions:
The version is selected by a config spec rule that includes the LATEST version label.
The version was checked in after the time the build began (the build reference time).
This reference-time facility applies to checked-in versions of elements only; it does not lock out changes to checked-out versions, other view-private files, and non-MVFS objects. omake automatically adjusts for the fact that the system clocks on different hosts in a network may be somewhat out of sync (clock skew).
For more information, see Building Software.
omake returns a zero exit status if all goal targets are successfully processed. It returns various nonzero exit status values when the build is not successful. See the OMAKE Guide.
Build target hello.exe without checking build scripts or build options during configuration lookup. Be moderately verbose in generating status messages.
>
omake -v -O hello.exe
Build the default target in the default makefile, with a particular value of make macro INCL_DIR.
>
omake INCL_DIR=c:\src\include_test
Build target bgrs.exe, restricting configuration lookup to the current view only. Have environment variables override makefile macro assignments.
>
omake -e -W bgrs.exe
Unconditionally build the default target in a particular makefile, along with all its dependent targets.
>
omake -a -f project.mk
ccase-home-dir\bin\builtins.cb
ccase-home-dir\bin\builtins.nm
ccase-home-dir\bin\make.ini
clearmake, clearaudit, cleartool, config_spec, promote_server, scrubber, Building Software, OMAKE Guide
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |