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:
.dvi.ps:
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.