Re: Android port

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> 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.