Re: Improving ncurses' win32 (_WIN32) port

[Thomas Dickey]

On Tue, Jun 26, 2018 at 07:26:42AM +0300, Ali Abdulkadir wrote:
> 
> > On Jun 24, 2018, at 3:39 AM, Thomas Dickey <address@hidden> wrote:
> > 
> >> 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 :-)
> Sounds like a plan. If there's anything I can help you with, let me know.

ok....

> >> 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.
> I haven't really explored a lot of ncurses features. I'm glad it builds and 
> runs at all. :-D
> At the top of my head, this does sounds like something that could work.

"could work", with some effort (mingw's terminal I/O is non-existent,
though its msys environment would be interesting if its developers
chose to provide development packages for _that_)
 
> >> 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).
> I found the issue. It was right in front of me all alone. I didn't notice 
> because I have been linking statically most of the time.
> 
> As you said, MinGW completely skips 
> the import/export block in ncurses_dll.h and simply exports/imports almost 
> everything.
> This was made possible be defining (read: hardcoding) "NCURSES_STATIC".
> The problem now is that there is no way to bypass this.
> Removing that line will make ncurses default to dynamic linkage. A user would 
> then need to define NCURSES_STATIC to set up things for static linkage.
> I like the idea, as this is the default for many projects I use. But 
> adjusting that block to favor static linkage is fine too.
> What do you think?

I'd like to have both static/dynamic build reliably :-)

either way, I'll have to explore the tools.  When I set up my mingw environment
for ncurses, that added in a 64-bit compiler, and for whatever reason, the
tools/options used for dll's with that are incompatible with the ones I use
for cross-compiling.  But time passes, and perhaps some of the tool deficiences
have been addressed (the only way to find out is to rebuild the environment...)
 
-- 
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: Digital signature