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

[Michael Ludwig]

Paul Smith schrieb am 02.04.2012 um 10:09 (-0400):
> On Mon, 2012-04-02 at 05:55 -0700, Mark Galeck (CW) wrote:
> > 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.

This explanation is very useful, and so are the others you gave in this
thread. Much more useful than the quotes from the manual Mark shared.

In my own words (please correct mercilessly if necessary):

While a rule's *recipe*, which might be seen as its implementation,
may do physical updates to things on the disk willy-nilly, it may, as
far as Make's logic is concerned, only update the rule's *targets*,
because that's the rule's specification which Make uses to wire up its
dependency matrix.

And Mark, your question is great, too, as it succinctly highlights
a point that's not obvious and easily misunderstood; and I hadn't
understood it before reading Paul's explanation here.

> 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.

Good conclusion.

Michael