From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Merging feature/android Date: Fri, 03 Mar 2023 13:27:07 +0200 Message-ID: <83356mcbxw.fsf@gnu.org> References: <87edq7ztks.fsf.ref@yahoo.com> <87edq7ztks.fsf@yahoo.com> <83pm9reccn.fsf@gnu.org> <87v8jjxxo9.fsf@yahoo.com> <835ybje2u5.fsf@gnu.org> <87fsanxoah.fsf@yahoo.com> <83zg8vckx5.fsf@gnu.org> <87bklay7wg.fsf@yahoo.com> <83ilficn4k.fsf@gnu.org> <87zg8uw9b9.fsf@yahoo.com> <837cvycjse.fsf@gnu.org> <87ttz2w4c3.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12583"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, eggert@cs.ucla.edu To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 03 12:28:00 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pY3Zv-00034M-Ax for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Mar 2023 12:27:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pY3ZU-0005KB-Jm; Fri, 03 Mar 2023 06:27:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pY3ZS-0005GL-MS for emacs-devel@gnu.org; Fri, 03 Mar 2023 06:27:30 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pY3ZR-0004j9-5O; Fri, 03 Mar 2023 06:27:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=s2sPz5Jra+ZniV2AwqhlUXGvy1tE6IAEOYCFTZ3SvzM=; b=UvMOsy+8l7P6 MRjk2t6aZBi4RcRvSw3bAegJFdaGQ+YkDLOYw43356Y9Pm6mN7jF/b3/189b/d1YDpclVBeolswYy jZQyqZsyRJd6vjiu/TTu2mDKr5y+7LZNR7cZhf4ArXcexL1mN2ANGwqVArZcrJ8pvCL4l9OsxOHBP Xytzahk29XaxOne1j5iMOHUXHad+LIsd07aelQPH2Tg7QYImptNXESmY8gx/as6QrVlkXif3DdfZe NltQ3qC4HdukQu8i+AedgM66RhRxN+1BIhCX2XrIhqbBdXgDCPpUIq0wtIe0KPR6gT8w+Y6Bp9vOK /+ncX2JHIF0R6whbykboOQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pY3ZK-0005gI-PE; Fri, 03 Mar 2023 06:27:28 -0500 In-Reply-To: <87ttz2w4c3.fsf@yahoo.com> (message from Po Lu on Fri, 03 Mar 2023 17:51:08 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303921 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org, eggert@cs.ucla.edu > Date: Fri, 03 Mar 2023 17:51:08 +0800 > > Eli Zaretskii writes: > > >> From: Po Lu > >> Cc: emacs-devel@gnu.org, eggert@cs.ucla.edu > >> Date: Fri, 03 Mar 2023 16:03:38 +0800 > >> > >> Eli Zaretskii writes: > >> > >> > If not, please explain more, because I don't think I understand what > >> > you say above. > >> > >> I was saying that the HarfBuzz check currently doesn't show an error > >> when it is enabled with ``--with-harfbuzz'' and HarfBuzz is not found. > > > > That's strange, because image libraries use the same OPTION_DEFAULT_ON > > way, and I definitely remember seeing an error message when I used the > > "--with-gif" option and the library wasn't available. The message > > suggested using ifavailable instead. > > > >> The reason is precisely that the option doesn't default to ifavailable; > >> as a result, configure cannot tell apart the two cases where > >> $with_harfbuzz is specified on the command line, and when it is simply > >> set to yes as its default value. That's why ifavailable is required. > > > > Do you see the same with image libraries? > > Image libraries default to being on, while also accepting > ``ifavailable'' as an option. The default values of the options for the > common image libraries is not ``ifavailable'', because we want configure > to error out by default if the library is not present. So why shouldn't it be the same with modules? Don't we want the user to be aware that modules support will be absent?