Re: Merging feature/android

[Po Lu]

Paul Eggert <eggert@cs.ucla.edu> writes:

> As I recall there wasn't much discussion, unfortunately. I very
> vaguely recall that there was some worry that Emacs modules would be
> written in C++, and that they would invoke Elisp code, and that this
> meant it'd be hard to do the cleanup in portable C.
>
> One option that was discussed was to require a C++ compiler to compile
> emacs-modules.cc (i.e., to write the emacs-modules interface in
> C++). I expect this would have addressed the cleanup issue in a
> different way. But RMS was very strongly against requiring a C++
> compiler.

We build emacs with -fexceptions?  That's the only case where GCC turns:

  foo ()
  {
    type *k __attribute__((cleanup, cleanup_func));
    k = /* ... */;
  }

into something other than:

  foo ()
  {
    type *k __attribute__((cleanup, cleanup_func));
    k = /* ... */;
    cleanup_func (k);
  }

and I really hope we are not building emacs with -fexceptions, because
it really generates a lot of extra code that increases binary size.

> You may find this patch useful:
>
> https://lists.gnu.org/archive/html/emacs-devel/2019-04/msg01075.html

This is essentially what was installed on feature/android (except that
check also works while cross compiling, and is only run when modules are
enabled.)

This says that the change was dismissed by virtue of modules being
disabled by default, but now that has changed, so wouldn't it be the
right time to reconsider the ``makes configure slower'' argument?

BTW, with a cache file, you only pay the price of the test once.