This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: (toplevel patch) Fix multilib.out dependencies and relatedproblems
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Nathanael Nerode <neroden at twcny dot rr dot com>
- Cc: 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 18:23:11 -0800
- Subject: Re: (toplevel patch) Fix multilib.out dependencies and relatedproblems
- References: <20021220015902.GA1721@doctormoo>
Nathanael Nerode <neroden@twcny.rr.com> writes:
>>> 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.
The Right Thing is ever so slightly more complicated:
STAMP = echo timestamp >
multilib.out : s-multilib ; @true
s-multilib : gcc/xgcc
gcc/xgcc --print-multilibs > multilib.tmp
$(srcdir)/move-if-change multilib.tmp multilib.out
$(STAMP) s-multilib
[plus, make sure to delete s-multilib as well as multilib.out on
'make clean'.]
What this does for you is avoid running the actual rule for
multilib.out if gcc/xgcc hasn't changed. Instead, it only runs the
rule for s-multilib, which is a no-op.
zw