Re: [PATCH] Hooks still needed for annotations

[Bob Rossi <bob@brasko.net>]

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