Re: Improving ncurses' win32 (_WIN32) port

[Thomas Dickey]

On Sat, Jun 23, 2018 at 11:39:56PM +0300, Ali Abdulkadir wrote:
> 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...

I could just write one :-)

> A few more thoughts:
> 
> For reference, these are my current configure flags:

looks ok
 
> 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.

I should ifdef that, since it's only usable when --enable-wgetch-events
is set.  That feature uses select() and probably doesn't work with MinGW.
 
> 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?

sorry, no - perhaps something to implement in ncurses_dll.h (which
doesn't have to do anything when building with MinGW).
 
> 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?

See the discussion of "--enable-overwrite" in the INSTALL file.
 
> 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
> >

-- 
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: Digital signature