clearmake

ClearCase build utility; maintains, updates, and regenerates groups of programs

APPLICABILITY

ClearCase (command)

SYNOPSIS

• Build a target:

  clearmake [ -f makefile ] ...  [ -ukinservwdpqUNR ]

  
  

  [ -C compat-mode ] [ -V | -M ] [ -O | -T | -F ]
  [ -A BOS-file ] ... [ macro=value ... ] [ target-name ... ]

• Display version information for clearmake:

  clearmake { -ver·sion | -VerAll }

DESCRIPTION

clearmake is ClearCase's variant of the UNIX make utility. It features a Gnu make compatibility mode, which enables you to use clearmake with makefiles that were constructed for use with Gnu make.

clearmake features a number of ClearCase extensions:

• Configuration Lookup-A build-avoidance scheme that is more sophisticated than the standard scheme, which is based on the time stamps of built objects. Configuration lookup also includes automatic dependency detection. 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 clearmake builds.
• Creation of Configuration Records-Software bill-of-materials records that fully document a build and support the ability to rebuild.

NOTE: clearmake is intended for use in dynamic views. You can use clearmake in a snapshot view, but most of the features that distinguish it from ordinary make programs-build avoidance, build auditing, derived object sharing, and so on-are not enabled in snapshot views. (Parallel builds are enabled.) The rest of the information in this reference page assumes you are using clearmake in a dynamic view.

Related Reference Pages

The following reference pages include information related to clearmake operations and results:

See also Building Software with ClearCase.

View Context Required

For a build that uses the data in one or more VOBs, the command interpreter from which you invoke clearmake must have a view context; you must be on the dynamic-views drive (default: M:\) or a drive assigned to a view. 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 this disables many of clearmake's special features.

clearmake AND MAKEFILES

clearmake is designed to read makefiles in a way that is compatible with other make variants. For details, including discussions of areas in which the compatibility is not absolute, see Using clearmake Compatibility Modes in Building Software with ClearCase.

For more information about makefiles and clearmake, see clearmake Makefiles and BOS Files in Building Software with ClearCase.

HOW BUILDS WORK

In many ways, ClearCase builds adhere closely to the standard make paradigm:

1. You invoke clearmake, optionally specifying the names of one or more targets. (Such explicitly specified targets are called "goal targets.")
2. clearmake reads zero or more makefiles, each of which contains targets and their associated build scripts. It also reads zero or more build options specification (BOS) files, which supplement the information in the makefiles.
3. clearmake supplements the makefile-based software build instructions with its own built-in rules, or (when it runs in a compatibility mode) with built-in rules specific to that mode.)
4. For each target, clearmake performs build avoidance, determining whether it actually needs to execute the associated build script (target rebuild). It takes into account both source dependencies (Have any changes occurred in source files used in building the target?) and build dependencies (Must other targets be updated before this one?).
5. If it decides to rebuild the target, clearmake executes its build script.

The following sections describe special clearmake build features in more detail. Figure 8 illustrates the associated data flow.

Figure 8 Data Flow in a clearmake Build

CONFIGURATION RECORDS AND DERIVED OBJECTS

In conjunction with the MVFS file system, clearmake audits the execution of all build scripts, keeping track of file use at the system-call level. For each execution of a build script, it creates a configuration record (CR), which includes the versions of files and directories used in the build, the build script, build options, (for example, macro assignments) and other related information. A copy of the CR is stored in the VOB database of each VOB in which the build script has built new objects.

A file created within a VOB by a build script is called a derived object (DO), and it can be shareable or nonshareable. When a shareable derived object is built in a view, a corresponding VOB database object is also created. This enables any view to access and possibly share (subject to access permissions) any derived object, no matter what view it was originally created in.

When a build tool creates a nonshareable derived object, the tool does not write any information about the DO to the VOB. Therefore, the DO is invisible to other views and cannot be winked in by them. Builds that create nonshareable DOs are called express builds. For more information about using express builds, see Preventing Winkin to Other Views.

