Horton
Menu

Thread

  1. configure.in patch for readline and curses.

    Jason Schroeder <shrode@astanetworks.com> — 2001-01-26T22:38:32Z

    hi,

The following configure.in patch changes the following:
1) It adds --without-readline to control whether the readling package is
used
   Obviously, this could be extended to the general
--with[out]-readline[=DIR] pattern, but this is as far as I got.
2) It permits the termcap library to be used IFF ncurses and curses are not
available.

(Some indenting has not be performed to save maintainer stress.)
The following patch is against cvs tag: REL7_1_BETA3.

*** orig/configure.in	2001/01/10 09:05:42
--- new/configure.in	2001/01/26 22:28:26
***************
*** 354,359 ****
--- 354,365 ----
  done
  IFS=$ac_save_IFS
  
+ #
+ # Readline
+ #
+ AC_MSG_CHECKING([whether to build with readline])
+ PGAC_ARG_BOOL(with, readline, yes, [  --without-readline      do not use
readline])
+ AC_MSG_RESULT([$with_readline])
  
  #
  # Tcl/Tk
***************
*** 654,664 ****
  ##
  
  AC_CHECK_LIB(sfio,     main)
! AC_CHECK_LIB(ncurses,  main, [], [AC_CHECK_LIB(curses, main)])
! AC_CHECK_LIB(termcap,  main)
! AC_SEARCH_LIBS(readline, [readline edit], [AC_DEFINE(HAVE_LIBREADLINE)])
! AC_SEARCH_LIBS(using_history, history,
[AC_DEFINE(HAVE_HISTORY_FUNCTIONS)])
  
  if test "$PORTNAME" != "aix" -a "$PORTNAME" != "alpha"
  then
  	AC_CHECK_LIB(bsd,      main)
--- 660,672 ----
  ##
  
  AC_CHECK_LIB(sfio,     main)
! AC_CHECK_LIB(ncurses,  main, [], [AC_CHECK_LIB(curses, main, [],
[AC_CHECK_LIB(termcap,  main)])])
  
+ if test "$with_readline" = yes; then
+   AC_SEARCH_LIBS(readline, [readline edit], [AC_DEFINE(HAVE_LIBREADLINE)])
+   AC_SEARCH_LIBS(using_history, history,
[AC_DEFINE(HAVE_HISTORY_FUNCTIONS)])
+ fi
+ 
  if test "$PORTNAME" != "aix" -a "$PORTNAME" != "alpha"
  then
  	AC_CHECK_LIB(bsd,      main)
***************
*** 724,731 ****
  
  PGAC_HEADER_STRING
  
! AC_CHECK_HEADERS([readline/readline.h readline.h], [break])
! AC_CHECK_HEADERS([readline/history.h history.h], [break])
  
  if test "$with_krb4" = yes ; then
    AC_CHECK_HEADER(krb.h, [], [AC_MSG_ERROR([header file <krb.h> is
required for Kerberos 4])])
--- 732,741 ----
  
  PGAC_HEADER_STRING
  
! if test "$with_readline" = yes; then
!   AC_CHECK_HEADERS([readline/readline.h readline.h], [break])
!   AC_CHECK_HEADERS([readline/history.h history.h], [break])
! fi
  
  if test "$with_krb4" = yes ; then
    AC_CHECK_HEADER(krb.h, [], [AC_MSG_ERROR([header file <krb.h> is
required for Kerberos 4])])
***************
*** 878,883 ****
--- 888,894 ----
  	      AC_CHECK_LIB(m, rint, AC_DEFINE(HAVE_RINT), , $HPUXMATHLIB))
  
  
+ if test "$with_readline" = yes; then
  # Readline versions < 2.1 don't have rl_completion_append_character
  AC_MSG_CHECKING([for rl_completion_append_character])
  AC_TRY_LINK([#include <stdio.h>
***************
*** 891,902 ****
  [AC_MSG_RESULT(yes)
  AC_DEFINE(HAVE_RL_COMPLETION_APPEND_CHARACTER)],
  [AC_MSG_RESULT(no)])
! 
  
  # Check whether readline's filename_completion_function is declared.
  # Some prehistoric versions of readline, in particular those shipped
  # with earlier Cygwins don't have this declared, although it's in the
  # library.
  AC_MSG_CHECKING([whether filename_completion_function is declared])
  if test "$ac_cv_header_readline_h" = yes; then
      _readline_header='readline.h'
--- 902,914 ----
  [AC_MSG_RESULT(yes)
  AC_DEFINE(HAVE_RL_COMPLETION_APPEND_CHARACTER)],
  [AC_MSG_RESULT(no)])
