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. A few more thoughts:
For reference, these are my current configure flags:
looks ok1. 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-eventsis 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. 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 (whichdoesn'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? 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.
Got it. Thanks 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.netftp://ftp.invisible-island.net
|