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 20:44:00 +0300 Message-ID: <83bkfkoylb.fsf@gnu.org> References: <1428589171.162865.1691134964773@mail1.libero.it> <3469960.ipicrQNo7v@nimes> <83h6pcp5rb.fsf@gnu.org> <5837029.DyV9NtORJm@nimes> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14089"; 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 19:44:07 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 1qShnS-0003RG-VP for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Aug 2023 19:44:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qShn7-00009N-Tu; Sun, 06 Aug 2023 13:43:45 -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 1qShn6-000098-4B for emacs-devel@gnu.org; Sun, 06 Aug 2023 13:43:44 -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 1qShn5-00085n-5B; Sun, 06 Aug 2023 13:43:43 -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=VB5w9deeGMpvU81EIEORNUUvt2gvRbzJXXOnXq658EU=; b=o8UBFFMqbE50 R5L/tR1KCHjMRgarujqsjYXGSgGucoIjjgfjcVfY8jz8NBXmJolPqPEXYLba0HtMcwTReTWuEr7JO lNC4yzTtrDp3bb5xoKc86eMG5+y6Due0MBGP2ufJj4fJLRxp+gNg7QAxOOwlM6oz9W3NUXzA9e5Op 4ZYtVywn4cDNNFuSc+ax37ZS8+MmnrN+pP/ggepaaFj/3hQGb1zkO2JtfUfCiY+UREsRgVSsRnfOG +RTHXHsF+NpCh9stDf7QqeKIstC4o8Hcs0Z0PukpULTP+Zyo+2KpAHGEP1hQpJzgb6RsMp7eegob8 FBvchV+QvA/NrFeK7eMV1w==; In-Reply-To: <5837029.DyV9NtORJm@nimes> (message from Bruno Haible on Sun, 06 Aug 2023 17:46:27 +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:308380 Archived-At: > From: Bruno Haible > Cc: luangruo@yahoo.com, eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org > Date: Sun, 06 Aug 2023 17:46:27 +0200 > > Eli Zaretskii wrote: > > > Will you typically want to > > > - review all format strings in Emacs, to see whether they are affected? > > > - add some note to Emacs-internal coding guidelines, e.g. to the effect > > > that %b should not be used? > > > - review the mingw-specific *printf override, to see whether it > > > needs a workaround (in case b) or an extension (in case c)? > > > - or do nothing at all? > > > > Some mix of the above, depending on the case. But only for the MinGW > > build. > > OK. How do you reliably get notified about the relevant changes? By watching the Gnulib updates and new Gnulib modules that get imported and compiled into libgnu.a. > If you look at gnulib/ChangeLog and search for "mingw" or "Windows" > you will spot some of the relevant changes. Thanks for the pointer. > For more reliability, I would save the generated config.cache from a mingw > build somewhere, and compare the config.cache of newer builds with the > saved one. I do that as well, when I suspect some change could cause a difference. > In case > > > (b) because a bug has been discovered on mingw > > Gnulib might stuff the new configure test into an existing AC_RUN_IFELSE > invocation and thus reuse an existing gl_cv_* variable. (Not for *printf, > but for other modules.) Say, gl_cv_foobar_works meant the absence of > bugs P and Q, and now it means the absence of bugs P, Q, and R. When > the override gl_cv_foobar_works=yes was added, it meant "our nt code > has workarounds for P and Q". Thus, you won't be alerted that you need > to add a workaround for R or remove the override gl_cv_foobar_works=yes. The foobar function (or its emulation) needs to do its job on MS-Windows well enough for us to set gl_cv_foobar_works=yes. If it doesn't, and Gnulib discovers that first (unlikely, but possible), we will have to pick that up in some way, either by watching Gnulib updates, or via user complaints, or in some other way. Luckily, this happens very rarely, IME, at least as far as things related to Emacs on Windows are concerned. > If you were to build the corresponding gnulib tests as part of the Emacs > build (gnulib-tool option '--with-tests'), then we would have added a unit > test against bug R, and this test would fail, thus alerting you that > you need to do something. Emacs doesn't (yet) have a facility to run Gnulib tests.