This is the mail archive of the
mailing list for the GDB project.
Re: [5.2.1] quiet warnings for gdbreplay.c
- From: Andrew Cagney <ac131313 at ges dot redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: obrien at FreeBSD dot org, gdb-patches at sources dot redhat dot com
- Date: Tue, 09 Jul 2002 17:13:54 -0400
- Subject: Re: [5.2.1] quiet warnings for gdbreplay.c
- References: <20020627204720.A13445@dragon.nuxi.com> <3D1C8AEF.email@example.com> <20020628180820.GA9115@nevyn.them.org> <3D1CD337.firstname.lastname@example.org> <20020628213904.GA15095@nevyn.them.org>
Ah, ok, I see your problem. Yes that does make things easier.
GDBserver on its own is far more likely to configure/build and is easier
to drag around.
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
Suggest a comment (I've no idea where) explaining this (or even mention
it in GDB's doco - something like stating that gdbserver can be
built/configured separate to GDB).
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!
True, but they are part of the same ``system''.
I think it would be easier to just clarify the guidelines for
``gdb_XXXX.h'' files - that they be independant as they are included by
GDB and friends.
>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
In the mean time, I guess the status quo remains.