From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <psmith@gnu.org>
Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10])
 by sourceware.org (Postfix) with ESMTPS id 57C5F3857C4F
 for <gdb@sourceware.org>; Mon, 19 Oct 2020 14:56:22 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 57C5F3857C4F
Received: from fencepost.gnu.org ([2001:470:142:3::e]:35339)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <psmith@gnu.org>) id 1kUWaD-0000SM-Sq
 for gdb@sourceware.org; Mon, 19 Oct 2020 10:56:21 -0400
Received: from pool-96-233-64-159.bstnma.fios.verizon.net
 ([96.233.64.159]:40266 helo=pdslaptop.home)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <psmith@gnu.org>) id 1kUWaA-0008KR-6N
 for gdb@sourceware.org; Mon, 19 Oct 2020 10:56:20 -0400
Message-ID: <69cd93ba5f8d0049cea98dfad396cb4ed3071afc.camel@gnu.org>
Subject: Re: Building gdb without ncursesw?
From: Paul Smith <psmith@gnu.org>
Reply-To: psmith@gnu.org
To: gdb@sourceware.org
Date: Mon, 19 Oct 2020 10:56:17 -0400
In-Reply-To: <9e754414-577e-f279-6418-b675b0c124ac@simark.ca>
References: <fce3cd418084779b786395aceefd4a8f68de6cf1.camel@gnu.org>
 <395a06fee09377bfe6c03a6a761be6e02b9a538b.camel@gnu.org>
 <9e754414-577e-f279-6418-b675b0c124ac@simark.ca>
Organization: GNU's Not UNIX!
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.4-0ubuntu1 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gdb@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gdb mailing list <gdb.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/gdb>,
 <mailto:gdb-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb>,
 <mailto:gdb-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2020 14:56:23 -0000

On Mon, 2020-10-19 at 10:21 -0400, Simon Marchi wrote:
> On 2020-10-17 6:22 p.m., Paul Smith via Gdb wrote:
> > On Sat, 2020-10-17 at 14:35 -0400, Paul Smith via Gdb wrote:
> > > There's really no need (that I can see) for ncursesw since we
> > > just always uses utf8 all the time for everything.
> 
> Looking at configure.ac, the library is chosen using this line:
> 
>   AC_SEARCH_LIBS(waddstr, [ncursesw ncurses cursesX curses])
> 
> Then, looking at my config.cache, I see this line:
> 
>   ac_cv_search_waddstr=${ac_cv_search_waddstr=-lncursesw}
> 
> So I suppose that if you pass ac_cv_search_waddstr=-lncurses to
> configure, it will just use that instead of probing.

Seems a bit dodgy.  Also, there are other places where ncursesw is
checked before ncurses:

  AC_SEARCH_LIBS(tgetent, [termcap tinfow tinfo curses ncursesw ncurses])
    ...
  AC_CHECK_HEADERS(curses.h cursesX.h ncurses.h ncursesw/ncurses.h ncurses/ncurses.h ncurses/term.h)

For my system luckily I don't need tgetent.  And, I'm not 100% sure if
the HAVE_NCURSESW_* config options will be set properly in this
situation.

It would be nice if there were a configure option to either ignore
ncursesw, or else to specifically set the library and headers location.

Oh well, I will hack at it; thanks!