On Thu, Sep 26, 2002 at 09:13:07AM -0400, Andy Dougherty wrote: > On 26 Sep 2002, Tom Hughes wrote: > > > Andy Dougherty <[EMAIL PROTECTED]> wrote: > > > > > > The problem here is that the rule in the Makefile that causes it to > > > > rerun Configure.pl if any of the Configure.pl generated files is out > > > > of date clashes with the recently introduced edit to stop Configure.pl > > > > updating a file that hasn't actually changed. > > > > > > I think that the 'recently-introduced-edit' is wrong. Make's dependency > > > system requires that the stated commands actually bring something > > > up-to-date. > > > > On the other hand, without that edit it winds up rebuilding everything > > every time you run Configure, even if it doesn't have to... > > Yes. That is correct expected 'make' behavior (assuming the dependencies > are correctly listed). By analogy, a Makefile can also assume that > cc -c foo.c > will re-run the compiler, not just run it only if the compiler decides the > output will change in some significant way.
But it's perfectly valid to have portions of the system outside of make's dependency tree. So if the Makefile makes something dependent on Configure.pl, then it means that the something's timestamp must be updated whenever Configure.pl is run. However, if the makefile is unaware of anything depending on Configure.pl, then it's fine for Configure.pl to avoid updating timestamps when it doesn't change files. Which means we need to make a choice: we can either avoid needless rebuilds after running Configure.pl, or we can have a slightly more complete dependency graph and hence reduce the chance of some autogenerated .h file being out of date. Pick one of the other, but not both! I've done it either way in the past. When I'm messing with .in files or the configuration scripts, I always want it to avoid rebuilds. But when I'm answering bug reports that can be tracked down to people forgetting to re-run configure, I want everything laid out in the makefile. For Parrot, I would probably go for the latter (maybe with a flag to Configure.pl for when I think I know what I'm doing) -- except that the makefile rule is probably too much of a pain to maintain, so we might as well go with the former. To expand on that: the currently commented-out dependency on Configure.pl in the makefile is wrong. It says the $(STICKY_FILES) depend only on the Configure.pl script itself, which is woefully incomplete: they also depend on all of the *.in files, all of the configuration scripts, the Configure/*.pm modules, and probably other stuff I've neglected. And those are much more likely to change than Configure.pl, which is just a driver script.