emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merging feature/android


From: Eli Zaretskii
Subject: Re: Merging feature/android
Date: Sat, 04 Mar 2023 09:28:48 +0200

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org,  eggert@cs.ucla.edu
> Date: Sat, 04 Mar 2023 08:07:27 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: emacs-devel@gnu.org,  eggert@cs.ucla.edu
> >> Date: Fri, 03 Mar 2023 21:28:27 +0800
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > So why shouldn't it be the same with modules?  Don't we want the user
> >> > to be aware that modules support will be absent?
> >> 
> >> No, I don't think so: that would amount to making Emacs not build
> >> by default without a recent GCC.
> >
> > We had this in emacs-module.c for a long time, including two major
> > releases.  How come it was never a problem until now?
> 
> I don't know, but it doesn't surprise me, since most people use GCC.

macOS builds don't use GCC.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]