all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Valtteri Vuorikoski <vuori@notcom.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 64577@debbugs.gnu.org
Subject: bug#64577: 29.0.92; configure on NetBSD forces unstable terminfo library
Date: Wed, 12 Jul 2023 23:22:16 +0300	[thread overview]
Message-ID: <nrdw7p2mgy3dpvobxc7xx7fpzbhul5nc2duusca4u67y2uada6@76axzuajs2zo> (raw)
In-Reply-To: <83wmz55d2l.fsf@gnu.org>

On Wed, Jul 12, 2023 at 07:06:42PM +0300, Eli Zaretskii wrote:
> > It fixes the immediate problem, yes. But I don't think this special
> > case should stick around, since it seems relevant only to a very
> > ancient version of NetBSD.
> 
> We don't want to drop support of old versions just because we can, and
> we don't really know how "ancient" those ancient versions should
> actually be to require this special case.  We know that in May 2010 it
> was TRT, but not when it stopped being TRT.  Without knowing that, I'd
> like to avoid removing this, at least until we hear a real problem
> with it.  Asking NetBSD users to install ncurses doesn't sound like a
> problem to me.

Can't say I'm happy about keeping the magical special case, which will
result in a different thing happening than what configure prints out.
But at least ncurses-having users will win and the ncurses-preferring
logic will mostly bring things in line with other BSDs.

The reason not much has been heard about this is probably that most
users likely use packaged emacs, and the pkgsrc build system forcibly sets
TERMINFO=yes if it determines that this is a NetBSD with the relevant
headers available. See this package build makefile:
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/editors/emacs21/Makefile.common?rev=1.21&content-type=text/x-cvsweb-markup
"CPPFLAGS+=-DTERMINFO" (similarly check exists for emacsen up to 28).

> That's strange, since termcap and terminfo are the same on NetBSD.
> Maybe the problem is that TERMINFO=no means we don't compile
> terminfo.c into Emacs, and/or also don't define TERMINFO, which could
> bypass more code that's needed for terminfo?  In that case, just
> avoiding TERMINFO=no, even if ncurses were not found, could be another
> good measure.

Looks like removing the TERMINFO=no line inside the if clause has the
same result as unconditionally using -lterminfo, which is to say that
emacs is linked with libterminfo, uses terminfo (and not the termcap
compatibility wrappers) and hence doesn't abort itself.

This seems to be what effectively happens in pkgsrc-packaged
emacs: TERMINFO=no is overridden and things largely proceed as if the
configure special case logic didn't exist, modulo the fact that
libterminfo is always used in preference to ncurses.

How about this then, this way should preserve the intent of the
original special casing while honoring the library selection configure
ended up with:

--- a/configure.ac
+++ b/configure.ac
@@ -5212,9 +5212,8 @@ AC_DEFUN
     ;;

   netbsd)
-    if test "x$LIBS_TERMCAP" != "x-lterminfo"; then
+    if test "x$LIBS_TERMCAP" = "x-ltermcap"; then
       TERMINFO=no
-      LIBS_TERMCAP="-ltermcap"
     fi
     ;;

On ancient NetBSD (without ncurses) LIBS_TERMCAP should be detected as
-ltermcap, and this will ensure that TERMINFO stays undefined
(probably a no-op). On a newer system where someone actually wants to use
termcap and forces LIBS_TERMCAP, this will make sure that TERMINFO is
"no" even though libtermcap is a symlink to libterminfo (= only
the termcap compatibility functions will be used and terminfo stuff
will be ignored even though configure sees tputs() and friends).

The end result should be the same binary as pkgsrc packaging has
provided for years, except that on a system with ncurses installed
it will be used.

> > If users with ancient NetBSD versions experience problems with
> > libterminfo (that the original special case logic presumably avoided),
> > they can install ncurses as a workaround. 
> 
> That argument goes both ways, doesn't it?

Not really. With the netbsd = gnu* version, users with NetBSD versions
released in last ~10 years i.e. most NetBSD users get a good
experience out of the box regardless of whether ncurses is installed,
and users of ancient versions _might_ have problems without ncurses.

With the LIBS_TERMCAP!=-lncurses version, everyone without ncurses
gets a bad experience, assuming TERMINFO=no isn't removed.

 -Valtteri
 





  reply	other threads:[~2023-07-12 20:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 20:37 bug#64577: 29.0.92; configure on NetBSD forces unstable terminfo library vuori
2023-07-12 12:11 ` Eli Zaretskii
2023-07-12 12:57   ` Valtteri Vuorikoski
2023-07-12 13:32     ` Eli Zaretskii
2023-07-12 14:06       ` Valtteri Vuorikoski
2023-07-12 16:06         ` Eli Zaretskii
2023-07-12 20:22           ` Valtteri Vuorikoski [this message]
2023-07-13  5:19             ` Eli Zaretskii
2023-07-13  9:35               ` Valtteri Vuorikoski
2023-07-15  8:17                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nrdw7p2mgy3dpvobxc7xx7fpzbhul5nc2duusca4u67y2uada6@76axzuajs2zo \
    --to=vuori@notcom.org \
    --cc=64577@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.