From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eli Zaretskii" To: Andrew Cagney Cc: nickrob@gnu.org, gdb-patches@sources.redhat.com Subject: Re: [Commit] New file Date: Thu, 27 May 2004 07:23:00 -0000 Message-id: <6137-Thu27May2004102142+0300-eliz@gnu.org> References: <16563.42891.155614.609433@nick.uklinux.net> <6654-Wed26May2004124733+0300-eliz@gnu.org> <40B4C9A9.3040904@gnu.org> X-SW-Source: 2004-05/msg00759.html > Date: Wed, 26 May 2004 12:45:29 -0400 > From: Andrew Cagney > > > I personally don't like the idea of having an Emacs file in the GDB > > distribution. We had such a file in the past, and the result was that > > it could never be in sync with the Emacs code base. I'm unwilling to > > go through that experience once again. > > As this code evolves it is going to find that it is caught between two > competing masters: GDB; and EMACS. For each we'll need to juggle both > interface and release cycle concerns. As such we need to decide which > of those two masters is, at least for the moment, more important. 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.