RE: Discussion: Formalizing the deprecation process in GDB

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: Andrew Cagney 
> Sent: 07 October 2004 16:38

> >   Ok, I also read the code, but I very much appreciate having good
> > documentation in book format.  If you've got a serious 
> chunk of architecture
> > to learn about, it's a lot easier if it's all in one file 
> that you can print
> > out and browse through at your leisure rather than a page 
> here and a page
> > there scattered across many files.
> 
> (An architecture document is no more than 2 A4 pages, and one 
> diagram - 
> that is extreemly highlevel but gets across the concepts.)

  Um, OK, that wasn't the kind of document I was talking about.  I was
thinking of something more like (frex) the set of manuals that describe and
specify the abstract PPC operating environment (without reference to any
specific ppc cpu implementation).

> A system that is being continuously re-factored is not well 
> suited for 
> detailed internals documentation - the effort is wasted.  Instead the 
> high level architecture and medium level object models that 
> are important.

  This is something more like what I meant to describe by the term "chunk of
architecture".  Or something like (to use another gcc example) rtl and the
chapter on rtl in the gccint manual.  As you say, high-to-mid range
overview.  Design decisions, system architecture, but not low-level
implementation specifics.

> There is no "migration" path.  The correct approach is:
> - delete all deprecated code
> - build
> - run testsuite
> - add a missing architecture vector method
> - repeat
> Instead of migrating, trying to reproduce each refactoring step, you 
> should leap frog.

  I'm not trying to migrate; I haven't been trying to get a stable working
version and make incremental changes that recapitulate the history of gdb's
recent development, I've been trying to do it all in one go as you suggest.
However, in order to do it all in one go, you still need to know *what* to
replace all the deprecated-and-deleted things with; that's not immediately
obvious by just browsing through the arch vector.  And it's quite easy to
implement some but not all of a set of mutually interacting or
interdependent arch methods and not know until you hit some particular
runtime combination of circumstances.

> A running joke between several of the GDB developers at the last GCC 
> summit was that we should present a 1hr paper titled "porting 
> GDB to a 
> new architecture".  Only instead of presenting slides, we'd 
> just write the code.

  I find it hard to believe that's possible for anyone who comes to the code
from fresh.  You have spent years working with gdb and have the advantage of
knowing your way round the code, and what the replacements for each
deprecated thing are; anyone else has to do lots of research.  If there's
going to be a formalization of the deprecation process, my 'feature request'
would be that there be one single central place where all deprecated
features are listed together with brief pointers to the new functionality
that has taken their place.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....