! fi
  
  # Check whether readline's filename_completion_function is declared.
  # Some prehistoric versions of readline, in particular those shipped
  # with earlier Cygwins don't have this declared, although it's in the
  # library.
+ if test "$with_readline" = yes; then
  AC_MSG_CHECKING([whether filename_completion_function is declared])
  if test "$ac_cv_header_readline_h" = yes; then
      _readline_header='readline.h'
***************
*** 909,915 ****
  [AC_DEFINE(HAVE_FILENAME_COMPLETION_FUNCTION_DECL)
  AC_MSG_RESULT(yes)],
  [AC_MSG_RESULT(no)])
! 
  
  
  dnl Cannot use AC_CHECK_FUNC because finite may be a macro
--- 921,927 ----
  [AC_DEFINE(HAVE_FILENAME_COMPLETION_FUNCTION_DECL)
  AC_MSG_RESULT(yes)],
  [AC_MSG_RESULT(no)])
! fi
  
  
  dnl Cannot use AC_CHECK_FUNC because finite may be a macr
jason

  2. Re: configure.in patch for readline and curses.

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-27T01:14:58Z

    Jason Schroeder <shrode@astanetworks.com> writes:
> The following configure.in patch changes the following:
> 1) It adds --without-readline to control whether the readling package is
> used

Just out of curiosity, why would you want such a thing?

			regards, tom lane

  3. Re: configure.in patch for readline and curses.

    Peter Eisentraut <peter_e@gmx.net> — 2001-01-27T09:12:54Z

    Jason Schroeder writes:

> The following configure.in patch changes the following:
> 1) It adds --without-readline to control whether the readling package is
> used
>    Obviously, this could be extended to the general
> --with[out]-readline[=DIR] pattern, but this is as far as I got.

Why would one not use readline?

> 2) It permits the termcap library to be used IFF ncurses and curses are not
> available.

I don't think older versions of readline can be linked against curses.  If
at all, termcap should be tried before curses, but that might not be
portable either.  You'd need to try a complete link of a readline-using
program, I think.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

  4. Re: configure.in patch for readline and curses.

    Rick Robino <rrobino@wavedivision.com> — 2001-02-04T04:44:47Z

    Tom Lane wrote:

> Jason Schroeder <shrode@astanetworks.com> writes:
> > The following configure.in patch changes the following:
> > 1) It adds --without-readline to control whether the readling package is
> > used
>
> Just out of curiosity, why would you want such a thing?
>

I can suggest one reason:

psql starts up with readline support turned on by default. If readline/curses
is broken, this may show up at runtime as a pq_recvbuf error and a core dump.
psql isn't obvious about the relationship to readline, creating a mystery for
first-timers.

Since it is readline, and it is on by default, just maybe that first-timer
might reconfigure turning "luxuries" off and psql will work. The alternative
is them finding that obscure scrap of advice (not in doc/*) associating
recvbuf errors with readline support.

I had this problem on a very typically setup Solaris but did not look for a
way to build w/o readline. I really wanted it so I kept at it, but one *can*
live without command-history, being content to have psql fire up without
errors (surviving nicely with \e). IIRC, my problem was ncurses existing and
being compiled with or without termcap. Can't remember the details, but it
wasn't psql, or even readline all by itself.

Suggestion: if this problem is common (anyone know?), it would be nice for
psql to trap the error and mention the "-n" option. I suspect that Solaris ppl
who install a pre-built ncurses might run into this alot.

Cheers,

--Rick

  5. Re: [PATCHES] configure.in patch for readline and curses.

    Peter Eisentraut <peter_e@gmx.net> — 2001-02-06T18:30:53Z

    Rick Robino writes:

> psql starts up with readline support turned on by default. If readline/curses
> is broken, this may show up at runtime as a pq_recvbuf error and a core dump.
> psql isn't obvious about the relationship to readline, creating a mystery for
> first-timers.
>
> Since it is readline, and it is on by default, just maybe that first-timer
> might reconfigure turning "luxuries" off and psql will work.

That looks like a rather unusual way to proceed.

> The alternative is them finding that obscure scrap of advice (not in
> doc/*) associating recvbuf errors with readline support.

The other alternative is fixing the underlying problem.

> I had this problem on a very typically setup Solaris but did not look for a
> way to build w/o readline.

Yes, we have had several reports that termcap and ncurses don't like each
other on Solaris.  I'm going to alter configure to check for only one of
the two.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/