This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: problem with chained if statements?


   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