[issue28190] Detect curses headers correctly for cross-compiling

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

> The only change that is needed here is to not include /usr/include/ncursesw 
> in setup.py when cross compiling

No. Lots of codes in _cursesmodule.c need to know whether it's ncursesw, 
ncurses, or SysV's curses. For example: (segments below are from unpatched 
codebase)

#if !defined(__hpux) || defined(HAVE_NCURSES_H)
/* On HP/UX 11, these are of type cchar_t, which is not an
   integral type. If this is a problem on more platforms, a
   configure test should be added to determine whether ACS_S1
   is of integral type. */
SetDictInt("ACS_S1",(ACS_S1));
SetDictInt("ACS_S9",(ACS_S9));
SetDictInt("ACS_DIAMOND",   (ACS_DIAMOND));
SetDictInt("ACS_CKBOARD",   (ACS_CKBOARD));
SetDictInt("ACS_DEGREE",(ACS_DEGREE));
SetDictInt("ACS_PLMINUS",   (ACS_PLMINUS));
SetDictInt("ACS_BULLET",(ACS_BULLET));
SetDictInt("ACS_LARROW",(ACS_LARROW));
SetDictInt("ACS_RARROW",(ACS_RARROW));
SetDictInt("ACS_DARROW",(ACS_DARROW));
SetDictInt("ACS_UARROW",(ACS_UARROW));
SetDictInt("ACS_BOARD", (ACS_BOARD));
SetDictInt("ACS_LANTERN",   (ACS_LANTERN));
SetDictInt("ACS_BLOCK", (ACS_BLOCK));
#endif

And

static int
PyCurses_ConvertToCchar_t(PyCursesWindowObject *win, PyObject *obj,
  chtype *ch
#ifdef HAVE_NCURSESW
  , wchar_t *wch
#endif
  )

So detecting ncurses's actual include path is necessary.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28190] Detect curses headers correctly for cross-compiling

[Xavier de Gaye]

Xavier de Gaye added the comment:

The only change that is needed here is to not include /usr/include/ncursesw in 
setup.py when cross compiling to ensure that the headers of the build platform 
are not included.  When cross compiling Python, it is the responsability of the 
packager to set the appropriate CPPFLAGS and LDFLAGS upon invoking configure, 
so that the curses headers are included and the curses libraries are linked at 
build time.
The same is true for the other extension modules, readline, openssl, libffi, 
etc...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28190] Detect curses headers correctly for cross-compiling

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

> second issue is that you apparently don't do the changes for term.h

term.h is included only if ncurses is missing and the system (SysV) curses is 
used, so I didn't change it. See below:

#ifdef __sgi
#include 
#endif

#ifdef HAVE_NCURSES_H
#include 
#else
#include 
#ifdef HAVE_TERM_H
/* for tigetstr, which is not declared in SysV curses */
#include 
#endif
#endif


> Third issue is that you can't make these changes for third party extensions

Did you mean 3rd party extensions that include py_curses.h may get broken with 
this patch? IMO they shouldn't include this as it's CPython's implementation 
detail and shouldn't be used outside Modules/_cursesmodule.c and 
Modules/_curses_panel.c

> however the ncursesw installation can be found in /include instead

This is what I want to solve at the first place - make _curses compatible with 
different configurations. In configure.ac, there's a line:

AC_CHECK_HEADERS(curses.h ncurses.h ncursesw/ncurses.h ncurses/ncurses.h 
panel.h ncursesw/panel.h ncurses/panel.h)

> so you apparently can assume that this directory name is fixed *iff* it exists

Did you mean there's no need to check panel.h? I'll try to update the patch.


There's something missing from this patch: if ncurses is built with 
--enable-reentrant, the library and include paths get an additional 't'. For 
example, the library name becomes libncursestw.so and includedir becomes 
$prefix/include/ncursestw. Note that 't' comes before 'w' as ncurses's 
configure.in handles --enable-widec before --enable-reentrant. I skip such 
cases as --enable-reentrant is not compatible with Modules/_cursesmodule.c yet 
(issue25720). I'd like to postpone it until issue25720 is resolved as it does 
not make sense to detect incompatible header paths.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28190] Detect curses headers correctly for cross-compiling

[Matthias Klose]

Matthias Klose added the comment:

the upstream ncurses has the ncursesw subdirinclude name, so you apparently can 
assume that this directory name is fixed *iff* it exists, however the ncursesw 
installation can be found in /include instead.  Can your changes cope 
with that?

second issue is that you apparently don't do the changes for term.h (and 
possibly for other headers in other places as well, I only looked at the diff), 
so you mix ncursesw and ncurses headers. So you have to make these changes in 
all other places as well.

Third issue is that you can't make these changes for third party extensions, if 
there are any relying on the ncurses/ncursesw distinction.

fyi, "all" ncursesw headers are:

/usr/include/ncursesw/curses.h
/usr/include/ncursesw/cursesapp.h
/usr/include/ncursesw/cursesf.h
/usr/include/ncursesw/cursesm.h
/usr/include/ncursesw/cursesp.h
/usr/include/ncursesw/cursesw.h
/usr/include/ncursesw/cursslk.h
/usr/include/ncursesw/eti.h
/usr/include/ncursesw/etip.h
/usr/include/ncursesw/form.h
/usr/include/ncursesw/menu.h
/usr/include/ncursesw/nc_tparm.h
/usr/include/ncursesw/ncurses_dll.h
/usr/include/ncursesw/panel.h
/usr/include/ncursesw/term.h
/usr/include/ncursesw/term_entry.h
/usr/include/ncursesw/termcap.h
/usr/include/ncursesw/tic.h
/usr/include/ncursesw/unctrl.h

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28190] Detect curses headers correctly for cross-compiling

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

A clean patch without changes in ./configure. autoreconf necessary

--
Added file: http://bugs.python.org/file45790/ncurses-headers.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28190] Detect curses headers correctly for cross-compiling

[Masayuki Yamamoto]

Masayuki Yamamoto added the comment:

test_curses has been skipped almost. the skip reason has been written  
"cygwin's curses mostly just hangs" in test case class.
I removed the skip condition, and ran test. Tests was almost passed. The only, 
unget_wch was failed by edge case '\U0010', because the wchar_t size on 
windows platfrom is two bytes. I'll upload test log together.

--
Added file: http://bugs.python.org/file44961/cygwin-test_curses.log

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28190] Detect curses headers correctly for cross-compiling

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

Hmm it's surprising for me that an irrelevant patch fixes issues on Cygwin. 
Does test_curses pass?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28190] Detect curses headers correctly for cross-compiling

[Masayuki Yamamoto]

Masayuki Yamamoto added the comment:

Now, Cygwin platform is able to build core interpreter on default branch. But 
the curses module has been failed to build. Therefore I tried to build curses 
module on Cygwin (Vista x86) using this patch. And it has been succeeded.
The patch effect at build time removes one compiler option 
"-I/usr/include/ncursesw". Maybe that modification position is setup.py:1352. I 
couldn't confirm why it has became success.

--
nosy: +masamoto

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28190] Detect curses headers correctly for cross-compiling

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
nosy: +xdegaye

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28190] Detect curses headers correctly for cross-compiling

[Matthias Klose]

Matthias Klose added the comment:

looks good to me, thanks for working on this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28190] Detect curses headers correctly for cross-compiling

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28190] Detect curses headers correctly for cross-compiling

[Chi Hsuan Yen]

Changes by Chi Hsuan Yen :


--
title: Cross-build _curses failed if host ncurses headers and target ncurses 
headers have different layouts -> Detect curses headers correctly for 
cross-compiling

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com