bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#43004: 28.0.50; Test failures due to symlinked Emacs sources


From: Stephen Berman
Subject: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Fri, 30 Oct 2020 22:26:21 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

On Fri, 30 Oct 2020 01:02:14 +0200 Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 16.10.2020 23:54, Stephen Berman wrote:
>> I've attached the output of two batch runs using the patched
>> elisp-mode-tests.el.  The first run was executed from my home directory,
>> the second run was executed from the partition the file is really
>> located on, which is symlinked from my home directory:
>> (expand-file-name
>> "~/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el")
>> =>
>> "/home/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el"
>> (file-truename
>> "/home/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el")
>> =>
>> "/datadisk/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el"
>> On the first run there are no unexpected failures, on the second, there
>> are five unexpected failures.
>
> So, what happens if you just remove the 'file-truename' call from the
> declaration of emacs-test-dir?

That's what I did in my patch in <87r1pyz27k.fsf@gmx.net>
(https://debbugs.gnu.org/cgi/bugreport.cgi?msg=11;att=1;bug=43004) and
initially concluded that with that patch "I now get no unexpected
failures when running the tests in batch mode, though when run
interactively xref-elisp-test-find-defs-defgeneric-implicit-generic
still fails."  But then in my next followup: "I also just realized that
I had run the patched batch mode tests from my home directory, i.e.,
following the symlink.  When I run them from the source directory
without following the symlink, I get the same five failures again (i.e.,
with the patch) that I had gotten before without the patch.  So much for
that attempt."

> It was added by Glenn in c4ecc01a45, and there must be a reason for it, but it
> seems like it causes the current failures.
>
> Ultimately, if we don't manage to fix it in an easy way, we could replace the
>
>   (should (equal xref expected-xref))
>
> comparison inside xref-elisp-test-run with multiple deeper comparisons (and
> use file-equal-p instead of equal for file names). Or call
> xref-location-marker and compare markers.

That may be a better test for my setup.

Steve Berman





reply via email to

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