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.

Reply via email to