omake is a ClearCase utility for building software. It includes many of the configuration management 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 scheme 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 who work 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.
Related Reference Pages
The following reference pages include information related to omake operations and results:
See also Building Software.
View Context Required
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 (by default, drive M). If you want derived objects to be shared among views, you must be on a drive assigned to a view.
You can build objects in a standard directory, without a view context, but doing so disables many of omake's special features.
OPTIONS AND ARGUMENTS
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 grouped on the command line (for example, –rOi).
- –f makefile
- Use makefile as
the input file. If you omit this option, omake looks for
input files named makefile and Makefile (in
that order) in the current working directory. You can use more than one –f makefile argument
pair. Multiple input files are effectively concatenated.
- –b file
- Specify an initialization (built-ins) file
to be read instead of the default. If file is the
empty string, omake does not read an initialization file.
Valid empty strings are "–b " (one space), –b" ",
or –b "".
Note: If you do not include the –b option, omake uses the file named by the OMAKECFG environment variable. If this environment variable is not set, omake looks for a file called make.ini in (in order) the current directory, ccase-home-dir\bin, and in directories specified by the INIT environment variable.
- Rebuild all goal targets specified on the
command line, along with the recursive closure of their dependencies, regardless
of whether they need to be rebuilt.
- Abandon work on the current entry if it fails,
but continue on other targets that do not depend on that entry.
- Ignore error codes returned by commands.
- (no-execute) List command lines from the makefile
for targets that need to be rebuilt, but do not execute them. Lines that begin
with an at-sign (@) character are included in this list.
To override this option for a recursive make, use the .MAKE target attribute. For example:
Typing the commanddoes a cd nt.dir then a recursive make with omake –n. Without the .MAKE attribute, omake displays, but does not execute, the cd nt.dir & $(MAKE) $(MFLAGS) line.
omake –n nt
- (Silent) Do not list command lines before
- Environment variables override macro assignments
within the makefile. (But macro=value assignments
on the command line override environment variables.)
- Do not use the built-in rules.
- (Verbose) Slightly more verbose than the default output mode. Some particularly useful features of verbose mode:
- (Debug) Quite verbose; appropriate only for
- Lists all target descriptions and all macro
definitions, including target-specific macro definitions and implicit rules.
- Displays the command-line syntax.
- –x file
- Redirects error messages into file.
If file is “-”,
the error messages are redirected to standard output.
- Ignore the MFLAGS macro.
- Use automatic dependencies. This option is
enabled only if you are not using configuration lookup (because you are processing
non-MVFS files or using the –W option).
- (Check out DOs) Before building or winking
in a target, omake determines whether the target is a checked-in
DO that is visible in the view at the path named in the makefile. If such
a DO is found, omake -C checks it out
before rebuilding it or winking it in.
- Keep-directory mode. The first access of a
directory to look for a file results in the directory being read into memory.
- Restricts dependency checking to makefile
dependencies only — those dependencies declared explicitly in the makefile
or inferred from an inference rule. All detected dependencies are ignored.
For safety, this option disables winkin of DOs from other views; it is quite
likely that other views select different versions of detected dependencies.
For example, a derived object in your view may be reused even if it was built with a different version of a header file than is currently selected by your view. This option is mutually exclusive with –W.
- Makes the makefile before reading it.
- Emulates Microsoft NMAKE utility.
- Emulates PVCS Configuration Builder (PolyMake)
- Default emulation mode (that is, no emulation).
For details on emulation features, see the OMAKE Guide.
- –O –L (mutually exclusive)
- –O compares only
the names and versions of objects listed in the targets' CRs; it does not
compare build scripts or build options. This option is useful when this extra
level of checking would force a rebuild that you do not want. Examples:
only change from the previous build is the setting or canceling of a “compile-for-debugging”
target was built using a makefile in the current working directory. Now, you
want to reuse it in a build to be performed in the parent directory, where
a different makefile builds the target (with a different script, which typically
references the target using a different pathname).
–L makes rebuild decisions using the standard algorithm, based on time-modified stamps; configuration lookup is disabled. It also suppresses creation of configuration records. All MVFS files created during the build are view-private files, not derived objects.
- The only change from the previous build is the setting or canceling of a “compile-for-debugging” option.
- Restricts configuration lookup to the current
view only. Winkin of DOs from other views is disabled.
- Examines sibling derived objects (objects
created by the same build rule that created the target) when determining whether
a target object in a VOB can be reused (is up to date). By default, when determining
whether a target can be reused, omake ignores modifications
to sibling derived objects. –T directs omake to
consider a target out of date if its siblings have been modified or deleted.
- Read-time debugging mode. Displays omake reading
makefiles and interpreting conditional directives.
- Displays a warning when omake tries
to expand the value of an undefined macro.
- Displays a warning when omake reads
a makefile line that it can't understand.
- Do not delete generated response files and
MAKE MACROS AND ENVIRONMENT VARIABLES
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:
Conflicts can occur in specifications of make macros and environment variables. For example, the same make macro may be specified both in a makefile and on the command line; or the same name may 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 are also placed in the environment of the command interpreter process in which a build script executes. Then, omake adds 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 macro value overwrites the EV value in the environment.
- If omake was invoked with the –e option, 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:
- CCASE_AUDIT_TMPDIR (or CLEARCASE_BLD_AUDIT_TMPDIR)
- Sets the directory where omake creates
temporary build audit files. If this variable is not set, omake creates
these files in %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
- Checks in DOs checked out by omake –C unless
the build of the corresponding target fails or the automatic checkout of the
DO or a sibling DO fails. Checkout comments are preserved. The checkin is
invoked with the -ptime option to preserve the DO's modification
time. This environment variable has no effect unless you specify –C.
BUILD REFERENCE TIME AND BUILD SESSIONS
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 do 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.
- Build the default target in the default makefile, with a particular value of make macro INCL_DIR.
- Build target bgrs.exe, restricting configuration lookup to the current view only. Have environment variables override makefile macro assignments.
- Unconditionally build the default target in a particular makefile, along with all its dependent targets.