From: DJ Delorie <dj@delorie.com>
To: neroden@twcny.rr.com
Cc: gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com,
binutils@sources.redhat.com
Subject: Re: (toplevel patch) Fix multilib.out dependencies and related problems
Date: Thu, 19 Dec 2002 18:00:00 -0000 [thread overview]
Message-ID: <200212200129.gBK1TQP18704@envy.delorie.com> (raw)
In-Reply-To: <20021220011716.GA1569@doctormoo> (message from Nathanael Nerode on Thu, 19 Dec 2002 20:17:16 -0500)
> 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
> 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.
> >gcc subdir, because we don't know if something else besides xgcc
> >affects the specs (which affects multilib.out).
> Eeech. We should actually know what affects the specs, you know. :-/
We should, but gcc may read from an external specs file, and we don't
always know (easily) where that comes from. Especially if the gcc
we're using isn't the one we just built.
> Have the build process for gcc (I hope there's nothing else which
> can affect multilib.out...) do the testing and move-if-changing of
> multilib.out.
Unless we're not building gcc.
> * Whatever determines the contents of multilib.out should just get its
> own damn rule at the top level, rather than messing around with building
> the whole of gcc to determine that it's ".;".
gcc determines the multilib list, and it's a very complicated process
to do so.
> * Force every target subdir which actually cares about this to produce
> its own copy of multilib.out and to test whether it's out of date on its
> own, so that it's out of the hair of the top level.
This won't work because the targets are configured once for each
multilib. By the time the target subdir has control, it's too late.
next prev parent reply other threads:[~2002-12-20 1:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-19 17:29 Nathanael Nerode
2002-12-19 18:00 ` DJ Delorie [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-12-19 18:08 Nathanael Nerode
2002-12-19 18:23 ` DJ Delorie
2002-12-19 18:24 ` Zack Weinberg
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=200212200129.gBK1TQP18704@envy.delorie.com \
--to=dj@delorie.com \
--cc=binutils@sources.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