From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8355 invoked by alias); 20 Dec 2002 01:29:52 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 8328 invoked from network); 20 Dec 2002 01:29:51 -0000 Received: from unknown (HELO delorie.com) (207.22.48.162) by 209.249.29.67 with SMTP; 20 Dec 2002 01:29:51 -0000 Received: from envy.delorie.com (envy.delorie.com [207.22.48.171]) by delorie.com (8.11.6/8.9.1) with ESMTP id gBK1TRX25201; Thu, 19 Dec 2002 20:29:27 -0500 Received: (from dj@localhost) by envy.delorie.com (8.11.6/8.11.2) id gBK1TQP18704; Thu, 19 Dec 2002 20:29:26 -0500 Date: Thu, 19 Dec 2002 18:00:00 -0000 Message-Id: <200212200129.gBK1TQP18704@envy.delorie.com> X-Authentication-Warning: envy.delorie.com: dj set sender to dj@delorie.com using -f From: DJ Delorie To: neroden@twcny.rr.com CC: gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com, binutils@sources.redhat.com In-reply-to: <20021220011716.GA1569@doctormoo> (message from Nathanael Nerode on Thu, 19 Dec 2002 20:17:16 -0500) Subject: Re: (toplevel patch) Fix multilib.out dependencies and related problems References: <20021220011716.GA1569@doctormoo> X-SW-Source: 2002-12/txt/msg00568.txt.bz2 > 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.