NOTE: Symbolic links created by a build script and files created in non-VOB directories are not DOs. See MVFS FILES AND NON-MVFS OBJECTS.

For each build script execution, ClearCase logically associates each DO created with the build script's CR.

You can suppress the creation of CRs and derived objects with the -F option. For details on CRs, derived objects, see Derived Objects and Configuration Records in Building Software with ClearCase. For information on ClearCase-specific special targets, see clearmake Makefiles and BOS Files in Building Software with ClearCase.

Configuration Record Hierarchies

A typical makefile has a hierarchical structure. Thus, a single invocation of clearmake to build a high-level target can cause multiple build scripts to be executed and, accordingly, multiple CRs to be created.

CONFIGURATION LOOKUP AND WINKIN

For directory targets, clearmake uses standard make logic.

When a target names a nondirectory file in a VOB, clearmake (by default) uses configuration lookup to determine whether a build is required. This involves comparing the CRs of existing DOs with the current build configuration:

• The versions of elements selected by the view's config spec.
• The build options to be applied, as specified on the clearmake command line, in the environment, in makefile(s), or in build options specification file. See BUILD OPTIONS SPECIFICATION FILE.
• The build script to be executed.

In performing configuration lookup, clearmake considers a DO version (a derived object that has been checked in as a version of an element) only if the version's element has the same pathname as the original derived object. That is, if you copy a DO to a different location from where it was created and check it in there, clearmake does not consider the DO version.

clearmake first tries to avoid rebuilding by reusing a DO in the current view; this succeeds only if the CR of the candidate DO matches the current build configuration. For the purpose of rebuilding, a branch/0 version of a file selected by a view is considered to match its non-zero predecessor version in a CR.

clearmake can also avoid rebuilding by finding a shareable DO, built in another view, whose CR matches the current build configuration. In this case, it winks in (winkin) that derived object, causing it to be shared among views. Other derived objects created by the same build script (siblings) are winked in at the same time. clearmake rebuilds a target only if it cannot locate any existing derived object that matches the current build configuration.

The .cmake.state File

The .cmake.state file is a view-private cache of config records for derived objects built in the view. clearmake creates this file in the directory that was current when the build started. During subsequent builds in that directory in the view, clearmake references the file instead of communicating with the VOB. This makes configuration lookup faster, improving clearmake performance.

You can delete .cmake.state files if they get too large. When clearmake looks for a .cmake.state file and it doesn't exist, no errors occur and clearmake creates a new file.

Suppressing Configuration Lookup

You can override the default configuration lookup behavior with command options and ClearCase special targets. (For information on ClearCase special targets, see clearmake Makefiles and BOS Files in Building Software with ClearCase). For example, -T turns off configuration lookup, basing rebuild decisions on time stamps, and -V disables winkin of DOs from other views.

Preventing Winkin to Other Views

You can prevent derived objects that you create from being winked in to other views by using express builds. During an express build, clearmake creates nonshareable DOs. These DOs have config records, but clearmake does not write information about the DOs into the VOB. DOs created during an express build are invisible to other views. To use express builds, invoke clearmake in a view configured with the nonshareable DOs property:

• To configure an existing view for express builds, use chview -nshareable_dos view-tag. See the chview reference page for more information.
• To create a new view and configure it with the nonshareable DOs property, use the mkview command and specify the -nshareable_dos option. See the mkview reference page for more information.
• Use the -T or -F options to create view-private files only.
• Use special targets that prevent winkin; for example, .NO_WINK_IN. For more information, see clearmake Makefiles and BOS Files in Building Software with ClearCase.
• Set an environment variable that will be recorded in the config records clearmake creates.

MVFS FILES AND NON-MVFS OBJECTS

All files with pathnames below a VOB-tag (VOB mount point) are termed MVFS files:

• Checked-in versions of file elements (data stored in VOB)

• Checked-out versions of file elements (data stored in view)
• Other view-private files
• Derived objects

Conversely, a non-MVFS object is any file or directory whose pathname is not under a VOB-tag; such objects are not version controlled. By default, non-MVFS objects are not audited during clearmake builds. Non-MVFS files that are read during a build are not included in the detected dependency list of the CR, and non-MVFS files that are created are not ClearCase derived objects. A CR includes information on a non-MVFS object used by a build script only if either of these conditions are true:

