See bug #20006 as another instance

See also bug #21670 for another instance of this.

Hm.  I looked at this.  It looks like a bug to me.  I traced it down to a change by BorisK on 21 Sep 2004:

• implicit.c (pattern_search): When considering an implicit rule's

prerequisite check that it is actually a target rather then
just an entry in the file hashtable.

By making this change we require that all prerequisites be targets at the time we do the implicit rule search, which is clearly not true for your situation as the prerequisite (foo) is not a target until after you match the implicit rule.  To see why this change was made I undid it, then ran the test suite and the reason for the change became obvious: the goal is to allow implicit rule searches to skip past explicit files that do not exist, to get to an implicit rule that CAN be made.  the misc/general4 test, for example, uses this makefile:

$ touch bar
$ cat makefile
test.foo:
%.foo : baz ; @echo done $<
%.foo : bar ; @echo done $<
fox: baz

For this makefile make 3.80 doesn't do what we'd like, which is skip the first implicit rule (because baz doesn't exist and cannot be remade) and find the second implicit rule, where "bar" does exist, and print "done bar".  With 3.81 we do get that behavior, but with 3.80 we don't: we get an error that baz does not exist and cannot be remade.

Looking at the GNU make manual section "Implicit Rule Search Algorithm", we see why 3.80 behaves the way it does; by step 5c make chooses the first implicit rule where all prerequisites exists or ought to exist.  Because of the "fox: baz" line above, mentioning "baz" as a prerequisite on an explicit rule, "baz" is considered a file that "ought to exist", and so make chooses the first rule and fails, even though if it skipped to the second rule it could succeed.

The change Boris added, while enabling this case to succeed, broke the case you're bringing up here and possibly some other problems with implicit rule chaining that have been reported (I'll have to look at them carefully to see).  Also, the behavior of make doesn't match the manual any longer since the meaning of "ought to exist" has been changed.

So, I'm tempted to revert the change.  I'm not adverse to modifying the chaining algorithm to allow make to be smarter about the case Boris is concerned about, but this simple change is too simple.  To really fix this we'd need to try to build the prerequisites and see if it fails, not just test to see if they're targets or not.  I suspect, though, that the reason rule 5c is there is to prune the decision tree to be manageable, and that if we extend that rule to allow searching to decide whether files that "ought to exist" really DO exist (or can be made to exist) the possible outcomes will explode and make will become pretty slow.

I'll discuss this with Boris.