Follow-up Comment #1, bug #21670 (project make):
Looks like a regression in 3.81, as the makefile works as desired with 3.80.
It seems the interpretation of step 5.c of the algorithm in section 10.8,
"Implicit Rule Search Algorithm" of the info pages changed:
c. Test whether all the prerequisites exist or ought
to exist. (If a file name is mentioned in the
makefile as a target or as an explicit
prerequisite, then we say it ought to exist.)
If all prerequisites exist or ought to exist, or
there are no prerequisites, then this rule applies.
make.c is mentioned in the makefile as an explicit prerequisite (for prog),
so make should conclude that "it ought to exist" and therefore the suffix rule
for .c.o should apply and block consideration of .DEFAULT for hello.o.
Note that 3.81 behaves as desired if this is added to the makefile:
make.o: make.c
It's like 3.81 interprets the phrase "explicit prerequisite" to mean
"explicit prerequisite of the current target" in step 5.c.
That said, the .DEFAULT rule in the example seems like the wrong tool for the
job here. The right way to tell GNU make that the backup/ directory may
contain a copy of a missing prerequisite would be this:
%:: backup/%
ln -s $< $@
Note that with that instead of the .DEFAULT rule, GNU make operates
correctly, even after removing the 'make.c' dependency for the 'prog' target.
(The rule for 'prog' doesn't use 'make.c', only 'make.o', so it has no real
reason to depend on 'make.c'.)
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?21670>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
