omake
ClearCase® build utility: Maintains, updates, and
regenerates groups of programs
Applicability
Product
|
Command
type
|
ClearCase
|
command
|
Synopsis
- omake [ –f makefile ...]
[ –b builtins-file ...]
- [ –akinservdphzACDGM] [ –x file ]
[ -OLWT ]
[ -EN | -EP | -EO]
[ -#1] [ -#2] [ -#4] [ -#8]
[–directOutput log_file]
[ macro=value ...]
[ target_name ...]
Description
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).
Restriction: 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 the IBM Rational ClearCase Guide to 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 special features of omake.
omake and makefiles
omake is designed to read
makefiles in a way that is compatible with other make variants.
For details, see the IBM Rational ClearCase OMAKE Guide.
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.
- –a
- 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.
- –k
- Abandon work on the current entry if it fails, but continue on other targets
that do not depend on that entry.
- –i
- Ignore error codes returned by commands.
- –n
- (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:
nt .MAKE :
cd nt.dir & $(MAKE) $(MFLAGS)
Typing
the command
omake –n nt
does 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.
- –s
- (Silent) Do not list command lines before executing them.
- –e
- Environment variables override macro assignments within the makefile.
(But macro=value assignments on the
command line override environment variables.)
- –r
- Do not use the built-in rules.
- –v
- (Verbose) Slightly more verbose than the default output mode. Some particularly
useful features of verbose mode:
- List of messages when omake does
not reuse a DO that already appears in your view (for example, because its
CR does not match your build configuration, or because your view does not
have a DO at that path name)
- List of names of DOs being created
- –d
- (Debug) Quite verbose; appropriate only for debugging makefiles.
- –p
- Lists all target descriptions and all macro definitions, including target-specific
macro definitions and implicit rules.
- –h
- Displays the command-line syntax.
- –x file
- Redirects error messages into file. If file is “-”, the error messages are redirected to standard output.
- –z
- Ignore the MFLAGS macro.
- –A
- 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).
- –C
- (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.
- –D
- Keep-directory mode. The first access of a directory to look for a file
results in the directory being read into memory.
- –G
- 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.
- –M
- Makes the makefile before reading it.
- –EN
- Emulates Microsoft NMAKE utility.
- –EP
- Emulates PVCS Configuration Builder (PolyMake) utility.
- –EO
- Default emulation mode (that is, no emulation).
For
details on emulation features, see the IBM Rational ClearCase 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:
- The only change from the previous build
is the setting or canceling of a “compile-for-debugging” option.
- A 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
path name).
–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.
- –W
- Restricts configuration lookup to the current view only. Winkin of DOs
from other views is disabled.
- –T
- 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.
- –#1
- Read-time debugging mode. Displays omake reading makefiles
and interpreting conditional directives.
- –#2
- Displays a warning when omake tries to expand the value
of an undefined macro.
- –#4
- Displays a warning when omake reads a makefile line
that it can't understand.
- –#8
- Do not delete generated response files and batch files.
- -directOutput logfile
- Redirects standard output to the specified file.
Environment variables and make macros
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:
Conflict resolution
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 exits.
- CCASE_AUTO_DO_CI
- 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.
Default: Undefined
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 the IBM Rational ClearCase Guide to Building Software.
Exit status
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 IBM Rational ClearCase OMAKE Guide.
Files
- ccase-home-dir\bin\builtins.cb
- ccase-home-dir\bin\builtins.nm
- ccase-home-dir\bin\make.ini
See also
catcr, clearmake, clearaudit, cleartool, config_spec, diffcr, lsdo, promote_server, rmdo, scrubber, IBM Rational ClearCase Guide to Building Software, IBM Rational ClearCase OMAKE Guide