Re: master 7ce721b: Migrate MH-E functional tests from SourceForge

[Eli Zaretskii <eliz@gnu.org>]

> From: Stephen Gildea <stepheng+emacs@gildea.com>
> Date: Thu, 23 Sep 2021 22:49:06 -0700
> Cc: emacs-devel@gnu.org
> 
> >   This leads to the following test failure -- but only when
> >   native-compilation is enabled.  And the backtrace looks pretty odd: It's
> >   failing when trying to make a trampoline for file-directory-p?
> 
> This test mocks out both call-process and file-directory-p.  Apparently
> changing file-directory-p causes call-process to be called to run a
> separate Emacs process to natively compile the new file-directory-p.
> This test does not expect that, and the mocked-out functions aren't
> prepared to handle this case.
> 
> I can change mh-utils-tests.el to tell the native compiler to ignore it
> (perhaps by binding native-comp-never-optimize-functions) but I'm
> surprised that I have to.  Why should fset of a locally-bound variable
> cause a separate Emacs process to be run to compile it?

Note that it compiles a trampoline, not the file itself.

That said, AFAIK we shouldn't automatically invoke native-compilation
in batch mode.  Lars, are by chance running the test suite in an
interactive session?  If not, we aren't supposed to natively-compile
code without an explicit request.

I hope Andrea could help us understand what is TRT in this case.

> Interestingly, I get a different failure when I run the tests with native
> compilation enabled.

"Enabled" or "disabled"?  If the former, how is that different from
the default?