From: Stan Shebs <shebs@cygnus.com>
To: ovidiu@cup.hp.com
Cc: James.C.Thompson@USAHQ.UnitedSpaceAlliance.com, gdb@cygnus.com
Subject: Re: problem with chained if statements?
Date: Thu, 01 Apr 1999 00:00:00 -0000 [thread overview]
Message-ID: <199903212138.NAA05643@andros.cygnus.com> (raw)
In-Reply-To: <199903182302.PAA30442@hpcll563.cup.hp.com>
Date: Thu, 18 Mar 1999 15:02:49 -0800
From: Ovidiu Predescu <ovidiu@cup.hp.com>
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 ).
[...]
SWIG is certainly an interesting approach, worth thinking about further.
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?
That's somewhat of a gray area. It's usually a good idea for any program
generating tool to include some sort of special provision for the generated
code, such as the terms for the skeleton parser in bison. I didn't see
anything like that in the SWIG info though.
Would FSF be happy if gdb suddenly becomes dependent on a tool
that's not owned by them?
Well, the "FSF" for this issue only consists of RMS, and everybody on
this mailing list. My own inclination is to be very careful about
adding dependencies of any sort, irrespective of tool ownership,
because that's just good engineering.
To take an example from GCC, the perfect hash table that GCC uses to
look up keywords is generated by a program called gperf. Gperf is in
C++ (or was anyway), and back in 1989, that meant g++ 1.x. I was
working on the Mac port of GCC, and the Mac API included several new
keywords, which meant tweaking GCC's hash table. The hardest part of
this task was getting g++ to build a working gperf! Fortunately, I
only had to do this the one time; it would have been a big timesink
if I'd had to do that much fiddling every time GCC got changed.
So to get back to SWIG, if its output became intertwined with GDB, we
would have to start shipping SWIG with every release and snapshot of
GDB, we would probably want to have it running on all of GDB's hosts,
work it into build processes (though perhaps for maintainers only), etc.
However, it's not clear to me that it has to be so interconnected;
I can see where GDB would be SWIG-friendly without having it be in the
critical path. That seems to me like better engineering for this kind
of extension.
Stan
next prev parent reply other threads:[~1999-04-01 0:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-04-01 0:00 Thompson, James C
1999-04-01 0:00 ` Ovidiu Predescu
1999-04-01 0:00 ` Stan Shebs [this message]
1999-04-01 0:00 ` Todd Whitesel
1999-04-01 0:00 J.T. Conklin
1999-04-01 0:00 ` Stan Shebs
1999-04-01 0:00 ` J.T. Conklin
1999-04-01 0:00 ` Stan Shebs
1999-04-01 0:00 Thompson, James C
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199903212138.NAA05643@andros.cygnus.com \
--to=shebs@cygnus.com \
--cc=James.C.Thompson@USAHQ.UnitedSpaceAlliance.com \
--cc=gdb@cygnus.com \
--cc=ovidiu@cup.hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox