Re: [bug-gtypist] ideas, implementations, patches.

[clutton]

On Tue, 2016-06-28 at 14:41 +0200, Felix Natter wrote:
> clutton <address@hidden> writes:
> 
[snip]

TL/DR: Using "-D_XOPEN_SOURCE_EXTENDED -I/usr/include/ncursesw" and
#include <curses.h>
would resolve all ncursesw.h functionality.
The meter of discussion is how to achieve that.

---------------answering to Felix----------------------
Why my last patch works: It's the same case when you don't include
<stdio.h> and use printf. The linker would find your printf eventually
by linking to standard libraries. We at the end linking to libncursesw,
although the processor know nothing, it works because linking resolve
Unknown symbols. The approach is unacceptable, anyway.
----------------end---------------------------

Take a look at my recent commit, I made it work with -Wall. -Wall
-Werror are flags which should be used by developers while coding to
avoid such situations.

For now, omit the configure.ac file, and push/[push after reviewing]
the C code. Or should I make a cleaning up as a final step?

Back to topic, after hacking a little I've found that nowadays projects
resolve such issues by using pkg-config. With pkg-config it'll awfully
simple to do proper checks. Something like:

pkg-config --cflags-only-I ncursesw
pkg-config --cflags ncursesw

People hack it like that

PKG_CHECK_MODULES([NCURSES], [ncursesw], [LIBS="$LIBS $NCURSES_LIBS";
ncurses=ncursesw],
  [AC_CHECK_LIB([ncursesw],
               [initscr],
               [LIBS="$LIBS -lncursesw"; ncurses=ncursesw],
               [ncurses=ncurses])
])

But, adding another dependence... What do you think? Should we left
everything as it is now? Or use some hack instead of pkg-config?

ncursesw has it's own utility for such a thing:ncursesw6-
config, ncursesw5-config. But I vote against using them.

signature.asc
Description: This is a digitally signed message part