• The object appears as an explicit dependency in the makefile.

• The object can be inferred to be a dependency through clearmake's file-name extension rules.

The explicit dependency is referred to as a makefile dependency. For example:

src.o : c:\msvc20\include\stdio.h

BUILD OPTIONS SPECIFICATION FILE

A build options specification (BOS) file is a text file containing macro definitions and/or ClearCase special targets. We recommend that you place nonpermanent option specifications (for example, a macro that specifies "compile for debugging") in a BOS file, instead of on the clearmake command line. This minimizes the likelihood of having clearmake perform a rebuild unexpectedly (for example, because you specified /Zi on a compiler command line last time, but forgot to specify it this time).

See clearmake Makefiles and BOS Files in Building Software with ClearCase for details.

clearmake SLEEP

clearmake can monitor the current VOB's lock status during a build, so that if an administrator locks the VOB while clearmake is running, the build does not terminate abnormally. Before executing the build script and before creating a derived object and configuration record, clearmake checks the lock status of the current VOB. If the VOB is locked, clearmake starts a sleep-check cycle. When it finds the VOB unlocked, the build proceeds.

NOTE: clearmake starts the sleep-check cycle even if the user who invokes the build is on the exception list for the lock.

When a sleep-check cycle begins, clearmake prints a message announcing the sleep, its duration, and the reason for it. Initially, clearmake checks the lock status 10 times, waiting 60 seconds between attempts. clearmake then increments the sleep time by 5 seconds and again tries 10 times, and so on. clearmake prints a sleep message at the start of each group of 10 retries.

This implementation does not guarantee that the build will not terminate abnormally. There are still a few "windows of failure." The build script will fail and terminate abnormally, and the build will terminate if any of these conditions is true:

• The build script modifies the VOB, either by running a cleartool command that modifies the VOB, or simply removing the derived object which is the target of the build.
• The build script writes to another VOB other than the current VOB, and the other VOB is locked.
• The VOB becomes locked in the short time between the check and the build script execution, and the build script has an action that modifies the VOB.

By default, clearmake checks the VOB containing the working directory that was current at the start of the build. To check a set of VOBs, set the environment variable CCASE_BLD_VOBS to the list of VOB-tags to check. Separate the VOB-tags in the list with a space, tab (\t), semicolon (;), or comma (,).

To disable the checks, set the environment variable CCASE_BLD_NOWAIT. When this environment variable is set, clearmake does not check for a VOB-lock (or wait for the VOB to be unlocked).

CACHING UNAVAILABLE VIEWS

When clearmake shops for a derived object to wink in to a build, it may find DOs from a view that is unavailable (because the view server host is down, the albd_server is not running on the server host, and so on). Attempting to fetch the DO's configuration record from an unavailable view causes a long time-out, and the build may reference multiple DOs from the same view.

clearmake and other cleartool commands that access configuration records and DOs (lsdo, describe, catcr, diffcr) maintain a cache of tags of inaccessible views. For each view-tag, the command records the time of the first unsuccessful contact. Before trying to access a view, the command checks the cache. If the view's tag is not listed in the cache, the command tries to contact the view. If the view's tag is listed in the cache, the command compares the time elapsed since the last attempt with the time-out period specified by the CCASE_DNVW_RETRY environment variable. If the elapsed time is greater than the time-out period, the command removes the view-tag from the cache and tries to contact the view again.

NOTE: The cache is not persistent across clearmake sessions. Each recursive or individual invocation of clearmake attempts to contact a view whose tag may have been cached in a previous invocation.

The default time-out period is 60 minutes. To specify a different time-out period, set CCASE_DNVW_RETRY to another integer value (representing minutes). To disable the cache, set CCASE_DNVW_RETRY to 0.

BUILD REFERENCE TIME AND BUILD SESSIONS

