[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-ncurses] API change with macro KEY_EVENT?
From: |
Thomas Dickey |
Subject: |
Re: [bug-ncurses] API change with macro KEY_EVENT? |
Date: |
Mon, 17 Aug 2020 06:19:56 -0400 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
On Mon, Aug 17, 2020 at 11:40:24AM +0200, Dr. Werner Fink wrote:
> On 2020/08/17 04:57:02 -0400, Thomas Dickey wrote:
> > On Mon, Aug 17, 2020 at 09:56:17AM +0200, Dr. Werner Fink wrote:
> > >
> > > Hmmm .... those packages do fail in staging test:
> > >
> > > apparmor failed
> > > ceph failed
> > > dpkg failed
> > > grantlee5 failed
> > > kbuild failed
> > > kdelibs4support failed
> > > libappindicator:gtk3 failed
> > > libarchive failed
> > > memcached failed
> > > meson:test failed
> > > python-pytest-django failed
> > > speech-dispatcher failed
> > > tcpd failed
> > > zsh failed
> >
> > I see - lots of copy/paste going on. Aside from zsh, none of those
> > appear to have a reason to use ncurses.
> >
> > > ... do I've revert the change for Visual C++ for OpenSUSE to get
> > > then to compile again?
> >
> > That seems to be the initial fix. I don't see a reason why ncurses
> > should provide a definition for a return value which is not supported
> > by the configuration you've built :-(
> >
> > fwiw, there's no known users of the wgetch_events feature.
> >
> > I could probably replace that definition by any integer constant without
> > altering the behavior of those programs.
> >
>
> AFAICS from source of both dpkg and zsh: it seems that those packages uses
> scripts (perl/awk) to seek for KEY_* macros to generate the header files
> used later in the sources. That seems to be a common method to grep
> through /usr/include/ncurses.h :/
In that case, I can simply omit the entire feature unless it's configured.
--
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: API change with macro KEY_EVENT?, Thomas Dickey, 2020/08/14