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

[clutton]

On Sat, 2016-07-16 at 19:46 +0200, Felix Natter wrote:
> hello clutton,
> 
> clutton <address@hidden> writes:
> > 
> > I've deleted old autoall branch and created clear new one.
> > Please review. I tested this on several Linuxe's and on
> > Free/Net/Open|BSD. Would like to see it tested on MacOS (should be
> > fine
> > too). And windows, I have no idea how you guys make it build for
> > windows...
> > 
> > The approach is of more extreme nature the previous one, but it
> > seems
> > good with autotools philosophy (testing capabilities).
> > 
> > If everything is ok, the branch is ready for merging. If not: there
> > are
> > my few thoughts: the test code could be separated to m4 directory
> > (I
> > tried using ax_with_curses.m4 but it's more Linux only). Maybe
> > using
> > resolv.h for headers (perfect autotools solution), but I'm ok with
> > how
> > my patch solves everything now...
> Just one small thing: What if ncursesw/curses.h is in
> prefix=/usr/local
> instead of prefix=/usr? Maybe it would suffice to:
> 
> diff --git a/configure.ac b/configure.ac
> index 7477ece..636c6e5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -71,7 +71,7 @@ AC_DEFUN([IS_CURSES_WIDE], [
>     have_ncursesw="yes"
>     AC_MSG_RESULT([yes])
>     AS_IF([test "x$1" = "xncursesw/curses.h"], [
> -     NCURSES_CPPFLAGS=-I/usr/include/ncursesw
> +     NCURSES_CPPFLAGS="-I/usr/include/ncursesw
> -I/usr/local/include/ncursesw"
>     ])
>    ],
>    [AC_MSG_RESULT([no])])
> 
> Of course there may be other prefixes.
> In this way, the #include <ncursesw/ncurses.h> is superior :-p

Indeed, many use cases. One way is to have --with-ncursesw=/.../...
The perfect solution would be if autotools could tell where the header
was found, something like[pseudocode]:

CHECK_HEADER(header, [if found, give me the full path of the header
location]

Then the user could use any CPPFLAGS and project would treat it
perfectly. But I don't know how to get the location of the found
header.

I'll think about it, may be I'll abandon the attempt.


Meantime :) could you add -liconv and commit this? It's not only a BSD
problem apparently:
https://trac.macports.org/ticket/40403

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