The clearmake program has been designed for compatibility with existing make programs, minimizing the work necessary to switch to clearmake. There are many independently-evolving variants of make, however, which provide different sets of extended features. clearmake does not support all the features of all the variants, and absolute compatibility is not guaranteed.
If your makefiles use only the common extensions, they will probably work with clearmake as-is. If you must use features that clearmake does not support, consider using another make program in a clearaudit shell. This alternative provides build auditing (configuration records), but does not provide build avoidance (wink-in).
In its default mode, clearmake is designed to be compatible with System V Release 3 make(1) — “standard make”. Standard make represents a “least common denominator” for make functionality; most other variants of make are at least upward-compatible with standard make.
We suggest that you limit yourself to standard make functionality, since this allows maximum portability among hardware/software platforms, and among different variants of make on any single platform. It is also the most complete and most fully-tested of the clearmake modes.
In its default mode, clearmake supports most standard make description file syntax and command line options.
clearmake does not support standard make inference rules for SCCS files — special-case suffix rules using the tilde (~) character.
The following standard make options are not supported by clearmake:
clearmake allows you to specify one make-compatibility mode with a command-line option. Complete compatibility is not guaranteed — only the features listed in the sections below are supported.
clearmake supports these make-compatibility modes:
| -C sgismake | emulate IRIX 4.0.1 smake (on SGI hosts) | |
| -C sgipmake | emulate IRIX 4.0.1 pmake (on SGI hosts) | |
| -C sun | emulate SunOS 4.1.x make and SunOS 5.1 (Solaris) make | |
| -C gnu | emulate Gnu make |
Except where noted, descriptions of the features listed below can be found in the manual pages for the relevant make variant on the appropriate platform.
The following features are enabled when you specify -C sgismake:
all extended macro-assignment operators:
?= assign if undefined := expand RHS immediately += append to macro != assign result of shell command
all extended macro-expansion operators:
$(VAR:T) $(VAR:S/pattern/replace/) $(VAR:H) $(VAR:R) $(VAR:Mpattern) $(VAR:E) $(VAR:Npattern)
most makefile conditional directives:
#if (expressions may contain `defined' operator and `make' operator) #ifdef, #ifndef #ifmake, #ifnmake #else #elif #elifmake, #elifnmake #elifdef, #elifndef #endifmakefile inclusion with search rules similar to those of cpp(1):
#include <file>
look for file in /usr/include/make#include "file"
look for file in current directory, then in directories specified with -I command-line options, then in /usr/include/makecommand line option – I, for use with #include statements
aliases for internal make macros:
$(.TARGET) alias for $@ $(.PREFIX) alias for $* $(.OODATE) alias for $? $(.IMPSRC) alias for $< $(.ALLSRC) alias for $>
Note: $> is not supported by standard make(1). smake-specific builtins file: /usr/include/make/system.mk
inference rules with non-existent intermediates
search paths for dependencies (.PATH and .PATH.suffix)
deferring build script commands (“...” in build script)
.NULL target: specifies suffix to use when target has no filename suffix
.NOTPARALLEL target: disables parallel building
.MAKE target: specifies that a target corresponds to a sub-make; that target's build script is be invoked even when -n is used
When you specify -C sgipmake, all the SGI smake features listed above are enabled, along with the following:
if no target description file is specified on the command line, search for Makefile before searching for makefile
undefined macros in build scripts are left unexpanded
undefined macros outside build scripts cause a fatal error
one shell per build script (with -C sgismake, each command in the build script is executed in a separate shell)
The following features are enabled when you specify -C sun:
all extended macro-expansion operators:
+= append to macro :sh= assign result of shell command
pattern-replacement macro expansions:
$(macro:op%os=np%ns)
shell-execution macro expansions:
$(macro:sh)
conditional (target-dependent) macro definitions:
tgt-list := macro = value tgt-list := macro += value
Target names must be explicit — patterns with % cannot be specified.
special-purpose macros:
HOST_ARCH TARGET_ARCH HOST_MACH TARGET_MACH
sun-specific builtins file:
./default.mk or /usr/include/make/default.mk (SunOS 4.1.x)
./make.rules or /usr/share/lib/make/make.rules (SunOS 5.1)
Sun pattern-matching rules:
tp%ts : dp%ds
When you specify - C sun, clearmake uses the VPATH search list (if there is one) to look for the target if both these conditions are true:
the target's name is not an absolute pathname
there is no existing file corresponding to the target's name
For each directory in the value of VPATH, the directory path is concatenated with the target's name, and if there is an existing file at the resulting path, then that file is evaluated.
This feature works whether or not clearmake uses configuration lookup (that is, either with or without the -T or -F option). If it does use configuration lookup, clearmake “prefers” to use a DO in the current view:
As always, clearmake tries to reuse the candidate DO (if any) in the current view, built at the target's name.
If such a candidate does not exist or does not qualify for reuse, clearmake searches for a candidate in the current view, built in directories on the VPATH.
If candidate with an appropriate name exists in a VPATH directory but is rejected by the configuration lookup algorithm, clearmake proceeds to look in the VOB database for other candidates that were built in that same VPATH directory.
If no VPATH directory has any candidate with an appropriate name, clearmake proceeds to search the VOB database for other candidates in the directory corresponding to the target's name.
| Note: In all these cases, all the DOs on which clearmake performs configuration lookup were built in a single directory — it traverses multiple VPATH directories only in deciding where to begin performing configuration lookup. |
The names of targets and dependencies in build scripts are replaced by their VPATH-elaborated counterparts. If a file is found using the VPATH, then all white-space-delimited occurrences of the file's name in a build script are replaced with the pathname at which the file was found. For example:
VPATH = tgtdir:depdir
bar.o : bar.c
cc -c bar.c -o bar.o
|
If bar.c is found in directory depdir, and bar.o is found in directory tgtdir, and the target must be rebuilt, then this build script will be executed:
cc -c depdir/bar.c -o tgtdir/bar.o |
clearmake provides partial compatibility with Gnu make. Some Gnu make features are supported directly by clearmake. Others are supported by preprocessing the makefile(s) using /usr/atria/bin/Gmake, a program derived from Gnu make.
| Note: Machine-readable sources to Gmake are available. For more information, call Atria Customer Support. |
The Gmake preprocessor “elaborates” the makefile(s). This involves evaluation of conditional expressions, static pattern rules, and macro references (except those in build scripts). The elaborated makefile is stored as a temporary file, used as input to clearmake, and (usually) deleted when clearmake no longer needs it.
You can save an elaborated makefile (for example, to examine it) in either of these ways:
Perform the build with a clearmake -C gnu -d command. clearmake will preserve the elaborated makefile and display its pathname.
Invoke Gmake directly, specifying -E option and redirecting standard output. For example:
/usr/atria/bin/Gmake -E > Makefile.elab
The following features are enabled when you specify -C gnu:
“export” statement
extended macro-assignment operator:
:= expand RHS immediately
macro assignment `override' keyword
pattern-replacement macro expansions:
$(macro:op%os=np%ns)
all other extended-macro expansion operators (unless the expansion occurs in a build script)
function calls, except those that occur in build scripts and those that occur on the RHS of an = macro assignment. (You can use a function call on the RHS of a := macro assignment.)
conditional expressions
static pattern rules
pattern-matching rules
When you use -C gnu, clearmake does not automatically use build options specification (BOS) files associated with the makefiles it reads. (This is due to the fact that the makefiles are read by the Gmake preprocessor, not by clearmake itself.) Use clearmake's - A option or environment variable CLEARCASE_BLD_OPTIONS_SPECS to specify the BOS files when using Gnu make compatibility.
Different systems have different names for their “built-in makefiles” — for example, system.mk versus default.mk. Using -C -sgismake on a non-IRIX system, or -C sun on a non-SunOS system, may cause errors. You can disable use of built-in rules with clearmake -r.
With -C sun, clearmake uses the SunOS arch(1) and mach(1) commands to set the values of special macros (for example, HOST_ARCH and HOST_MACH). This generates error messages on systems that do not support these commands. You can safely ignore such messages if your build scripts do not use the special macros. Some alternatives:
Comment out the lines in /usr/atria/etc/sunvars.mk that define the .CLEARMAKE_ARCH and .CLEARMAKE_MACH macros.
Write shell scripts to implement the arch and mach commands.