[PATCH] Fix compilation of tui/tui.c

[PATCH] Fix compilation of tui/tui.c

[Mark Kettenis]

Ouch.  We have serious portability problems with the TUI.  We should
either disable it again before the 6.1 release, or be prepared to
release 6.1.1 if any build problems come up.  I'm sure we'll see build
problems on many systems that we don't regularly test.

Anyway, I committed the attached such that FreeBSD (and probably the
other BSD's work again/.

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* tui/tui.c: Include <readline/readline.h> instead of
	"readline/readline.h".  Include it after <term.h> and
	"gdb_curses.h".

Index: tui/tui.c
===================================================================
RCS file: /cvs/src/src/gdb/tui/tui.c,v
retrieving revision 1.48
diff -u -p -r1.48 tui.c
--- tui/tui.c 26 Feb 2004 02:08:04 -0000 1.48
+++ tui/tui.c 28 Feb 2004 14:59:29 -0000
@@ -34,7 +34,6 @@
 #include "tui/tui-win.h"
 #include "tui/tui-winsource.h"
 #include "tui/tui-windata.h"
-#include "readline/readline.h"
 #include "target.h"
 #include "frame.h"
 #include "breakpoint.h"
@@ -56,6 +55,11 @@
 #include <setjmp.h>
 
 #include "gdb_curses.h"
+
+/* This redefines CTRL if it is not already defined, so it must come
+   after terminal state releated include files like <term.h> and
+   "gdb_ncurses.h".  */
+#include <readline/readline.h>
 
 /* Tells whether the TUI is active or not.  */
 int tui_active = 0;

Re: [PATCH] Fix compilation of tui/tui.c

[Andrew Cagney]

> Ouch.  We have serious portability problems with the TUI.  We should
> either disable it again before the 6.1 release, or be prepared to
> release 6.1.1 if any build problems come up.  I'm sure we'll see build
> problems on many systems that we don't regularly test.
> 
> Anyway, I committed the attached such that FreeBSD (and probably the
> other BSD's work again/.

It works on my bsd system (how do you think I was testing it)?  What 
portability problem.  Is there a reason for changing "" to <>, it breaks 
some of GDB's scripts.

Andrew

Re: [PATCH] Fix compilation of tui/tui.c

[Mark Kettenis]

   Date: Sat, 28 Feb 2004 10:20:55 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > Ouch.  We have serious portability problems with the TUI.  We should
   > either disable it again before the 6.1 release, or be prepared to
   > release 6.1.1 if any build problems come up.  I'm sure we'll see build
   > problems on many systems that we don't regularly test.
   > 
   > Anyway, I committed the attached such that FreeBSD (and probably the
   > other BSD's work again/.

   It works on my bsd system (how do you think I was testing it)?

I didn't check on OpenBSD or NetBSD, but I supposed they would suffer
from the same problems as my FreeBSD-system.

   What portability problem.

The TUI code is including header files and using library functions
that we've never used before in GDB.  We've already seen the fall-out
from this on HP-UX and Solaris, and now on FreeBSD.  I'm just afraid
that more of these problems will surface when somebody tries to build
GDB other platforms.

   Is there a reason for changing "" to <>, it breaks some of GDB's
   scripts.

I changed because we seem to use <> everywhere else in GDB for the
readline includes, e.g. event-top.c, completer.c.  I think it's good
to be consistent; you get less surprises that way.

Mark

Re: [PATCH] Fix compilation of tui/tui.c

[Andrew Cagney]

>    What portability problem.
> 
> The TUI code is including header files and using library functions
> that we've never used before in GDB.  We've already seen the fall-out
> from this on HP-UX and Solaris, and now on FreeBSD.  I'm just afraid
> that more of these problems will surface when somebody tries to build
> GDB other platforms.

There aren't that many other systems left!   As with off64_t, while 
certainly a step into the unknown, we've done our homework - notice, 
paced patches, and testing it on a varity of systems.  The only real way 
to flush out the remaining problems is to push it through to a release.

>    Is there a reason for changing "" to <>, it breaks some of GDB's
>    scripts.
> 
> I changed because we seem to use <> everywhere else in GDB for the
> readline includes, e.g. event-top.c, completer.c.  I think it's good
> to be consistent; you get less surprises that way.

I'll change them so that they are consistent. gdb_makefile.sh:
http://sources.redhat.com/gdb/current/ari/gdb_makefile.sh
knows about "..." includes.

Andrew

Re: [PATCH] Fix compilation of tui/tui.c

[Eli Zaretskii]

> Date: Sat, 28 Feb 2004 11:21:45 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> >    Is there a reason for changing "" to <>, it breaks some of GDB's
> >    scripts.
> > 
> > I changed because we seem to use <> everywhere else in GDB for the
> > readline includes, e.g. event-top.c, completer.c.  I think it's good
> > to be consistent; you get less surprises that way.
> 
> I'll change them so that they are consistent. gdb_makefile.sh:
> http://sources.redhat.com/gdb/current/ari/gdb_makefile.sh
> knows about "..." includes.

Andrew, how about saying this somewhere in the coding standards
description?  I, for one, was unaware of the special importance of
"...", and I presume Mark didn't know that as well.

Re: [PATCH] Fix compilation of tui/tui.c

[Andrew Cagney]

>>Date: Sat, 28 Feb 2004 11:21:45 -0500
>>> From: Andrew Cagney <cagney@gnu.org>
>>> 
>>
>>>> >    Is there a reason for changing "" to <>, it breaks some of GDB's
>>>> >    scripts.
>>>> > 
>>>> > I changed because we seem to use <> everywhere else in GDB for the
>>>> > readline includes, e.g. event-top.c, completer.c.  I think it's good
>>>> > to be consistent; you get less surprises that way.
>>
>>> 
>>> I'll change them so that they are consistent. gdb_makefile.sh:
>>> http://sources.redhat.com/gdb/current/ari/gdb_makefile.sh
>>> knows about "..." includes.
> 
> 
> Andrew, how about saying this somewhere in the coding standards
> description?  I, for one, was unaware of the special importance of
> "...", and I presume Mark didn't know that as well.

Once there's a branch I intend going two (?) better, change the build 
process so that we don't need to worry about dependencies any more (but 
yes that will involve documentation).

Andrew