Re: obsoleting the annotate level 2 interface

[Pierre Muller <muller at ics dot u-strasbg dot fr>]

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?).

 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.