Re: Android port

[Eli Zaretskii]

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