From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1215 invoked by alias); 15 Jun 2005 16:31:53 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1193 invoked by uid 22791); 15 Jun 2005 16:31:50 -0000 Received: from lakermmtao04.cox.net (HELO lakermmtao04.cox.net) (68.230.240.35) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 15 Jun 2005 16:31:50 +0000 Received: from white ([68.9.64.121]) by lakermmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050615163148.FQTN20878.lakermmtao04.cox.net@white> for ; Wed, 15 Jun 2005 12:31:48 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1Dians-0005VT-00 for ; Wed, 15 Jun 2005 12:31:48 -0400 Date: Wed, 15 Jun 2005 16:31:00 -0000 From: Bob Rossi To: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Hooks still needed for annotations Message-ID: <20050615163147.GD20778@white> Mail-Followup-To: gdb-patches@sources.redhat.com References: <17053.24737.153388.915345@farnswood.snap.net.nz> <20050601113004.GC15414@white> <17054.10607.109160.333076@farnswood.snap.net.nz> <20050603190856.GB32722@nevyn.them.org> <17056.56022.36723.292491@farnswood.snap.net.nz> <20050603235923.GA9992@nevyn.them.org> <20050604130228.GA24976@white> <20050613031400.GF9288@nevyn.them.org> <20050615155248.GC20778@white> <20050615160749.GA17626@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050615160749.GA17626@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-06/txt/msg00198.txt.bz2 On Wed, Jun 15, 2005 at 12:07:49PM -0400, Daniel Jacobowitz wrote: > On Wed, Jun 15, 2005 at 11:52:48AM -0400, Bob Rossi wrote: > > > I don't much think a parser is GDB's responsibility. Offering one as a > > > convenience, sure, maybe. Note that a lot of frontends won't get to > > > use it anyway! If we ship it with GDB, then it's going to be covered > > > under the GPL. > > > > Well, could I maintain a copy under the LGPL, and then contribute all of > > the modifications to the FSF GDB under the GPL? > > LGPL would not help much; you'd need something BSD-ish. You could, of > course, do whatever you wanted to do with code that you wrote. But I > don't think there's much point to that; if you contribute it to GDB, > that will be so that other developers can help you maintain it and keep > it up to date with changes in MI. You won't get all the other GDB > contributors to relicense their work. O Right. Sorry to even bring it up. What is the stand of the FSF regarding an LGPL library? and why do you think that the parser would have to be under a more academic license instead of a reciprocal license? > > Either way, I don't care much about commercial tools. If a good parser > > is created, I think it's possible a lot of front ends will use it. For > > instance, KGDB, DDD and GVD are all free projects that could benefit > > from such a technology. Right? > > KGDB is a stub, not a frontend. DDD could use it - not sure if > anyone's updating DDD enough nowadays to bother. GVD could, but would > be unlikely to unless you wrote the parser in Ada! (Not that Ada can't > use C bindings, but the GPS maintainers would presumably prefer > language consistency.) Well, I already have planned a way to translate the parse tree into Tcl. I am going to walk the parse tree and then build up a Native Tcl parse tree using callbacks. By doing this, I can write testcase's in Tcl using the parse tree. This would really allow for a much higher level of testing. The ADA developers could use the exact same approach and it would be much more trivial for them to do so. I'm getting a vibe from you that you think writing a parser could be a bad idea. Do you really think that the community wouldn't embrace such a parser? The whole reason I decided to create it (or at least in the works) is because I was frustrated with the thought of writing yet another low level parser to parse the MI. I just wanted one that worked, and worked well. Even more than that, I wanted one that I didn't have to constantly maintain. I mean, Nick and I are already going to create two different parsers. As things evolve, and the parser's need to work with old versions of GDB, different bugs will pop up in each. I think this hurts GDB in the long run. I also firmly think that the only possible way to get a stable MI parser is to test it in GDB's testsuite. Thanks, Bob Rossi