Re: Android port

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: angelo.g0@libero.it, luangruo@yahoo.com, eggert@cs.ucla.edu, 
> emacs-devel@gnu.org
> Date: Sat, 05 Aug 2023 14:25:59 +0200
> 
> Eli Zaretskii wrote:
> > The MinGW build omits building the Gnulib's stdio module.  We did that
> > since 2017.  The exact reasons are probably lost in time, but I can
> > assure you they were real, and I wouldn't want to reintroduce them for
> > this particular reason.
> 
> It'd be worth a try nevertheless. Gnulib has changed a lot since 2017.

If someone wants to try that and report back, I won't mind.  But I
personally don't have time (nor the motivation, TBH).  There be
dragons: for example, Emacs on MS-Windows provides its own
implementation of fopen, because we want to support UTF-8 encoded file
names even when the system codepage is not (or cannot be) UTF-8.
Likewise with any other Gnulib replacement that accepts file names:
Emacs must be able to pass UTF-8 encoded file names on Windows,
because it supports non-ASCII file names without restrictions imposed
by the current system codepage.

> So, if you decided not to have a generated stdio.h, the simplest
> solution seems to be:
>   1) in the conf_post.h or nt/inc/ms-w32.h, include <stdio.h>
>      (this is the one from the system),
>   2) after this #include, add
>      #define asprintf rpl_asprintf
>      #define printf __printf__
>      #define vasprintf rpl_vasprintf
>      #define vfprintf rpl_vfprintf
>      and add prototypes for these 4 functions.

I'd prefer to use the simpler machinery of OMIT_GNULIB_MODULE to
prevent the Emacs build from compiling asprintf.c and similar
replacements on MS-Windows.  Is that possible?  We do that with
several other Gnulib modules, see the file nt/gnulib-cfg.mk in the
Emacs repository.

Thanks.