Repository navigation
Fix curses module compilation with ncurses6 #69906
Description
Activity
ncurses6 turned on NCURSES_OPAQUE, so now you have to use some helper functions instead of accessing the structs directly. This _should_ be compatible with ncurses5 though I didn't test it.
Original patch is from openSUSE.
- addedextension-modulesC modules in the Modules dirC modules in the Modules dir
on Nov 24, 2015 - addedbuildThe build process and cross-buildThe build process and cross-build
on Nov 24, 2015 Any patch review/comment ?
configure.ac directly uses w->_flags in a check. It looks that this check always fails with ncurses6.
Thats not an issue for ncurses because Include/py_curses.h does:
#ifdef HAVE_NCURSES_H /* configure was checking <curses.h>, but we will use <ncurses.h>, which has all these features. */ #ifndef WINDOW_HAS_FLAGS #define WINDOW_HAS_FLAGS 1 #endif #ifndef MVWDELCH_IS_EXPRESSION #define MVWDELCH_IS_EXPRESSION 1 #endif #endif
So it overrides WINDOW_HAS_FLAGS for ncurses case.
ping?
I suspect that the patch can break build with non-ncurses implementations or with old ncurses (when is_pad() was added?). Needed more direct feature check.
is_pad is added in ncurses 5.7-20090906 [1]. At least Mac OS X still ships ancient ncurses 5.7-20081102 [2], so an check in configure.ac is necessary. I'm trying it out.
[1] http://invisible-island.net/ncurses/NEWS.html#t20090906
[2] http://opensource.apple.com//source/ncurses/ncurses-46/ncurses/NEWSMark, do you have relation to this?
I tried to build curses module on Cygwin (Vista x86) using bpo-25720 patch. And it has been succeeded.
When test_curses ran without skip condition, it was same result as msg278060 (bpo-28190).I found out build success reasons for cases of applying patch:
bpo-25720 -- implementation of WINDOW is opaque (but WINDOW_HAS_FLAGS is defined at Include/py_curses.h:61 ). However, curses module build went well to cover the _flags field from source code by is_pad.
bpo-14598 -- implementation of WINDOW is not opaque (WINDOWS_HAS_FLAGS is defined at configure script). Therefore, curses module build went well because WINDOW has the _flags field.
bpo-28190 -- implementation of WINDOW is opaque (WINDOW_HAS_FLAGS isn't defined: py_curses.h has been cleaned by patch). Hence, curses module build went well to remove the _flags field from source code at preprocessing.All case tests on Cygwin have failed at unget_wch.
Mark, do you have relation to this?
Sorry, no. Whatever ncurses knowledge I may once have had has long since vanished.
I updated the patch that add configuration check for is_pad. the is_pad is wrapped into py_is_pad at Modules/_cursesmodule.c:932 by either of three ways.
Case one -- is_pad is found: Define the macro that is simple wrapping.
Case two -- is_pad is not found, however WINDOW has _flags field: Define the macro using _flags field.
Case three -- is_pad is not found, and WINDOW doesn't have _flags field: Define the macro that is always preprocessed to FALSE.I succeeded to build curses module on Cygwin (Vista x86) using this patch.
This patch doesn't include that undo fixes for specific platforms.@masamoto thank you!
6 remaining items
What's the status on this? Can you please create a pull request on Github so we can continue there?
Hi, I finished various things and tackle the issue again, I opened PR 1689 at last.
Changes from previous patch:
- If ncurses doesn't have both is_pad function and _flags field of WINDOW, NCURSES_OPAQUE is defined as zero to make WINDOW to non-opaque type before including ncurses.h.
- The conditional compile on function definition are kept, it replaces WINDOW_HAS_FLAGS with py_is_pad macro itself.
- Unindent the blocks that places after section of the conditional compile on function definition.
Ping. I updated PR a bit: macOS is joined to new compile condition and remove platform-specific condition.
I opened PR 4164 to improve the is_pad configure check and previous PR was closed.
I'll try to test this on NetBSD after fixing curses on NetBSD. It uses a different implementation of curses which don't support is_pad.
Thank you for your contribution Masayuki!
- added 2 commits that reference this issue
on Oct 5, 2023 - added a commit that references this issue
on Oct 6, 2023 - added a commit that references this issue
on Jun 14, 2024
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: