RE: this is embarrasing... prerequisiste gets updated, but make still says it is older than target

[Paul Smith]

On Mon, 2012-04-02 at 05:55 -0700, Mark Galeck (CW) wrote:
> >This is not different.  The order-only prerequisite means that the
> "resources" target is not considered by make when it decides whether or
> not to rebuild foobar1.  So make never tries to rebuild 'foobar1' (you
> can see this in the output).
> 
> 
> Fine, same behaviour, one more step.  This time you have a "normal" 
> prerequisite.
> 
> .PHONY: phony
> 
> foobar: foobar1
>       touch $@
> 
> foobar1: foobar2 | resources
>       touch $@
> 
> resources: phony 
>       touch foobar1
>       touch $@

If foobar2 is newer than foobar1, then foobar1 will rebuild.  If not,
not.  Adding the target foobar2 doesn't change the relationship between
foobar1 and the "resources" target, which updates foobar1 without make's
knowledge.

> I badly need the clarification of exactly when is the checking of
> timestamps of the "normal" (Not order-only) prerequisites, done for
> the purpose of deciding whether the target needs to be updated.
> Please.  

I've already explained it as well as I'm able.  Maybe someone else can
take a crack at it.

For the purposes of thinking about make, you should consider that make
knows the timestamps when it starts up, and it knows, based ONLY on the
definitions of the rules it's invoked and nothing else, what targets
have been updated.  That's all there is to it.  If your makefile changes
targets in ways that make doesn't know about, then make may not realize
that.

The reality is more nuanced than that, as I've discussed: make has a
cache of time-last-modified stamps that it updates dynamically as it
runs, so it doesn't really pre-determine all the timestamps right up
front.  This cache was implemented a long time ago (before I started
maintaining make) as a performance enhancement, since running stat(2)
can be expensive (Windows, actually, is one of the worst in this
category) and make needs to do it a lot.  The cache does cause a lot of
confusion, however, so I've considered doing away with it despite it's
performance impact.

However, if you stick with the simple model (an initial state, plus the
targets make knows it's updated, and no targets updated in any other
way) you will definitely not go wrong.


You still haven't described what you're trying to do.  However, I'll say
that _probably_ the way to solve your problem is to go back to the
original attempt, with the phony prerequisite, and just add an empty
rule to foobar1:

> > foobar: foobar1
> >         touch $@
> > 
> > foobar1:  foobar_phony
> > 
> > .PHONY: foobar_phony
> > foobar_phony:
> >         touch foobar1

Change the rule for foobar1 so there's a recipe there, even a "do
nothing" recipe:

        foobar1: foobar_phony
                @:

Now that make has a recipe that could potentially create foobar1 it will
need to re-check the timestamp on foobar1.  It was only because there
was no recipe for building foobar1, that make decided there was no way
the timestamp on foobar1 could have changed and so it didn't re-check
it.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          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