[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: master 7ce721b: Migrate MH-E functional tests from SourceForge
From: |
Eli Zaretskii |
Subject: |
Re: master 7ce721b: Migrate MH-E functional tests from SourceForge |
Date: |
Fri, 24 Sep 2021 14:40:07 +0300 |
> 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?