Jak skutecznie radzić sobie z ogromnymi projektami Linux / makefile?


16

Aplikacje Windows pracuję w C ++ od około 10 lat. Niedawno zacząłem zagłębiać się w niektóre projekty Linuksa i nie mogę znieść, jak jestem nieproduktywny ...

Szybko się uczę i od pewnego czasu używam Linuksa jako podstawowej platformy. Czuję się bardzo dobrze z powłoką, zasadami systemu operacyjnego i graficznym interfejsem użytkownika. Ale jeśli chodzi o rozwój, wydaje mi się, że wróciłem do szkoły.

Gdy tylko otworzę jakiś większy projekt, utknąłem. Większość z nich jest oparta na plikach makefile, więc w zasadzie, kiedy próbuję nawigować nimi za pomocą QT lub CodeBlocks, w najlepszym wypadku mogę korzystać z intellisense dla poszczególnych plików. I większość zmiennych czasowych wyciek z zakresu.

Potem jest kwestia przejścia do definicji, która wydaje się nieistniejąca, spróbuj dołączyć do jakiegoś większego projektu z sourceforge i utkniesz na kilka dni, ponieważ nawigacja do definicji jest tak trudna ... grep -r "this_def" . --include "*.cpp" --include "*.h"wydaje się taka powolna i niezdarna.

A potem debugowanie gdb działa, ale bez względu na to, co robię, wydaje się, że minęły lata świetlne od debugera WinDbg lub VisualStudio.

Te rzeczy sprawiają, że jestem zdesperowany, chcę pisać kod, ale to idzie tak wolno ... Zaczynam myśleć, że programiści Linuksa uczą się definicji funkcji na pamięć i analizują kod oczami, ale nie mogę uwierzyć, że to więc.

Czy ktoś przez to przeszedł? Czy brakuje mi czegoś, co mogłoby zwiększyć produktywność?


8
+1, doszedłem do tego samego wniosku dotyczącego debugera Visual Studio; żadne inne IDE na żadnej platformie nie zbliża się do jego możliwości inspekcji.
Aphex,

Odpowiedzi:


22

Co ciekawe, okresowo mam ten sam problem w przeciwnym kierunku. Jestem przede wszystkim programistą UNIX, ale okresowo muszę przenosić pliki do systemu Windows. Nie mogę powiedzieć, ile razy chciałem wyciągnąć włosy, ponieważ nie mogę znaleźć odpowiedniego pola wyboru dla opcji kompilatora ukrytej na jednej z 35 stron ustawień preferencji dla projektu. Wolę po prostu otworzyć plik proj i sam dodać kod XML.

W obu kierunkach sekretem jest cierpliwość i nauka zestawu narzędzi dla platformy, na której próbujesz pracować. Oczywiście będziesz sfrustrowany, nowy i nieznany, a ty zostaniesz przywrócony do statusu początkującego od nowa. Nie da się tego uniknąć.

W twoim konkretnym przypadku istnieje kilka dodatkowych narzędzi, o których powinieneś wiedzieć. Pierwszym z nich jest DDD , interfejs GUI dla gdb. Nie jest tak elegancki jak Visual Studio, ale będzie trzymał twoją rękę. Jednak naprawdę poleciłbym gryźć kulę i zająć się poznawaniem tajników gdb. W rzeczywistości, jeśli jesteś zwykłym użytkownikiem, nie ma dużej różnicy między zapamiętywaniem poleceń do wpisania a zapamiętywaniem okna dialogowego, które musisz wyświetlić, aby zmienić ustawienie.

Musisz także wiedzieć o narzędziach takich jak CScope i CTags . Jako że możesz się oprzeć, sugerowałbym naukę VIM lub EMACS . Dobrze integrują się z narzędziami tagów, o których właśnie wspomniałem. Jeśli wejdziesz między wrony, musisz krakać jak i one. Możesz znaleźć rozszerzenia dla VIM i EMACS, które wykonają dla Ciebie uzupełnianie kodu. Moje własne doświadczenie z narzędziami oferującymi uzupełnianie kodu jest takie, że oszczędza trochę pisania, ale ogólnie pisanie jest łatwe. Myślenie jest tym, co trudne. Twoja opinia może się różnić, szczególnie jeśli masz zespół cieśni nadgarstka.

Co do marki. Make jest wprawdzie okropny, ale prawdopodobnie będziesz musiał go po prostu wyssać i nauczyć się.


6
+1, zapamiętywanie poleceń nie jest trudniejsze niż zapamiętywanie GUI
Javier

5
Zdecydowanie naucz się VIM lub EMACS. Powodem, dla którego Linux nie ma GUI takiego jak Visual Studio, jest to, że VIM i EMACS mają te same funkcje i wiele więcej. Mam swoją kopię VIM skonfigurowaną do korzystania z zestawu wtyczek, które dają mi autouzupełnianie z tabulatorem, fragmentami, nawigacją projektu, wbudowanym terminalem, tagami, nawigacją tagów, konwersją białych znaków i cała kopia zapasowa wraca do github . W pracy używam jednak systemu Windows, więc tego właśnie używa informacja o ścieżce w pliku vimrc.
Spencer Rathbun,

2
@Javier Kiedy ostatnio sprawdzałem, GUI wyświetlały wiele funkcji na widoku, bez potrzeby zapamiętywania. Ekran VIM nie zawiera żadnych podpowiedzi ani przypomnień.
quant_dev,

2
@tdammers W swoim czasie widziałem wystarczająco dużo kodu Linuksa, żeby zadzwonić do BS.
quant_dev,

4
@quant_dev, szybko! Gdzie ustawiasz opcję linkera, aby traktować zduplikowane symbole jako błąd? Pewnie, możesz go znaleźć, eksplorując wszystkie elementy w sekcji linkera we właściwościach C / C ++ projektu, ale nie jest to nic więcej (lub mniej) na pierwszy rzut oka niż wyszukiwanie go na stronie podręcznika dla linkera.
Charles E. Grant,

11

Aplikacje Windows pracuję w C ++ od około 10 lat. Niedawno zacząłem zagłębiać się w niektóre projekty Linuksa i nie mogę znieść, jak jestem nieproduktywny ...

Czy brakuje mi czegoś, co mogłoby zwiększyć produktywność?

Rozwijaj w systemie Windows, wdrażaj w systemie Linux.

Obejmuje to przeprowadzanie testów jednostkowych zarówno na własnym komputerze (Windows), jak i na serwerze kompilacji (Linux).

Jako efekt uboczny nauczysz się pisać przenośny kod.

Kolejnym pozytywnym efektem jest to, że używanie różnych kompilatorów generuje więcej ostrzeżeń, a tym samym wykrywa więcej błędów.

AKTUALIZACJA : Wszystkim fanom Linuksa oceniającym odpowiedź: Nie twierdzę, że każdy powinien rozwijać się w systemie Windows! Ale korzystanie z platformy, którą znasz bardzo dobrze, jest bardziej produktywne niż poświęcanie dużo czasu na naukę nowej platformy.


Czy downvoter mógłby podać, dlaczego przegłosował?
Sjoerd,

Domyślam się, że nie odpowiadasz na pytanie. Problem polega na pracy nad istniejącym projektem linux; przeniesienie go najpierw do systemu Windows, a następnie z powrotem, nie jest realnym rozwiązaniem.
tdammers,

-1: Gdyby to była opcja, OP nie miałby swojego pierwotnego problemu. A programowanie w systemie Windows pociąga za sobą wszystkie koszty związane z tworzeniem systemu Windows (takie jak okropna procedura instalacyjna oprogramowania z XVIII wieku) i nadal musisz pisać plik Makefile i debugować aplikację za pomocą gdb, jeśli coś nie jest całkowicie przenośne.
thiton,

@tdammers Sprawdzanie źródeł i tworzenie projektu z * .cpp działa w wielu przypadkach. Nawet jeśli konfiguracja zajmuje kilka godzin, to o wiele mniej niż zajęłoby nauczenie się zupełnie innego środowiska programistycznego.
Sjoerd,

1
Z drugiej strony, więcej informacji na temat platformy, na której powinieneś pracować, wydaje się naturalne i opłacalne.
Basile Starynkevitch,

4

Twój problem został rozwiązany wiele razy w świecie Linuksa, jednak w przeciwieństwie do narzędzi Windows / Microsoft, nie zostanie przekazany na srebrnej płycie z przystawką dodatków. Być może trzeba będzie popracować, aby go zdobyć.

Używam edytora komercyjnego (Visual Slick Edit, który jest uważany za drogi przez tych, którzy nie cenią swojego czasu tak bardzo jak ja) do tego dokładnego problemu. Eclipse z wtyczką CDT to droga typu open source, która ma uzasadnione szerokie grono zwolenników. (Nie jest to dla mnie dobre, ponieważ często potrzebuję wsparcia ADA)

Czego nie robię, spróbuj przekształcić makefile w jakiś projekt. Korzystam z wbudowanych systemów IDE i ręcznie dodam / usuwam pliki w razie potrzeby. Jestem pewien, że mógłbym to zrobić, ale ten czas prawdopodobnie nie jest tego wart. W tym celu znalazłem zaćmienie nieco mniej użyteczne niż Slickedit (co mogło łatwo (i prawdopodobnie zmieniło się) od czasu ostatniego spojrzenia)

Linux ma szeroką gamę narzędzi, faceci, którzy wiedzą, że dobrze mnie wykonują we wszystkich aspektach edycji, mają odnośniki, itp., Po prostu stroma krzywa uczenia się. Jestem pewien, że Emacs może to wszystko zrobić, chociaż nigdy tego nie używał.


3
„Twój problem został rozwiązany wiele razy w świecie Linuksa, jednak w przeciwieństwie do narzędzi Windows / Microsoft nie zostanie przekazany na srebrnej tacy z dodatkami”. Zatem nie zostało to całkowicie rozwiązane.
quant_dev,

4
@quant_dev. Słusznie czy nie, nie jest rzadkością, że oprogramowanie Linuksa stara się być wszystkim dla każdego użytkownika. Bardziej powszechne jest posiadanie modelu, w którym każdy kawałek dobrze robi małą rzecz, a użytkownik końcowy gromadzi to, czego potrzebuje, aby rozwiązać swoje problemy. Dla użytkownika systemu Windows problem nie jest uważany za rozwiązany, dla użytkownika Linuksa to on ma rację, oczywiście myślisz, że jesteś, nie wiem, a większość użytkowników Linuksa tak uważa. To trochę trudne, dać mi -1 tylko dlatego, że nie zgadzam się z tym, jaki jest świat.
mattnz,


3

jedna sugestia dotycząca tego, jak żmudne jest używanie grep do wyszukiwania kodu: skonfiguruj aliasy bash w pliku .bashrc. Więc to tylko jedno polecenie:

alias searchCode='find -iname \*.cpp | xargs grep $1'
alias searchCodeHeaders='find -iname \*.h | xargs grep $1'

prawdopodobnie są lepsze sposoby na napisanie polecenia, ale pomysł jest taki sam. Chcesz wyszukać kod? napisz alias o nazwie searchCode. Pamiętaj, że chociaż są one uciążliwe i skomplikowane, narzędzia uniksowe mogą być również używane, aby ułatwić Ci życie.


3

Mój 2c jako ktoś, kto opracował C ++ na obu platformach i lubi je oba.

1) Pliki makefile są bolesne - najlepszą radą, jaką mogę ci dać, jest próba przejścia na inny system kompilacji, jeśli to możliwe.

2) Do edycji i przeglądania kodu istnieje kilka całkiem przydatnych narzędzi. Jasne, nie są zintegrowane, ale tak naprawdę nie ma to znaczenia, jeśli chodzi o wykonanie zadań. vim + ctags + grep po prostu cię tam zaprowadzą. Oczywiście są też IDE, ale szczerze mówiąc nie podobało mi się to, czego próbowałem: Eclipse + CDT, KDevelop, Code :: Block. Możesz jednak dojść do innych wniosków.

3) W celu debugowania wystarczy trzymać się wiersza polecenia gdb. Oczywiście, jeśli chodzi o funkcje, jest dość opóźniony w stosunku do Windbg, ale w większości przypadków jest w porządku. Graficzne nakładki (ddd, KDbg) były dość wadliwe, kiedy je wypróbowałem, ale znowu rzeczy mogły się zmienić :)

Najważniejsze jest - tak, musisz włożyć trochę wysiłku w naukę, ale potem będziesz tak samo produktywny jak w systemie Windows.


Często biegam gdbod wewnątrz emacs(na Linuksie) i to bardzo pomaga.
Basile Starynkevitch,

1

Do wszystkich pozostałych dobrych porad, które już otrzymałeś, chciałbym dodać kilka linków, odpowiednio do ack i pss .

Są one skierowane do programistów, którzy muszą szczególnie dbać o kod źródłowy, starając się ulepszyć w stosunku do grep.


0

Świetne odpowiedzi. Dodając do nich,