clearmake takes into account the fact that 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, clearmake locks out any version that meets both of 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. clearmake 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 Pointers on Using ClearCase Build Tools in Building Software with ClearCase.

EXIT STATUS

clearmake returns a zero exit status if all goal targets are successfully processed. It returns a nonzero exit status in two cases:

• clearmake itself detects an error, such as a syntax error in the makefile. In this case, the error message includes the string "clearmake".
• A makefile build script terminates with a nonzero exit status (for example, a compiler error).

See also the description of the -q option.

OPTIONS AND ARGUMENTS

clearmake supports the options below. In general, standard make options are lowercase characters and clearmake extensions are uppercase. Options that do not take arguments can be combined on the command line (for example, -rOi).

-f makefile

Use makefile as the input file. If you omit this option, clearmake 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.

-u

(Unconditional) 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. (See also -U.)

-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 which need to be rebuilt, but do not execute them. Even lines beginning with an at-sign (@) are listed. See clearmake Makefiles and BOS Files in Building Software with ClearCase.

Exception: A command containing the string $(MAKE) is always executed.

-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 or in a build options spec override environment variables.)

-r

(No-rules) Do not use the built-in rules in file ccase-home-dir\etc\builtin.mk. When used with -C, this option also disables reading platform-specific startup files. See the -C option for more information.

-v

(Verbose) Slightly more verbose than the default output mode. These features are particularly useful:

-w

(Working directory) Prints a message containing the working directory both before and after executing the makefile.

-d

(Debug) Quite verbose; appropriate only for debugging makefiles.

-p

(Print) Lists all target descriptions and all macro definitions, including target-specific macro definitions and implicit rules, and stops before executing anything.

-q

(Query) Evaluates makefile targets, but does not run the build scripts. clearmake returns 0 if the targets are up to date, and 1 if any targets need to be rebuilt. Note that clearmake treats a winkin of a derived object as a rebuild, so clearmake -q returns 1 if a DO can be winked in for a target.

-U

Unconditionally builds goal targets only. Subtargets undergo build avoidance. If you don't specify any target on the command line, the default target is the goal. (The -u option unconditionally builds both goal targets and build dependencies.)

-N

Disables the default procedure for reading one or more BOS files. For a description of the default procedure, see clearmake Makefiles and BOS Files in Building Software with ClearCase.

-R

(Reuse) 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, clearmake ignores modifications to sibling derived objects. -R directs clearmake to consider a target out of date if its siblings have been modified or deleted.

-C compat-mode

(Compatibility) Invokes one of clearmake's compatibility modes. (Alternatively, you can use environment variable CCASE_MAKE_COMPAT in a BOS file or in the environment to specify a compatibility mode.) compat-mode can be one of the following:

For details on compatibility mode features, see Using clearmake Compatibility Modes in Building Software with ClearCase.

-V

(View) Restricts configuration lookup to the current view only. Winkin is disabled. This option is mutually exclusive with -M.

-M

(Makefile) Restricts dependency checking to makefile dependencies only-those dependencies declared explicitly in the makefile or inferred from a suffix rule. All detected dependencies are ignored. For safety, this disables winkin.

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 -V.

-O (Objects)

-T (Time stamps)

-F (Files)

