* Termcap saga again @ 2001-05-08 9:36 Peter Stephenson 2001-05-08 13:34 ` Clint Adams 2001-05-08 14:35 ` Bart Schaefer 0 siblings, 2 replies; 14+ messages in thread From: Peter Stephenson @ 2001-05-08 9:36 UTC (permalink / raw) To: Zsh hackers list SunOS 5.8 is giving me ../../../Src/Modules/termcap.c: In function `scantermcap': ../../../Src/Modules/termcap.c:327: `boolcodes' undeclared (first use in this function) ../../../Src/Modules/termcap.c:327: (Each undeclared identifier is reported only once ../../../Src/Modules/termcap.c:327: for each function it appears in.) ../../../Src/Modules/termcap.c:336: `numcodes' undeclared (first use in this function) ../../../Src/Modules/termcap.c:345: `strcodes' undeclared (first use in this function) It seems HAVE_CURSES_H isn't getting defined --- it's generating warnings about redefined macros, is this enough to stop configure recognising it? There's no error message: /usr/include/widec.h:38: warning: `getwc' redefined /usr/include/iso/wchar_iso.h:337: warning: this is the location of the previous definition /usr/include/widec.h:39: warning: `putwc' redefined /usr/include/iso/wchar_iso.h:340: warning: this is the location of the previous definition /usr/include/widec.h:40: warning: `getwchar' redefined /usr/include/iso/wchar_iso.h:338: warning: this is the location of the previous definition /usr/include/widec.h:41: warning: `putwchar' redefined /usr/include/iso/wchar_iso.h:341: warning: this is the location of the previous definition However, TERM_H_NEEDS_CURSES_H is getting defined. This should be enough to allow us to set HAVE_CURSES_H. I tried doing that in termcap.h and terminfo.h and it's compiling (haven't dared try it) but I'm now getting ../../../Src/Modules/termcap.c: In function `bin_echotc': ../../../Src/Modules/termcap.c:136: warning: passing arg 3 of `tputs' from incompatible pointer type ../../../Src/Modules/termcap.c:139: warning: passing arg 1 of `tputs' makes pointer from integer without a cast ../../../Src/Modules/termcap.c:139: warning: passing arg 3 of `tputs' from incompatible pointer type which I find a bit alarming. However, the arg 3 messages are because I have `int (*)(char)' as that argument's type whereas we're using `int (*)(int)', while the arg 1 message appears because tgoto is only defined if __STDC__ isn't. So this doesn't seem really to be our fault Doesn't make we wildly enthusiastic about terminal handling systems in general, frankly. The inet_* stuff is a bit weird, here, too, but it's still compiling. I haven't got time to look at this in any detail at the moment. -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Termcap saga again 2001-05-08 9:36 Termcap saga again Peter Stephenson @ 2001-05-08 13:34 ` Clint Adams 2001-05-08 14:35 ` Bart Schaefer 1 sibling, 0 replies; 14+ messages in thread From: Clint Adams @ 2001-05-08 13:34 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh hackers list > SunOS 5.8 is giving me > > ../../../Src/Modules/termcap.c: In function `scantermcap': > ../../../Src/Modules/termcap.c:327: `boolcodes' undeclared (first use in this function) > ../../../Src/Modules/termcap.c:327: (Each undeclared identifier is reported only once > ../../../Src/Modules/termcap.c:327: for each function it appears in.) > ../../../Src/Modules/termcap.c:336: `numcodes' undeclared (first use in this function) > ../../../Src/Modules/termcap.c:345: `strcodes' undeclared (first use in this function) I don't get that from Forte C; these are the only warnings I get. "parse.c", line 1911: warning: end-of-loop code not reached "parse.c", line 1973: warning: end-of-loop code not reached "parse.c", line 1983: warning: end-of-loop code not reached "/usr/include/iso/stddef_iso.h", line 73: warning: macro redefined: offsetof "termcap.c", line 132: warning: argument #3 is incompatible with prototype: prototype: pointer to function(char) returning int : "/usr/include/term.h", line 1205 argument : pointer to function(int) returning int "termcap.c", line 135: warning: improper pointer/integer combination: arg #1 "termcap.c", line 135: warning: argument #3 is incompatible with prototype: prototype: pointer to function(char) returning int : "/usr/include/term.h", line 1205 argument : pointer to function(int) returning int "terminfo.c", line 96: warning: argument #3 is incompatible with prototype: prototype: pointer to function(char) returning int : "/usr/include/term.h", line 1205 argument : pointer to function(int) returning int HAVE_CURSES_H is being defined. On the other hand, I get what you get with gcc 2.95.2. > which I find a bit alarming. However, the arg 3 messages are because I > have `int (*)(char)' as that argument's type whereas we're using `int > (*)(int)', while the arg 1 message appears because tgoto is only defined if > __STDC__ isn't. So this doesn't seem really to be our fault We could test for this and provide char (*)(int) and int (*)(char) versions of putraw/putshout, but it hardly seems worth it. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Termcap saga again 2001-05-08 9:36 Termcap saga again Peter Stephenson 2001-05-08 13:34 ` Clint Adams @ 2001-05-08 14:35 ` Bart Schaefer 2001-05-08 14:56 ` Peter Stephenson 1 sibling, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2001-05-08 14:35 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list On May 8, 10:36am, Peter Stephenson wrote: } Subject: Termcap saga again } } It seems HAVE_CURSES_H isn't getting defined --- it's generating warnings } about redefined macros, is this enough to stop configure recognising it? Is it HAVE_CURSES_H that's not defined, or is it TERM_H_NEEDS_CURSES_H ? It's that dang GCC overoptimization again, I'll wager. Index: configure.in =================================================================== RCS file: /extra/cvsroot/zsh/zsh-4.0/configure.in,v retrieving revision 1.7 diff -c -r1.7 configure.in --- configure.in 2001/05/02 16:59:00 1.7 +++ configure.in 2001/05/08 14:33:52 @@ -566,11 +566,11 @@ if test x$ac_cv_header_term_h = xyes; then AC_MSG_CHECKING(if term.h needs curses.h) -AC_TRY_COMPILE([#include <term.h>], [char **test = boolcodes;], boolcodes_with_only_term_h=yes, -boolcodes_with_only_term_h=no) +AC_TRY_COMPILE([#include <term.h>], [char **test = boolcodes; printf(*test);], +boolcodes_with_only_term_h=yes, boolcodes_with_only_term_h=no) AC_TRY_COMPILE([#include <curses.h> -#include <term.h>], [char **test = boolcodes;], boolcodes_with_curses_h_and_term_h=yes, -boolcodes_with_curses_h_and_term_h=no) +#include <term.h>], [char **test = boolcodes; printf(*test);], +boolcodes_with_curses_h_and_term_h=yes, boolcodes_with_curses_h_and_term_h=no) if test "x$boolcodes_with_curses_h_and_term_h" = xyes && test "x$boolcodes_with_only_term_h" = xno; then AC_DEFINE(TERM_H_NEEDS_CURSES_H) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Termcap saga again 2001-05-08 14:35 ` Bart Schaefer @ 2001-05-08 14:56 ` Peter Stephenson 2001-05-08 15:14 ` Bart Schaefer 0 siblings, 1 reply; 14+ messages in thread From: Peter Stephenson @ 2001-05-08 14:56 UTC (permalink / raw) To: Zsh hackers list > On May 8, 10:36am, Peter Stephenson wrote: > } Subject: Termcap saga again > } > } It seems HAVE_CURSES_H isn't getting defined --- it's generating warnings > } about redefined macros, is this enough to stop configure recognising it? > > Is it HAVE_CURSES_H that's not defined, or is it TERM_H_NEEDS_CURSES_H ? Definitely the former, so the patch doesn't help. Here's the config.log section in full. Looks like some standards organisation has been along and redefined anything... it doesn't work any more, but no doubt it passes some quality control test instead. widec.h is including wchar.h, which is including iso/wchar_iso.h, so this seems to be intrinsic to SunOS 5.8 (again). Maybe we should upgrade to 5.7. Is there some other way of doing the test that will simply see if it compiled? I should know but I can't remember. configure:3207: checking for curses.h configure:3217: gcc -E -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 conftest.c >/dev/null 2>conftest.out In file included from /usr/include/curses.h:23, from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include/curses.h:5, from configure:3213: /usr/include/widec.h:38: warning: `getwc' redefined /usr/include/iso/wchar_iso.h:337: warning: this is the location of the previous definition /usr/include/widec.h:39: warning: `putwc' redefined /usr/include/iso/wchar_iso.h:340: warning: this is the location of the previous definition /usr/include/widec.h:40: warning: `getwchar' redefined /usr/include/iso/wchar_iso.h:338: warning: this is the location of the previous definition /usr/include/widec.h:41: warning: `putwchar' redefined /usr/include/iso/wchar_iso.h:341: warning: this is the location of the previous definition configure: failed program was: #line 3212 "configure" #include "confdefs.h" #include <curses.h> -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Termcap saga again 2001-05-08 14:56 ` Peter Stephenson @ 2001-05-08 15:14 ` Bart Schaefer 2001-05-08 16:23 ` Peter Stephenson 0 siblings, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2001-05-08 15:14 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list On May 8, 3:56pm, Peter Stephenson wrote: } Subject: Re: Termcap saga again } } Is there some other way of doing the test that will simply see if it } compiled? I should know but I can't remember. Yeah, change it from AC_TRY_COMPILE to AC_TRY_LINK, though it's pretty stupid that AC_TRY_COMPILE fails on harmless warnings. So apply my patch (which is necessary to get AC_TRY_LINK to work right) and also change the _COMPILE to _LINK (which I should have noticed in the first place) and try again. If it works, either you can commit it, or let me know and I will. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Termcap saga again 2001-05-08 15:14 ` Bart Schaefer @ 2001-05-08 16:23 ` Peter Stephenson 2001-05-08 18:01 ` Andrej Borsenkow 2001-05-08 18:07 ` Bart Schaefer 0 siblings, 2 replies; 14+ messages in thread From: Peter Stephenson @ 2001-05-08 16:23 UTC (permalink / raw) To: Zsh hackers list > On May 8, 3:56pm, Peter Stephenson wrote: > } Subject: Re: Termcap saga again > } > } Is there some other way of doing the test that will simply see if it > } compiled? I should know but I can't remember. > > Yeah, change it from AC_TRY_COMPILE to AC_TRY_LINK, though it's pretty > stupid that AC_TRY_COMPILE fails on harmless warnings. > > So apply my patch (which is necessary to get AC_TRY_LINK to work right) > and also change the _COMPILE to _LINK (which I should have noticed in the > first place) and try again. If it works, either you can commit it, or > let me know and I will. Actually, AC_TRY_COMPILE is OK, it was only AC_CHECK_HEADERS that barfed on the warnings. This means rewriting bits of the AC_CHECK_HEADERS internals to get the right definitions. Here's the combined diff. Or do the COMPILEs here still need to be LINKs? I left term.h with AC_CHECK_HEADERS, because otherwise it fails if curses.h is needed to make it work, which is tested later. This gets worse and worse. I can't believe how long I've wasted on this, and lots of other people have wasted a good bit longer. Index: acconfig.h =================================================================== RCS file: /cvsroot/zsh/zsh/acconfig.h,v retrieving revision 1.9 diff -u -r1.9 acconfig.h --- acconfig.h 2001/04/26 15:48:14 1.9 +++ acconfig.h 2001/05/08 16:22:20 @@ -318,5 +318,8 @@ /* Define if you have the terminfo strnames symbol. */ #undef HAVE_STRNAMES +/* Define if we have curses.h */ +#undef HAVE_CURSES_H + /* Define if term.h chokes without curses.h */ #undef TERM_H_NEEDS_CURSES_H Index: configure.in =================================================================== RCS file: /cvsroot/zsh/zsh/configure.in,v retrieving revision 1.53 diff -u -r1.53 configure.in --- configure.in 2001/05/02 16:48:32 1.53 +++ configure.in 2001/05/08 16:22:32 @@ -562,15 +562,20 @@ AC_SEARCH_LIBS(tgetent, [$termcap_curses_order]) case "$LIBS" in *curses*) -AC_CHECK_HEADERS(curses.h term.h) +AC_CACHE_CHECK(for curses.h, ac_cv_header_curses_h, +AC_TRY_COMPILE([#include <curses.h>], [], +[ac_cv_header_curses_h=yes +AC_DEFINE(HAVE_CURSES_H)], +ac_cv_header_curses_h=no)) +AC_CHECK_HEADERS(term.h) if test x$ac_cv_header_term_h = xyes; then AC_MSG_CHECKING(if term.h needs curses.h) -AC_TRY_COMPILE([#include <term.h>], [char **test = boolcodes;], boolcodes_with_only_term_h=yes, -boolcodes_with_only_term_h=no) +AC_TRY_COMPILE([#include <term.h>], [char **test = boolcodes; printf(*test);], +boolcodes_with_only_term_h=yes, boolcodes_with_only_term_h=no) AC_TRY_COMPILE([#include <curses.h> -#include <term.h>], [char **test = boolcodes;], boolcodes_with_curses_h_and_term_h=yes, -boolcodes_with_curses_h_and_term_h=no) +#include <term.h>], [char **test = boolcodes; printf(*test);], +boolcodes_with_curses_h_and_term_h=yes, boolcodes_with_curses_h_and_term_h=no) if test "x$boolcodes_with_curses_h_and_term_h" = xyes && test "x$boolcodes_with_only_term_h" = xno; then AC_DEFINE(TERM_H_NEEDS_CURSES_H) -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Termcap saga again 2001-05-08 16:23 ` Peter Stephenson @ 2001-05-08 18:01 ` Andrej Borsenkow 2001-05-08 18:07 ` Bart Schaefer 1 sibling, 0 replies; 14+ messages in thread From: Andrej Borsenkow @ 2001-05-08 18:01 UTC (permalink / raw) To: Zsh hackers list On Tue, 8 May 2001, Peter Stephenson wrote: > > Actually, AC_TRY_COMPILE is OK, it was only AC_CHECK_HEADERS that barfed on > the warnings. This is known problem in autoconf and is supposed to be fixed in next release ... unfortunately, autoconf very much resembles zsh w.r.t. next release date ... -andrej ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Termcap saga again 2001-05-08 16:23 ` Peter Stephenson 2001-05-08 18:01 ` Andrej Borsenkow @ 2001-05-08 18:07 ` Bart Schaefer 2001-05-08 18:25 ` Peter Stephenson 1 sibling, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2001-05-08 18:07 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list On May 8, 5:23pm, Peter Stephenson wrote: } } Actually, AC_TRY_COMPILE is OK, it was only AC_CHECK_HEADERS that barfed on } the warnings. This means rewriting bits of the AC_CHECK_HEADERS internals } to get the right definitions. Here's the combined diff. Or do the } COMPILEs here still need to be LINKs? The `printf(*test)' is only necessary if they're changed to LINKs. (I had overlooked that before.) So if it's not AC_TRY_COMPILE that is causing the error, then you can drop my patch entirely. } This gets worse and worse. I can't believe how long I've wasted on this, } and lots of other people have wasted a good bit longer. Curses is a complete disaster and always has been. I could bore you all with stories about writing the "full screen character terminal" interface for Z-Mail (so-called "Lite"), but you've already got the flavor of them. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Termcap saga again 2001-05-08 18:07 ` Bart Schaefer @ 2001-05-08 18:25 ` Peter Stephenson 2001-05-09 5:03 ` Bart Schaefer 0 siblings, 1 reply; 14+ messages in thread From: Peter Stephenson @ 2001-05-08 18:25 UTC (permalink / raw) To: Zsh hackers list Bart wrote: > The `printf(*test)' is only necessary if they're changed to LINKs. (I had > overlooked that before.) So if it's not AC_TRY_COMPILE that is causing > the error, then you can drop my patch entirely. In that case I shall commit the following. Are we any nearer to being stable? I don't know whether I'll get round to that math fix in the next few days. Maybe I'll produce 4.0.1-pre-4 tomorrow anyway. Index: acconfig.h =================================================================== RCS file: /cvsroot/zsh/zsh/acconfig.h,v retrieving revision 1.9 diff -u -r1.9 acconfig.h --- acconfig.h 2001/04/26 15:48:14 1.9 +++ acconfig.h 2001/05/08 18:22:07 @@ -318,5 +318,8 @@ /* Define if you have the terminfo strnames symbol. */ #undef HAVE_STRNAMES +/* Define if we have curses.h */ +#undef HAVE_CURSES_H + /* Define if term.h chokes without curses.h */ #undef TERM_H_NEEDS_CURSES_H Index: configure.in =================================================================== RCS file: /cvsroot/zsh/zsh/configure.in,v retrieving revision 1.53 diff -u -r1.53 configure.in --- configure.in 2001/05/02 16:48:32 1.53 +++ configure.in 2001/05/08 18:22:13 @@ -562,7 +562,12 @@ AC_SEARCH_LIBS(tgetent, [$termcap_curses_order]) case "$LIBS" in *curses*) -AC_CHECK_HEADERS(curses.h term.h) +AC_CACHE_CHECK(for curses.h, ac_cv_header_curses_h, +AC_TRY_COMPILE([#include <curses.h>], [], +[ac_cv_header_curses_h=yes +AC_DEFINE(HAVE_CURSES_H)], +ac_cv_header_curses_h=no)) +AC_CHECK_HEADERS(term.h) if test x$ac_cv_header_term_h = xyes; then AC_MSG_CHECKING(if term.h needs curses.h) -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Termcap saga again 2001-05-08 18:25 ` Peter Stephenson @ 2001-05-09 5:03 ` Bart Schaefer 2001-05-09 5:19 ` Andrej Borsenkow ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Bart Schaefer @ 2001-05-09 5:03 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list On May 8, 7:25pm, Peter Stephenson wrote: } Subject: Re: Termcap saga again } } In that case I shall commit the following. Unfortunately, that has now broken my build on RedHat 5.2 and 6.2. It appears that AC_CACHE_CHECK does *nothing* when ac_cv_header_curses_h is already set, so the AC_DEFINE(HAVE_CURSES_H) never happens. In short, this patch works only if you configure from scratch without using a cache. I'll see if I can untangle it. } Are we any nearer to being stable? I should hope so, but this configure stuff is becoming silly. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Termcap saga again 2001-05-09 5:03 ` Bart Schaefer @ 2001-05-09 5:19 ` Andrej Borsenkow 2001-05-09 5:32 ` PATCH: " Andrej Borsenkow 2001-05-09 5:37 ` PATCH (the last?) " Bart Schaefer 2 siblings, 0 replies; 14+ messages in thread From: Andrej Borsenkow @ 2001-05-09 5:19 UTC (permalink / raw) To: Zsh hackers list On Wed, 9 May 2001, Bart Schaefer wrote: > On May 8, 7:25pm, Peter Stephenson wrote: > } Subject: Re: Termcap saga again > } > } In that case I shall commit the following. > > Unfortunately, that has now broken my build on RedHat 5.2 and 6.2. It > appears that AC_CACHE_CHECK does *nothing* when ac_cv_header_curses_h > is already set, so the AC_DEFINE(HAVE_CURSES_H) never happens. In > short, this patch works only if you configure from scratch without using > a cache. > Works as designed :-) You are expected to test the value of cache variable *after* AC_CACHE_CHECK if you need to take appropriate action. Anything inside AC_CACHE_CHECK shuld do just that - check and set value of cache variable. -andrej ^ permalink raw reply [flat|nested] 14+ messages in thread
* PATCH: Re: Termcap saga again 2001-05-09 5:03 ` Bart Schaefer 2001-05-09 5:19 ` Andrej Borsenkow @ 2001-05-09 5:32 ` Andrej Borsenkow 2001-05-09 5:42 ` Bart Schaefer 2001-05-09 5:37 ` PATCH (the last?) " Bart Schaefer 2 siblings, 1 reply; 14+ messages in thread From: Andrej Borsenkow @ 2001-05-09 5:32 UTC (permalink / raw) To: Zsh hackers list On Wed, 9 May 2001, Bart Schaefer wrote: > On May 8, 7:25pm, Peter Stephenson wrote: > } Subject: Re: Termcap saga again > } > } In that case I shall commit the following. > > Unfortunately, that has now broken my build on RedHat 5.2 and 6.2. It > appears that AC_CACHE_CHECK does *nothing* when ac_cv_header_curses_h > is already set, so the AC_DEFINE(HAVE_CURSES_H) never happens. In > short, this patch works only if you configure from scratch without using > a cache. > Any better? -andrej Index: configure.in =================================================================== RCS file: /cvsroot/zsh/zsh/configure.in,v retrieving revision 1.54 diff -u -r1.54 configure.in --- configure.in 2001/05/08 18:34:38 1.54 +++ configure.in 2001/05/09 05:30:43 @@ -564,9 +564,12 @@ *curses*) AC_CACHE_CHECK(for curses.h, ac_cv_header_curses_h, AC_TRY_COMPILE([#include <curses.h>], [], -[ac_cv_header_curses_h=yes -AC_DEFINE(HAVE_CURSES_H)], -ac_cv_header_curses_h=no)) +[ac_cv_header_curses_h=yes], +[ac_cv_header_curses_h=no])) +if test x$ac_cv_header_curses_h = xyes; then + AC_DEFINE(HAVE_CURSES_H) +fi + AC_CHECK_HEADERS(term.h) if test x$ac_cv_header_term_h = xyes; then ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: PATCH: Re: Termcap saga again 2001-05-09 5:32 ` PATCH: " Andrej Borsenkow @ 2001-05-09 5:42 ` Bart Schaefer 0 siblings, 0 replies; 14+ messages in thread From: Bart Schaefer @ 2001-05-09 5:42 UTC (permalink / raw) To: Andrej Borsenkow, Zsh hackers list On May 9, 9:32am, Andrej Borsenkow wrote: } } Any better? Probably, but I prefer mine. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 14+ messages in thread
* PATCH (the last?) Re: Termcap saga again 2001-05-09 5:03 ` Bart Schaefer 2001-05-09 5:19 ` Andrej Borsenkow 2001-05-09 5:32 ` PATCH: " Andrej Borsenkow @ 2001-05-09 5:37 ` Bart Schaefer 2 siblings, 0 replies; 14+ messages in thread From: Bart Schaefer @ 2001-05-09 5:37 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list On May 9, 5:03am, Bart Schaefer wrote: } } On May 8, 7:25pm, Peter Stephenson wrote: } } } } In that case I shall commit the following. } } Unfortunately, that has now broken my build on RedHat 5.2 and 6.2. Ok, this seems to have got it. I put all of PWS's new code into the not-found branch of a new AC_CHECK_HEADERS call that checks for ONLY curses.h. The empty if-found branch correctly results in an AC_DEFINE call as needed. I then forced the AC_CHECK_HEADERS to fail by the simple expedient of changing the name of the file to one that doesn't exist, and thereby verified that AC_TRY_COMPILE in the not-found branch works correctly. By virtue of using AC_CHECK_HEADERS, autoheader discovers that we're looking for curses.h and it's no longer necessary to have a #undef for it in acconfig.h, which increases my confidence that everything will work right. I hate having to add things explicitly to acconfig.h. Since term.h is now alone in its own call to AC_CHECK_HEADERS, I took the opportunity to remove an explicit `if test ...' and simply move the code that followed into the if-found branch of that macro. Index: acconfig.h =================================================================== --- acconfig.h 2001/05/09 04:42:10 1.5 +++ acconfig.h 2001/05/09 05:19:35 @@ -318,8 +318,5 @@ /* Define if you have the terminfo strnames symbol. */ #undef HAVE_STRNAMES -/* Define if we have curses.h */ -#undef HAVE_CURSES_H - /* Define if term.h chokes without curses.h */ #undef TERM_H_NEEDS_CURSES_H Index: configure.in =================================================================== --- configure.in 2001/05/09 04:42:10 1.8 +++ configure.in 2001/05/09 05:25:35 @@ -562,15 +562,14 @@ AC_SEARCH_LIBS(tgetent, [$termcap_curses_order]) case "$LIBS" in *curses*) -AC_CACHE_CHECK(for curses.h, ac_cv_header_curses_h, +AC_CHECK_HEADERS(curses.h, [], +AC_CACHE_CHECK(for Solaris 8 curses.h mistake, ac_cv_header_curses_h, AC_TRY_COMPILE([#include <curses.h>], [], [ac_cv_header_curses_h=yes AC_DEFINE(HAVE_CURSES_H)], -ac_cv_header_curses_h=no)) -AC_CHECK_HEADERS(term.h) -if test x$ac_cv_header_term_h = xyes; then - -AC_MSG_CHECKING(if term.h needs curses.h) +ac_cv_header_curses_h=no))) +AC_CHECK_HEADERS(term.h, +[AC_MSG_CHECKING(if term.h needs curses.h) AC_TRY_COMPILE([#include <term.h>], [char **test = boolcodes;], boolcodes_with_only_term_h=yes, boolcodes_with_only_term_h=no) AC_TRY_COMPILE([#include <curses.h> @@ -620,8 +619,7 @@ #include <term.h>], [char **test = strnames; printf(*test);], AC_DEFINE(HAVE_STRNAMES) strnames=yes, strnames=no) AC_MSG_RESULT($strnames) - -fi;; +]);; esac dnl Some systems (Solaris 2.x, Linux Redhat 5.x) require -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2001-05-09 5:43 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-05-08 9:36 Termcap saga again Peter Stephenson 2001-05-08 13:34 ` Clint Adams 2001-05-08 14:35 ` Bart Schaefer 2001-05-08 14:56 ` Peter Stephenson 2001-05-08 15:14 ` Bart Schaefer 2001-05-08 16:23 ` Peter Stephenson 2001-05-08 18:01 ` Andrej Borsenkow 2001-05-08 18:07 ` Bart Schaefer 2001-05-08 18:25 ` Peter Stephenson 2001-05-09 5:03 ` Bart Schaefer 2001-05-09 5:19 ` Andrej Borsenkow 2001-05-09 5:32 ` PATCH: " Andrej Borsenkow 2001-05-09 5:42 ` Bart Schaefer 2001-05-09 5:37 ` PATCH (the last?) " Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).