Re: Improving ncurses' win32 (_WIN32) port

[Ali Abdulkadir]

This is a duplicate reply for the mailing list. I forgot to hit "Reply all".

I currently use a header-only, drop-in, Frankenstein getopt.h that I
maintain here https://github.com/sgeto/getoptvs.
In terms of licensing it could be what you're looking for.
One downside to it is that every program that wants to use it must
explicitly include it. Using a common header file for all
progs/samples, and include getopt.h there, and then making all source
files include that file, as it is currently the case, is not possible.
At least not now...

A few more thoughts:

For reference, these are my current configure flags:
--disable-db-install
--disable-getcap
--disable-hard-tabs
--disable-leaks
--disable-macros
--disable-overwrite
--disable-termcap
--enable-interop
--enable-opaque-curses
--enable-opaque-form
--enable-opaque-menu
--enable-opaque-panel
--enable-pc-files
--enable-term-driver
--enable-warnings
--enable-widec
--verbose
--with-abi-version=6
--with-develop
--with-fallbacks=unknown,rxvt
--without-shared
--with-trace
--with-xterm-kbs=DEL
--without-ada
--without-debug
--without-manpages
--without-progs
--without-tests
--without-cxx
--with-libtool

1. Including windows.h alongside ncurses.h currently causes a
KEY_EVENT redefinition warning (see wincon.h). It's a quite loud
warning and there doesn't seem to be a simple way to bypass it other
than including windows.h first and then #undef the offending macro.

2. I'm currently unable to get ncurses.h to mark stdscr() and acs_map
as exported. Works fine with MinGW, but MSVC refuses. Any advice?

3. When installing ncurses, I get a subdirectory called
"ncurses/ncursesw" in ../include that contains all .h files.
When I add that folder to my CFLAGS (via -I../include/ncursesw for
example), compilation fails because ncurses.h assumes to be located in
../include and contains lines such as "#include <ncursesw/ncurses*>"
How is that meant to work and/or how to tell the build system to
install header files in ../include as well?

Thanks

On 6/23/18, Thomas Dickey <address@hidden> wrote:
> On Thu, Jun 21, 2018 at 07:36:15AM +0300, Ali Abdulkadir wrote:
>> Hello,
>>
>> I've been compiling ncurses with MSVC for a few months now and I wanted
>> to
>> give some feedback and/or exchange experiences.
>>
>> 1.  Would it be possible to rename the __MINGW32__ and __MINGW64__
>> directives
>> to the more common _WIN32 and _WIN64 preprocessor definitions?  In
>> ncurses_dll.h as well please.  Every toolchain on windows I know of
>> understands it.
>
> probably (on to-do list...)
>
>> 2.  I was wondering how up-to-date the todo list in README.mingw is.  For
>> example, is widechar support production ready or still somewhat
>> experimental?
>
> It works for some people.  For general purposes, the problem is that an
> ordinary out-of-the-box Windows machine doesn't have the language support
> installed to really use the feature.
>
> The other to-do items are still to-do :-)
>
>> And what about the suggested configure flags? Are they still our best
>> bet.
>
> For reference (that's Juergen's recommendation):
>         --with-libtool
>         --disable-home-terminfo
>         --enable-database
>         --disable-termcap
>         --enable-sp-funcs
>         --enable-term-driver
>         --enable-interop
>
> I use this in cross-compiling:
>
>       --with-shared \
>       --without-debug \
>       --with-trace \
>       --disable-hard-tabs \
>       --enable-term-driver \
>       --enable-sp-funcs \
>       --enable-widec \
>       --with-fallbacks=unknown,rxvt \
>       --with-tparm-arg=intptr_t \
>       --without-ada \
>       --without-cxx-binding \
>
> in one scenario.  There's the cross-compiling packaging scripts which
> I've made longer lists.
>
> With/without libtool, I've not seen useful DLL's built using mingw
> directly.
> Someone might want to look into that, but relying on libtool is only
> half a solution.
>
>> 3.  Correct me if I'm wrong but I think getopt.h is only needed when
>> building
>> the progs/samples and maybe the tests too.
>> It would be nice if the configure script wouldn't error if getopt.h
>> wasn't
>> found *and* if mentioned features are disabled.
>> Another way would be to ship a "standalone" getopt.h.  If possible of
>> course.
>
> yes... I've not given much attention to that because all of my compile
> environments have getopt.  If I were to add a fallback, it would have to
> be BSD- or MIT-licensed.
>
>> 4.  I would had shared build instructions for MSVC, but they are quite
>              ^^ missing word?
>> complex.  I wrote a script to automate the process, but you'll still need
>> good knowledge about Windows, the autotools and how/why they too often
>> not
>> get along very well.
>>
>> My build steps are quite messy actually.  I basically first configure and
>> build with msys2, and then configure and build with MSVC without running
>> any
>> kind of "make *clean" in between.  This is currently necessary because of
>> the
>> complexity of the build scripts with their many tiny steps to
>> generate/move
>> files around during compilation.
>> So is there a way to generate all needed files in some other (possibly
>> autotools independent) way?
>
> not easily.  I'd do a configure, "make sources" and replace ncurses_cfg.h
> with whatever made MSVC work.  (That was what I was doing - starting
> in 2005 - before Juergen started the work with mingw -- looks like 2008).
>
> fwiw, at the time I was testing with the getopt which I added to cproto
> a while back - see this for instance:
>
> https://github.com/ThomasDickey/cproto-snapshots/tree/master/porting
>
> however, something explicitly licensed BSD/MIT would be needed for ncurses.
>
> --
> Thomas E. Dickey <address@hidden>
> https://invisible-island.net
> ftp://ftp.invisible-island.net
>