Re: (toplevel patch) Fix multilib.out dependencies and related problems

[Nathanael Nerode <neroden@twcny.rr.com>]

>> Uh, yeah.  Make isn't designed to realize that you can change a file
>> and not change the generated file depending on it; this is not an
>> unreasonable assumption in most cases.  To put it another way, I
>> don't care very much.
>
>Except that gcc's makefile does this all over the place, and it works
>just fine.  I was told about this trick in school - in 1986, on a
>Gould mainframe.  It works.
>
>multilib.out : gcc/xgcc
>        gcc/xgcc --print-multilibs > multilib.tmp
>        $(srcdir)/move-if-change multilib.tmp multilib.out
Right.  I'm happy to do this.

>> Of course it should.  But it can't, it actually can't, because then
>> we have a real target depending on a phony target, and every target
>> subdir gets reconfigured every single time.  Sorry.
>
>Right, except for the move-if-change trick, which short circuits it if
>there is no real change.  That's the whole purpose of the
>move-if-change script.

Hmm.  So the trick is that *multilib.out* gets hit every single time 
because it depends on all-gcc, but foo/Makefile *doesn't*.

In other words, when multilib.out is considered 'out of date' and needs 
to be rebuilt, its rule is run.  But if that rule doesn't change the 
datestamp on multilib.out, Make decides that the things depending on 
multilib.out, such as foo/Makefile, *don't* need to be rebuilt.

How sad for Make; it can't assume that because it rebuilt something, 
that that something changed. :-)  I didn't know that POSIX makes were 
required to deal with that sort of seeming paradox...

OK, I get it.  Revised patch coming in a minute or two.

--Nathanael