Fix "stdscr" configure failure & ncursest support #1558
Conversation
BenBE
added
enhancement
There was a problem hiding this comment.
LGTM.
Document the #if defined(HAVE_CONFIG_H) to be used for reference inside configure.ac.
Also, if not done, have the ncursest specific changes re macros and the ProvideCurses changes live inside separate commits (though that already seems to be the case AFAICS).
Explorer09
force-pushed
the
ncursest-support
branch
2 times, most recently
from
5f0d8f1
to
8eac24b
Compare
| #ifndef _XOPEN_SOURCE_EXTENDED | ||
| #undef _XOPEN_SOURCE_EXTENDED | ||
| #endif |
There was a problem hiding this comment.
I think you got the check inverted by accident …
| #ifndef _XOPEN_SOURCE_EXTENDED | |
| #undef _XOPEN_SOURCE_EXTENDED | |
| #endif | |
| #ifdef _XOPEN_SOURCE_EXTENDED | |
| #undef _XOPEN_SOURCE_EXTENDED | |
| #endif |
There was a problem hiding this comment.
No. It is not an error. It's the peculiarity of the config.h.in format. The #undef is technically the placeholder that would be replaced by #define during configure.
There was a problem hiding this comment.
TIL. Please add a small note about this to document this somewhat. TIA.
Explorer09
force-pushed
the
ncursest-support
branch
2 times, most recently
from
845bc0c
to
6a4b665
Compare
Explorer09
force-pushed
the
ncursest-support
branch
2 times, most recently
from
d5320f9
to
e3f2bb2
Compare
|
I have a idea when trying to improve configure in detecting ncurses header, but am not sure whether such a change is acceptable: --- a/ProvideCurses.h
+++ b/ProvideCurses.h
@@ -16,16 +16,13 @@ in the source distribution for its full text.
// IWYU pragma: begin_exports
-#if defined(HAVE_NCURSESW_CURSES_H)
-#include <ncursesw/curses.h>
-#elif defined(HAVE_NCURSES_NCURSES_H)
-#include <ncurses/ncurses.h>
-#elif defined(HAVE_NCURSES_CURSES_H)
-#include <ncurses/curses.h>
-#elif defined(HAVE_NCURSES_H)
-#include <ncurses.h>
-#elif defined(HAVE_CURSES_H)
-#include <curses.h>
+// The CURSES_HEADER_NAME macro may be defined by configure script to any of these:
+// <ncursesw/curses.h>
+// <ncurses/curses.h>
+// <ncurses.h>
+// <curses.h>
+#if defined(CURSES_HEADER_NAME)
+#include CURSES_HEADER_NAME
#endif
#ifdef HAVE_LIBNCURSESWInstead of having a lot of boolean |
|
I considered it briefly when that header was created, but decided against it, as we hate the ProvideCurses.h anyway to deal with all the other aspects of curses that come bundled with terminal control stuff. And since you get those booleans for free™ from autoconf there's no real reason not using them in favour of some little-used feature of the pre-processor. So keep it as-is. |
The problem is, the list of possible header names for ncurses is non-exhaustive. We only check header names that are common in distributions ( I know these are custom builds and niche use cases, but as I introduced |
|
People who mess around with the header names may also just mess around with the code at that point. I doubt most programs using (n)curses at that point would even compile properly with these custom header names. That's some additional complexity added that doesn't provide reasonable benefit for the average case or is common enough to warrant going that extra kilometer. People messing with their header names can feel lucky, that it's basically just one place they have to mess with in our code … |
It makes no sense to error out if the builder runs "./configure --with-curses" and no option argument. "--with-curses" without an option argument now keeps using the default name list for detecting ncurses library. Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
When "configure" suggests user to install pkg-config, output the '*curses*.pc' file detected in the config.log. This aids diagnosing the configure script. Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
Explorer09
force-pushed
the
ncursest-support
branch
2 times, most recently
from
2c4e92e
to
eb2ee64
Compare
It is slightly more robust to grep for the 'pkg_m4_included' token when running "make dist". Also, shorten the "make dist" warning message, and tell users if they need to regenerate configure when we recommend them to install pkg-config. Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
When ncurses is compiled with reentrant support, the "stdscr" may be only available as a macro and not a symbol for direct linking. We can check for "stdscr" only after the curses headers are included. For now we can remove the "stdscr" test when checking for keypad() function. Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
According to ncurses man page, mvadd_wchnstr() may be implemented as a macro. Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
This allows configure tests to utilize the macro. Also explain the reasons that we define _XOPEN_SOURCE_EXTENDED and not _XOPEN_SOURCE. Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
The main thing I intended to test is "stdscr", but it is also useful to test ncurses functions that might be implemented as macros, such as refresh() and mvadd_wchnstr(). Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
curses.h may define its own "bool" type, because the X/Open Curses standard defines "bool" that predates C99 "bool". If curses.h "bool" is not compatible with ISO C, fail at configure time. (The C23 standard now makes "bool" a keyword so that a "typedef /*whatever*/ bool;" is no longer portable. This is a bug that curses implementations should fix.) Solaris 11 is known to ship with a broken curses.h header (the default curses, not ncurses). Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
Explorer09
force-pushed
the
ncursest-support
branch
from
eb2ee64
to
a1f2175
Compare
The first two commits should be enough to fix the issue of #1548. But I plan to add some other improvements to make ncurses detection more robust. Notably we could add ncursest and ncursestw into the search list.