Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: bruno@clisp.org,  angelo.g0@libero.it,  eggert@cs.ucla.edu,
>   emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 13:07:19 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Look, I'm the only person around here who had ever seriously worked
> > with these facilities, so please believe me when I say that some ways
> > are better than others, okay?
> 
> OK, but the Gnulib developers aren't inclined to introduce any changes
> for us here.

Paul didn't chime in yet, so I'd like to wait for him to comment on
this.  I see no reason why we would be unable to omit these modules
like we do with others.

> So we've got to work with what we have, following practice
> that already exists within mingw-cfg.site:
> 
> # We don't need fdopendir
> ac_cv_func_fdopendir="not-needed"
> gl_cv_func_fdopendir_works="no-but-not-needed-so-yes"
> 
> # Avoid gnulib replacement
> gl_threads_api=posix
> gl_cv_func_pthread_sigmask_return_works=yes
> gl_cv_func_pthread_sigmask_unblock_works="not relevant"
> gl_cv_func_pthread_sigmask_macro=no

There are good reasons for those (and others like them).  fdopendir is
not a feature, it's an API that cannot work on Windows.  And the
pthreads stuff causes Emacs to depend on the pthreads DLL (which is
bad for distributing the binaries), and also replaces some
time-related structure definitions ('struct timespec', I think) with
pthread ones -- and these cannot be undone by omitting some Gnulib
modules.

Like I said: this stuff is done for very good reasons, and only after
careful consideration of the alternatives.  It worked for the last 10
years with almost no changes.