(-O, -T, and -F are 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 is useful when this extra level of checking would force a rebuild that you do not want. Examples:

-T makes rebuild decisions using the standard algorithm, based on time stamps; configuration lookup is disabled. (A CR is still created for each build script execution.)

NOTE: This option causes both view-private files and derived objects to be used for build avoidance. Because the view-private file does not have a CR to be included in the CR hierarchy, the hierarchy created for a hierarchical build has a gap wherever clearmake reuses a view-private file for a subtarget.

-F works like -T, but also suppresses creation of configuration records. All MVFS files created during the build are view-private files, not derived objects.

-A BOS-file ...

You can use this option one or more times to specify BOS files to be read instead of, or immediately after, the ones that are read by default. Using -N along with this option specifies "instead of"; omitting -N causes clearmake to read the -A file after reading the standard BOS files.

Alternatively, you can specify a semicolon-separated list of BOS file pathnames as the value of environment variable CCASE_OPTS_SPECS.

-ver·sion

Prints version information about the clearmake executable.

-VerAll

Prints version information about the clearmake executable and the ClearCase DLLs that clearmake uses.

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:

cl $(CFLAGS) msg.c

Environment variables (EVs) can also be used in a makefile, but only in a build script. For example:

print:
     print_report -style $$PRT_STYLE -dest $${PRT_DEST}.rpt

clearmake converts the double-dollar-sign ($$) to a single dollar sign; the EV is expanded in the shell in which the build script executes only if the shell recognizes the dollar sign ($) (cmd.exe does not).

Conflict Resolution

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 may be specified both as a make macro and as an environment variable.

clearmake resolves such conflicts similarly to other make variants; it uses the following priority order, from highest to lowest:

1. Target-specific macros specified in a BOS file
2. Target-specific macros specified in a makefile
3. Make macros specified on the command line
4. Make macros specified in a BOS file
5. Make macros specified in a makefile
6. Environment variables
7. Built-in macros

Using the -e option gives environment variables higher priority than make macros specified in a makefile.

Conflict Resolution Details. The following discussion treats this topic more precisely but less concisely.

clearmake starts by converting all EVs in its environment to make macros. (SHELL is an exception-see SHELL Environment Variable.) These EVs are also placed in the environment of the shell 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 clearmake was not invoked with the -e option, the macro value overwrites the EV value in the environment.
• If clearmake was invoked with the -e option, the EV value becomes the value of the make macro.

Finally, clearmake adds make macros specified on the command line or in a BOS file; these settings are also added to the environment. These assignments always override any others that conflict. (A command-line assignment overrides a BOS setting of the same macro.)

SHELL Environment Variable

clearmake does not use the SHELL environment variable to select the shell program in which to execute build scripts. It uses cmd.exe, unless you specify another program with a SHELL macro. You can specify SHELL on the command line, in the makefile, or in a build options spec; the value of SHELL must be a full pathname, including the file extension.

NOTE: If clearmake determines that it can execute the build script directly, it does not use the shell program even if you specify one explicitly. If you use .bat files in build scripts, you must make them executable (use the cleartool protect command). To force clearmake to always use the shell program, set the environment variable CCASE_SHELL_REQUIRED.

Specifying Command Options in an Environment Variable

The CCASE_MAKEFLAGS and MAKEFLAGS environment variables provide an alternative (or supplementary) mechanism for specifying clearmake command options. These environment variables can contain a string of keyletters, the same letters used for clearmake command-line options. (However, clearmake does not allow options that take arguments in a CCASE_MAKEFLAGS or MAKEFLAGS string. See Special Environment Variables for information about specifying options that are not supported through CCASE_MAKEFLAGS or MAKEFLAGS.)

For example, the commands

are equivalent to this one:

clearmake combines the value of CCASE_MAKEFLAGS or MAKEFLAGS with the options specified on the command line (if any). The combined string of keyletters becomes the value of the macro MAKEFLAGS, available to build scripts.

This is very useful for build scripts that involve recursive invocations of clearmake. When clearmake -n is applied to such a build script, all the nested invocations of clearmake pick up the "no-execute" option from the value of CCASE_MAKEFLAGS or MAKEFLAGS. Thus, no targets are actually rebuilt, even though many levels of clearmake command may be executed. This is one way to debug all of the makefiles for a software project without building anything.

clearmake uses one of CCASE_MAKEFLAGS or MAKEFLAGS, but not both. If CCASE_MAKEFLAGS is set, clearmake uses it. If CCASE_MAKEFLAGS is not set, clearmake looks for MAKEFLAGS.

If you use other make programs in addition to clearmake, putting clearmake-specific options in the MAKEFLAGS environment variable may cause the make programs to generate errors. Therefore, we suggest you use the CCASE_MAKEFLAGS and MAKEFLAGS environment variables in the following ways:

Special Environment Variables

The environment variables described below are also read by clearmake at startup. In some cases, as noted, you can also specify the information as a make macro on the command line, in a makefile, or in a BOS file.

CCASE_AUDIT_TMPDIR (or CLEARCASE_BLD_AUDIT_TMPDIR)

Sets the directory where clearmake and clearaudit create temporary build audit files. If this variable is not set or is set to an empty value, clearmake creates these files in the directory specified by the TMP environment variable. All temporary files are deleted when clearmake exits. If the value of CCASE_AUDIT_TMPDIR is a directory under a VOB-tag, clearmake prints an error message and exits.

NOTE: Multiple build clients can use a common directory for audit files. Names of audit files are unique because clearmake names them using both the PID of the clearmake process and the hostname of the machine on which the process is running.

Default:None.

CCASE_BLD_NOWAIT

Turns off clearmake's sleep-check cycle during a build. When this environment variable is set, clearmake does not check for a VOB-lock (or wait for the VOB to be unlocked). See clearmake SLEEP for more information.

CCASE_BLD_VOBS

A list of VOB-tags (separated with a space, tab (\t), semicolon (;), or comma (,)) to be checked for lock status during a build. If a VOB on this list is locked, clearmake goes into a sleep-check cycle. See clearmake SLEEP for more information.

CCASE_DNVW_RETRY

Specifies time-out period, in minutes, for clearmake to wait before trying to contact an inaccessible view listed in its cache. To disable the cache, set CCASE_DNVW_RETRY to 0.

Default: 60 minutes.

CCASE_MAKE_CFG_DIR (or CLEARCASE_MAKE_CONFIG_DIR)

Expands to the full pathname of the clearmake configuration directory in the ClearCase installation area-typically ccase-home-dir\config\clearmake.

CCASE_MAKE_COMPAT (or CLEARCASE_MAKE_COMPAT)

Specifies one of clearmake's compatibility modes. This EV takes the same values as the -C option. Specifying a -C option on the command line overrides the setting of this EV. This EV may also be coded as a make macro, but only in a BOS file (not in a makefile).

Default: None.

CCASE_OPTS_SPECS (or CLEARCASE_BLD_OPTIONS_SPECS)

A semicolon-separated list of pathnames, each of which specifies a BOS file to be read. You can use this EV instead of specifying BOS files on the command line with one or more -A options.

Default: None.

CCASE_SHELL_FLAGS (or CLEARCASE_BLD_SHELL_FLAGS)

Specifies command options to be passed to the subshell program that executes a build script command.

Default: None.

CCASE_SHELL_REQUIRED

Forces clearmake to execute build scripts in the shell program you specify with the SHELL macro. To make clearmake execute builds scripts in the shell program, set this EV to TRUE. To allow clearmake to execute build scripts directly, unset the EV.

Default: clearmake executes build scripts directly.

CCASE_VERBOSITY (or CLEARCASE_BLD_VERBOSITY)

Sets the clearmake message logging level, as follows:

If you also specify -v or -d on the command line, the higher value prevails.

Default: 0

CMAKE_PNAME_SEP

Sets the pathname separator for pathnames constructed by clearmake. This variable can also be coded as a make macro in the makefile or in a BOS file.

Default: If this variable is not set or is set to any other value than / or \ (the slashes), clearmake uses \ (a backslash) as the pathname separator.

EXAMPLES

• Unconditionally build the default target in a particular makefile, along with all its dependent targets.

z:\src> clearmake -u -f project.mk

• Build target hello without checking build scripts or build options during configuration lookup. Be moderately verbose in generating status messages.

z:\src> clearmake -v -O hello

• Build the default target in the default makefile, with a particular value of make macro INCL_DIR. Base rebuild decisions on time-stamped comparisons instead of performing configuration lookup, but still produce CRs.

y:\> clearmake -T INCL_DIR=\src\include_test

• Build target bgrs.exe, restricting configuration lookup to the current view only. Have environment variables override makefile macro assignments.

z:\src> clearmake -e -V bgrs.exe

FILES

ccase-home-dir\etc\builtin.mk

SEE ALSO

clearaudit, omake, promote_server, scrubber

Building Software with ClearCase