* bug#15933: make check not working
@ 2013-11-20 12:55 Andy Moreton
2013-11-20 18:49 ` Glenn Morris
0 siblings, 1 reply; 30+ messages in thread
From: Andy Moreton @ 2013-11-20 12:55 UTC (permalink / raw
To: 15933
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 \
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 12:55 bug#15933: make check not working Andy Moreton
@ 2013-11-20 18:49 ` Glenn Morris
2013-11-20 18:56 ` Glenn Morris
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: Glenn Morris @ 2013-11-20 18:49 UTC (permalink / raw
To: Andy Moreton; +Cc: 15933
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?
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 18:49 ` Glenn Morris
@ 2013-11-20 18:56 ` Glenn Morris
2013-11-20 21:33 ` Eli Zaretskii
2013-11-20 19:04 ` Eli Zaretskii
2013-11-20 20:34 ` Andy Moreton
2 siblings, 1 reply; 30+ messages in thread
From: Glenn Morris @ 2013-11-20 18:56 UTC (permalink / raw
To: Andy Moreton; +Cc: 15933
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 18:49 ` Glenn Morris
2013-11-20 18:56 ` Glenn Morris
@ 2013-11-20 19:04 ` Eli Zaretskii
2013-11-20 19:10 ` Glenn Morris
2013-11-20 20:34 ` Andy Moreton
2 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-20 19:04 UTC (permalink / raw
To: Glenn Morris; +Cc: 15933, andrewjmoreton
> 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 ';'.)
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 19:04 ` Eli Zaretskii
@ 2013-11-20 19:10 ` Glenn Morris
2013-11-20 19:14 ` Glenn Morris
2013-11-20 21:34 ` Eli Zaretskii
0 siblings, 2 replies; 30+ messages in thread
From: Glenn Morris @ 2013-11-20 19:10 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 15933, andrewjmoreton
Eli Zaretskii wrote:
> since the MSYS Bash will automatically convert ':' into ';'.)
Amazingly, not something I was aware of.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 19:10 ` Glenn Morris
@ 2013-11-20 19:14 ` Glenn Morris
2013-11-20 21:38 ` Eli Zaretskii
2013-11-20 21:34 ` Eli Zaretskii
1 sibling, 1 reply; 30+ messages in thread
From: Glenn Morris @ 2013-11-20 19:14 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 15933, andrewjmoreton
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?
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 18:49 ` Glenn Morris
2013-11-20 18:56 ` Glenn Morris
2013-11-20 19:04 ` Eli Zaretskii
@ 2013-11-20 20:34 ` Andy Moreton
2013-11-21 0:36 ` Glenn Morris
2 siblings, 1 reply; 30+ messages in thread
From: Andy Moreton @ 2013-11-20 20:34 UTC (permalink / raw
To: 15933
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 18:56 ` Glenn Morris
@ 2013-11-20 21:33 ` Eli Zaretskii
2013-11-21 0:34 ` Glenn Morris
0 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-20 21:33 UTC (permalink / raw
To: Glenn Morris; +Cc: 15933, andrewjmoreton
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 19:10 ` Glenn Morris
2013-11-20 19:14 ` Glenn Morris
@ 2013-11-20 21:34 ` Eli Zaretskii
1 sibling, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-20 21:34 UTC (permalink / raw
To: Glenn Morris; +Cc: 15933, andrewjmoreton
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 19:14 ` Glenn Morris
@ 2013-11-20 21:38 ` Eli Zaretskii
2013-11-20 21:53 ` Eli Zaretskii
2013-11-21 0:33 ` Glenn Morris
0 siblings, 2 replies; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-20 21:38 UTC (permalink / raw
To: Glenn Morris; +Cc: 15933, andrewjmoreton
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 21:38 ` Eli Zaretskii
@ 2013-11-20 21:53 ` Eli Zaretskii
2013-11-21 0:33 ` Glenn Morris
1 sibling, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-20 21:53 UTC (permalink / raw
To: rgm; +Cc: 15933, andrewjmoreton
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 21:38 ` Eli Zaretskii
2013-11-20 21:53 ` Eli Zaretskii
@ 2013-11-21 0:33 ` Glenn Morris
2013-11-21 3:46 ` Eli Zaretskii
1 sibling, 1 reply; 30+ messages in thread
From: Glenn Morris @ 2013-11-21 0:33 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 15933, andrewjmoreton
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")?
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 21:33 ` Eli Zaretskii
@ 2013-11-21 0:34 ` Glenn Morris
0 siblings, 0 replies; 30+ messages in thread
From: Glenn Morris @ 2013-11-21 0:34 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 15933, andrewjmoreton
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-20 20:34 ` Andy Moreton
@ 2013-11-21 0:36 ` Glenn Morris
2013-11-21 0:56 ` Andy Moreton
0 siblings, 1 reply; 30+ messages in thread
From: Glenn Morris @ 2013-11-21 0:36 UTC (permalink / raw
To: Andy Moreton; +Cc: 15933
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-21 0:36 ` Glenn Morris
@ 2013-11-21 0:56 ` Andy Moreton
2013-11-24 14:36 ` Michael Albinus
0 siblings, 1 reply; 30+ messages in thread
From: Andy Moreton @ 2013-11-21 0:56 UTC (permalink / raw
To: 15933
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-21 0:33 ` Glenn Morris
@ 2013-11-21 3:46 ` Eli Zaretskii
0 siblings, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-21 3:46 UTC (permalink / raw
To: Glenn Morris; +Cc: 15933, andrewjmoreton
> 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")
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-21 0:56 ` Andy Moreton
@ 2013-11-24 14:36 ` Michael Albinus
2013-11-25 11:48 ` Andy Moreton
0 siblings, 1 reply; 30+ messages in thread
From: Michael Albinus @ 2013-11-24 14:36 UTC (permalink / raw
To: Andy Moreton; +Cc: 15933
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-24 14:36 ` Michael Albinus
@ 2013-11-25 11:48 ` Andy Moreton
2013-11-25 12:31 ` Michael Albinus
2013-11-28 19:46 ` Eli Zaretskii
0 siblings, 2 replies; 30+ messages in thread
From: Andy Moreton @ 2013-11-25 11:48 UTC (permalink / raw
To: 15933
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-25 11:48 ` Andy Moreton
@ 2013-11-25 12:31 ` Michael Albinus
2013-11-25 17:15 ` Eli Zaretskii
2013-11-28 19:46 ` Eli Zaretskii
1 sibling, 1 reply; 30+ messages in thread
From: Michael Albinus @ 2013-11-25 12:31 UTC (permalink / raw
To: Andy Moreton; +Cc: 15933
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-25 12:31 ` Michael Albinus
@ 2013-11-25 17:15 ` Eli Zaretskii
2013-11-25 19:24 ` Michael Albinus
0 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-25 17:15 UTC (permalink / raw
To: Michael Albinus; +Cc: 15933, andrewjmoreton
> 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?)
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-25 17:15 ` Eli Zaretskii
@ 2013-11-25 19:24 ` Michael Albinus
2013-11-25 21:08 ` Eli Zaretskii
0 siblings, 1 reply; 30+ messages in thread
From: Michael Albinus @ 2013-11-25 19:24 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 15933, andrewjmoreton
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-25 19:24 ` Michael Albinus
@ 2013-11-25 21:08 ` Eli Zaretskii
2013-11-25 21:30 ` Glenn Morris
2013-11-26 13:13 ` Michael Albinus
0 siblings, 2 replies; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-25 21:08 UTC (permalink / raw
To: Michael Albinus; +Cc: 15933, andrewjmoreton
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-25 21:08 ` Eli Zaretskii
@ 2013-11-25 21:30 ` Glenn Morris
2013-11-26 13:08 ` Michael Albinus
2013-11-26 13:13 ` Michael Albinus
1 sibling, 1 reply; 30+ messages in thread
From: Glenn Morris @ 2013-11-25 21:30 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Michael Albinus, 15933, andrewjmoreton
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).
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-25 21:30 ` Glenn Morris
@ 2013-11-26 13:08 ` Michael Albinus
0 siblings, 0 replies; 30+ messages in thread
From: Michael Albinus @ 2013-11-26 13:08 UTC (permalink / raw
To: Glenn Morris; +Cc: andrewjmoreton, 15933
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-25 21:08 ` Eli Zaretskii
2013-11-25 21:30 ` Glenn Morris
@ 2013-11-26 13:13 ` Michael Albinus
1 sibling, 0 replies; 30+ messages in thread
From: Michael Albinus @ 2013-11-26 13:13 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 15933, andrewjmoreton
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-25 11:48 ` Andy Moreton
2013-11-25 12:31 ` Michael Albinus
@ 2013-11-28 19:46 ` Eli Zaretskii
2013-11-28 20:28 ` Eli Zaretskii
2013-11-29 10:22 ` Andy Moreton
1 sibling, 2 replies; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-28 19:46 UTC (permalink / raw
To: Andy Moreton; +Cc: 15933
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-28 19:46 ` Eli Zaretskii
@ 2013-11-28 20:28 ` Eli Zaretskii
2013-11-29 10:36 ` Eli Zaretskii
2013-11-29 10:22 ` Andy Moreton
1 sibling, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-28 20:28 UTC (permalink / raw
To: andrewjmoreton; +Cc: 15933
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-28 19:46 ` Eli Zaretskii
2013-11-28 20:28 ` Eli Zaretskii
@ 2013-11-29 10:22 ` Andy Moreton
2013-11-29 11:16 ` Eli Zaretskii
1 sibling, 1 reply; 30+ messages in thread
From: Andy Moreton @ 2013-11-29 10:22 UTC (permalink / raw
To: 15933
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]------------------------------------------------
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-28 20:28 ` Eli Zaretskii
@ 2013-11-29 10:36 ` Eli Zaretskii
0 siblings, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-29 10:36 UTC (permalink / raw
To: andrewjmoreton; +Cc: 15933
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#15933: make check not working
2013-11-29 10:22 ` Andy Moreton
@ 2013-11-29 11:16 ` Eli Zaretskii
0 siblings, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2013-11-29 11:16 UTC (permalink / raw
To: Andy Moreton; +Cc: 15933
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2013-11-29 11:16 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-20 12:55 bug#15933: make check not working Andy Moreton
2013-11-20 18:49 ` Glenn Morris
2013-11-20 18:56 ` Glenn Morris
2013-11-20 21:33 ` Eli Zaretskii
2013-11-21 0:34 ` Glenn Morris
2013-11-20 19:04 ` Eli Zaretskii
2013-11-20 19:10 ` Glenn Morris
2013-11-20 19:14 ` Glenn Morris
2013-11-20 21:38 ` Eli Zaretskii
2013-11-20 21:53 ` Eli Zaretskii
2013-11-21 0:33 ` Glenn Morris
2013-11-21 3:46 ` Eli Zaretskii
2013-11-20 21:34 ` Eli Zaretskii
2013-11-20 20:34 ` Andy Moreton
2013-11-21 0:36 ` Glenn Morris
2013-11-21 0:56 ` Andy Moreton
2013-11-24 14:36 ` Michael Albinus
2013-11-25 11:48 ` Andy Moreton
2013-11-25 12:31 ` Michael Albinus
2013-11-25 17:15 ` Eli Zaretskii
2013-11-25 19:24 ` Michael Albinus
2013-11-25 21:08 ` Eli Zaretskii
2013-11-25 21:30 ` Glenn Morris
2013-11-26 13:08 ` Michael Albinus
2013-11-26 13:13 ` Michael Albinus
2013-11-28 19:46 ` Eli Zaretskii
2013-11-28 20:28 ` Eli Zaretskii
2013-11-29 10:36 ` Eli Zaretskii
2013-11-29 10:22 ` Andy Moreton
2013-11-29 11:16 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.