Emacs/CEDET. Multiple projects and code completion

Question

I've setup emacs 23.1.50.1 with CEDET 1.0 and ECB 2.40 (heavily inspired by Alex Otts setup at http://github.com/alexott/emacs-configs/blob/master/rc/emacs-rc-cedet.el and his gentle introduction to Cedet ( http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html ), thanks Alex). It works quite well, but I need more understanding about how code-completion and symbol-references are handled when working with multiple projects.

I've created a simple ede project like this:

(ede-cpp-root-project "test"
                      :file "~/src/sw/anchor"
                      :include-path '("/Common")
                      :system-include-path '("~/include"))

When this project is loaded, will Semantic only look for completions in the various directories specified in the project configurations?

I followed http://mmmyddd.freeshell.net/blog/Computer/Emacs/usecscopesemanticdbbackend to use cscope as backend for semanticdb. I can run semanticdb-enable-cscope-in-buffer without emacs throwing any errors, but I have no idea if semantic uses my database. Can I add a reference to a cscope.out in my project-definition as well, to have more control over which files to search for references in my current context?

A couple of oddities:

When I try to open a new source file I get the error "apply: Searching for program: no such file or directory, global" and nothing happens. If I try to open it again, everything is fine.

When I try to load a project by pointing at the anchor file, I get this error: "if: Wrong type argument: class-p, ede-cpp-root"

Dour

For the "apply: Searching for program: no such file or directory, global" error, did you copy the part of Alex Ott's setup that used "(semanticdb-enable-gnu-global-databases ...)"? – Ejaculate

That I did, but I suspect I don't need it. The fact that it says "gnu global support", should have made my suspect the problem was there :). Thanks. – Dour

Answer 1

When you get errors in your configuration, the best thing to do is:

M-x toggle-debug-on-error RET

and get the stack trace which will point at the problem area. Often times that is helpful in identifying the configuration issue.

CEDET will try to associate every file with a single project, and all the commands that operate in that buffer will be restricted to the bounds of that project. For the CScope support, it too will use EDE to identify the root directory, and that will help find the cscope.out file, and that is related to both the completion and reference tools.

The exception, of course, is the system include path which is usually /usr/include or whatever. This is an augmentation to the default system include path which is calculated with the GCC support. In one of your C files you can do:

M-x semantic-c-describe-environment RET

and that should show what Semantic will try to use.

To double check if CScope is being used for code completion, you can check with:

M-x semanticdb-find-test-translate-path RET

and check the end of the list for some CScope thing.

Bitolj

Thanks Eric, both for the answer and the software. Those commands are indeed very useful. Currently, semantic-c-describe-environment doesn't say anything about cscope, and semanticdb-find-test-translate-path says: *#<semanticdb-table-cscope Cscope Search Table (0 tags)> – Dour

Right, the cscope support doesn't bother calculating the number of tags CScope knows about, and it isn't really part of the "project" since the internals are abstracted away, so the C environment doesn't know about it. – Bitolj