Re: GDB/MI snapshots between major release's

["Eli Zaretskii" <eliz at gnu dot org>]

> Date: Tue, 5 Oct 2004 10:07:36 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Bob Rossi <bob@brasko.net>, kettenis@gnu.org, gdb@sources.redhat.com
> 
> I think using a command line switch makes sense.  You're going to have
> to restart GDB to change MI protocols anyway, so why force the user to
> go into MI?

First, it is possible that when the front end knows which MI version
is the last stable one, it will not need to restart GDB, but just
arrange for the appropriate parser to be used for the rest of the
session.

And second, even if you do need to restart, it makes sense to have
this command in the MI so that the same parser could be used to do
the job of finding the MI version(s) as well, instead of having a
special code that parses the ouput of a command-line option.

A downside of the command-line option that I very much don't like is
that command-line options are mainly for the human users and are
documented in a special section that describes how to run GDB, not how
to use the MI interpreter.

> I also like the idea of listing non-MI (which right now means annotate)
> protocols in the same output.

Does some front end need that?  If not, why introduce unneeded
generalizations?  I actually think that the output of the feature we
are discussing needs to be a single string: the latest version of MI
supported by this GDB that is known to be stable.  Given that info,
the front end should be able to figure out all the stable versions it
can use: they are those whose version numbers are below the latest
stable one.