%% Ross Boylan <[EMAIL PROTECTED]> writes: >> >> $(SOURCES): m.touch >> >> >> >> m.touch: m.web >> >> ftangle -F m.web >> >> @touch $@
rb> "Every non-.PHONY rule must update a file with the exact name of its target." rb> $(SOURCES) is the target in the line rb> $(SOURCES): m.touch rb> yet the $(SOURCES) are not updated by the rule. Further, at least rb> some members of $(SOURCES) are likely not to be updated by actions of rb> other rules (the one for m.touch) in the makefile (specifically, rb> ftangle -F). rb> But perhaps since this rule only expresses a dependency, and there rb> are no other rules with $(SOURCES) targets, we're in a different rb> ballpark. Correct; this is just a dependency definition. A rule would have a command associated with it. rb> Though I didn't have that rule specifically in mind, I did think rb> I'd get in some trouble if some of $(SOURCES) were permanently rb> older than m.touch. Apparently not... Make doesn't know about "permanently"; it has no concept of state. All it knows is that some files are older, and some are newer; in a dependency definition like the one above where multiple files appear on the left-hand side each one is considered individually. rb> Ah. I didn't know such caching was going on. Does the "behind rb> the back" ness derive from the fact that the files do not appear rb> in the command line for ftangle, or in the fact that the relevant rb> rule doesn't list them as targets? The latter. Make doesn't know anything about command lines: it doesn't parse them in any way except expanding variables [*]. It just passes them to the shell. rb> It might be useful at least to document it. I didn't notice any rb> mention of it in the make info pages, and there is no index entry rb> for cache or caching. The theory is that the cache is an implementation detail which is invisible to the user. Unfortunately in some situations that's not true (enough). rb> In my particular case it seems there is a solution that doesn't rb> require disabling the cache. Yes. rb> A final general comment on the documentation: I couldn't tell from rb> it exactly when out-of-dateness was determined. For example, it rb> could be done once before the makefile is processed; it could be rb> done just at the time a rule is checked; it could be done some rb> other way. It would be very helpful to say explicitly how this rb> happens. I suppose the caching makes that a little tricky. There is really only one possible answer for this, though: out-of-date-ness for a given target is evaluated after all its prequisites have been determined to be up-to-date, to decide whether the target needs to be updated. I suppose this could be made more explicit in the manual. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/help-make
