This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [5.2.1] quiet warnings for gdbreplay.c

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.
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.

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 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.
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.

In the mean time, I guess the status quo remains.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]