This is the mail archive of the
mailing list for the binutils project.
Re: (toplevel patch) Fix multilib.out dependencies and related problems
- From: Nathanael Nerode <neroden at twcny dot rr dot com>
- To: gcc-patches at gcc dot gnu dot org, binutils at sources dot redhat dot com, gdb-patches at sources dot redhat dot com, dj at redhat dot com
- Date: Thu, 19 Dec 2002 20:59:02 -0500
- Subject: Re: (toplevel patch) Fix multilib.out dependencies and related problems
>> 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
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.