From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20901 invoked by alias); 29 Sep 2002 17:30:24 -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 20882 invoked from network); 29 Sep 2002 17:30:22 -0000 Received: from unknown (HELO nerodeguest) (24.161.107.98) by sources.redhat.com with SMTP; 29 Sep 2002 17:30:22 -0000 Received: from neroden by nerodeguest with local (Exim 3.35 #1 (Debian)) id 17vhpY-0001KQ-00; Sun, 29 Sep 2002 13:26:08 -0400 Date: Sun, 29 Sep 2002 10:30:00 -0000 To: Andrew Cagney Cc: gdb-patches@sources.redhat.com, binutils@sources.redhat.com, gcc-patches@gcc.gnu.org Subject: Re: top level: make more dependencies explicit Message-ID: <20020929172608.GA27678@doctormoo.dyndns.org> References: <20020929165232.GA27545@doctormoo.dyndns.org> <3D9733C2.2010405@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D9733C2.2010405@redhat.com> User-Agent: Mutt/1.4i From: Nathanael Nerode X-SW-Source: 2002-09/txt/msg00717.txt.bz2 On Sun, Sep 29, 2002 at 01:09:22PM -0400, Andrew Cagney wrote: > Nathanael, > > FYI, I'm about to revert this change: > > 2002-09-25 Nathanael Nerode > > * Makefile.tpl: Make subsituted variables more autoconfy. > * Makefile.in: Regenerate. > * configure: Make seds more autoconfy. > > It breaks both the GDB and BINUITLS snapshot processes. Details to > follow, however, suggest a short pause. Uh... yuck. Are there some details on the GDB and BINUTILS snapshot processes so that I can fix *them*? This change is going to happen eventually, even if it's reverted for now; the Makefile changes will be necessary for autoonfiscation. Wait, let me look at Makefile.in... Ewwwww. The taz rules use Makefile.in *as a Makefile*. That's the root of the problem, isn't it? Incidentally, that's disgusting. :-) 1. Is there a simple way to stop doing this, by generating a proper Makefile? 2. If not, how about generating an alternate file 'Makefile.in.for.taz' (better names solicited) for these rules to use, so that the ordinary Makefile.in can keep progressing? Would that do? I think that's pretty easy. --Nathanael