GNU bug report logs - #15933
make check not working

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15933 in the body.
You can then email your comments to 15933 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: make check not working
Date: Wed, 20 Nov 2013 12:55:09 +0000

Hi,

Running 'make check' does not work correctly for me with bzr r115157 on
Windows with mingw and and out of tree build directory:

--[make check]------------------------------------------------------
Compiling ../../../test/automated/package-x-test.el

In toplevel form:
../../../test/automated/package-x-test.el:38:30:Error: Cannot open load file: no such file or directory, package-test
make[2]: *** [../../../test/automated/package-x-test.elc] Error 1
--[make check]------------------------------------------------------

It seems that the recent changes for relative paths and msys
translations have not been added to tests/automated/Makefile.in. The
following patch copies the new behaviour from lisp/Makefile.in and
allowed the tests to build and run (one test aborts emacs, for other
reasons).

=== modified file 'test/automated/Makefile.in'
--- test/automated/Makefile.in	2013-11-06 17:56:48 +0000
+++ test/automated/Makefile.in	2013-11-20 11:49:09 +0000
@@ -20,8 +20,13 @@
 SHELL = @SHELL@
 
 srcdir = @srcdir@
+test_automated = $(srcdir)
 VPATH = $(srcdir)
 
+# Empty for all systems except MinGW, where xargs needs an explicit
+# limitation.
+XARGS_LIMIT = @XARGS_LIMIT@
+
 # We never change directory before running Emacs, so a relative file
 # name is fine, and makes life easier.  If we need to change
 # directory, we can use emacs --chdir.
@@ -66,20 +71,20 @@
 # Compile all the Elisp files that need it.  Beware: it approximates
 # `no-byte-compile', so watch out for false-positives!
 compile-main: compile-clean
-	@$(setwins); \
+	@(cd $(test_automated) && $(setwins); \
 	els=`echo "$$wins " | sed -e 's|/\./|/|g' -e 's|/\. | |g' -e 's| |/*.el |g'`; \
 	for el in $$els; do \
 	  test -f $$el || continue; \
 	  test ! -f $${el}c && GREP_OPTIONS= grep '^;.*no-byte-compile: t' $$el > /dev/null && continue; \
 	  echo "$${el}c"; \
-	done | xargs echo | \
+	done | xargs  $(XARGS_LIMIT) echo) | \
 	while read chunk; do \
 	  $(MAKE) $(MFLAGS) compile-targets EMACS="$(EMACS)" TARGETS="$$chunk"; \
 	done
 
 # Erase left-over .elc files that do not have a corresponding .el file.
 compile-clean:
-	@$(setwins); \
+	@cd $(test_automated) && $(setwins); \
 	elcs=`echo "$$wins " | sed -e 's|/\./|/|g' -e 's|/\. | |g' -e 's| |/*.elc |g'`; \
 	for el in $$(echo $$elcs | sed -e 's/\.elc/\.el/g'); do \
 	  if test -f "$$el" -o \! -f "$${el}c"; then :; else \

Message #8 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 15933 <at> debbugs.gnu.org
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 13:49:53 -0500

Andy Moreton wrote:

> Running 'make check' does not work correctly for me with bzr r115157 on
> Windows with mingw and and out of tree build directory:
>
> --[make check]------------------------------------------------------
> Compiling ../../../test/automated/package-x-test.el
>
> In toplevel form:
> ../../../test/automated/package-x-test.el:38:30:Error: Cannot open load file: no such file or directory, package-test
> make[2]: *** [../../../test/automated/package-x-test.elc] Error 1
> --[make check]------------------------------------------------------

It works fine for me on GNU/Linux.
I see nothing mingw specific in the changes you suggest, so it is not
obvious to me what is going on.
Perhaps -L :foo is not working correctly on mingw?

Message #11 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 15933 <at> debbugs.gnu.org
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 13:56:40 -0500

Glenn Morris wrote:

> I see nothing mingw specific in the changes you suggest,

Well, apart from the XARGS_LIMIT thing, which if needed would imply that
make check has never worked on mingw.

Message #14 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 21:04:09 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Date: Wed, 20 Nov 2013 13:49:53 -0500
> Cc: 15933 <at> debbugs.gnu.org
> 
> Perhaps -L :foo is not working correctly on mingw?

Why should it?  Observe:

		  ((member argi '("-L" "-directory"))
		   ;; -L :/foo adds /foo to the _end_ of load-path.
		   (let (append)
		     (if (string-match-p
			  "\\`:"  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
			  (setq tem (or argval (pop command-line-args-left))))
			 (setq tem (substring tem 1)
			       append t))

It should use path-separator instead of a literal ':'.

(No, you don't need to change anything in test/automated/Makefile,
since the MSYS Bash will automatically convert ':' into ';'.)

Message #17 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 14:10:11 -0500

Eli Zaretskii wrote:

> since the MSYS Bash will automatically convert ':' into ';'.)

Amazingly, not something I was aware of.

Message #20 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 14:14:29 -0500

Glenn Morris wrote:

> Eli Zaretskii wrote:
>
>> since the MSYS Bash will automatically convert ':' into ';'.)
>
> Amazingly, not something I was aware of.

I mean, how does that even work?
Does

 echo :foo

print ";foo"?

Does

  : foo

return a syntax error?

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 20:34:14 +0000

On Wed 20 Nov 2013, Glenn Morris wrote:

> Andy Moreton wrote:
>
>> Running 'make check' does not work correctly for me with bzr r115157 on
>> Windows with mingw and and out of tree build directory:
>>
>> --[make check]------------------------------------------------------
>> Compiling ../../../test/automated/package-x-test.el
>>
>> In toplevel form:
>> ../../../test/automated/package-x-test.el:38:30:Error: Cannot open load file: no such file or directory, package-test
>> make[2]: *** [../../../test/automated/package-x-test.elc] Error 1
>> --[make check]------------------------------------------------------
>
> It works fine for me on GNU/Linux.
> I see nothing mingw specific in the changes you suggest, so it is not
> obvious to me what is going on.
> Perhaps -L :foo is not working correctly on mingw?

I use a an out of tree build i.e for bzr sources in "trunk/", I build
in "trunk/obj-mingw32/". Without the patch I get the error above. With
it, the tests build and run.

The compile-main targets in test/automated/Makefile.in was originally
copied from lisp/Makefile.in (according to the comments). It seems that
it has not been updated to match the recent changes for msys path
translation and relative paths.

The suggested patch simply updates the build targets to more closely
match how the updated lisp/Makefile.in does things.

    AndyM

Message #26 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 23:33:38 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Date: Wed, 20 Nov 2013 13:56:40 -0500
> Cc: 15933 <at> debbugs.gnu.org
> 
> Glenn Morris wrote:
> 
> > I see nothing mingw specific in the changes you suggest,
> 
> Well, apart from the XARGS_LIMIT thing, which if needed would imply that
> make check has never worked on mingw.

It could have worked when there were fewer tests.

Message #29 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 23:34:42 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: andrewjmoreton <at> gmail.com,  15933 <at> debbugs.gnu.org
> Date: Wed, 20 Nov 2013 14:10:11 -0500
> 
> Eli Zaretskii wrote:
> 
> > since the MSYS Bash will automatically convert ':' into ';'.)
> 
> Amazingly, not something I was aware of.

That's what MSYS does, that's its raison d'etre.

Message #32 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 23:38:35 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 15933 <at> debbugs.gnu.org,  andrewjmoreton <at> gmail.com
> Date: Wed, 20 Nov 2013 14:14:29 -0500
> 
> Glenn Morris wrote:
> 
> > Eli Zaretskii wrote:
> >
> >> since the MSYS Bash will automatically convert ':' into ';'.)
> >
> > Amazingly, not something I was aware of.
> 
> I mean, how does that even work?

When MSYS invokes a native Windows program (as opposed to an MSYS
program), it converts : into ; in PATH and similar environment
variables, and also in the argv[] array it passes to the native
program.

> Does
> 
>  echo :foo
> 
> print ";foo"?

No, because 'echo' is a shell builtin.  But if you invoke echo.exe
that is a native Windows program (e.g., compiled with MinGW, then yes,
it will print ";foo".

> Does
> 
>   : foo
> 
> return a syntax error?

No (if it did, it would break too many shell scripts).  The conversion
only happens in environment and in argv[] passed to native programs.

Message #35 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rgm <at> gnu.org
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 23:53:26 +0200

> Date: Wed, 20 Nov 2013 23:38:35 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
> 
> > Does
> > 
> >  echo :foo
> > 
> > print ";foo"?
> 
> No, because 'echo' is a shell builtin.  But if you invoke echo.exe
> that is a native Windows program (e.g., compiled with MinGW, then yes,
> it will print ";foo".

Well, for some values of 'foo'.  MSYS has a complex heuristics that
does this conversion only when 'foo' is believed to be a file name.
So, a literal ":foo" prints as ":foo", but, e.g., ":../foo" prints as
";..\foo" (yes, with mirrored slash), and ":/foo" prints as (gasp!)
";D:\MSYS\foo" (assuming that MSYS is installed at D:\MSYS).

This heuristics does TRT 99% of the time, but sometimes it fails, and
then we need to help it with the likes of unmsys-file-name etc.

Message #38 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 19:33:30 -0500

Eli Zaretskii wrote:

> No (if it did, it would break too many shell scripts).  The conversion
> only happens in environment and in argv[] passed to native programs.

I was sort of expecting it with the environment, but not with argv.
So in particular "emacs -L :/foo" would result in command-line-args
containing ("-L" ";/foo")?

Message #41 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 19:34:54 -0500

Eli Zaretskii wrote:

>> Well, apart from the XARGS_LIMIT thing, which if needed would imply that
>> make check has never worked on mingw.
>
> It could have worked when there were fewer tests.

The filenames being passed were absolute before and are relative now,
so I expect current arg lists to be shorter than they were previously.

Message #44 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 15933 <at> debbugs.gnu.org
Subject: Re: bug#15933: make check not working
Date: Wed, 20 Nov 2013 19:36:05 -0500

Andy Moreton wrote:

> The compile-main targets in test/automated/Makefile.in was originally
> copied from lisp/Makefile.in (according to the comments). It seems that
> it has not been updated to match the recent changes for msys path
> translation and relative paths.

I don't believe this analysis is correct.

Assuming Eli's analysis was correct, this should be fixed now.

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15933: make check not working
Date: Thu, 21 Nov 2013 00:56:17 +0000

On Thu 21 Nov 2013, Glenn Morris wrote:

> Andy Moreton wrote:
>
>> The compile-main targets in test/automated/Makefile.in was originally
>> copied from lisp/Makefile.in (according to the comments). It seems that
>> it has not been updated to match the recent changes for msys path
>> translation and relative paths.
>
> I don't believe this analysis is correct.
>
> Assuming Eli's analysis was correct, this should be fixed now.

As ever, Eli is correct. The updated tests now run for me on mingw.
The file notify tests still abort, but that is a separate issue noted on
the devel list.

    AndyM

Message #52 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Thu, 21 Nov 2013 05:46:27 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 15933 <at> debbugs.gnu.org,  andrewjmoreton <at> gmail.com
> Date: Wed, 20 Nov 2013 19:33:30 -0500
> 
> So in particular "emacs -L :/foo" would result in command-line-args
> containing ("-L" ";/foo")?

Almost: MSYS also replaces / with its Windows mapping (which depends
on where is the MSYS tree's root).  In my case, this gives

    ("-L" ";D:\usr\MSYS\foo")

Message #55 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 15933 <at> debbugs.gnu.org
Subject: Re: bug#15933: make check not working
Date: Sun, 24 Nov 2013 15:36:40 +0100

Andy Moreton <andrewjmoreton <at> gmail.com> writes:

> The updated tests now run for me on mingw.  The file notify tests
> still abort, but that is a separate issue noted on the devel list.

Could you, please, point me to that message? I can't find it.

>     AndyM

Best regards, Michael.

Message #58 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15933: make check not working
Date: Mon, 25 Nov 2013 11:48:10 +0000

On Sun 24 Nov 2013, Michael Albinus wrote:

> Andy Moreton <andrewjmoreton <at> gmail.com> writes:
>
>> The updated tests now run for me on mingw.  The file notify tests
>> still abort, but that is a separate issue noted on the devel list.
>
> Could you, please, point me to that message? I can't find it.
>
>>     AndyM
>
> Best regards, Michael.

The thread was about changes to bool vector stuff:
http://permalink.gmane.org/gmane.emacs.devel/165398

The log from my most recent run of 'make check' ended with:

--[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'
--[make check]----------------------------------------------

I haven't got any further looking into this as the machine I was using
died last week...

    AndyM

Message #61 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 15933 <at> debbugs.gnu.org
Subject: Re: bug#15933: make check not working
Date: Mon, 25 Nov 2013 13:31:03 +0100

Andy Moreton <andrewjmoreton <at> gmail.com> writes:

> The log from my most recent run of 'make check' ended with:
>
> --[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'
> --[make check]----------------------------------------------

Thanks. However, I haven't seen this information somewhere else yet. I
believe, it is worth another bug report.

> I haven't got any further looking into this as the machine I was using
> died last week...

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).

>     AndyM

Best regards, Michael.

Message #64 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Mon, 25 Nov 2013 19:15:11 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Mon, 25 Nov 2013 13:31:03 +0100
> Cc: 15933 <at> debbugs.gnu.org
> 
> Andy Moreton <andrewjmoreton <at> gmail.com> writes:
> 
> > The log from my most recent run of 'make check' ended with:
> >
> > --[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'
> > --[make check]----------------------------------------------
> 
> Thanks. However, I haven't seen this information somewhere else yet. I
> believe, it is worth another bug report.
> 
> > I haven't got any further looking into this as the machine I was using
> > died last week...
> 
> 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.")

How is this supposed to work?  null-device is not a directory.  I'm
guessing that "Error 5" is "access denied" emitted by Windows because
some file primitive tries to treat null-device as if it were a
directory.

If you could explain what you intended to achieve by that, perhaps I
could suggest a solution.  (Does "/ssh::/tmp" assume there's an sshd
running on the machine that runs the tests?)

Message #67 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Mon, 25 Nov 2013 20:24:28 +0100

Eli Zaretskii <eliz <at> 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. No remote access.

file-notify-test02-events-remote would be skipped, like
file-notify-test00-availability-remote and
file-notify-test01-add-watch-remote above.

> How is this supposed to work?  null-device is not a directory.  I'm
> guessing that "Error 5" is "access denied" emitted by Windows because
> some file primitive tries to treat null-device as if it were a
> directory.

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

> If you could explain what you intended to achieve by that, perhaps I
> could suggest a solution.  (Does "/ssh::/tmp" assume there's an sshd
> running on the machine that runs the tests?)

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

Best regards, Michael.

Message #70 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Mon, 25 Nov 2013 23:08:25 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: andrewjmoreton <at> gmail.com,  15933 <at> debbugs.gnu.org
> Date: Mon, 25 Nov 2013 20:24:28 +0100
> 
> Eli Zaretskii <eliz <at> 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.

Message #73 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: andrewjmoreton <at> gmail.com, 15933 <at> debbugs.gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#15933: make check not working
Date: Mon, 25 Nov 2013 16:30:06 -0500

Before spending too much time on this, could I encourage someone to make
a new bug report based on the current trunk, if this still happens there?

Because the "separate issue noted on the devel list" refered to was a
different issue that has since been fixed (and even that was not the
actual subject of this bug report).

Message #76 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, andrewjmoreton <at> gmail.com,
 15933 <at> debbugs.gnu.org
Subject: Re: bug#15933: make check not working
Date: Tue, 26 Nov 2013 14:08:42 +0100

Glenn Morris <rgm <at> gnu.org> writes:

> Before spending too much time on this, could I encourage someone to make
> a new bug report based on the current trunk, if this still happens there?

Nobody did yet, but I've hijacked an MS Windows machine, and I'll run
file-notify and tramp tests there. (Found already the first Tramp bugs
to be corrected :-)

Best regards, Michael.

Message #79 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15933 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15933: make check not working
Date: Tue, 26 Nov 2013 14:13:38 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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.

It was the next test case in queue (that's why I've numbered the test
case names).

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

Don't know yet.

>> null-device is an indicator NOT to try remote test cases.
>
> Why not nil?

`file-remote-p' expects a string.

>> "/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.

tramp-tests.el accepts environment variable $TRAMP_TEST_TEMPORARY_FILE_DIRECTORY,
overriding the default. Maybe I shall add a similar mechanism in
file-notify-tests.el.

Best regards, Michael.

Message #82 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 15933 <at> debbugs.gnu.org
Subject: Re: bug#15933: make check not working
Date: Thu, 28 Nov 2013 21:46:21 +0200

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Mon, 25 Nov 2013 11:48:10 +0000
> 
> The log from my most recent run of 'make check' ended with:
> 
> --[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'
> --[make check]----------------------------------------------
> 
> I haven't got any further looking into this as the machine I was using
> died last week...

Please try again when you can.  This was actually a crash (didn't you
see a popup asking whether to debug or close the application?), due to
the fact that w32 file notifications, as implemented, did not support
batch mode of operation -- they relied on machinery that is only up
and running in interactive sessions.  This should be fixed as of trunk
revision 115269.

The other part of the puzzle was that auto-revert-stop-on-user-input
should be bound to nil when running the rest of the tests in
file-notify-tests.el, but Michael already fixed that part earlier
today.

There are still a few (6 on one machine, 3 on another) tests that fail
on Windows, but there are no more crashes.

Message #85 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrewjmoreton <at> gmail.com
Cc: 15933 <at> debbugs.gnu.org
Subject: Re: bug#15933: make check not working
Date: Thu, 28 Nov 2013 22:28:24 +0200

> Date: Thu, 28 Nov 2013 21:46:21 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 15933 <at> debbugs.gnu.org
> 
> There are still a few (6 on one machine, 3 on another) tests that fail
> on Windows, but there are no more crashes.

Actually, all but 2 of these failures happen on GNU/Linux as well, so
that's not a Windows-specific issue.

The 2 that fail only on Windows are almost certainly problems with the
test setup and/or data, I will take a look soon.

Message #88 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15933: make check not working
Date: Fri, 29 Nov 2013 10:22:50 +0000

On Thu 28 Nov 2013, Eli Zaretskii wrote:

> Please try again when you can.  This was actually a crash (didn't you
> see a popup asking whether to debug or close the application?), due to
> the fact that w32 file notifications, as implemented, did not support
> batch mode of operation -- they relied on machinery that is only up
> and running in interactive sessions.  This should be fixed as of trunk
> revision 115269.

Thanks for looking at this. The file-notify tests that were previously
crashing emacs now complete successfully with r115282.

> The other part of the puzzle was that auto-revert-stop-on-user-input
> should be bound to nil when running the rest of the tests in
> file-notify-tests.el, but Michael already fixed that part earlier
> today.
>
> There are still a few (6 on one machine, 3 on another) tests that fail
> on Windows, but there are no more crashes.

I also see one test that displays an interactive prompt, which does not
make much sense in batch mode:

--[make check]------------------------------------------------
  skipped  514/521  vc-bzr-test-bug9781
  skipped  515/521  vc-bzr-test-faulty-bzr-autoloads
Loading cc-langs...
Buffer "test.c" has a running process; kill it? (yes or no)
Test warning-predicate-function-gcc backtrace:
  (if (unwind-protect (setq value-78801 (apply fn-78799 args-78800)) (
  (let (form-description-78803) (if (unwind-protect (setq value-78801
  (let ((value-78801 (quote ert-form-evaluation-aborted-78802))) (let
  (let ((fn-78799 (function eq)) (args-78800 (list (quote flymake-warn
  (lambda nil (let ((value-78797 (cl-gensym "ert-form-evaluation-abort
  #[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\317\320%DC
  funcall(#[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\31
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  #[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\316%DC\2
  funcall(#[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\
  ert-run-test([cl-struct-ert-test warning-predicate-function-gcc "Tes
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test a
  ert-run-tests(t #[385 "\306\307\"\203D\211\211G\310U\203\211@\20
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  command-line-1(("-L" ";../../../test/automated" "-l" "../../../test/
  command-line()
  normal-top-level()
Test warning-predicate-function-gcc condition:
    (ert-test-failed
     ((should
       (eq 'flymake-warnline
            (flymake-tests--current-face "test.c" ...)))
      :form
      (eq flymake-warnline nil)
      :value nil))
   FAILED  516/521  warning-predicate-function-gcc
--[make check]------------------------------------------------

Message #91 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrewjmoreton <at> gmail.com
Cc: 15933 <at> debbugs.gnu.org
Subject: Re: bug#15933: make check not working
Date: Fri, 29 Nov 2013 12:36:58 +0200

> Date: Thu, 28 Nov 2013 22:28:24 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 15933 <at> debbugs.gnu.org
> 
> > Date: Thu, 28 Nov 2013 21:46:21 +0200
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: 15933 <at> debbugs.gnu.org
> > 
> > There are still a few (6 on one machine, 3 on another) tests that fail
> > on Windows, but there are no more crashes.
> 
> Actually, all but 2 of these failures happen on GNU/Linux as well, so
> that's not a Windows-specific issue.
> 
> The 2 that fail only on Windows are almost certainly problems with the
> test setup and/or data, I will take a look soon.

Actually, 3 of the failures seem to be Windows-specific.  I fixed 2 of
them; the 3rd one, in icalendar-tests.el, seems to be something about
time-zone data in icalendar events, which is beyond my pay-grade.

Message #94 received at 15933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 15933 <at> debbugs.gnu.org
Subject: Re: bug#15933: make check not working
Date: Fri, 29 Nov 2013 13:16:10 +0200

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Fri, 29 Nov 2013 10:22:50 +0000
> 
> On Thu 28 Nov 2013, Eli Zaretskii wrote:
> 
> > Please try again when you can.  This was actually a crash (didn't you
> > see a popup asking whether to debug or close the application?), due to
> > the fact that w32 file notifications, as implemented, did not support
> > batch mode of operation -- they relied on machinery that is only up
> > and running in interactive sessions.  This should be fixed as of trunk
> > revision 115269.
> 
> Thanks for looking at this. The file-notify tests that were previously
> crashing emacs now complete successfully with r115282.

Good, thanks for testing.

> > The other part of the puzzle was that auto-revert-stop-on-user-input
> > should be bound to nil when running the rest of the tests in
> > file-notify-tests.el, but Michael already fixed that part earlier
> > today.
> >
> > There are still a few (6 on one machine, 3 on another) tests that fail
> > on Windows, but there are no more crashes.
> 
> I also see one test that displays an interactive prompt, which does not
> make much sense in batch mode:

Yes, I see that as well.  But these flymake tests fail on GNU/Linux as
well, so "Someone Else" should look into this.

Previous Next

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