Re: Merging feature/android

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org,  eggert@cs.ucla.edu
> Date: Sat, 04 Mar 2023 16:05:19 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > macOS builds don't use GCC.
> 
> They use Clang, which pretends to be GCC well enough to support this
> extension.
> 
> > But if this problem is basically limited to Android, how about solving
> > it in emacs-module.c, via preprocessor directives, instead?  Or even
> > unconditionally disable modules in the configure script for Android?
> > I think making changes that affect all the platforms for the benefit
> > of Android should be limited to the absolute minimum.
> 
> This problem in emacs-module.c affects all platforms except MS-DOS.
> Basically any non-GCC and non-Clang compiler cannot compile Emacs by
> default.

What are those "non-GCC and non-Clang compilers" that are prone to
this problem?

> Also, some versions of Android's GCC do support the cleanup attribute,
> while others are new enough to support it but signal an ICE compiling
> any code that actually uses it.  And Android's clang is a hit and miss I
> have not yet figured out.

<Shrug> It is strange that GCC and Clang for Android behave
differently in this regard from the same compilers configured for
other platforms.  The cleanup attribute is not supposed to be so
platform-dependent, AFAIU.

> In general, it is better to write tests for a feature than tests for a
> version of one tool known to support a feature.  That's why Autoconf was
> created.

I'm okay with writing tests for this, but can be arrange for those
tests to be run only in the Android build?  Once again, I'd prefer not
to make non-trivial changes in our configury with a clear test case,
and we don't have any such case that doesn't involve the Android
build, AFAIU.