From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Eli Zaretskii Cc: nickrob@gnu.org, gdb-patches@sources.redhat.com Subject: Re: [Commit] New file Date: Thu, 27 May 2004 20:19:00 -0000 Message-id: <40B63FED.7080502@gnu.org> References: <16563.42891.155614.609433@nick.uklinux.net> <6654-Wed26May2004124733+0300-eliz@gnu.org> <40B4C9A9.3040904@gnu.org> <6137-Thu27May2004102142+0300-eliz@gnu.org> X-SW-Source: 2004-05/msg00761.html 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