From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23887 invoked by alias); 8 Jan 2003 21:19:34 -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 23879 invoked from network); 8 Jan 2003 21:19:31 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 8 Jan 2003 21:19:31 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18WPUG-0000WY-00; Wed, 08 Jan 2003 17:19:52 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18WNbr-0005lv-00; Wed, 08 Jan 2003 16:19:35 -0500 Date: Wed, 08 Jan 2003 21:19:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney , Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [rfa/i386] Make codestream deprecated? Message-ID: <20030108211935.GA22170@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , gdb-patches@sources.redhat.com References: <3DEAAB57.4070609@redhat.com> <86bs3yoxc7.fsf@elgar.kettenis.dyndns.org> <3E1C878B.2050607@redhat.com> <20030108203021.GA5740@nevyn.them.org> <3E1C9225.8050605@redhat.com> <20030108211349.GA10113@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030108211349.GA10113@nevyn.them.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00341.txt.bz2 On Wed, Jan 08, 2003 at 04:13:50PM -0500, Daniel Jacobowitz wrote: > On Wed, Jan 08, 2003 at 04:03:33PM -0500, Andrew Cagney wrote: > > > > >Besides: this is why you should _remove_ them, rather than just > > >commenting them, if you want them to go away. > > > > The implication here being that I'm not removing deprecated code? > > A heck of a lot slower than you're deprecating! There are now over > 1200 references to deprecated constructs in GDB. That's just a rough > estimate, mind. > > I understand why release branches are bad points to compare against for > this, but since I have several handy: > ~150 deprecated references in gdb 5.3 > ~30 in gdb 5.2 > > > The simple reality is that it is not possible for a single individual > > remove all the old code in a single hit. It takes a group of people > > co-operating, and it takes time. I feel the need to add: If you are deprecating things single-handedly, what group of people do you expect to co-operate? It's a matter of cleaning up after yourself. > Sure, it takes time. Not all that much time, though; and it doesn't > have to be done all at once. I prefer to remove it from one target at > a time and then remove support for it entirely. There should be a > reasonably close alternative available; after all, it's being > deprecated in favor of something. > > > If you look through the change log you'll notice that deprecated methods > > are being removed from the core of GDB, but the -tdep and -nat files are > > being left largely untouched. Then, every so often, I or another > > maintainer will expunge the deprecated code from a target being it back > > into synck. Over time the old code moves to the edges of gdb where it > > wilters and dies. > > I don't see this happening. I see it move to the edge of GDB where it > withers, period. > > To come back to the case at hand, this construct has already "moved" > (started out?) to the edge of GDB. Deprecating it isn't going to help > it wither. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer