This is the mail archive of the binutils@sources.redhat.com 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 related problems


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


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