Re: problem with chained if statements?

[Ovidiu Predescu <ovidiu@cup.hp.com>]

On Thu, 18 Mar 1999 15:51:12 -0600, "Thompson, James C" 
<James.C.Thompson@USAHQ.UnitedSpaceAlliance.com> wrote:

> > From: Stan Shebs [mailto:shebs@cygnus.com]
> > No consensus.  The tclites push for tcl of course, but that has
> > political problems. Guile would be officially approved of, but no
> > actual hacker seems to care enough to contribute actual changes.
> > Other ideas surface from time to time, but haven't really gone
> > anywhere.  If I was told I could have only one, I would probably
> > go with Guile.
> 
> I recently added guile scripting support to a simulator project I work on,
> and found it fairly easy; we added simple (usually) guile wrappers to each
> function that needed to be available as a guile call.  If the gdb command
> parser is structured so that each major command -- print, where, next, etc.
> -- is bound to a single C function, then adding guile should be
> straightforward.  Of course, you probably wouldn't want to completely
> supplant the current command parser, but to augment it so that the current
> command syntax is still available, with "guile-looking" commands getting
> passed off to guile for evaluation.  This is certainly possible.
> 
> But I think the real power would be to add hooks into gdb at various places
> to which guile scripts can be attached.  Breakpoints, for example: if I
> could tell gdb to run a guile script each time a breakpoint is encountered,
> then I could do "conditional debugging" by letting the script examine the
> inferior program state so that execution pauses only when certain criteria
> are met.  Of course, it's possible to accomplish the same thing by building
> special debug code into the executable, but that's invasive and
> time-consuming -- best case, I have to recompile my program.  The ability to
> set up and change these hooks on the fly would be very nice.
> 
> --JT

Even more interesting would be to add support for more than one scripting
language. This could be achieved very easy with SWIG (http://www.swig.org).
This is a free software tool (has a BSD license) that makes easy adding
scripting support to C programs. All you have to do is to write an interface
file describing your internal C functions. SWIG is a compiler that takes this
interface file and generates the glue functions that are could be used directly
from various interpreters, including Perl, Python, TCL and Guile. The only
thing now is to see how to integrate it with the current command line
processing code.

I think such a thing could satisfy most of the people since they will not be
forced to use a scripting language or another to write their extension. One
question though: would its license allow FSF to release the resulting C code
under GPL? Would FSF be happy if gdb suddenly becomes dependent on a tool
that's not owned by them?

Greetings,
Ovidiu