[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #59490] target may not be remade if prerequisite has no recipe

From: Paul D. Smith
Subject: [bug #59490] target may not be remade if prerequisite has no recipe
Date: Fri, 20 Nov 2020 15:12:01 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

Follow-up Comment #3, bug #59490 (project make):

Your attached makefile shows the issue you're trying to get at, but the
example in your question is incomplete: it's missing the fact that (a) you run
"make d1" and (b) the file "c1" must already exist before the makefile runs. 
If "c1" doesn't exist, then "d1" will get rebuilt.

It's not actually the case that this is due to the directory cache, at least
not exactly.  I have a set of changes locally that "fix" the directory cache
problem by invalidating the cache every time make invokes a command of any
type.  However it doesn't change the behavior in this case.

The reason for the behavior is that make starts with d1, then decides it needs
c1.  Then it tries to build "b1", and succeeds.  However, your makefile is
lying to make; it says that the recipe for b1 builds just b1, but in fact it
also builds c1 "behind make's back".  Since make has no idea that c1 was
modified, it does not re-check the timestamp for c1.

Whether this is right or not, I'm not sure.  I'd have to re-check the manual
and the POSIX spec.  It's certainly the way GNU make has worked for 30 years
or so.

If you just want to avoid the problem, another alternative to using an empty
recipe (assuming you have GNU make 4.3) is to tell make the truth: that one
rule builds both targets.  You can do that with:

b1 c1 &: a1
        touch b1
        touch c1

(and remove the "c1: b1" prerequisite).


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]