From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6376 invoked by alias); 20 Dec 2006 06:01:55 -0000 Received: (qmail 6368 invoked by uid 22791); 20 Dec 2006 06:01:54 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 20 Dec 2006 06:01:49 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 0689D48CBF5; Wed, 20 Dec 2006 01:01:48 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05056-01-9; Wed, 20 Dec 2006 01:01:47 -0500 (EST) Received: from takamaka.act-europe.fr (AStDenis-105-1-88-134.w80-8.abo.wanadoo.fr [80.8.217.134]) by nile.gnat.com (Postfix) with ESMTP id 300C148CB9E; Wed, 20 Dec 2006 01:01:47 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id CF53334C099; Wed, 20 Dec 2006 10:02:33 +0400 (RET) Date: Wed, 20 Dec 2006 06:01:00 -0000 From: Joel Brobecker To: Mark Kettenis , gdb@sourceware.org, dave.anglin@nrc-cnrc.gc.ca, Mark Kettenis Subject: Re: Likely obsolete pieces of GDB Message-ID: <20061220060233.GA27642@adacore.com> References: <20061216205923.GA21428@nevyn.them.org> <13057.82.92.89.47.1166358029.squirrel@webmail.xs4all.nl> <20061217153726.GB16423@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061217153726.GB16423@nevyn.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00181.txt.bz2 > I am happy to change the mechanism; I don't like // OBSOLETE either. > We can't even use the current mechanism for some of these files: > anything not directly corresponding to a target. > > To be honest, I'd been thinking about waiting for everyone to agree on > which things to remove, sending a message to gdb-announce, and then > just doing it. If there were any justifiable complaints at the time of > the next release we could recover targets from CVS history. I'm sure > not everyone is comfortable with that sudden of an approach, so > using configure for targets for one release is fine with me too. Either approach is fine with me. I agree the // OBSOLETE approach is a bit of a pain... -- Joel