Re: [rfa/i386] Make codestream deprecated?

[Daniel Jacobowitz <drow@mvista.com>]

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.

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