"Eric M. Ludlam" <eric@...> writes:
> Hi again, I've responded to various other related messages, but not to
> this one yet. The inode thing above I hope is taken care of now.
With the latest changes in CVS, cedet-build works now on Windows.
>>- I can see that tests fails, but cedet-utest continues
>> nonetheless. When the utest finishes, I only see the result of the
>> last test (cogre). How can I view a complete log of all tests (the
>> messages buffer doesn't seem to report all errors I see during the
> There was a bug in the analyzer tests that caused it not to stop
> testing if there was a failure. I fixed this in CVS.
I'm afraid it's still not stopping. I can just see the result because
it's waiting for a keypress on the "throw-on-input" test.
>>- the 'sleep' test fails (obviously, since there's no sleep binary).
> I haven't liked this test for a while. I think I'll disable it.
Well, the test is working with cygwin. I guess almost all users running
Emacs in Windows will have some kind of Unix environment installed, so
I'd say this is not really a serious issue (the same applies for the
symref-grep test, which also depends on external binaries like find,
grep, xargs, and a shell).
>>- On first run, pulse interactive test stalls Emacs for some seconds and
>> doesn't seem to do anything. If I run it again, it often works as
> Can you try using M-x toggle-debug-on-quit to see what it's thinking
> Alternately, do you see pulse doing that during regular use, such as
> when using various functions that pulse tags, like the jump routines?
I tracked down this issue, and it's actually cedet-files-utest that's
stalling Emacs, not the pulsing. It just seemed that way on first sight
since the stalling apparently delayed the redisplay.
The problem is calling file-directory-p with a path that begins with two
slashes, in this case "//windows/proj/foo.java". This stalls the Emacs
Windows port for about 10-15 seconds, while under GNU/Linux such paths
are no problem at all. I will file a bug report on this issue.
>>Debugger entered--Lisp error: (void-variable semanticdb-current-table)
> [ ... ]
> This sounds like semanticdb Lisp code wasn't even loaded in, which
> seems a bit odd. Do you enable semantic minimum features?
No, I was just loading common/cedet.el. Sorry, I wasn't aware that you
had to enable the minimum features, too.
With this, everything was working except the symref-grep test. The
reason for this is not the call to grep, but the parsing of the output,
since filenames in Windows usually begin with something like "c:". The
attached patch fixes this for me, and now all unit tests run without
--- semantic-symref-grep.el 2008-12-13 18:23:49.000000000 +0100
+++ /Users/david/semantic-symref-grep.el 2009-03-06 00:06:47.000000000 +0100
@@ -131,7 +131,7 @@
(when (re-search-forward "^\\([^\n]+\\)$" nil t)
- (when (re-search-forward "^\\([^:\n]+\\):\\([0-9]+\\):" nil t)
+ (when (re-search-forward "^\\(?:[a-zA-Z]:\\)?\\([^:\n]+\\):\\([0-9]+\\):" nil t)
(cons (string-to-number (match-string 2))