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 <psm...@gnu.org> 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 _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make