>>> Hannu Koivisto <azure@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>> Second, I found a bug in the semantic-analyzer today. If you had a
>> superclass that could not be found, an error would prevent the entire
>> chain from providing smart completions. With this fixed, you can at
>> least get some completions instead of no completions. This is likely
>> the "I can't reproduce the problem with a small example" problem that
>> was floating on the list earlier this summer.
>
>I suspect you refer to the problem I tried to report but failed :)
>So I thought I'd start testing this latest version but so far I
>haven't been able to build it.
>
>On Linux with Emacs 21.4. build stops with:
>
>-------------------------------------------------------------------
>Wrote /home/hannuko/share/emacs21/site-lisp/cedet/contrib/eassist.elc
>While compiling toplevel forms in file /home/hannuko/share/emacs21/site-lisp/cedet/contrib/wisent-ruby.el:
> !! error (("Invalid escape character syntax"))
>-------------------------------------------------------------------
Ah, Daniel had some bad regexps that weren't quoted in properly.
Emacs 22 allows those quoted strings to work. I checked in a fix for
that.
This shouldn't affect the parts you are working with though, that
compiles last, and is not needed for C++ completion.
>On Windows with Emacs 22.0.990.1 (Emacs-W32) and build started from
>Cygwin shell (zsh) using Cygwin make (sorry about wrapped lines):
>
>-------------------------------------------------------------------
>Wrote c:/documents and settings/hannuko/share/emacs22/site-lisp/cedet/ede/ede-lo
>addefs.el
>for loadpath in . ../common/ ../speedbar/ ../eieio/; do \
> echo "(add-to-list 'load-path \"$loadpath\")" >> init-compile-script;
> \
> done;
>"emacs" -batch --no-site-file -l init-compile-script -f batch-byte-compile ede-l
>oad.el
>Wrote c:/documents and settings/hannuko/share/emacs22/site-lisp/cedet/ede/ede-lo
>ad.elc
>for loadpath in . ../common/ ../speedbar/ ../eieio/; do \
> echo "(add-to-list 'load-path \"$loadpath\")" >> ede-compile-script;
>\
> done;
>"emacs" -batch --no-site-file -l ede-compile-script -f batch-byte-compile projec
>t-am.el ede.el ede-pmake.el ede-pconf.el ede-proj.el ede-dired.el ede-proj-elisp
>.el ede-proj-misc.el ede-proj-obj.el ede-proj-prog.el ede-proj-archive.el ede-pr
>oj-shared.el ede-proj-info.el ede-proj-scheme.el ede-proj-aux.el ede-proj-comp.e
>l ede-source.el ede-util.el ede-system.el ede-speedbar.el ede-simple.el ede-cpp-
>root.el
>
>In toplevel form:
>project-am.el:44:4:Error: Cannot open load file: ede-speedbar
>
[ ... ]
It could be that ede-speedbar was somehow whacked during a
cvs-update. Deleting the file (if it is in cedet/ede) and doing
another cvs update ought to fix that up.
>-------------------------------------------------------------------
>
>Both ede-compile-script and init-compile-script contain
>
>-------------------------------------------------------------------
>(add-to-list 'load-path nil)
>(add-to-list 'load-path ".")
>(add-to-list 'load-path "../common/")
>(add-to-list 'load-path "../speedbar/")
>(add-to-list 'load-path "../eieio/")
>(setq debug-on-error t)
>-------------------------------------------------------------------
>
>*script files in common also have (add-to-list 'load-path nil) as
>their first lines. I wonder where that nil comes from. But a
>quick (setq load-path (cons nil load-path)) test seems to indicate
>that a nil entry doesn't break load-path traversal, so I can't see
>why it can't open those files...
Nil means to include the current working directory, which sort-of
obsoletes ".". The algorithm that builds that could use some work.
Eric
--
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org
|