Re: [Commit] New file

[Andrew Cagney <cagney at gnu dot org>]

> Yes.
>
> My take of this is that IMHO the code in gdb-mi.el will bit-rot on the
> Emacs side much faster than on the GDB side.  That is because the
> GDB/MI API is supposed to change/evolve much slower than the Emacs
> features related to gdb-mi.el.
>
> It's true that GDB release cycle is much frequent than the Emacs
> release cycle, but OTOH the pace of code changes checked into the
> Emacs CVS is much faster than that of GDB.  Specifically, many
> display-related features for which gdb-mi is an ideal application were
> introduced during the the last couple of months alone.  There's no
> comparable change in the MI interface and/or features.
>
>
> > > With GDB's more frequent release cycles there's a greater oportunity
> > > to expose the code to a wider audience.
>
>
> As the Emacs CVS is accessible by anonymous, it's very easy to get the
> latest gdb-mi.el.  So this is a non-issue, I think.

Here's the catch.  It isn't the existing GDB/MI API at issue here, it's 
the new/missing interfaces needed to reflect ongoing changes in GDB:

- support for frame IDs
- support for register groups
- support for event notifications
- a fix to that ``query'' problem
- ...

along perhaphs with:

- support for NxM breakpoints (if they happen)
- proper event notification (ongoing)

It's going to be a lot easier if both the client and server are there in 
front of us.

(For me personally, I'm not going to rush out and down load the latest 
emacs, however I will be comfortable with using the latest gdb-mi.el 
with a recent emacs release.)

Andrew