bug#15933: make check not working

bug#15933: make check not working

[Andy Moreton]

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 \

bug#15933: make check not working

[Glenn Morris]

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?

bug#15933: make check not working

[Glenn Morris]

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.

bug#15933: make check not working

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 20 Nov 2013 13:49:53 -0500
> Cc: 15933@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 ';'.)

bug#15933: make check not working

[Glenn Morris]

Eli Zaretskii wrote:

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

Amazingly, not something I was aware of.

bug#15933: make check not working

[Glenn Morris]

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?

bug#15933: make check not working

[Andy Moreton]

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

bug#15933: make check not working

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 20 Nov 2013 13:56:40 -0500
> Cc: 15933@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.

bug#15933: make check not working

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: andrewjmoreton@gmail.com,  15933@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.

bug#15933: make check not working

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 15933@debbugs.gnu.org,  andrewjmoreton@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.

bug#15933: make check not working

[Eli Zaretskii]

> Date: Wed, 20 Nov 2013 23:38:35 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 15933@debbugs.gnu.org, andrewjmoreton@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.

bug#15933: make check not working

[Glenn Morris]

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")?

bug#15933: make check not working

[Glenn Morris]

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.

bug#15933: make check not working

[Glenn Morris]

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.

bug#15933: make check not working

[Andy Moreton]

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

bug#15933: make check not working

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 15933@debbugs.gnu.org,  andrewjmoreton@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")

bug#15933: make check not working

[Michael Albinus]

Andy Moreton <andrewjmoreton@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.

bug#15933: make check not working

[Andy Moreton]

On Sun 24 Nov 2013, Michael Albinus wrote:

> Andy Moreton <andrewjmoreton@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

bug#15933: make check not working

[Michael Albinus]

Andy Moreton <andrewjmoreton@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.

bug#15933: make check not working

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Mon, 25 Nov 2013 13:31:03 +0100
> Cc: 15933@debbugs.gnu.org
> 
> Andy Moreton <andrewjmoreton@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?)

bug#15933: make check not working

[Michael Albinus]

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

bug#15933: make check not working

[Eli Zaretskii]

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

bug#15933: make check not working

[Glenn Morris]

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

bug#15933: make check not working

[Michael Albinus]

Glenn Morris <rgm@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.

bug#15933: make check not working

[Michael Albinus]

Eli Zaretskii <eliz@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.

bug#15933: make check not working

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@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.

bug#15933: make check not working

[Eli Zaretskii]

> Date: Thu, 28 Nov 2013 21:46:21 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 15933@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.

bug#15933: make check not working

[Andy Moreton]

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

bug#15933: make check not working

[Eli Zaretskii]

> Date: Thu, 28 Nov 2013 22:28:24 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 15933@debbugs.gnu.org
> 
> > Date: Thu, 28 Nov 2013 21:46:21 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 15933@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.

bug#15933: make check not working

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@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.