|
|
The ClearCase omake utility is based on Opus Config Builder 6.10, from OPUS Software, and is compatible with most of its makefiles. It has been extended to include the fundamental ClearCase build features. This section describes the ClearCase extensions and offers some basic usage guidelines. Other sources of help on omake:
omake reference page (in the Command Reference)
omake -h
omake -EN -h (help on NMAKE compatibility mode)
omake -EP -h (help on PolyMake compatibility mode)
For more information on the ClearCase build model, see Building Software and the clearmake reference page.
The features described here constitute the core of ClearCase build configuration management.
ClearCase omake uses a build-avoidance scheme based on configuration lookup that is more sophisticated than the conventional make and Opus Make schemes, which are based on time stamps of built objects. For example, the omake build-avoidance scheme guarantees correct build behavior as C-language header files change, even if the header files are not listed as dependencies in the makefile. By default, omake uses configuration lookup when you are working in a view, and the target is located in the MVFS.
Developers working in different views can share the MVFS objects created by omake builds. See the clearmake reference page for details.
omake audits the build operations, generating software bill-of-materials records, called configuration records, that fully document a build. In the process, omake also performs automatic dependency detection. By default, configurations records are created whenever you run omake from a ClearCase view, and derived files are stored in the MVFS. See the clearmake and catcr reference pages for details.
You can use either omake or clearmake during an express build, which is a build that creates nonshareable derived objects. Express builds do not write DO information to the VOB, and therefore enhance site-wide performance because they do not block other users' access to the VOB. For more information on express builds, see Building Software.
The following options have been added to omake:
-L | Disables configuration lookup and config record creation. See also clearmake -F. |
-O | Disables build script checking during configuration lookup. |
-v | Increases output verbosity during the build process (particularly with respect to configuration lookup and config record creation). NOTE: The Opus Make -V option, which prints the version string, has been removed. |
-W | Disables shopping for derived objects to wink in. See also clearmake -V. |
-T | Examines sibling derived objects when determining whether a target object in a VOB can be reused. See also clearmake -O. |
The CCASE_AUDIT_TMPDIR environment variable controls the location of build audit temporary files. By default, these files are stored in the directory named by the TMP environment variable. If you do not set CCASE_AUDIT_TMPDIR, make sure that TMP is set to a valid temporary storage directory on a FAT, NTFS, or LAN Manager file system. Note that setting CCASE_AUDIT_TMPDIR to a location on a remote file system increases build times.
omake supports local and remote non-MVFS dependencies:
If the dependency resides on a local drive, you can use the local drive letter. However, to share the applicable derived object, users on other hosts must access the dependency using the same drive-specific pathname.
If the dependency resides on a remote host, you must use UNC names. (If you use drive letters, only users with identical network drive configurations can share the resultant DOs.)
$? means all dependencies, not just out-of date dependencies for targets for which configuration lookup is used.
Double-colon (::) rules. If any instance of a double-colon rule is out of date (based on configuration lookup), all double-colon build scripts for the affected target are executed. Conversely, if an error occurs during a build of the target of a double-colon rule, the target's remaining build scripts are not executed, and no config records or derived objects are constructed. For example:
install::foo.exe
copy foo.exe \inst\bin
install::bar.exe
copy bar.exe \inst\bin
If foo.exe or bar.exe is out of date, both build scripts are executed. (Both programs are copied.)
Typically, you run omake from a view using the following procedure:
Set a view context by assigning a drive to a view (with Tools > Map Network Drive in Windows Explorer or the net use command) and changing to that view:
c:\> net use f: \\view\myview
c:\> f:
f:\>
Change to the appropriate directory and run omake:
|
f:\> cd myvob\src |
(\Q\myvob' is the VOB-tag) |
f:\myvob\src> omake options
You are using a view context to prevent VOB pathnames from being dependent on the view the build occurs in. From f:, you (and your makefiles) can access versioned objects with non-view-extended, absolute VOB pathnames such as \vob2\src\main.c in either cleartool commands or standard operating system commands.
If you work directly on M:, in view-extended namespace, full pathnames to VOB objects include a view-specific prefix, which can affect configuration lookup so as to prevent DO sharing between views.
There are several rules to follow when constructing, or converting, makefiles for use by omake on a Windows NT host.
It is possible, but not trivial, to prepare makefiles that can be used with either omake or clearmake. The general approach is to supply omake-specific macro definitions in the makefile, and to supply clearmake-specific macro overrides in a build options specification (BOS) file; clearmake reads the BOS file, but omake does not. When clearmake executes, it looks for macro definitions in two locations:
%HOME%\.clearmake.options
makefile.options, in the same directory as makefile (substitute the actual name of your makefile, if it is not makefile)
BOS files at other locations can be passed to clearmake with the -A option.
Each omake build executes serially on the local Windows NT host. Parallel and distributed build operations are not available.
It is common for a makefile to include a target whose build script invokes a command such as rm to delete files. Some Windows NT installations include rm commands that do not actually delete a file, but move it to a deleted directory instead. As a result, build script temporary files become sibling DOs of the targets. To avoid this problem, use a remove command-del, for example-that actually deletes files.
In a config record created on Windows NT, MVFS object pathnames begin with the VOB-tag and do not include view-tag prefixes. For example:
...
---------------------------- MVFS objects: ----------------------------
\proj1\include\cmsg.h@@\main\nt3\39 <22-Jul-94.17:49:53>
\proj1\lib\fsutl.h@@\main\12 <22-Jun-94.12:07:24>
...
Pathnames in this format can be cut and copied, and applied elsewhere as is, if you are on a drive assigned to a view (with Tools > Map Network Drive in Windows Explorer or the net use command).
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
