gdb.h, libgdb.h, gdblib.h, gdb-lib.h, ...?

[Andrew Cagney]

Stan Shebs wrote:
> 
>    Date: Mon, 13 Dec 1999 11:35:31 +1100
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    So, ok I've been ignoring this one.
> 
>    We're going to try to create a library.  Some bits, like ``struct
>    gdb_file'' can easily live in ``gdb-file.h'' where they can be (fairly
>    safely) included by non-core GDB code.
> 
>    But what of the main GDB functions? Eg:
> 
>            XXX {lib,}gdb{,lib}_breakpoint_query (..., b, ...);
> 
>    For the moment, based on a detailed probabilistic analysis (coin toss)
>    I'll assume ``gdb.h''.  If anyone can think of a compelling case for
>    some other name, please speak now :-)
> 
> I'd vote for libgdb.h, since a) it's the term we've been using for the
> past seven years, and b) it's useful to emphasize that this is a
> library interface, not something that is purely internal to GDB.  For
> instance, if you look at X11, X clients normally include Xlib.h.
> Xlib.h then includes X.h, which is the lower-level stuff that's (at
> least partly) common to both clients and servers.
> 
> I'd also like us just to have a single .h file that includes
> everything that a libgdb client would need.  It's going to be very
> hard for someone to use just part of libgdb, because of all the
> internal interconnections.  If GDB ever gets decoupled internally,
> and anybody cares, they can split libgdb.h too - until then we'd
> just be deceiving ourselves.

While initially there will be only one file ``libgdb.h'' I think we
still need to make it our clear objective that the interface presented
be clearly decoupled from the internals and, consequently modularized. 
Even if the internal spaghetti is never eliminated that tangle should
not be reflected in the interface :-).

BTW, off the top of my head, I can already see the separate components:

	libgdb.h:
		basic types for gdb including *$(*@ CORE_ADDR
		bit like defs.h was like before it lost the plot :-)
	libgdb-varobj.h:
		A cleanup/rewrite of GDBtk's variable object code.
		Only code wanting to manage variable objects would
		need to pull that in.
	libgdb-eventloop.h:
		GDB's event-loop requirements/interface.  Only the
		clients ``xxx-top.c'' would need to worry about
		that.

Any way, next question.  In a futile attempt to avoid name space
pollution, are all external names prefixed with ``gdb_'' or ``libgdb_''?

	Andrew