make.1 (2010 09)

ManualsBrandsHP ManualsSoftwareHP-UX Manpages

make(1) make(1)

$(LIB)(file.o)

both refer to an archive library that contains file.o (this assumes the

LIB macro

has been previously deﬁned). The expression

$(LIB)(file1.o file2.o) is not valid. Rules per-

taining to archive libraries have the form

xx.a where xx is the sufﬁx from which the archive member is

to be made. An unfortunate byproduct of the current implementation requires the xx to be different from

the sufﬁx of the archive member. Thus, one cannot have

lib(file.o) depend upon file.o explicitly.

The most common use of the archive interface follows. Here, we assume the source ﬁles are all C type

source:

lib: lib(file1.o) lib(file2.o) lib(file3.o)

@echo lib is now up-to-date

.c.a:

$(CC) -c $(CFLAGS) $<

ar rv $@ $*.o

rm -f $*.o

(See the subsection on Built-in Macros for an explanation of the

<, @, and * symbols.) In fact, the .c.a

rule listed above is built into make

and is unnecessary in this example. This rule is applied to each

dependent of

lib in turn. The following example accomplishes this more efﬁciently:

lib: lib(file1.o) lib(file2.o) lib(file3.o)

$(CC) -c $(CFLAGS) $(?:.o=.c)

ar rv lib $?

rm $?

@echo lib is now up-to-date

.c.a:;

Here substitution in the macros is used. The $? list is deﬁned to be the set of object ﬁle names (inside

lib) whose C source ﬁles are out-of-date. The substitution sequence translates the .o to

.c. (Unfor-

tunately, one cannot as yet transform to

.c˜; however, this may become possible in the future.) Note

also, the disabling of the .c.a rule, which would have created and archived each object ﬁle, one by one.

This particular construct speeds up archive library maintenance considerably, but becomes very cumber-

some if the archive library contains a mix of assembly programs and C programs.

Archive members containing the deﬁnition of a symbol are designated by double parentheses around the

symbol name,

lib((entry_name )), but are otherwise handled as described above.

Built-In Targets

make has knowledge about some special targets. These must be speciﬁed in the makeﬁle to take effect

(with the exception of .SUFFIXES, which is automatically set by

make but can be changed by the user).

.DEFAULT If a ﬁle must be made but there are no explicit commands or relevant built-in rules

for it, the commands associated with the target name .DEFAULT are used if

.DEFAULT has been deﬁned in the makeﬁle. .DEFAULT does not have any explicit

dependents.

.PRECIOUS Dependents of this target are not removed when QUIT, INTERRUPT, TERMINATE,

or HANGUP are received.

.SILENT Same effect as the -s option. No dependents or explicit commands need to be

speciﬁed.

.IGNORE Same effect as the -i option. No dependents or explicit commands need to be

speciﬁed.

.SUFFIXES The explicit dependents of .SUFFIXES are added to the built-in list of known

sufﬁxes and are used in conjunction with the inference rules. If .SUFFIXES does

not have any dependents, the list of known sufﬁxes is cleared. There are no com-

mands associated with .SUFFIXES.

.MUTEX Serialize the updating of speciﬁed targets (See the Parallel Make Section).

Built-in Macros

There are ﬁve internally maintained macros that are useful for writing rules for building targets. In

order to clearly deﬁne the meaning of these macros, some clariﬁcation of the terms target and depen-

dent is necessary. When

make updates a target, it may actually generate a series of targets to update.

Before any rule (either explicit or implicit) is applied to the target to update it, recursion takes place on

each dependent of the target. The dependent, upon recursion, becomes a target itself, and may have or

generate its own dependents, which in turn are recursed upon until a target is found that has no

HP-UX 11i Version 3: September 2010 − 7 − Hewlett-Packard Company 7