|
|
Makefile directives provide additional control over omake. There are two directive types:
Percent directives, which use a percent sign (%) as the first non-white-space character on the makefile line.
Dot directives, which look like dependency lines but use special target names.
Percent directives (usually called directives) have names of the form %name, where the directive character is the first non-white-space character on the makefile line. White space is allowed between % and name.
These directives work as read-time directives or run-time directives with indentation determining whether they are interpreted at read time or at run time. If % is in the leftmost column of the line, the directive is interpreted at read time. If white space precedes the %, the directive is interpreted at run time.
The directives in Table 6 control the flow of the make process at read time and at run time. Conditional and iteration directives can be nested up to 31 levels deep.
Conditional Directives | Action | Applicable Time |
|---|---|---|
% if condition | Start a conditional block | read/run |
% ifdef macro | Start a conditional block | read/run |
% ifndef macro | Start a conditional block | read/run |
% elif / elseif condition | Continue the conditional block | read/run |
% else | Start the default conditional block | read/run |
% endif | End the conditional block | read/run |
The directives in Table 7 provide iteration control. Iteration and conditional directives can be nested up to 31 levels deep.
Iteration Directives | Action | Applicable Time |
|---|---|---|
% foreach name [ in ] list | Loop for each name in list | read/run |
% while condition | Loop while condition is true | run |
% end | End the loop | read/run |
% break | Interrupt and quit innermost loop | run |
% continue | Interrupt and restart innermost loop | run |
Other directives behave like commands built into omake. At run time, these directives can be preceded with build script prefixes, which must appear before the %. See Table 8.
Other Directives | Action | Applicable Time |
|---|---|---|
% abort [ status ] [ message ] | Display message, exit with status | read/run |
% chdir directory | Change current directory | run |
% do [ target ] [ macros ] | Execute build scripts of target | run |
% echo [ -n ] message | Display message | read/run |
% error [ status ] [ message ] | Display message, return exit status | read/run |
% exec command | Execute command line | read |
% include [ <" ] file [ >" ] | Include contents of makefile | read |
% restart [ flags ] | Start omake again | read/run |
% set name [+]= value | Set macro name with value | run |
% setenv name [ = ] value | Set environment variable NAME | read/run |
% undef name | Undefine macro name | read/run |
Conditional directives control the makefile lines that omake reads at read time and control the build scripts that are executed at run time. These directives take this form:
%if condition
[ makefile line ]
.
.
.
[ %elif condition ]
[ makefile line ]
.
.
.
[ %else ]
[ makefile line ]
.
.
.
%endif
Each %if must be matched with an %endif. There can be several %elif or %elseif clauses and at most one %else. Lines between %if or %elif and the next %elif, %else, or %endif are a block. If condition is true, the makefile lines are read or the build-script lines are executed. If none of the conditions is true and there is a %else clause, the block between %else and %endif is read or executed.
If the % of these directives is in the leftmost column of the makefile, the directive is evaluated at read time; otherwise, the directive is evaluated at run time. There can be white space between % and the name of the directive. No shell-line prefixes are allowed before the %.
There are two specialized version of %if:
%ifdef name
%ifndef name
%ifdef is true if macro name is defined. %ifndef is true if macro name is not defined.
Directives can be used to conditionally select the continued makefile text. For example:
|
OBJS = main.obj parse.obj \ |
(the continuing line) |
|
%ifdef Debugging |
|
|
version.obj \ |
(continues here if Debugging defined) |
|
mymalloc.obj |
|
|
%endif |
|
|
a blank line |
(continues here if Debugging undefined) |
If the Debugging macro is not defined, the OBJS macro value is main.obj parse.obj. If the macro is defined, the value is main.obj parse.obj version.obj mymalloc.obj.
The way this example is written makes the blank line after the %endif necessary because the continuing line is continued on the first line after the %endif if Debugging is undefined. Using an %else clause instead is done like this:
|
OBJS = main.obj parse.obj \ |
(the continuing line) |
|
%ifdef Debugging |
|
|
version.obj \ |
(continues here if Debugging defined) |
|
mymalloc.obj |
|
|
%else |
|
|
|
(continues here if Debugging undefined) |
|
%endif |
|
The %if, %elif, and %while directives use the same conditional expressions. These expressions compare strings and numbers and combine the comparisons with logical operations. As well, the status of macros, command-line targets, and files can be determined. All macro references in the conditional expression are expanded before the expression is evaluated.
The conditional expressions here are organized by type. Some examples follow each type. For the examples, the following macros are assumed to be defined:
DEBUG = 0
MODEL = S
NONE =
OBJS = 1.obj 2.obj
You can use any of the following simple expressions:
If value is zero, the condition is false; all other values indicate true. Single or double quotes must be placed around value if it contains spaces or is null.
Some examples of simple expressions:
%if ASTRING value is true
%if 12 value is true
%if 0 value is false
%if $(MODEL) value is true
%if $(DEBUG) value is false
%if $(NONE) ERROR! $(NONE) is null
%if "$(NONE)" value is false
The operators in Table 9 make a numerical or alphabetical comparison of two values, returning 1 if the comparison is true and 0 if false.
Comparison Operators | Value |
|---|---|
value1 = = value2 | True if value1 is equal to value2. |
value1 != value2 | True if value1 is not equal to value2. |
value1 < value2 | True if value1 is less than value2. |
value1 <= value2 | True if value1 is less than or equal to value2. |
value1 > value2 | True if value1 is greater than value2. |
value1 >= value2 | True if value1 is greater than or equal to value2. |
If both values start with a digit, the comparison is done numerically; otherwise, it is done alphabetically. If either value contains spaces or is null, it must be enclosed in quotes. The case-sensitivity of the string comparison is the same as for target names and can be set with the .CASE_TARGET and .NOCASE_TARGET directives.
Some examples of comparison operators:
%if $(MODEL) == S true
%if ABC > DEF false
%if $(DEBUG) != 0 false
%if $(XYZ) == 1 error! $(XYZ) is null
%if $(XYZ)x == 1x false
%if $(OBJS)x != x error! $(OBJS) has spaces
%if "$(OBJS)" != "" true
All function operators take one or more arguments and return a value that is false (0), true (1) or some other number. See Table 10.
Functional Operators | Value |
|---|---|
%defined(name) | True if macro name is defined. |
%dir(name) | True if name is a directory. |
%exists(name) | True if name is a file or directory. |
%file(name) | True if name is a file. |
%length(name) | The number of characters in $(name). |
%make(name) | True if name is a command-line target. |
%member(name, list) | True if name appears exactly as an element of list. |
%null(name) | True if macro name is undefined or if its expansion is null. |
%time(name) | The on-disk time stamp of file name. |
%writable(name) | True if file name is writable |
The file-test operators return the state of files and directories. Most of these operators have been made obsolete by the equivalent functional operators. See Table 11.
File-Test Operators | Value |
|---|---|
-d name | Same as %dir(name). |
-e name | Same as %exists(name). |
-f name | Same as %file(name). |
-r name | Same as %file(name). |
-w name | Same as %writable(name). |
-z name | True if name is a zero-length file. |
One example of the file-test operators:
|
%if -e builtins.mak |
(true if builtins.mak exists) |
The command-execution operator executes a command using the shell program. See Table 12.
Execution Operator | Value |
|---|---|
[ command ] | The exit status of the command. By convention, commands return 0 if they succeed. |
Here is an example that runs a hypothetical mkproto program that freshens the prototype files for its source files:
%if [ mkproto *.c ]
% abort MKPROTO could not freshen the prototypes.
%endif
You can ignore the exit status of the executed command by using an %if ... %endif pair that doesn't encapsulate anything. The following idiom is seen in VC++ makefiles:
!if [ if exist MSVC.BND del MSVC.BND ]
!endif
The logical operators are used to combine other expressions. Each expression is evaluated from left to right, but parentheses can be used to order the evaluation. See Table 13.
Logical Operators | Value |
|---|---|
exp1 && exp2 | True if both exp1 and exp2 are true. |
exp1 | | exp2 | True if either exp1 or exp2 are true. |
! exp | True if exp is false. False if exp is true. |
( exp ) | The same state as exp. |
Unlike the C programming language, the logical expressions do not short-circuit. That is, exp1 and exp2 are always evaluated. For example:
|
%if %defined(NONE) && %null(NONE) |
(true) |
|
%if %defined(XYZ) && %null(XYZ) |
(false) |
|
%if ! ( ! -f file || -z file ) |
(false if file is absent or is zero length) |
The %while and %foreach directives provide iteration capability. At run time, they allow build scripts to be executed multiple times. %foreach can also be used at read time to replicate makefile lines.
The form of the %foreach directive:
%foreach name [ in ] list_of_names
[ makefile lines ]
.
.
.
%end
The list_of_names is a set of names separated by white space. The value of macro name is set to the first name in the list_of_names, and the makefile lines after this %foreach and before %end are read (at read time) or executed (at run time).
If the % of these directives is in the leftmost column of the makefile, the directive is evaluated at read time; otherwise, the directive is evaluated at run time. No shell-line prefixes are allowed before %foreach or %end.
When %end is reached, name is set to the next name in list_of_names, and the loop is restarted. When there are no more names, the loop is done and name returns to its previous value. For PM/CB compatibility, the optional keyword in is supported and %endfor can be used in place of %end.
If %foreach is used at read time, the makefile lines between %foreach and %end are parsed multiple times with name taking on successive values from the list_of_names. As the lines are parsed, all macro references to name are expanded.
The following example illustrates the use of %foreach at read time:
%foreach var in main sub io
macro_$(var) = $(value_$(var)) $(other_macro)
$(var).obj : $(var).c
cl -c $(.SOURCE)
%endfor
All $(var) references are replaced with the current value of var. omake treats the previous %foreach loop as if it has read the following makefile lines:
macro_main = $(value_main) $(other_macro)
main.obj : main.c
cl -c $(.SOURCE)
macro_sub = $(value_sub) $(other_macro)
sub.obj : sub.c
cl -c $(.SOURCE)
macro_io = $(value_io) $(other_macro)
io.obj : io.c
cl -c $(.SOURCE)
Here is an example run-time use of %foreach to build a linker response file using the inline response file syntax (see Inline Response Files):
|
project.exe : $(OBJS) |
|
|
link @<< |
(link @response_file) |
|
%foreach x in $(.SOURCES) |
|
|
$x |
(adds each .obj +) |
|
%end |
|
|
|
(adds a blank line) |
|
$(.TARGET); |
(add the executable name) |
|
<< |
(end the response file) |
The form of the %while directive:
%while condition
[ build script and directives ]
.
.
.
%end
While condition is true, the build script and directives are executed. When %end is reached the loop is restarted at the top, condition is reexpanded (because it may contain macros) and retested. This is repeated until condition is false. No shell-line prefixes are allowed before %while or %end.
When you use omake in a VOB, there is a side effect with the %foreach and %while directives: the build script in the CR does not expand loop macros. For a makefile like this one,
all:
%foreach platform in i386,alpha
$(MAKE) -f makefile.$(platform)
%endfor
you may expect the configuration record to include the commands that were executed. For example:
omake -f makefile.i386
omake -f makefile.alpha
Instead, you get a copy of the build script:
%foreach platform in i386,alpha
omake.exe -f makefile.
%endfor
Note also that the platform macro has a value only while inside the loop, so the macro in the configuration record is expanded to nothing.
%break and %continue interrupt the iteration. %break stops the iteration immediately. %continue restarts the iteration at the top. For %while, the condition is reexpanded and retested. For %foreach the name is advanced to the next in the list_of_names.
The ! shell-line prefix iterates the build script for elements of either the .SOURCES (or **) or .NEWSOURCES (or ?) macro, depending on which appears first on the build script. During iteration, ${.SOURCES} (or $**) or ${.NEWSOURCES} (or $?) evaluates to each element, in turn, of the macro value. We discourage the use of ! for iteration, preferring the explicit %foreach directive.
Here is a sample makefile that uses conditional and iteration directives:
|
%if defined(CV) |
(Read-time conditional) |
|
CFLAGS = -Od -Zi |
|
|
%else |
|
|
CFLAGS = -Ox |
|
|
%endif |
|
This example shows a compile-edit loop. The file io.c is compiled with all compiler messages redirected into file io.err. The 2>&1 redirection is compatible with Windows NT and UNIX. It means that standard error is redirected to standard output. The previous > io.err means standard output is redirected into io.err. Together, they mean that standard error and standard output both are redirected to io.err.
If the compile is successful, the %break directive breaks out of the %while 1 loop and erase the io.err file.
Otherwise, notepad (the Notepad editor) is started and told to jump to the first error. After Notepad finishes, check the time of the io.c file to see whether it is more recent than io.err, indicating it has been changed. If it hasn't, omake breaks out of the compile-edit loop by calling the %error directive. Otherwise, the loop restarts and the file is recompiled.
Table 14 lists other percent directives, the times at which they are applicable, and their descriptions.
Directive | Appl. Time | Description | |
|---|---|---|---|
%abort [ status ] [ message ] | read, run | At read time and run time, terminates omake with the user-supplied exit status (1 if status is not supplied). If message is supplied, omake prints it on the error output (standard error) before terminating; otherwise, the termination is silent. When you use %abort while running omake in a VOB, no configuration records are written. Any output files created by the build script before it executes %abort will not be derived objects. | |
%chdir directory | run | Changes the current directory to directory. This is the directory in which each subsequent build script starts. For example: | |
copyit: |
| ||
The MAKEDIR macro is not affected by %chdir and its value is always the directory omake started in. | |||
%do [ target ] [ macro[+]=value ... ] | run | Executes the build scripts of the named target. The exit status of the %do is the exit status of the last build script of target. If nothing appears after the %do, this directive does nothing. If target does not exist, omake issues a warning unless %do is preceded by the @ shell-line prefix. During the %do, the attributes of target are the combination of the attributes of the current target and of target, with the current target having precedence. macro=value is a macro definition that is in effect during this %do. macro+=value appends value to the current value of macro. For either form of redefinition, the old value is restored after the %do is finished. Spaces in target or between the start of macro and the end of value must be enclosed in double quotes. Up to 10 macro definitions are allowed per %do, separating the definitions with spaces. For example, the directive sub.obj : sub.c produces the following build scripts when sub.obj is updated: Compiling ==== sub.c ===== | |
When you use %do while running omake in a VOB, the commands from the other build script are not included in the configuration record. For the following makefile, any changes to the rules to build MakeCFile do not cause derived objects built previously to be out of date even though the executed commands have changed: .c.obj: $< | |||
%echo [ -n ] message [ >[>] file ] | read, run | Prints message either to standard output, or to file if redirected. The message is followed by a line feed unless -n is specified. | |
%error [ status ] [ message ] | read, run | At read time, omake terminates with the user-supplied exit status (1 if status is not supplied). At run time, this returns the exit status which is treated like any other build script exit status. If message is supplied, omake prints this message to the error output (standard error) before terminating or returning the exit status. | |
%exec command_line | read | Executes the command_line and sets the status macro to the exit status. | |
%include [ < or " ]name[ > or " ] | read | Reads the contents of name into this makefile. omake looks in different places depending on whether the file is specified as name, "name", or <name>. If name is an absolute pathname, it is only looked for there. Otherwise, "name" is looked for in the directory of the including file, then in the directory of make.ini. For Windows NT, omake looks in the directory of omake.exe, then in directories of the INIT environment variable, and finally in directories of the INCLUDE environment variable. <name> is looked for in the same manner as is "name", except the directory of the including file is not used. For example: | |
%include c:\home\make.ini | (use the absolute path) | ||
%restart [ command_line ] | read, run | Restarts the make process. If command_line is not supplied , omake is restarted with the original command line. This calls omake recursively; it can be done at read time, and you don't have to keep track of the command line. When you use %restart while running omake in a VOB, %restart writes a configuration record before restarting. Note that if a target with %restart in the build script is ever winked in, the %restart doesn't occur. Therefore, if your build script has a rule to rebuild the makefile and then has %restart to re-read the updated makefile and continue building, this won't have the desired effect if the makefile is winked in. omake winks in the makefile, but no restart occurs, and the old makefile is used for the rest of the build. In this case, use -M or .MAKE_MAKEFILES to build the makefile before reading it. In all other cases, mark any target with %restart in it as .NOWINK_IN. | |
%set name [+]= value | read, run | Sets macro name to value at run time, although it can be used at read time. Use += to append to the current definition. As an example, the build scripts of the following set_debug_flags target sets the LDFLAGS value to /CO and appends -Od -Zi to the CFLAGS value: set_debug_flags : Any white space between = and value is ignored. Any white space between += and value is condensed to a single space. | |
%setenv name [=] value | read, run | Sets environment variable NAME (converted to uppercase on Windows NT) to value. The variable is available to omake and to the build scripts executed by omake. If NAME is also a macro, the macro value is also updated to value. After omake terminates, the variable reverts to its previous value. The main use of this directive is in the .BEFORE special target to set up the environment for the makefile. For example: .BEFORE .MAKE : We recommend that you not use this command with configuration records at run time. It can cause evaluation of environment variables to differ from run to run and prevents shopping from finding an appropriate derived object to wink in. For example, in one build, target A is built and changes the value of an EV; target B is then built and references the value of that EV. The next time the build is run, B may be built first and because A hasn't modified the environment variable yet, it runs differently than it did the first time. | |
%undef name | read, run | Undefines the macro named name. When you use %undef while running omake in a VOB, the configuration record is stored as if the %undef were not executed. The %undef runs when the build script is executed, but if the macro is evaluated after the %undef, the macro is expanded in the configuration record with the value of the macro when the target build began, even though the build script ran with the macro expanding to nothing after the %undef. | |
For PM/CB compatibility, omake supports the %exit directive and %status functional operators. For Microsoft NMAKE compatibility, omake supports the !CMDSWITCHES and !message directives. See Appendix D, Compatibility and Emulation, for details.
Dot directives (usually called directives, also) appear on a dependency line where the target name is a period followed by uppercase letters. Dot directives only work at read time.
At read time, dot directives modify the operation of omake from the point the directive is encountered in the makefile. Most command-line options have an equivalent dot directive.
The current state of each dot directive is kept by omake in a state macro with the same name as the directive. For example, the .DEBUG directive sets the debugging mode and the $(.DEBUG) is the value of the debugging mode. (The state macros are described in Predefined Macros: State Macros and listed in condensed form in Table 22 here.)
Directives that are effective on only some operating systems are noted.
Some directives accept lists of patterns as their dependents. Pattern lists may contain the pattern character %. When evaluating whether a name matches a pattern, the tail of the prefix of the name (subtracting directory names as appropriate) must match the part of the pattern before the %; the suffix of the name must match the part of the pattern after the %. For example, /dir/subdir/x.o matches the patterns %.o, x.o, subdir/%.o, and subdir/x.o, but does not match /dir/subdir/otherdir/x.o.
The following omake directives accept pattern lists:
.DEPENDENCY_IGNORED_FOR_REUSE:
.DO_FOR_SIBLING:
.INCREMENTAL_REPOSITORY_SIBLING:
.INCREMENTAL_TARGET:
.SIBLING_IGNORED_FOR_REUSE:
.WINK_IN:
Table 15 lists omake directives, their equivalent command-line options (if applicable), and the actions that the directives perform.
Directive | Flag | Action |
|---|---|---|
.CASE_MACRO : | By default, omake treats macro names in a case-insensitive fashion. For this reason, the makefile lines Case = mixed define only one macro. That is, both $(Case) and $(CASE) evaluate to The .NOCASE_MACRO directive makes macro names case-insensitive. | |
.CASE_TARGET : | By default, omake treats target names as case-insensitive, so main.obj and MAIN.OBJ are the same target. The .CASE_TARGET directive causes the case of target names to be considered. The .NOCASE_TARGET directive makes target names case-insensitive. | |
.DEBUG : value | -# | Selects debugging actions, as listed below: 0 Turn off all warnings The values can be summed to combine message types. Also, each .DEBUG directive adds its value to the current value, which is initially zero. The .NODEBUG directive turns off listed values. Here are some makefile examples: .DEBUG : 4 (warn about unknown lines) |
.DEBUG_GRAPHICS : | Run-time debugging uses line-drawing characters. | |
.DEBUG_PRINT : | -p | Selects the print debugging information mode. |
.DEBUG_RUN : | -d | Selects the run-time debugging mode. |
.DEPENDENCY_IGNORED_FOR_REUSE : file ... | Ignores the files when omake determines whether a target object in a VOB can be reused (is up to date). By default, omake considers that a target cannot be reused if its dependencies have been modified or deleted since it was built. This directive applies only to reuse, not to winkin. Also, it applies only to detected dependencies, which are dependencies that do not appear in the makefile. You can specify the list of files with a tail-matching pattern; for example, subdir/%.module. Unlike the files listed in most directives, the files on this list refer to the names of dependencies, not to the names of targets. As such, the directive may apply to the dependencies of many targets at once. This directive is most useful when identifying a class of dependencies found in a particular toolset for which common behavior is desired across all targets that have that dependency. | |
.DO_FOR_SIBLING : file ... | This directive is intended to be used in its negative form (.NODO_FOR_SIBLING). .NODO_FOR_SIBLING disables the creation of a derived object for any file listed if that file is created as a sibling derived object (an object created by the same build rule that created the target). These sibling derived objects are left as view-private files. You can specify the list of files with a tail-matching pattern, for example, %.lock. Unlike the files listed in most directives, the files on this list refer to the names of sibling objects, not to the names of targets. As such, the directive may apply to the siblings of many targets at once. This directive is most useful when identifying a class of siblings found in a particular toolset for which common behavior is desired across all targets that have that sibling. | |
.ENV_OVERRIDE : | -e | Causes macro definitions from the environment to take precedence over macros defined in the makefile. The negation is .NOENV_OVERRIDE. |
.ENVMACROS : | Causes macro definitions to be made of each environment variable. The negation is .NOENVMACROS. | |
.INCLUDE : file ... | The files are included at this point in the makefile. Each file is treated as if %include file happened at this point. | |
.INCREMENTAL_REPOSITORY_SIBLING : file ... | The sibling files listed are incremental repository files created as siblings of a primary target. They may contain incomplete configuration information, and should prevent omake from winking in the primary target. This is a very special-purpose directive, useful when a toolset creates an incremental sibling object, and the user wants more manual control over that object. You can specify the list of files with a tail-matching pattern, for example, %.pdb. Unlike the files listed in most directives, the files on this list refer to the names of sibling objects and not the names of targets. As such, the directive may apply to the siblings of many targets at once. This directive is most useful when identifying a class of siblings found in a particular toolset for which common behavior is desired across all targets that have that sibling. | |
.INCREMENTAL_TARGET : tgt ... | Merges configuration record incrementally for the listed targets. In other words, this directive combines information from instances of this target generated previously with the current build of this target. This directive is most useful when building library archives, because typically only some of the objects going into a library are read each time the library is updated. You can specify the list of files with a tail-matching pattern, for example, %.a. | |
.KEEPDIR : | -D | Enables keep-directory mode. The first access of the current directory or any search directory (see Search Directories) to look for a file results in the directory being read into memory and kept. Subsequent accesses to the directory use the in-memory version and occur much quicker. The negation is .NOKEEPDIR. |
.KEEPWORKING : | -k | Enables the keep-working mode. Any errors when updating a target cause work on that target to be stopped, but the make process continues. Because the target was incompletely made, any other targets that depend on it are prevented from being updated. This mode is handy for long, unattended builds because it maximizes the amount of making without ignoring the exit status as the -i command-option does. The negation is .NOKEEPWORKING. |
.MACRO_CHAR : char | Selects char as the new macro character. It is best to put this directive in make.ini. For example, to change from the default $ to + use the following: .MACRO_CHAR : + These characters cannot be the macro character: ( ) { } , : = # ' @ * < & | |
.MAKE_MAKEFILE : | -M | Tells omake to make each makefile before trying to read it. In terms of implementation of this feature, omake reads make.ini and checks whether .MAKE_MAKEFILE is selected. If it is, omake makes the first makefile and reads it. It then makes the next makefile (if any) and reads it. The make.ini file must supply the rule for making the makefile. The .MAKE_MAKEFILE directive turns on makefile making. You can put this rule in make.ini: .MAKE_MAKEFILE Doing an omake target uses imake to create the makefile. You can also define different search directories for different extensions with the .PATH.ext macro. See Search Directories for more information. NOTE: Be aware that the makefile may contain information (such as the imake directory) needed to extract the makefile itself. You must provide some means of determining the imake directory from make.ini or you must give the imake directory to omake with a command-line macro. |
.MS_NMAKE : | -EN | Turns on fullest Microsoft NMAKE emulation. A discussion of the extensive NMAKE emulation capability is in the section Microsoft NMAKE Compatibility. The .MS_NMAKE, .omake, and .POLY_MAKE are exclusive modes and only one of them is true. That is, only one of $(.MS_NMAKE), $(.omake) or $(.POLY_MAKE) is 1 at any one instance. |
.NOCMP_SCRIPT : tgt ... | Builds the specified targets as if the -O option were specified; build scripts are not compared during configuration lookup. This is useful when different makefiles (and, hence, different build scripts) are regularly used to build the same target. The list of targets may be specified with a tail-matching pattern, for example, %.obj. | |
.omake : | -EO | omake is set to its native emulation mode. |
.POLY_MAKE : | -EP | Selects PM/CB emulation. A discussion of the extensive PM/CB emulation capability is in the section PM/CB (Intersolv Configuration Builder and PolyMake). |
.REGEX_CHAR : char | Selects char as the character that indicates special regular expression character sequences. It is best to put this directive in make.ini. For example, to change from \ (the default) to ~ use this directive: .REGEX_CHAR : ~ | |
.REGEX_WILD : char | Selects char as the regular expression wildcard character that matches any single character. For example, to change from . (the default) to ? use this directive: .REGEX_WILD : ? | |
.REJECT_RULES : | -r | Rejects all rules defined prior to this directive's appearance. Use this directive at the top of make.ini to reject omake's predefined rules. Use it at the top of your makefile to reject all rules defined prior to the makefile. The -r command-line option is equivalent to a .REJECT_RULES directive at the end of make.ini. |
.RESPONSE.XXX : [ response definition ] | Controls automatic response files (see Response Files). | |
.RULE_CHAR : char | Selects char as the new inference rule character. It is best to put this directive in make.ini. To change from the default of % to * use this directive: .RULE_CHAR : * | |
.SHELL : [ .AUTO | .NOMULTI | Names both the shell program and its flags and specifies that the shell program be used to execute every build script. The .NOSHELL directive specifies that all build scripts are executed directly, without using the shell program. However, the + (use shell) and : (suppress shell) shell-line prefixes override any .SHELL and .NOSHELL directives. The .AUTO keyword tells omake to determine when to use the shell program. Without this keyword, the .SHELL directive specifies that the shell program is used for every shell line. The .NOMULTI keyword tells omake not to do special processing for multiple-command shell lines. By default, omake turns the multiple-command shell line into a batch file, which is executed. The .NOREDIR keyword tells omake not to handle redirection of I/O on the shell line. By default, omake handles redirection except |. With this keyword, only the shell program handles redirection. If .NOREDIR is used with .AUTO, any redirection on the shell line causes the command to be executed by the shell program. A .SHELL directive that is not given a program reverts to the remembered shell program: .SHELL : to execute every build script. The initial value of .SHELL: .SHELL : $(COMSPEC) /C To use the MKS shell, use the following syntax: .SHELL : "$(ROOTDIR)\mksnt\sh" or, alternatively for the MKS shell, you could use: .SHELL : "$(ROOTDIR)\mksnt\sh -c" | |
.SIBLING_IGNORED_FOR_REUSE : file ... | Ignores files when omake determines whether a target object in a VOB can be reused (is up to date). This is the default behavior, but this directive can be useful in conjunction with the .SIBLINGS_AFFECT_REUSE directive or -t command-line option. This directive applies only to reuse, not to winkin. You can specify the list of files with a tail-matching pattern, for example, %.lock. Unlike the files listed in most directives, the files on this list refer to the names of sibling objects, not to the names of targets. As such, the directive may apply to the siblings of many targets at once. This directive is most useful when identifying a class of siblings found in a particular toolset for which common behavior is desired across all targets that have that sibling. | |
.SIBLINGS_AFFECT_REUSE : | -t | Examines sibling derived objects when determining whether a target object in a VOB can be reused (is up to date). By default, omake ignores modifications to objects created by the same build rule that created the target (sibling derived objects). This directive tells omake to consider a target out of date if its siblings have been modified or deleted. |
.SUFFIXES : [ extension ... ] | Limits and orders the inference rules. .SUFFIXES is provided for compatibility with other make utilities and its use is discussed in the section Compatibility with Suffix Rules (.SUFFIXES). | |
.UNIXPATHS : | Determines where omake looks for the inferred dependency when the current target name has a directory component. omake first tries matching the pathed target name against pathed inference rules. When the .UNIXPATHS directive is used, the second step is to match the full target name against unpathed inference rules, effectively causing omake to look for the inferred dependency in the same directory as the target. The default behavior, and the behavior when the .NOUNIXPATHS directive is used, is that the second step matches the file name of the target name against unpathed inference rules, causing omake to look for the inferred dependency in the current directory and in the search directories. | |
.WINK_IN : tgt ... | -W | This directive is intended to be used in its negative form (.NOWINK_IN). .NOWINK_IN specifies that the configuration lookup is restricted to the current view for the listed targets. The list of targets may be specified with a tail-matching pattern; for example, %.obj. |
omake supports many other directives for NMAKE, PM/CB, and Borland Make compatibility. See Appendix D, Compatibility and Emulation for details.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
