bug-gtypist
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: clutton
Subject: Re: [bug-gtypist] ideas, implementations, patches.
Date: Tue, 28 Jun 2016 16:57:53 +0300

On Tue, 2016-06-28 at 14:41 +0200, Felix Natter wrote:
> clutton <address@hidden> writes:
> 
> > 
> > On Sat, 2016-05-28 at 11:45 +0200, Felix Natter wrote:
> > > 
> > > clutton <address@hidden> writes:
> > > 
> > > > 
> > > > 
> > > > On Sun, 2016-05-15 at 10:00 +0200, Felix Natter wrote:
> > > > > 
> > > > > 
> > > > > clutton <address@hidden> writes:
> > > hello Clutton,
> > > 
> > > > 
> > > > 
> > > > Could you guys please check this patch out?
> > > Now I am doing this, sorry for the delay.
> > > 
> > > > 
> > > > 
> > > > 1) malloc->stdlib obvious.
> > > Should be ok.
> > > 
> > > > 
> > > > 
> > > > 2) the change I was talking about, include <curses.h> instead
> > > > of
> > > > <ncursesw/ncursesw.h>, if you still don't believe that this is
> > > > the
> > > > thing to do check out if your curses.h has function prototypes
> > > > like add_wch, etc.
> > > This does not work for Debian/GNU (only works for BSD curses as
> > > far
> > > as I
> > > understand you):
> > > 
> > > In Debian/GNU, ncurses and ncursesw are separated.
> > > /usr/include/curses.h
> > > does not have add_wch & co:
> > > 
> > > $ dpkg -S /usr/include/curses.h 
> > > libncurses5-dev:amd64: /usr/include/curses.h
> > > 
> > > $ grep add_wch /usr/include/curses.h
> > > 
> > > // this is what we need on GNU:
> > > $ dpkg -S /usr/include/ncursesw/ncurses.h
> > > libncursesw5-dev:amd64: /usr/include/ncursesw/ncurses.h
> > > 
> > > $ grep add_wch /usr/include/ncursesw/ncurses.h
> > > extern NCURSES_EXPORT(int) add_wch (const cchar_t *);
> > > [...]
> > > 
> > > So if you need /usr/include/curses.h (and don't have
> > > ncursesw/ncurses.h), then we need to do sth like:
> > > 
> > > # check for ncursesw (GNU)
> > > AC_CHECK_HEADER(ncursesw/ncurses.h, HAVE_NCURSESW_H=1)
> > > if test -n "$HAVE_NCURSESW_H";  then
> > >    AC_CHECK_HEADER(curses.h, HAVE_CURSES_H=1)
> > >    if test -n "$HAVE_CURSES_H";  then
> > >       echo -e "Couldn't find ncursesw/curses header."\
> > >           "On Debian/Ubuntu you need to install libncursesw5-
> > > dev."
> > >       exit 1;
> > >    fi
> > > fi
> > > 
> > > which is not perfect because it will silently use curses.h if
> > > ncursesw
> > > is not installed on GNU systems. But I guess we will catch that
> > > problem
> > > when doing AC_CHECK_LIB(ncursesw, add_wch) afterwards.
> > > 
> > > Then we need this:
> > > 
> > > #if defined(HAVE_PDCURSES) || !defined(HAVE_NCURSESW_H)
> > > #include <curses.h>
> > > #else
> > > #include <ncursesw/ncurses.h>
> > > #endif
> hello clutton,
> 
> > 
> > Ok, now I have those OS's installed. It seems I was right about the
> > approach, could you please check out "autoall" branch and try
> > compiling
> > it?
> > That would really help. Because it works for me on debian.
> > 
> > grep wouldn't tell you all truth because some #ifdef are involved
> > there.
> > 
> > You might also check out some other utf8 curses programs like
> > toxic,
> > etc. They use include <curses.h> approach, with some build flags
> > like
> > _EXTENDED_SOMETHING or/and _WCURSES_SOMETHING which we have too.
> > 
> > This is not a big deal, but somehow I'd love this thing to be
> > implemented.
> Indeed, your branch works on Debian jessie, which surprises me ;-)
> 
> But I don't think my grep was wrong:
> 
> address@hidden:/usr/include$ grep add_wch curses.h
> <nothing>
> 
> address@hidden:/usr/include$ grep add_wch ncursesw/curses.h
> [...]
> #define add_wch(c)                    wadd_wch(stdscr,(c))
> [...]
> 
> Maybe, if libncurses5w-dev is installed,
> /usr/include/ncursesw/curses.h
> comes before /usr/include/curses.h in the default search path
> (I don't see a -I/usr/include/ncursesw when compiling autoall)?

No, your grep works as expected :D. And it doesn't look into ncursesw,
you can look at a preprocessor output gcc -E. As I understand during
composing object files compiler doesn't care about unresolved
dependencies. You may see that without patch symbols output is U
(unresolved): nm utf8.o

                 U towupper
                 U waddch
                 U waddnstr
                 U wadd_wch
                 U wattr_off

With patch or without. It looks the same.
It's just thought, I guess I should investigate more if I'm proposing
this. I'll give you full answer soon. I saw this approach used by
software which highly uses utf8 borders, symbols.

In short: ncursesw/curses.h has everything, using right include
directory -I ....ncursesw and #include <curses.h> would cover all
needs. But we are talking about something different now. I'll
investigate this.

> 
> I'd like to understand _why_ this works ;-)
> 
> > 
> > > 
> > > > 
> > > > 
> > > > 2) AM_ICONV doesn't work for me somehow, does it add -liconv
> > > > for
> > > > you?
> > > > It looks like everything is ok
> > > Using AM_ICONV seems to be a good idea because it handles corner
> > > cases:
> > >  
> > > https://www.gnu.org/software/gettext/manual/html_node/AM_005fICON
> > > V.ht
> > > ml
> > Ok,  let it be. It seems that handling corner cases the macros
> > iconv.m4
> > has forgotten to do the job. FeeBSD have hack in ports which would
> > deal
> > with this.
> Again, have you tried this very simple patch?
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index e0a6ad3..03fafed 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -12,7 +12,7 @@ gtypist_SOURCES = gtypist.c cursmenu.c script.c
> error.c getopt.c getopt1.c            \
>       infoview.c speedbox.c banner.c cmdline.c cursmenu.h error.h
> getopt.h              \
>       gettext.h gtypist.h script.h utf8.c utf8.h infoview.h
> speedbox.h banner.h   \
>       cmdline.h cmdline.ggo
> -gtypist_LDADD = @LIBINTL@ # TODO: do we need @LIBICONV@ here?
> +gtypist_LDADD = @LIBINTL@ @LIBICONV@
>  
>  AM_CPPFLAGS = -I../intl \
>    -DDATADIR=\"$(pkgdatadir)\" \

That would work. But if curses.h would be included the code would be
changed, I'll finish that thing first.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]