[bug #17752] target fails depending on order of prereqs

[Paul D. Smith]

Follow-up Comment #1, bug #17752 (project make):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?17752>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/