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 <[email protected]> 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 _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
