[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Android port
From: |
Bruno Haible |
Subject: |
Re: Android port |
Date: |
Sun, 06 Aug 2023 16:40:10 +0200 |
Eli Zaretskii wrote:
> Unless there's a misunderstanding, your understanding contradicts what
> I wanted to convey in the quoited text.
It's possible that I had misunderstood you. In fact, I don't fully
understand your argument even now:
> 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.
I'd like to view this question from the process point-of-view:
If some new functionality test is introduced in gnulib/m4/printf.m4,
be it
(a) because a bug has been discovered on a non-mingw platform
(such as recently the %lc bug), or
(b) because a bug has been discovered on mingw, or
(c) because a new ISO C or POSIX standard requires new functionalities
(such as recently the support of %b),
what do you expect to see and do in Emacs?
In all three cases, we update the Gnulib documentation, but don't put
an entry into gnulib/NEWS.
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?
Bruno
- Re: Android port, (continued)
- Re: Android port, Po Lu, 2023/08/06
- Re: Android port, Eli Zaretskii, 2023/08/06
- Re: Android port, Po Lu, 2023/08/06
- Re: Android port, Eli Zaretskii, 2023/08/06
- Re: Android port, Po Lu, 2023/08/06
- Re: Android port, Eli Zaretskii, 2023/08/06
- Re: Android port, Bruno Haible, 2023/08/06
- Re: Android port, Eli Zaretskii, 2023/08/06
- Re: Android port, Po Lu, 2023/08/06
- Re: Android port, Eli Zaretskii, 2023/08/06
- Re: Android port,
Bruno Haible <=
- Re: Android port, Eli Zaretskii, 2023/08/06
- Re: Android port, Bruno Haible, 2023/08/06
- Re: Android port, Eli Zaretskii, 2023/08/06
- Re: Android port, Bruno Haible, 2023/08/06
- Re: Android port, Eli Zaretskii, 2023/08/06
- Re: Android port, Eli Zaretskii, 2023/08/06
- Re: Android port, Bruno Haible, 2023/08/06
- Re: Android port, Eli Zaretskii, 2023/08/06
- Re: Android port, Po Lu, 2023/08/06
- Re: Android port, Angelo Graziosi, 2023/08/06