[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
- Re: API change with macro KEY_EVENT?,
Sven Joachim <=