3.4 Targets

This section provides general information about targets.

Case-Sensitivity of Target Names

By default, for Windows NT omake target names are case-insensitive. The .CASE_TARGET and .NOCASE_TARGET directives turn case-sensitivity on and off.

A Target Has a Name and a Pathname

It is an important fact that a target has both a name (from the makefile) and a pathname (its location on disk). Each name in the makefile specifies a unique target. The pathname is determined when omake searches for the target on disk.

If name does not have a path component in it, omake may search multiple directories to locate the target and the name and pathname may differ. If name has a path component, or if omake is not instructed to search multiple directories, the name and pathname are the same. See Search Directories.

Using the Path Separator in Names

On Windows NT, you can use either a slash ( / ) or backslash ( \ ) as the path separator inside of omake makefiles. Windows NT accepts either character as the path separator when Make looks in the file system directory.

We suggest you use the slash in your makefiles because the backslash can be used to modify the meaning of the character that follows it. For example, \<ENTER> continues makefile lines and \# is a literal #. If you use the backslash as the path separator, you must be aware of how omake interprets this expression:

\the-following-character

The First Target in the Makefile Is the Default Target

If no targets are specified on the omake command line, the first normal target in the makefile is made. In this context, a normal target is not a directive, special target, attribute, or inference rule. It is a common practice to have the default target depend on other targets to be built. Consider this makefile:

all : a.exe b.exe

a.exe : dependencies
build scripts

b.exe : dependencies
build scripts

Running omake without a command-line target causes all (a.exe and b.exe) to be made. The target all is sometimes called a dummy target because it is used to drive the build of other (real) targets.

Targets May Appear on Several Dependency Lines

A target may appear on the target side of more than one dependency line. The target depends on all dependencies on all dependency lines that the target appears on, but the build script that updates the target can be listed after only one of the dependency lines.

Double-Colon Dependency Lines

When a double-colon (::) separates the target and its dependencies, build scripts can be specified after each double-colon dependency line. If in the MVFS, all build scripts are executed if any dependency on any dependency line is newer than the target. Double-colon dependencies are rarely used. Here is a simple example:

backup :: a.exe
copy $(.SOURCE) c:\backup

backup :: b.exe
copy $(.SOURCE) c:\backup

If you were to execute the omake backup command, a.exe is built and then b.exe . Each target is copied to c:\backup after it is built.

Mixing Single-Colon and Double-Colon Dependency Lines

A target cannot appear on the target side of both double- and single-colon dependency lines. If it does, omake displays a warning and ignores the offending dependency line.

Targets Without Dependencies

A target that has no dependencies (neither explicit nor inferred) is up to date if it exists as a file; if it doesn't exist, it is out of date and must be updated.

Target Groups

Several targets may be made simultaneously from a single dependency. This is called a target group. Updating any target of the group (by running the target's build scripts) updates all the targets.

To indicate a target group, put a plus sign (+) between each target on the dependency line. For example, here is a rule to build parse.h and parse.c simultaneously from parse.y using the program called yacc:

parse.h + parse.c : parse.y
yacc -d parse.y # produce ytab.h & ytab.c
copy ytab.h parse.h # copy ytab.h to parse.h
copy ytab.c parse.c # copy ytab.c to parse.c
del ytab.* # remove the ytab files

Assume that parse.y was changed recently and that some other target depended on parse.h. Making this other target causes parse.h to be made, which executes the build scripts. If parse.c is evaluated later in the make process, omake recognizes that it is a member of the same target group as parse.h, which has already been updated, and does not rerun the build scripts.