Re: [5.2.1] quiet warnings for gdbreplay.c

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Jun 28, 2002 at 05:20:55PM -0400, Andrew Cagney wrote:
> >On Fri, Jun 28, 2002 at 12:12:31PM -0400, Andrew Cagney wrote:
> >
> >>>+#ifdef HAVE_STRING_H
> >>>+#include <string.h>
> >>>+#endif
> >
> >>
> >>Should that bit be "gdb_string.h"?
> >
> >
> >That depends :)  gdbreplay is not part of GDB and has a different
> >config.h header (tests for a different set of macros).
> 
> (We could always fix that - eliminate that configure file :-^ )

I dunno, I appreciate being able to run configure in the gdbserver/
directory.  It means you don't need to a terminal library for your
target if you just want gdbserver.  A lot of people have seemed to
appreciate this.

> More seriously, I think someone hacking on gdbreplay is likely to also 
> be hacking on GDB.  Consequently, they are going to expect the two 
> directories to follow the same coding conventions.

We discussed this.  The two directories share no code except for
signals/signals.c off in its own space.  If they share headers, some
care is called for.  They are not part of the same program!

>   I had
> >eliminated all references to the gdb source code but then I introduced
> >an include of "gdb_proc_service.h", since the alternative was just
> >duplicating it; I have the feeling we should move that and headers like
> >gdb_string.h somewhere common - are they include/gdb/ candidates?
> 
> You mean #include "gdb/gdb_string.h"?  I think include/gdb/ is for 
> external interfaces that are at some level controlled by GDB.

Then do we want a separate gdb/gdbint/ directory for this?  I strongly
prefer that headers shared between GDB and other directories be clearly
marked and separated.  That'd give me a place to move
gdb_proc_service.h, too.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer