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

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

bug#15933: make check not working


From: Eli Zaretskii
Subject: bug#15933: make check not working
Date: Mon, 25 Nov 2013 23:08:25 +0200

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: andrewjmoreton@gmail.com,  15933@debbugs.gnu.org
> Date: Mon, 25 Nov 2013 20:24:28 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > --[make check]----------------------------------------------
> >> > Indenting module modname...done
> >> >    passed  180/521  f90-test-bug8691
> >> >    passed  181/521  f90-test-bug8820
> >> >    passed  182/521  f90-test-bug9553a
> >> >    passed  183/521  f90-test-bug9553b
> >> >    passed  184/521  f90-test-bug9690
> >> >    passed  185/521  f90-test-indent
> >> >    passed  186/521  file-notify-test00-availability
> >> >   skipped  187/521  file-notify-test00-availability-remote
> >> >    passed  188/521  file-notify-test01-add-watch
> >> >   skipped  189/521  file-notify-test01-add-watch-remote
> >> > make[1]: *** [check] Error 5
> >> > make[1]: Leaving directory 
> >> > `/c/emacs/src/emacs/trunk/obj-mingw32/test/automated'
> >> Oops. Please indicate in the bug report the environment you were
> >> using. I guess it was MS Windows whatever (which might it make hard for
> >> me to debug, 'cause I don't use it).
> >
> > It might be easy enough to guess why it fails.  I see this in
> > file-notify-tests.el:
> >
> >   ;; There is no default value on w32 systems, which could work out of the 
> > box.
> >   (defconst file-notify-test-remote-temporary-file-directory
> >     (if (eq system-type 'windows-nt) null-device "/ssh::/tmp")
> >     "Temporary directory for Tramp tests.")
> 
> No, it did fail in file-notify-test02-events.

How do you know?  The fact that it said "skipped" does not necessarily
mean the code that "skipped" didn't error out.

If you do know what triggered the error, can you point it out?

> null-device is an indicator NOT to try remote test cases.

Why not nil?

> "/ssh::/tmp" is indeed for accessing a local sshd. Nothing I would
> assume for MS Windows.

You could provide for a possibility to set this up with a remote Unix
machine.  It would be better than just skipping, I think.





reply via email to

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