bug-ncurses
[Top][All Lists]
Advanced

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

Re: API change with macro KEY_EVENT?


From: Sven Joachim
Subject: Re: API change with macro KEY_EVENT?
Date: Fri, 18 Sep 2020 21:37:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.50 (gnu/linux)

On 2020-08-17 06:19 -0400, Thomas Dickey wrote:

> 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.

This is what you claimed to do in the 20200817 patchlevel, but it does
not actually work as advertised.

The v1.49 change to include/Makefile.in is this:

diff --git a/include/Makefile.in b/include/Makefile.in
index d89dfa3d..25cca487 100644
--- a/include/Makefile.in
+++ b/include/Makefile.in
@@ -1,4 +1,4 @@
-# $Id: Makefile.in,v 1.48 2020/02/19 23:54:22 tom Exp $
+# $Id: Makefile.in,v 1.49 2020/08/17 10:43:16 tom Exp $
 ##############################################################################
 # Copyright 2019,2020 Thomas E. Dickey                                       #
 # Copyright 1998-2013,2015 Free Software Foundation, Inc.                    #
@@ -104,6 +104,7 @@ curses.h :  $(CAPLIST) \
                $(srcdir)/MKkey_defs.sh
        cat curses.head >$@
        AWK=$(AWK) $(SHELL) $(srcdir)/MKkey_defs.sh $(CAPLIST) >>$@
+       $(SHELL) -c 'if test "@NCURSES_EXT_FUNCS@" = "1" ; then cat 
$(srcdir)/curses.events >>$@ ; fi'
        $(SHELL) -c 'if test "@NCURSES_CH_T@" = "cchar_t" ; then cat 
$(srcdir)/curses.wide >>$@ ; fi'
        cat $(srcdir)/curses.tail >>$@

and @NCURSES_EXT_FUNCS@ evaluates to 1 unless "--disable-ext-funcs" is
given to configure AFAICS.  That's not what was intended, namely a check
for "--enable-wgetch-events", it seems?

In Debian I have upgraded ncurses to the 20200912 patchlevel, and now
at least dpkg and zsh fail to build.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970545

Cheers,
       Sven

reply via email to

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