Re: make rule order

[Paul Smith]

On Wed, 2010-07-28 at 14:45 +0100, Ian Lynagh wrote:
> Running "make" (3.82) with the Makefile below prints:
>     x
>     foo rule 1
>     bar rule 2
> but I would expect make to use either the first rule in both cases, or
> the second rule in both cases. Is this a bug? If so, what is the right
> behaviour? If not, what is the reason that the first and second rules
> are chosen respectively?
> 
> #####################################
> FOO=
> .SECONDEXPANSION:
> default: foo bar
> f%: $$(info x)
>         @echo foo rule 1
> f%: $$(info y)
>         @echo foo rule 2
> b%: $$(FOO)
>         @echo bar rule 1
> b%: $$(FOO)
>         @echo bar rule 2
> #####################################

I don't believe this is a bug... or at least I don't see any way to
avoid it or any sensible alternative.

GNU make allows redefinition of pattern rules as the makefile is read
in, and the way you do this is by creating a new pattern rule with
exactly the same target and prerequisite patterns.  If you do that (as
you've done above with "b%", then the last definition of that rule takes
precedence and the previous definitions are deleted.

This overriding happens when the makefile is parsed, using simple
textual comparisons.  So, in the case of f%, when the makefile is parsed
the prerequisites of the f% pattern are different; one is '$(info x)'
and the other is '$(info y)'.  Thus these are not considered the same
pattern rule so the second does not overwrite the first and BOTH will be
present in GNU make's internal rules database.

However, because make matches rules in the order in which they're
defined, the second one will never be used (because the first one will
match).


I don't see any good way to determine that the f% rules are duplicates.
We can't know until we resolve the rule, so the only way that could work
would be that we resolve ALL the possible rules, not just the first
matching one, and keep the LAST rule that had the same
target/prerequisite after evaluation, which is insane.

Another option, which might be more reasonable, would be to go the other
way: to say that rules that contain variable references
when .SECONDEXPANSION is enabled never override each other, even if they
target and prerequisites (before expansion) are the same.

In other words, in the above example you would get "bar rule 1" instead
of "bar rule 2".

The thinking I have here is that since the prerequisite value is not
known until runtime in this situation (consider, for example, if FOO was
a target-specific variable that was different for different targets that
matched "b%"), you shouldn't override the first one on a simple textual
comparison because you don't know that they are actually the same.

That's an enhancement we could consider.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist