Re: Improving ncurses' win32 (_WIN32) port

[Thomas Dickey]

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

signature.asc
Description: Digital signature