Certain variants of make, such as GNU make or Sun make, support so-called pattern rules. These rules use a wildcard character of %, for example
%.ps: %.dvi
	dvips -o $@ $?
This specifies that files with filenames that end in .ps will be made from files with the same name, except that they end in .dvi, by running the dvips command as specified. Contrast this with the non-pattern rule
*.ps: *.dvi
	dvips -o $@ $?
which specifies the same thing, but only for files that already exist in the current directory.

Thus, pattern rules provide the same role as suffix rules, which could in fact be used in this example:

	dvips -o $@ $?
but they are more flexible; the wildcard does not have to appear in front of a dot and a filename extension.

However, pattern rules are still too limited if you want to write truly generic building rules. For instance, we can't write a rule that combines the names of two dependencies into the name of the result:

%-then-%.txt: %.txt %.txt
	cat $+ > $@
is not allowed: we can only have one wildcard on the left hand side.

Problems like this indicate that make isn't very generally applicable; it could be much more powerful if it supported more flexibility in its rule construction. There are other limitations, too, and various ways have developed to work around them. One way to do that is by avoiding the handcoding of Makefiles. Systems like imake and autoconf were created to generate Makefiles from their own sets of specification files.

Log in or registerto write something here or to contact authors.