This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Nathanael Nerode <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]