GNU bug report logs - #43004
28.0.50; Test failures due to symlinked Emacs sources

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Glenn Morris <rgm <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>, 43004 <at> debbugs.gnu.org
Subject: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Fri, 30 Oct 2020 22:26:21 +0100

On Fri, 30 Oct 2020 01:02:14 +0200 Dmitry Gutov <dgutov <at> 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 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.