Emacs/CEDET. Wielokrotne projekty i realizacja kodu

Question

Mam skonfigurowany emacs 23.1.50.1 z CEDET 1.0 i ECB 2.40 (mocno zainspirowany instalacją Alexa Ottsa pod numerem http://github.com/alexott/emacs-configs/blob/master/rc/emacs-rc-cedet.el i jego łagodnym wstępem do Cedeta (http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html), dzięki Alex). Działa całkiem dobrze, ale potrzebuję więcej zrozumienia, w jaki sposób obsługa kodu i odniesienia do symboli są obsługiwane podczas pracy z wieloma projektami.

stworzyłem prosty projekt Ede takiego:

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

Kiedy ten projekt jest załadowany, będzie semantyczny patrzeć tylko dla uzupełnień w różnych katalogach określonych w konfiguracji projektu?

Śledziłem http://mmmyddd.freeshell.net/blog/Computer/Emacs/usecscopesemanticdbbackend, aby użyć cscope jako zaplecza dla semanticdb. Mogę uruchomić semanticdb-enable-cscope-in-buffer bez emacsa wyrzucającego jakiekolwiek błędy, ale nie mam pojęcia, czy semantyczna używa mojej bazy danych. Czy mogę dodać odniesienie do cscope.out również w mojej definicji projektu, aby mieć większą kontrolę nad plikami, które będą wyszukiwać odniesienia w moim bieżącym kontekście?

Kilka osobliwości:

Kiedy próbuję otworzyć nowy plik źródłowy pojawia się błąd „stosuje się: Poszukuję programu: Nie ma takiego pliku lub katalogu, globalny” i nic się nie dzieje. Jeśli spróbuję otworzyć go ponownie, wszystko jest w porządku.

Kiedy próbuję załadować projekt wskazując na plik kotwicy, otrzymuję ten błąd: „jeżeli: niewłaściwy typ argumentu: klasy P, Ede-CPP-root”

Answer 1

Gdy pojawi się błędy w konfiguracja, najlepiej zrobić:

M-x toggle-debug-on-error RET 

i uzyskać ślad stosu, który wskaże obszar problemowy. Często pomaga to w identyfikacji problemu z konfiguracją.

CEDET spróbuje powiązać każdy plik z pojedynczym projektem, a wszystkie polecenia działające w tym buforze będą ograniczone do granic tego projektu. W przypadku obsługi CScope będzie również używał EDE do identyfikowania katalogu głównego, a to pomoże znaleźć plik cscope.out i dotyczy zarówno narzędzi uzupełniających, jak i referencyjnych.

Wyjątek stanowi oczywiście ścieżka zawierająca zwykle/usr/include lub cokolwiek innego. Jest to rozszerzenie do domyślnego systemu obejmuje ścieżkę, która jest obliczana przy pomocy GCC. W jednym z plików C możesz:

M-x semantic-c-describe-environment RET 

, który powinien pokazać, z czego Semanton spróbuje skorzystać.

dokładnie sprawdzić czy Cscope jest używany do uzupełniania kodu, można skontaktować się z:

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

i sprawdź koniec listy jakiegoś Cscope rzeczy.