Re: [CEDET-devel] cedet-build.el fails on Windows

[David E. <de...@ra...>]

"Eric M. Ludlam" <er...@si...> 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
>>  test). 
>
> 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
>>  expected.
>
> Can you try using M-x toggle-debug-on-quit to see what it's thinking
> about?
>
> 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?
>
> (semantic-load-enable-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
problems. :-)

Regards,
David

--- 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)
 	   (match-string 1)))
 	(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))
 		 (match-string 1))
 	   ))))