From: Eli Zaretskii <eliz@gnu.org>
To: Valtteri Vuorikoski <vuori@notcom.org>
Cc: 64577@debbugs.gnu.org
Subject: bug#64577: 29.0.92; configure on NetBSD forces unstable terminfo library
Date: Thu, 13 Jul 2023 08:19:21 +0300 [thread overview]
Message-ID: <83jzv45qxy.fsf@gnu.org> (raw)
In-Reply-To: <nrdw7p2mgy3dpvobxc7xx7fpzbhul5nc2duusca4u67y2uada6@76axzuajs2zo> (message from Valtteri Vuorikoski on Wed, 12 Jul 2023 23:22:16 +0300)
> Date: Wed, 12 Jul 2023 23:22:16 +0300
> From: Valtteri Vuorikoski <vuori@notcom.org>
> Cc: 64577@debbugs.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.
That happens on other systems as well, look at the code around the
netbsd case. The fact that the configure script says "ncurses" is not
a promise that ncurses will be used, it's just a status report of that
particular test.
> 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).
If you could find out since when did the NetBSD pkgsrc system start
using this override, it could be a data point that we could consider
in making these decisions.
> 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.
I don't mind installing the above instead of my proposal, thanks.
next prev parent reply other threads:[~2023-07-13 5:19 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
2023-07-13 5:19 ` Eli Zaretskii [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83jzv45qxy.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=64577@debbugs.gnu.org \
--cc=vuori@notcom.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).