From: Zack Weinberg <zack@codesourcery.com>
To: Nathanael Nerode <neroden@twcny.rr.com>
Cc: gcc-patches@gcc.gnu.org, binutils@sources.redhat.com,
gdb-patches@sources.redhat.com, dj@redhat.com
Subject: Re: (toplevel patch) Fix multilib.out dependencies and related problems
Date: Thu, 19 Dec 2002 18:24:00 -0000 [thread overview]
Message-ID: <874r99mnsg.fsf@egil.codesourcery.com> (raw)
In-Reply-To: <20021220015902.GA1721@doctormoo> (Nathanael Nerode's message of "Thu, 19 Dec 2002 20:59:02 -0500")
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
next prev parent reply other threads:[~2002-12-20 2:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-19 18:08 Nathanael Nerode
2002-12-19 18:23 ` DJ Delorie
2002-12-19 18:24 ` Zack Weinberg [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-12-19 17:29 Nathanael Nerode
2002-12-19 18:00 ` DJ Delorie
2002-12-19 16:16 Nathanael Nerode
2002-12-19 17:18 ` DJ Delorie
2002-12-21 19:02 ` Alexandre Oliva
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874r99mnsg.fsf@egil.codesourcery.com \
--to=zack@codesourcery.com \
--cc=binutils@sources.redhat.com \
--cc=dj@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=neroden@twcny.rr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox