2012-02-21 14 views
7

Próbowałem skonfigurować projekt EDE dla C++ (emacs24 + wbudowany CEDET) i zaczynam być zdesperowany, ponieważ nie mogę znaleźć sposobu, w jaki chcę pliki makefiles do wygenerowania. Jestem stosunkowo nowy w Emacs. postaram się opisać to, co robię:Jak utworzyć projekt EDE dla C++

Mam projekt zabawki ustawione tak:

main.cpp 
other/ 
    Utils.cpp 
    Utils.h 
    CGrabBuffer.cpp 
    CGrabBuffer.h 

main.cpp obejmuje zarówno .h jest wewnątrz katalogu „/” innej. Są to kroki śledzę założyć projekt EDE z tej prostej konfiguracji katalogu:

  • Otwórz main.cpp w emacs i zrobić M-x ede-new; typ: Make; imię i nazwisko: main-proj.
  • Otwórz jeden z plików w katalogu "other" i wykonaj M-x ede-new; typ: Make; imię i nazwisko: aux-proj.
  • Teraz nadszedł czas, aby utworzyć cele (które moim zdaniem są trzy w tym przypadku):
    • W buforze main.cpp: M-x ede-new-target; nazwa: main; typ: program. Po wyświetleniu monitu dodaję plik main.cpp do tego obiektu docelowego.
    • Powtarzam to samo dla dwóch pozostałych celów (Utils z Utils.cpp i Utils.h oraz CGrabBuffer z CGrabBuffer.cpp i CGrabBuffer.h). Tutaj znajduję pierwszy problem. Jakiego rodzaju muszą być te dwa cele? Chcę tylko, żeby generowały pliki .o.
  • Gdy to nastąpi, wpisuję M-x ede-customize-current-target do wszystkich trzech celów i dodaję niektóre zawierają ścieżek, niektóre biblioteki itd
  • Po tym, jeśli zadzwonię M-x ede-compile-project nie skompilować, ponieważ:
    • Najpierw próbuje skompilować plik main.cpp; Nie mam pojęcia, jak określić (przy użyciu EDE), że zarówno Utils.o, jak i CGrabBuffer.o są potrzebne przed przystąpieniem do budowania main.cpp.
    • Jeśli ręcznie zmieniam kolejność (edytując plik Makefile), nie można połączyć pliku main.cpp, ponieważ nie można znaleźć plików Utils.o i CGrabBuffer.o.

Jak widać, jestem w środku wielkiego bałaganu. Może nawet nie rozumiem, co oznacza "cel" w EDE. Przeczytałem także o istnieniu projektu ede-cpp-root, który musi zostać określony w pliku .emacs. Nie próbowałem tego, ponieważ myślę, że to tylko pomaga w semantykach. Nie generuje plików Makefiles, prawda? Czy mogę mieć (lub potrzebuję) projekt EDE zbudowany z Project.el's i to samo, używając ede-cpp-root-projektu dla semantyki? Czy jest to zbędne?

Przepraszam, jeśli źle zrozumiałem wiele rzeczy, ale jestem bardzo zdezorientowany, a bycie nowym dla emacs pogarsza sprawę. Dziękuję za cierpliwość!

EDYCJA: z niektórymi majsterkowania i odpowiedzi, które otrzymałem, udało mi się wymyślić wiele rzeczy, więc wielkie dzięki. To, czego wciąż nie rozumiem, to wykorzystanie projektu ede-cpp-root, który musi zostać określony w pliku .emacs. Czy jest to tylko dla semantyki C++? Czy zbędne jest posiadanie projektu z Okładkami Project.el ORAZ również linie elisp w .emacs?

+1

Używam CEDET, ale nie mogę zrozumieć wsparcia projektu dla mojego życia. Korzystam tylko z zewnętrznych plików Makefile i dodam typ projektu "prosty". –

+0

Tak, i to jest jedyna rzecz, która sprawia, że ​​trzymam się innych IDE, takich jak Eclipse, które pozwalają ci łatwiej zarządzać tymi rzeczami ... – pparescasellas

+0

Świetne pytanie. Spędziłem ostatnie kilka dni próbując zrobić coś takiego, ale gdy tylko wydaje mi się, że gdzieś się dostaję, wszystko się rozpada. Mówienie, że EDE jest słabo udokumentowane, jest niedopowiedzeniem. – Mike

Odpowiedz

7

EDE jest przeznaczony do obsługi wielu różnych projektów, zwykle typu, w którym system kompilacji został napisany poza Emacsem w innym narzędziu.

Typ projektu EDE, który tworzy pliki Makefile dla ciebie, może zrobić kilka rzeczy, ale musisz mieć podstawową wiedzę na temat systemów kompilacji, aby był pomocny i naprawdę potrzebujesz dostosować projekty, aby uzyskać wszystko jakakolwiek złożoność działa.

Ostatnio dodałem sekcję do podręcznika EDE, aby pomóc w podstawowych ustawieniach projektu, które automatycznie generują pliki Automake. Możesz sprawdzić tutorial tutaj:

http://www.randomsample.de/cedetdocs/ede/ede/Quick-Start.html

Te same kroki będą miały zastosowanie w przypadku projektów, które po prostu użyj make zamiast, ale upewnij projektów opartych często mają problemy z bibliotek dzielonych ze względu na dodatkową złożoność.

Odpowiedź Mike'a jest całkiem dobra, ale myślę, że można po prostu dodać pliki .h do tego samego celu, co źródła .cpp. Będzie je śledzić osobno.

Inną użyteczną sztuczką jest użycie całego projektu, kompilacji naciśnięcia klawisza (C-c. C), który używa dużego C, gdy zmienisz coś dużego. To zregeneruje pliki Makefile, ponownie uruchomi wszelkie potrzebne funkcje Automake i zacznie od początku.

EDIT: Potrzebujesz tylko jednego projektu EDE dla obszaru projektu. Projekt ede-cpp-root jest przydatny, gdy nie działa żaden inny automatyczny typ projektu. Stworzysz to w pliku .emacs, aby działały inne narzędzia wymagające definicji projektu, takie jak inteligentne uzupełnianie semantyczne i wyszukiwanie znaczników.

+1

Ten samouczek jest tym, czego szukałem kilka tygodni temu, kiedy zacząłem patrzeć na EDE po raz pierwszy, ale nie mogłem znaleźć czegoś podobnego. Jest to bardzo pomocne i nowi użytkownicy pokochają te informacje, więc bardzo dziękuję :) – pparescasellas

+0

Eric, czego brakuje w tym samouczku, to jakikolwiek opis, jak faktycznie używać typu 'ede-cpp-root-project'. Do czasu, gdy dojdziesz do tej części podręcznika, widzisz rzeczy nie zorientowane na użytkownika, takie jak podklasy eieio, itp. Czy na przykład masz skonfigurowany plik projektu? W jaki sposób konfigurujesz rzeczy za pomocą tego typu projektu? –

+1

Łącze jest uszkodzone i powinno zostać zaktualizowane do http://www.randomsample.de/cedetdocs/ede/Quick-Start.html Próbowałem edytować, ale istnieje głupia zasada, że ​​zmiany muszą mieć więcej niż 6 znaków. – nispio

3

Cóż, wydaje mi się, że tym razem udało mi się to wymyślić, ale jest brzydka.Utils.cpp i CGrabBuffer.cpp nie powinny uzyskiwać własnych indywidualnych celów, ponieważ nie ma odpowiedniego typu celu. Zamiast tego musisz utworzyć archiwum lub bibliotekę, która automatycznie skompiluje dla ciebie: Utils.cpp i CGrabBuffer.cpp. Poniżej zakładam, że chcesz być statyczny, ale łatwo go zmienić.

[Dla osób, które nie znają archiwów lub bibliotek, po prostu zbierają pliki .o w oddzielnej jednostce. W rzeczywistości nie komplikuje to kompilacji. Przeczytaj więcej here.]

1) Wykonaj pierwsze dwa i pół kroku powyżej (w tym celu main, ale nie innych celów).

2) Przejdź do Utils.cpp i wykonaj M-x ede-new-target; nazwa: aux; typ: archive. Po wyświetleniu monitu dodaj plik Utils.cpp do tego miejsca docelowego.

3) Przełącz na CGrabBuffer.cpp i wykonaj C-c . a; Miejsce docelowe: aux.

4) Ponownie wygeneruj plik Makefile za pomocą M-x ede-proj-regenerate. W tym momencie, jeśli uruchomisz make w podkatalogu other, powinieneś pobrać archiwum libaux.a.

5) Przełącz z powrotem na main.cpp i wykonaj M-x ede-customize-current-target. Pojawi się interaktywny bufor dostosowywania emacs, który pozwala na edycję szczegółów konfiguracji ede. W sekcji Ldflags kliknij [INS]. To wyskakuje nowa linia, która mówi: Link Flag: i ma trochę różnokolorowe pudełko do wpisania (moje jest szare). Wpisz -Lother -laux, aby other/libaux.a było uwzględniane podczas kompilowania main. Następnie na szczycie bufora naciśnij [Accept], który powinien zapisać tę zmianę i wrócić do main.cpp.

6) Ponownie wygeneruj plik Makefile za pomocą M-x ede-proj-regenerate.

Niestety plik Makefile najpierw wykonuje cel main, a następnie zstępuje do katalogu other i wykonuje go. Niestety oznacza to, że marka z katalogu najwyższego poziomu nie będzie działać na czystym drzewie. Nie wiem, dlaczego tak jest, ponieważ wygląda na to, że nigdy nie będzie to, co chcesz w każdym projekcie, który jest kiedykolwiek wykonany z EDE. Nie mogę znaleźć żadnego sposobu, aby to zmienić, z wyjątkiem tego hacka:

7) Czy M-x customize-project; pod Inference-Rules kliknij [INS]. Następnie wprowadź Target: all; Zależności: aux main; Zasady: [INS]; String @:. (Ta ostatnia jest po prostu, aby zapobiec błędowi na pustej regule z kartą, prawdopodobnie błąd EDE.) Kliknij [Accept] i regeneruj pliki Makefile.

Teraz, w katalogu głównym, możesz po prostu uruchomić make, a main powinien być działającym plikiem wykonywalnym.

Szybko przekonuje mnie, że EDE nie jest jeszcze gotowy do użycia przez osoby inne niż jego autorzy. Pomimo swojej wielkości i wysiłku, który wyraźnie włożyli w to, jest zbyt niepotrzebny, zbyt kontrowersyjny i po prostu niewystarczająco inteligentny. Jaka szkoda. Emacs potrzebuje czegoś takiego.

+0

Po zadaniu pytania kontynuowałem majsterkowanie z typami projektów i skończyło się na zrobieniu czegoś podobnego do tego, co mówisz. Zrobiłem dwa cele archiwum typów (jeden dla CGrabBuffer, a drugi dla Utils) zamiast jednego. I, jak mówisz, musiałem najpierw wywołać 'make' w katalogu' other'. Ten sposób postępowania wydaje się "dziwny", ale działa :). – pparescasellas

+0

Nowy samouczek Erica jest zdecydowanie bardzo pomocny. W szczególności wygląda na to, że używanie Automake rozwiąże wiele z tych problemów. Mimo to, zdałem sobie sprawę, że możesz również włączyć 'other/Utils.cpp' i' other/CGrabBuffer.cpp' jako źródła w 'main' celu, i będą one poprawnie zbudowane. Nie potrzebujesz nawet dla nich oddzielnych celów. – Mike