From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2476 invoked by alias); 12 May 2006 19:01:58 -0000 Received: (qmail 2462 invoked by uid 22791); 12 May 2006 19:01:56 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 12 May 2006 19:01:54 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Fectc-00041y-L9 for gdb-patches@sourceware.org; Fri, 12 May 2006 15:01:52 -0400 Date: Fri, 12 May 2006 19:16:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: CLI and GDB/MI documentation patch Message-ID: <20060512190152.GA15416@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <20060512011730.GA26655@brasko.net> <20060512124940.GB3860@nevyn.them.org> <20060512135802.GA6472@nevyn.them.org> <20060512183723.GA14434@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00256.txt.bz2 On Fri, May 12, 2006 at 09:55:38PM +0300, Eli Zaretskii wrote: > > Date: Fri, 12 May 2006 14:37:23 -0400 > > From: Daniel Jacobowitz > > > > So, for someone who must support multiple versions of GDB, they would > > have to read NEWS looking for changes, find the new behavior in the > > current manual, and find the old (hopefully documented) behavior in the > > old manual? > > No. I propose to have a special section devoted to incompatible > changes in the remote protocol, and another one for incompatible > changes in MI. Thus, no searching is necessary. New sections in NEWS, you mean? I see. > As for old behavior, since the old versions of protocol/MI is already > supported by the tools whose authors are the audience of these NEWS > sections, I'd expect them to be well acquainted with the old behavior. > So I don't think they will need to look for that. No, I can't support that assumption. New tools, written today, are probably written against a fairly current manual. Then someone approaches you and says "I'd like to use your nice IDE on our stable enterprise platform from three years ago which has an older GDB". The range of supported GDBs does not only grow forwards. > If you feel we should tell how to create a front end and/or a stub > that supports several versions of GDB/MI or remote protocol, that's > fine by me, but let's have sections whose focus is to provide tips to > such programmers, not to tell the history of MI or the protocol's > evolution. That's quite a different attitude than what Bob wrote. I do think that such a section would be useful. I'm not entirely sure about the distinction you are drawing, though. Is it a "what" versus "why" difference? -- Daniel Jacobowitz CodeSourcery