This is the mail archive of the
mailing list for the binutils project.
Re: (toplevel patch) Fix multilib.out dependencies and related problems
- From: DJ Delorie <dj at delorie dot com>
- To: neroden at twcny dot rr dot com
- Cc: gcc-patches at gcc dot gnu dot org, gdb-patches at sources dot redhat dot com, binutils at sources dot redhat dot com
- Date: Thu, 19 Dec 2002 20:29:26 -0500
- Subject: Re: (toplevel patch) Fix multilib.out dependencies and related problems
- References: <20021220011716.GA1569@doctormoo>
> 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
> >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
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.