Re: obsoleting the annotate level 2 interface

[Elena Zannoni <ezannoni@redhat.com>]

Pierre Muller writes:
 > At 08:32 21/01/2003, Jim Blandy wrote:
 > 
 > >GDB seems to support two different ways of doing detailed annotations
 > >of its output for consumption by other programs: MI and 'set annotate
 > >2'.  I don't think annotation level 2 has many active users, if any at
 > >all.  It pervades GDB's code.  Would it make sense to put 'set
 > >annotate 2' on the path to obsolescence?
 > >
 > >Some background: the 'set annotate' command sets the
 > >'annotation_level' variable.  There are only three distinguished
 > >values for this variable:
 > >
 > >0: nothing special, GDB behaves normally.
 > >1: in source.c:line_info and stack.c:print_frame_info, when we print
 > >   the source line, we print out something extra that helps Emacs pop
 > >   up the source code in a window.
 > >2 or greater: we enable around 250 calls to a variety of functions in
 > >   annotate.c to mark and identify lots of things GDB prints.
 > >
 > >I think we should keep level 1, since the standard Emacs GDB interface
 > >uses it, and it's not very much code.
 > >
 > >I'd like to see GDB dump level 2, since it duplicates MI, badly.  MI's
 > >design ensures that whoever's trying to parse GDB's output gets
 > >something that's well-formed, whereas annotate just sticks escape
 > >codes into the outgoing stream of text.  This means that, if you
 > >change the way anything prints, you may break an annotate level 2
 > >client.  But to break an MI client, you actually have to change a
 > >ui_out call, whose sole purpose is to produce output for clients to
 > >read.  So MI is a much more maintainable approach, because it's easier
 > >for people to see what they're doing.
 > >
 > >If folks agree that annotate level 2 should go, we could:
 > >- announce that annotate level 2 will be disabled in the release after
 > >  next;
 > >- in that release, disable the code, but leave it there, to see if
 > >  anyone complains, and whether they can be persuaded to switch to MI;
 > >  and
 > >- in the release after that, if all goes well, remove the code to
 > >  support annotation level 2.
 > 
 > 
 > I don't really understand the final implications of this removal:
 > 
 > -  the GDB support inside the FP IDE
 > (Free Pascal Integrated Development Editor)
 > is done by specific implementation of all the
 > annotate_XXX functions defined in annotate.h.
 > 
 > Are you going to remove all these functions?
 > Because the annotate.c almost empty
 > if we remove all code that has
 > 'if (annotation_level > 1) '
 > apart from some annotation hooks...
 > 
 > I am not against moving to MI, but I still didn't find the time to do it....
 > Where can I find a clean example of an implementation of gdb that
 > only uses mi functions (is insight mi clean?).
 > 

No, insight doesn't use MI. Apple's Project Builder does, I think the sources
are available on their web site. Alternatively, look at www.eclipse.org,
their cdt uses MI.

 >  I still do not undersantd clearly the difference between 
 > cli and mi, is that explained in the docs?
 > I didn't find anything about MI interface in gdbint doc.
 > 

Wrong manual, it is in the gdb users manual:
http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC217


Elena