POSIX proposal: make and "pattern matching" rules

[Robert Elz <kre%munnari.OZ.AU@localhost>]

A very old enhancement request for the posix specification of make
(old as in submitted in 2011) is now under discussion ... the delay
as being an enhancement, it couldn't be added in a "technical corrigenda"
update, which is all that has been issued since 2011.

This comes from GNU initially, and the most recent proposal to handle
it (I believe it can be understood well enough without seeing exactly
where it is to be inserted) is shown below (probably lacking some
formatting here).   After that (after a line of '=' chars) I append
two notes added from the GNU world (this proposed text is not from
there).

Anyone with comments can either join the austin list, and contribute
directly, or I can forward them.

You can see the entire recorded history of this discussion (except parts
that might have occurred on the mailing list only) at:

    https://www.austingroupbugs.net/view.php?id=513

(I believe that anyone can access that page.)

kre

ps: many of you can probably guess who submitted this proposed version,
just from the contents of it:


This is an attempt to make a simplified proposal for adding pattern rules
to the POSIX make definition soon, to allow them to appear in the upcoming
issue 8 version of the standard. The simplification in this proposal is
identical to the simplification used by smake. So there is no need to
discuss whether this simplification describes a useful subset. This subset
has been verified to be useful since almost 25 years, so it disproves the
concerns currently written down on page 2909 in the lines 97901 ... 97906.

The page and line numbers match the 1.1 draft for issue 8.

On Page 2897 change line 97390 to:

Suffix based inference rules are formatted as follows:


On page 2897 after line 97401 add:

When no pattern matching inference rule applies, make shall check the
target name to see if it ends with a suffix in the known suffixes list.

On page 2898 after line 97438 add:

Pattern matching inference rules:

A target entry of the form:

       tp%ts: dp%ds
            command

or

       tp%ts:
            command

is a pattern matching inference rule, in which tp is a target prefix,
ts is a target suffix, dp is a dependency prefix, and ds
is a dependency suffix (any of which can be empty).

The % stands for a basename of zero or more characters that
shall be matched in the target, and shall be used to construct the name
of a dependency. When make encounters a match in its search
for an inference rule, it shall use the rule in that target entry
to build the target from the dependency file. Pattern-matching
inference rules typically make use of the $@ and $<
dynamic macros as placeholders for the target and dependency names.

Pattern Matching Inference Rules are searched in in the same
order as they have been defined.

Pattern Matching Inference Rules have precedence over Suffix Rules.
The builtin rules defined by make are typically defined
as Suffix Rules to allow them to be overwritten by Pattern Matching
Inference Rules in regular makefiles.

On page 2909 replace lines 97901 ... 97906 with:

SunPro Make supports pattern matching inference rules in the form:

      tp%ts: [dependency ...] dp%ds [dependency ...]
            command

or

       tp%ts: [dependency ...]
            command

as well. This feature has not been added to the standard, in order to make
it easier to implement the feature by make implementations that do not yet
support pattern matching inference rules. This feature shall be seen as a
valid enhancement that may become part of a future version of the standard.

GNU make permits to define pattern rules in the form:

       tp%ts:: dp%ds
            command

to mark them as termination rules that stop recursive searches for inference
rules. This could e.g. be used to define prefix based rules for SCCS. The
current standard does not include this feature, but future versions of the
standard may add it.

It has been discussed whether a pattern matching inference rule with no
command shall be used to remove an existing pattern matching inference rule
with the same pattern and whether the pattern matching inference rule:

     %: %

with no command shall remove all existing pattern matching inference
rules. This is helpful, since otherwise it would not be possible to
replace or overwrite previous pattern matching inference rule definitions.
This version of the standard does not require this behavior but
permits it in order to allow it to be added to a future version of the
standard.


========================================

There are two issues that need to be addressed before this can be accepted
(perhaps the only way to address them would be to make them unspecified
which would be unfortunate...) I will create separate comments for them to
try to focus discussion.

First, GNU make does not use pure definition order when searching for
matching pattern rules. You can see the original proposal above for a
description of GNU make's algorithm: it first chooses the "most specific"
pattern match; by "most specific" it means the one with the smallest stem
value. So if you have a target pattern "foo%.o" and another one "%.o" then
a target "foobar.o" will use the first pattern rule even if it's defined
later in the makefile, because the pattern match stem ("bar") is shorter
than the other rule (stem is "foobar").

If there are multiple rules which have the same stem length ("%.o" and "%.x")
then the first one defined takes precedence.

One way to make this work is to ensure that your patterns are ordered
properly in the makefile (shorter stems come first) then it works in
either model. But I don't know how to write this in the standard.

The second issue is what happens if the pattern doesn't contain a slash.
GNU make has special handling of this situation to allow situations like this:

    f%.o : b%.c ; ...

to match a target like "dir/foo.o" and construct a prerequisite of "dir/boo.c".

This is really useful but may not be appropriate for standardization.
But again I'm not sure how to write the standard text to manage this difference.

In both of these issues, I don't agree that when .POSIX is defined we would
use a different algorithm. We'll need to find a way to allow these behaviors
in makefiles with .POSIX set.