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: Android port Date: Sun, 06 Aug 2023 14:56:32 +0300 Message-ID: <83tttcpeof.fsf@gnu.org> References: <1428589171.162865.1691134964773@mail1.libero.it> <87il9s5vmv.fsf@yahoo.com> <83zg34pi7p.fsf@gnu.org> <9065382.vXJBWSPEcx@nimes> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12203"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org To: Bruno Haible Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 06 13:57:12 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 1qScNj-0002vs-Lf for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Aug 2023 13:57:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qScMu-0005rK-99; Sun, 06 Aug 2023 07:56:20 -0400 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 1qScMs-0005qn-4a for emacs-devel@gnu.org; Sun, 06 Aug 2023 07:56:18 -0400 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 1qScMq-0004yU-In; Sun, 06 Aug 2023 07:56:16 -0400 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=wTAB4XhapsF0/QkSOMoAVuh3QPjKNv+SAvAUp6e289c=; b=dwDKm4XV5j42 HshoXhzdigFI79L37Xon5Tz+TanVhDbvycwRkXMnazRz+TI674zOe5rVdNAMxCuIjQkWcgb0GT3Xh sMiwXNP3NGe4LzcoIEdqzkJaaXr2/q+n91SkMCM7Q3gRxx9MT9q0zGG1mcnQx679Mowyedp6cmKPu w2WHoxzd+uhX5qNYnFR/2p16bJW/v28aLZaWAAcZ8KUhVT2WaMdG/BdkClcGqKzW5xhB2rAT6fw7K VJZJF05SyHbX8/COBSf8bg58p+TQaCb0Sc7dMXQ/cs0N1Rv1hkUhPd7m/wDxXGs92qa81achRkO9X d5vqvEYhXMfFpgEsP5HixQ==; 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 1qScMq-0003Au-2A; Sun, 06 Aug 2023 07:56:16 -0400 In-Reply-To: <9065382.vXJBWSPEcx@nimes> (message from Bruno Haible on Sun, 06 Aug 2023 13:02:45 +0200) 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:308351 Archived-At: > From: Bruno Haible > Cc: eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org > Date: Sun, 06 Aug 2023 13:02:45 +0200 > > Eli Zaretskii wrote: > > Isn't there some "summary" variable for printf, like > > gl_cv_func_printf_works or some such, which is set if all of the above > > variables are set? I'd prefer to override summary if it exists > > No, there is no such "summary" variable. And it would be overkill to > introduce one, because > - Emacs is the only package that needs a certain Gnulib module on > most platforms but wants to deactivate it on one particular platform. > Other packages don't work this way. > - The approach to set the variables individually in mingw-cfg.site > is good enough. It occasionally needs updates, every N years or so, > when some variable is added. But that's not a good enough justification > for adding complexity to Gnulib. The decision whether Emacs's needs justify some additional complexity in Gnulib is yours, of course (although I'd argue that Emacs is not just any package), but please don't decide for the Emacs maintainers whether this or that alternative is "good enough" for Emacs. If we reach out to Gnulib developers asking them for help in this matter, we do that in good faith, and _after_ we considered the alternatives which don't involve Gnulib changes (which are always preferable, for obvious reasons). > Also, a "summary" variable would not fulfil the goal that you set out > yourself yesterday: > "I prefer not to preset gl_cv_* variables in this case, since they are > general enough tests of specific printf features, and if those > features will ever be really needed in Emacs, we want to be alerted to > that." > > I perfectly understand this argument, that you want to be aware if the > mingw-cfg.site file for example pretends that Emacs does not need %b support, > in order to check the format strings to see whether that's indeed the case. > The individual gl_cv_* variables are the right instrument to achieve this > process. Unless there's a misunderstanding, your understanding contradicts what I wanted to convey in the quoited text. The individual gl_cv_* variables, if overridden by mingw-cfg.site, will completely shadow the feature tests and will from that moment on make detecting any new needs for that and dealing with those new needs our responsibility, with nothing to aid us. Which in practice means we could have a broken port on Windows if some other functionality, which _is_ needed on Windows, will become dependent on a test that we've overridden via these variables. Which is why I prefer to disable a module or a function replacement without overriding the individual functionality tests which led to the inclusion of the module and/or replacement of a function. Disabling the module or a function replacement just says that this module/function is not needed or is implemented differently, without saying anything about the respective functionalities. Disabling functionality tests is only TRT when they are implemented in Emacs's own code (and thus the configure script cannot possibly know about them). And even then we try to minimize the list of disabled functionalities by telling the configure script as much as we can; that is the reason why the configure script does this: *-mingw* ) opsys=mingw32 # MinGW overrides and adds some system headers in nt/inc. GCC_TEST_OPTIONS="-I $srcdir/nt/inc"