Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: angelo.g0@libero.it,  emacs-devel@gnu.org
> Date: Sat, 05 Aug 2023 09:04:54 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> >> Date: Fri, 04 Aug 2023 21:17:47 +0800
> >> 
> >> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> >> index 68e264fde4c..f78ee525bf1 100644
> >> --- a/nt/mingw-cfg.site
> >> +++ b/nt/mingw-cfg.site
> >> @@ -175,6 +175,7 @@ gl_cv_func_nanosleep=yes
> >>  enable_xattr=no
> >>  # Don't build gnulib printf either.
> >>  gl_cv_func_printf_sizes_c99=yes
> >> +gl_cv_func_printf_sizes_c23=yes
> >>  gl_cv_func_printf_long_double=yes
> >>  gl_cv_func_printf_infinite_long_double=yes
> >>  gl_cv_func_printf_directive_a=yes
> >
> > What feature does the gl_cv_func_printf_sizes_c23 variable test?  Does
> > MinGW printf indeed support that feature?  If not, we are lying to the
> > configure script, and that is not TRT.
> 
> We are deceiving the configure script, but that's the only ``supported''
> way to disable the printf* modules, as they aren't subject to the normal
> Make-based controls in gnulib.mk.

I'm sorry, but such a solution is not acceptable, as it will be a
maintenance headache, if and when we actually need these features in
Emacs.  We must find a cleaner solution.

Let's wait for the Gnulib folks to chime in and suggest better ways of
solving this.