2010-10-20 13 views
8

Ho installato emacs 23.1.50.1 con CEDET 1.0 e ECB 2.40 (fortemente ispirato alla configurazione di Alex Otts allo http://github.com/alexott/emacs-configs/blob/master/rc/emacs-rc-cedet.el e alla sua gentile introduzione a Cedet (http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html), grazie Alex). Funziona abbastanza bene, ma ho bisogno di maggiori informazioni su come vengono gestiti il ​​completamento del codice e i riferimenti ai simboli quando si lavora con più progetti.Emacs/CEDET. Progetti multipli e completamento del codice

ho creato un progetto semplice ede in questo modo:

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

Quando questo progetto è caricato, sarà semantica guardare solo per completamenti nelle varie directory specificate nelle configurazioni di progetto?

Ho seguito http://mmmyddd.freeshell.net/blog/Computer/Emacs/usecscopesemanticdbbackend per utilizzare cscope come backend per semanticdb. Posso eseguire semanticdb-enable-cscope-in-buffer senza emacs che genera errori, ma non ho idea se semantica usi il mio database. Posso aggiungere un riferimento a un cscope.out nella mia definizione di progetto, per avere più controllo su quali file cercare nel mio contesto corrente?

Quando provo ad aprire un nuovo file sorgente ottengo l'errore "si applicano:: Ricerca di programmi: Nessun file o directory, globale"

Un paio di stranezze e non succede nulla. Se provo ad aprirlo di nuovo, va tutto bene.

Quando provo a caricare un progetto che punta al file di ancoraggio, ottengo questo errore: "se: tipo di argomento sbagliato: class-p, ede-cpp-root"

+0

Per "applicare: ricerca di un programma: nessun file o directory, globale" errore, hai copiato la parte della configurazione di Alex Ott che utilizzava "(semanticdb-enable-gnu-global-databases ...)"? – Dingo

+0

Che ho fatto, ma ho il sospetto che non ne ho bisogno. Il fatto che dice "supporto globale di gnu" avrebbe dovuto far sospettare che il problema fosse lì :). Grazie. – anr78

risposta

5

Quando si arriva errori nel la configurazione, la cosa migliore da fare è:

M-x toggle-debug-on-error RET 

e ottenere l'analisi dello stack che puntare al settore problematico. Spesso è utile per identificare il problema di configurazione.

CEDET proverà ad associare ogni file a un singolo progetto e tutti i comandi che operano in quel buffer saranno limitati ai limiti di quel progetto. Per il supporto di CScope, anch'esso utilizzerà EDE per identificare la directory root, e questo aiuterà a trovare il file cscope.out, e questo è correlato sia agli strumenti di completamento che di riferimento.

L'eccezione, ovviamente, è il percorso di inclusione del sistema che di solito è/usr/include o qualsiasi altra cosa. Questo è un aumento del percorso di sistema predefinito che viene calcolato con il supporto GCC. In uno dei tuoi file C puoi fare:

M-x semantic-c-describe-environment RET 

e che dovrebbe mostrare ciò che Semantic proverà ad usare.

Per fare doppio controllo se Cscope viene utilizzato per il completamento del codice, è possibile controllare con:

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

e controllare la fine della lista per qualche cosa Cscope.

+0

Grazie Eric, sia per la risposta che per il software. Questi comandi sono davvero molto utili.Attualmente, semantic-c-describe-environment non dice nulla su cscope, e semanticdb-find-test-translate-path dice: * # anr78

+0

Giusto, il cscope il supporto non si preoccupa di calcolare il numero di tag che CScope conosce e non fa realmente parte del "progetto" dal momento che gli interni sono astratti, quindi l'ambiente C non ne sa nulla. – Eric