public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com,
	Ben Elliston <bje@cygnus.com>
Subject: Re: Proposal: --with-gdb-interpreter=...  --interpreter=...
Date: Thu, 19 Aug 1999 03:29:00 -0000	[thread overview]
Message-ID: <37BBDC67.64557E0F@cygnus.com> (raw)
In-Reply-To: <199908190052.RAA27597@andros.cygnus.com>

[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 <ac131313@cygnus.com>
> 
>    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

  reply	other threads:[~1999-08-19  3:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-08-18 17:39 Andrew Cagney
1999-08-18 17:53 ` Stan Shebs
1999-08-19  3:29   ` Andrew Cagney [this message]
1999-08-19 19:30 ` Jim Blandy
1999-08-20 18:35   ` Andrew Cagney
1999-08-19 23:07 ` ovidiu
1999-08-20 10:22   ` ovidiu
1999-08-20 18:20     ` Andrew Cagney

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=37BBDC67.64557E0F@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=bje@cygnus.com \
    --cc=gdb@sourceware.cygnus.com \
    --cc=insight@sourceware.cygnus.com \
    --cc=shebs@cygnus.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).