From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Stan Shebs Cc: gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com, Ben Elliston Subject: Re: Proposal: --with-gdb-interpreter=... --interpreter=... Date: Thu, 19 Aug 1999 03:29:00 -0000 Message-id: <37BBDC67.64557E0F@cygnus.com> References: <199908190052.RAA27597@andros.cygnus.com> X-SW-Source: 1999-q3/msg00078.html [Ben, as the autoconf maintainer you might have an idea] Stan Shebs wrote: > > Date: Thu, 19 Aug 1999 10:38:33 +1000 > From: Andrew Cagney > > We're now starting to see the situtation where GDB can support multiple > interpreters. At present there is GDB's traditional CLI, the TUI (from > HP) and TCL/TK. We've had many threads of Python, Perl, Java, Visual > Basic and evey guile interpreters comming in down the track. > > What I'd like to do is set in motion change that should greatly > simplify the integration of various interpreters. Accordingly I'd like > to propose the following changes: > > Of course I think this is a great idea! It occurs to me that the > situation is very similar to that in GCC, where the language-specific > frontends live in subdirs. It's not identical, because each frontend > results in a distinct executable (cc1plus, etc), while for GDB we'd > rather end up with a single debugger, but the configury and makefile > fragment ideas could be useful to learn from. Progress? It works provided the interpreter being added doesn't depend on any complex configure actions. The TUI fits in well with this model - no TUI stuff in gdb/Makefile.in has to be a good thing :-) Insight on the other hand is looking more difficult. It needs to link in a random set of extra libraries (X11, tk, tcl, ...) and relies on configure to find them. I can see two possible ways of handling this: o gdb/configure.in include checks those libraries o gdb/insight/configure.in treated as a separate independant sub-directory and be configured/built accordingly. comments, suggestions? Andrew