Kiedy wykonałem ten ruch, popełniłem błąd, próbując wskoczyć do kodu bez należytej staranności w systemie kompilacji GNU, który wrócił, by mnie ugryźć, gdy chciałem wprowadzić zmiany w kodzie. Poświęć kilka dni, aby zrozumieć, jak działa zestaw narzędzi AutoMake / AutoConf / Make, po tym będziesz bardzo szybki.

Jeśli chodzi o narzędzia - Eclipse + CDT / GDB + DDD to naprawdę długa droga.


-1

Oto kilka porad, które ułatwią Ci działanie:

  1. Zacząć od nowa. Oznacza to, że najpierw użyjesz skryptu bash jako zamiennika makefile, a następnie prostych plików makefile, gdy będziesz potrzebować zależności. Na początku zachowaj prostotę. Twój plik makefile nie musi obsługiwać 15 różnych platform unixowych - po prostu kompiluj go z zależnościami. (Twój początkowy plik makefile będzie wyglądał następująco: all: g ++ -o main main.cpp) (bardziej złożony przykład można znaleźć w http://sivut.koti.soon.fi/~terop/Makefile - kiedy zaczynasz od zera , po prostu skopiuj plik do projektu, zmień nazwy plików, katalog mkdir objs, zmień biblioteki, które chcesz)
  2. Zapomnij o IDE. To tylko spowolni cię. Naucz się czytać kod i zapamiętaj hierarchię plików swojego projektu. Normalne narzędzia wiersza poleceń, takie jak „cd dir” i „emacs foo.cpp”, muszą być tak automatyczne, abyś nie pomyślał o dwukrotnym wpisywaniu.
  3. Zapomnij o podświetlaniu składni i inteligencji. Nigdy nie będzie działać tak samo, jak działa w studiu wizualnym, a podpowiedzi, które daje, będą tylko mylić, ponieważ różnią się od tego, do czego byłeś kiedyś. Naucz się na nich nie polegać.
  4. Gdb jest dobrym debuggerem. Dostaniesz stos połączeń. Nie próbuj nawet omijać kodu, ponieważ nie zadziała to zbyt dobrze. Użyj też valgrind. Punkty przerwania są również dobre, ale nie polegaj na nich zbytnio; rzadko używany z gdb.
  5. Jeśli twoja kompilacja jest czymś innym niż prostym „make” w powłoce, musisz przemyśleć swój edit-compile-debug-edit -cycle.
  6. Oto sztuczka, której Visual Studio nie jest w stanie zrobić: Pokaż jednocześnie plik nagłówka i plik .cpp na ekranie - aby oba były widoczne bez przechodzenia między nimi za pomocą kart. Emacs może to zrobić. Tak może notatnik. Visual Studio lub IDE nie mogą.
  7. Dowiedz się skrótów klawiszowych emacsa. Sprawi, że będziesz szybszy. Dobrą wskazówką jest to, że wszystkie klawisze znajdują się bardzo blisko klawiatury. Sekwencje poleceń są dłuższe, ale nadal jest szybsze ich wpisywanie.
  8. Jest prosta sztuczka, aby zastąpić przejście do definicji: napisz kod do tego samego pliku i użyj esc- <i Cs :: myfunction w emacs, aby znaleźć żądaną funkcję. Proces jest inny, jeśli przyzwyczaiłeś się do wielu krótkich plików - twój kod będzie wyglądał inaczej. (naucz się Ctrl-F w Notatniku, a wpadniesz na pomysł). Ale zdecydowanie nie musisz tego robić w skorupkach.
  9. Czas uruchamiania edytora tekstu jest bardzo ważny. Jeśli otwarcie trwa dłużej niż 1 sekundę, nie jest to dobre. Każde IDE jest zepsute z powodu tego wymagania. Notatnik i emacs są w porządku.
  10. goto-line w emacsie jest ważną funkcją do programowania. Powiąż to z jakimś kluczem. Używam Cx g

1
-1 dla „napisz kod do tego samego pliku”: Musisz żartować! I jak możesz przyznać „Nawet nie próbuj obchodzić kodu” i nadal nalegać, aby „Gdb to dobry debugger”!
Sjoerd

@sjoerd: To tylko techniki, które okazały się działać poprawnie. Może nie jest to, czego używają inni ludzie, ale działają dobrze w środowisku Linux - większe programy muszą koniecznie używać większych plików. Dzięki 10-letniemu doświadczeniu w programowaniu nie musi już chodzić po kodzie - już wie, jak działa wykonywanie programu i nie potrzebuje pomocy zapewnianej przez kodowanie.
tp1
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.