|
|
omake is highly compatible with Microsoft NMAKE up to version 1.3 (the version supplied with Visual C++). omake supports all NMAKE directives, macros, paths, and rules.
omake supports the following NMAKE directives:
This read-time directive turns on (+) or off (-) one or more options, opt.
This read-time directive is the same as the %echo message directive.
omake is highly compatible with NMAKE, but there are differences in how they read makefiles and in how they run. omake's NMAKE emulation mode causes omake to operate like NMAKE.
If NMAKE emulation mode is selected at startup time, omake emulates the NMAKE command line and selection of the initialization file. Selection of NMAKE emulation at startup time is done with the -EN flag, either on the command line or in the OMAKEOPTS environment variable.
To determine the startup emulation mode, omake first examines the OMAKEOPTS environment variable for -Ex flags, and then the command-line for -Ex flags. If the last -Ex flag is -EN, omake starts up emulating NMAKE.
NOTE: If you want submakes (recursive invocations of omake) to inherit NMAKE emulation mode, you must specify the -EN flag in the OMAKEOPTS environment variable.
The .MS_NMAKE directive turns on NMAKE emulation mode from the point it appears in the initialization file or any makefile.
The OMAKEOPTS environment variable is parsed for options, and then the command line is parsed. Parsing entails the following:
Handling the case-insensitivity of the NMAKE command line.
Handling all NMAKE command-line options.
Switching the help screen to the options available with NMAKE v1.3. The help screen's contents are stored in the file omhelp.nm.
Without emulation at startup, the command line is as documented in the section Command-Line Options.
If omake is emulating NMAKE at startup, omake reads its internal rules and macros, and then looks for builtins.nm in the directory of make.ini, in the directory of the omake.exe file, and along directories of the INIT environment variable, in that order. If builtins.nm is found, it is read for macros and rules that give more complete NMAKE emulation.
If omake is emulating NMAKE at startup, omake reads the tools.ini file found in one of these directories:
In the current directory
In a directory named by the INIT environment variable
If omake finds the initialization file, it reads information in the file starting with the section heading [NMAKE.
If omake is emulating NMAKE:
The ^ character is used for quoting and produces the following effects:
| Character | Effect |
|---|---|
^^ | literal ^ |
^<ENTER> | literal <ENTER> |
^$ | literal $ |
^\ | literal \ |
^# | literal # |
The !else if, !else ifdef, and !else ifndef directives are supported.
Macro definitions of the form
VAR = ... $(VAR) ...
are supported and cause $(VAR) to be expanded before VAR is redefined. Other macro references in the macro value are not expanded.
Macro definitions of the form
ENVVAR = value
where ENVVAR is an environment variable, assign to the ENVVAR macro the value, which is also exported to the environment. If the -E command-line flag is used, makefile macros cannot override environment macros, and this macro redefinition is ignored.
Search paths for dependents are supported. These look like this:
forward.exe : {\src\alpha;d:\proj}pass.obj ...
Inference rule search paths are supported. These look like this:
|
{fromdir}.fromext{todir}.toext : |
(build script for inference rule) |
Inference rules for targets that have a directory component look for the inferred source in the directory of the target.
The !include file directive is supported. If file is an absolute pathname, it is used; otherwise, omake looks for file in the current directory, and then in the directory of the including file. If file appears inside angle brackets (for example, <file>), omake then looks along the directories in the INCLUDE environment variable.
If omake is emulating NMAKE, the following macro features are supported:
Command-line macros are exported to the environment, and become available to recursive makes.
Environment variables override built-in macro definitions (see the section Macros).
The MAKEFLAGS macro is exported to the environment.
Non-run-time macros are expanded at parse time.
Most other make programs expand macros when a build script is run, but NMAKE expands macros when it parses the makefile. When the rule is parsed, it is defined with the expanded value of the macro, rather than with a reference to the macro. (The reference would be expanded at run time).
EXCEPTION: NMAKE evaluates run-time macros at run time, because the values to which they are set are based on the target.
Therefore, the following makefile is evaluated differently by NMAKE and clearmake:
FOO=A
rule:
@echo $(FOO)
FOO=B
In NMAKE, $(FOO) is evaluated at parse time, so building rule echoes A. In clearmake, $(FOO) is evaluated at run-time and its value after parsing is B, so building rule echoes B.
If omake is emulating NMAKE, the following build-script features are supported:
The shell program is used for executing every build script.
The build scripts cd dir and chdir dir both change to directory dir and stay there until changed back explicitly.
A set var=val build script is treated specially and sets the environment variable VAR to the value val. That is, this build script is treated exactly like the omake directive %setenv var=val.
The filename-parts syntax is supported. You can use this to get at the components of the name of the first source file. The complete file name is represented with the %s syntax. Parts of the file name are represented with this syntax: %| [parts] F , where parts is zero or more of the following letters: none, the complete name; d, drive; p, path; f, file base name; e, file extension.
Shell-line prefixes are limited to @, -, and !. The ^ prefix stops processing of prefixes.
The # character is not treated as a comment in build scripts.
omake supports the NMAKE response file syntax, except that multiple inline response files on a single build script are not support.
NMAKE and omake allow the keywords KEEP or NOKEEP in the epilog of the inline response file. KEEP causes the response file to be kept (that is, not deleted). The default is NOKEEP.
Multiple inline response files on a single build script are not supported.
Arithmetic operators are not supported in preprocessing expressions.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
