Re: libgdb (was none)

[Stan Shebs <shebs@cygnus.com>]

   From: Robert Hoehne <robert.hoehne@gmx.net>
   Date: Mon, 8 Mar 1999 23:34:05 +0100

   I did that already since years in RHIDE and it worked perfectly.

   Now I have reviewed the latest gdb sources and saw that the
   problem really exists and I'm not happy about this change.

But how is anybody supposed to know what can be changed and what not?
This is a perfect example of why things have to be at least documented.
I had no idea that RHIDE did anything tricky with GDB main files, nor
I imagine did HP or anybody else, so we'll assume that things can be
rearranged or restructured as necessary.

   > is that we don't want to get into maintaining GDB with this kind of
   > application in mind.  If we turn GDB into a library, we should do it
   > right --- design an interface that makes sense, document the
   > interface, make sure that future changes preserve the boundaries, etc.
   > My guess is that that would be more work than we really want to take
   > on.

   So my question is now: Why does exist there a file called libgdb.texi
   in the doc directory?

I just left it there because I thought it would be useful guidance for
anyone wanting to undertake the project, because it *is* a worthwhile
project.  However, it seems to have been more misleading than helpful,
so now I'm thinking it should just be whacked out.  (Questions about
libgdb come up about twice/year, but nobody does anything to make it
work.)

   I know now, that this file describes only an
   imaginary library which does not exist, but if there exists such a
   description of a libgdb the maintainer of gdb should think also a little
   bit about that people, who did the hard job to integrate the gdb functionality
   also in other programs even when it is not the described libgdb but a
   lib with the same goal.

Propose a structure and the changes to go with it, and I will tell you
if it seems reasonable or not.  If it is reasonable, then we can look
at documenting it so future GDB hackers will know what the rules are,
and make any needed changes to support it.

   BTW: There is not only an describtion of the imaginary libgdb, but there
   is also a target in the Makefile which is called libgdb-files, which creates
   a file containing all the names of the object files for the libgdb. So if, main.o
   is not part of it, but main.o conatains code which is refered by other
   files, than this is a bug.

I thought all the libgdb crud in the makefile was gone, thanks for
pointing it out.  I'll delete it if nobody comes up with a good reason
for saving it - incomplete and/or broken code in the source never seems
to do anything except cause confusion and thus waste people's time, so
it's better just to make it go away.

							Stan