Wie können massive Linux- / Makefile-Projekte effektiv angegangen werden?

16

Ich entwickle seit ungefähr 10 Jahren Windows-Anwendungen in C ++. Und seit kurzem beschäftige ich mich mit einigen Linux-Projekten und ich kann es nicht ausstehen, wie unproduktiv ich bin ...

Ich lerne schnell und nutze Linux seit einiger Zeit als primäre Plattform. Und ich fühle mich sehr wohl mit Shell, Betriebssystemprinzipien und GUI. Aber wenn es um Entwicklung geht, fühle ich mich wie zurück in die Schule.

Sobald ich ein größeres Projekt öffne, stecke ich fest. Die meisten von ihnen basieren auf Makefiles. Wenn ich also versuche, sie mit QT oder CodeBlocks zu navigieren, kann ich Intellisense bestenfalls pro Datei verwenden. Und die meisten Zeitvariablen verlieren ihren Gültigkeitsbereich.

Dann gibt es eine Art von Definition, die es anscheinend nicht gibt. Versuchen Sie, sich einem größeren Projekt von SourceForge anzuschließen, und Sie stecken tagelang fest, weil das Navigieren zu Definitionen so schwierig ist ... grep -r "this_def" . --include "*.cpp" --include "*.h"so langsam und unbeholfen erscheint.

Und dann funktioniert das Debuggen von gdb, aber egal was ich mache, es scheint, als ob es Lichtjahre hinter WinDbg oder VisualStudio Debugger liegt.

Und diese Dinge machen mich verzweifelt, ich möchte Code schreiben, aber es geht nur so langsam ... Ich fange an zu denken, dass Linux-Entwickler Funktionsdefinitionen auswendig lernen und Code mit den Augen analysieren, aber ich kann es nicht glauben so.

Hat jemand das durchgemacht? Fehlt mir etwas, das mich produktiver machen könnte?

Coder
quelle
8
+1, ich bin in Bezug auf den Visual Studio-Debugger zu derselben Schlussfolgerung gelangt. Keine andere IDE auf einer Plattform kommt ihren Inspektionsmöglichkeiten nahe.
Aphex

Antworten:

22

Interessanterweise habe ich regelmäßig das gleiche Problem in die entgegengesetzte Richtung. Ich bin in erster Linie ein UNIX-Codierer, aber ich muss regelmäßig Dinge auf Windows portieren. Ich kann Ihnen nicht sagen, wie oft ich mir die Haare ausreißen wollte, weil ich das entsprechende Kontrollkästchen für eine Compiler-Option auf einer der 35 Seiten mit Voreinstellungen für ein Projekt nicht finden kann. Ich öffne lieber die proj-Datei und füge die XML selbst hinzu.

Wenn Sie sich in eine der beiden Richtungen bewegen, ist es das Geheimnis, Geduld zu haben und das Toolset für die Plattform zu lernen, auf der Sie arbeiten möchten alles wieder von vorn. Es gibt keine Möglichkeit, dies zu vermeiden.

In Ihrem speziellen Fall gibt es einige zusätzliche Tools, die Sie kennen sollten. Das erste ist DDD , ein GUI-Frontend für gdb. Es ist nicht so schick wie Visual Studio, aber es wird Ihre Hand halten. Ich würde jedoch wirklich empfehlen, die Kugel zu beißen und die Vor- und Nachteile von GDB zu lernen. Wenn Sie ein normaler Benutzer sind, gibt es in der Tat keinen großen Unterschied zwischen dem Speichern der zu tippenden Befehle und dem Speichern des Dialogfelds, das Sie zum Ändern einer Einstellung aufrufen müssen.

Sie müssen auch über Tools wie CScope und CTags Bescheid wissen . So sehr Sie sich auch widersetzen mögen, ich würde vorschlagen, VIM oder EMACS zu lernen . Sie lassen sich gut in die gerade erwähnten Tag-Tools integrieren. Wenn du in Rom bist, mach wie es die Römer tun. Sie finden Erweiterungen für VIM und EMACS, mit denen Sie den Code vervollständigen können. Meine eigene Erfahrung mit Tools, die Code-Vervollständigung bieten, ist, dass ja, es einige Eingaben spart, aber im Allgemeinen ist das Eingeben einfach. Denken ist das, was schwer ist. Ihre Meinung kann abweichen, insbesondere wenn Sie an einem Karpaltunnelsyndrom leiden.

Wie für machen. Make ist zugegebenermaßen schrecklich, aber wahrscheinlich musst du es einfach aufsaugen und lernen.

Charles E. Grant
quelle
6
+1, ist das Speichern von Befehlen nicht schwieriger als das Speichern von GUIs
Javier
5
Lernen Sie auf jeden Fall VIM oder EMACS. Der Grund, warum Linux nicht wirklich eine GUI wie Visual Studio hat, ist, dass VIM und EMACS alle die gleichen Funktionen haben und vieles mehr. Ich habe meine VIM-Version so eingerichtet, dass sie eine Reihe von Plugins verwendet, die mir die automatische Vervollständigung mit Tabulatoren, Snippets, Projektnavigation, integriertem Terminal, Tags, Tag-Navigation, Whitespace-Konvertierung und Backups auf Github ermöglichen . Bei der Arbeit benutze ich allerdings Windows, so wie es die Pfadinformationen in der vimrc-Datei verwenden.
Spencer Rathbun
2
@Javier Als ich das letzte Mal nachgesehen habe, zeigten die GUIs eine Menge Funktionen, ohne dass ich sie auswendig lernen musste. Der VIM-Bildschirm enthält keine Hinweise oder Erinnerungen.
quant_dev
2
@tdammers Ich habe in meiner Zeit genug Linux-Code gesehen, um BS darauf aufzurufen.
quant_dev
4
@quant_dev, schnell! Wo setzen Sie die Linker-Option, um doppelte Symbole als Fehler zu behandeln? Sicher, Sie können es finden, indem Sie alle Elemente im Linker-Abschnitt der C / C ++ - Eigenschaften des Projekts untersuchen, aber das ist nicht mehr (oder weniger) auf den ersten Blick, als in der Manpage nach dem Linker zu suchen.
Charles E. Grant
11

Ich entwickle seit ungefähr 10 Jahren Windows-Anwendungen in C ++. Und seit kurzem beschäftige ich mich mit einigen Linux-Projekten und ich kann es nicht ausstehen, wie unproduktiv ich bin ...

Fehlt mir etwas, das mich produktiver machen könnte?

Unter Windows entwickeln, unter Linux bereitstellen.

Dies umfasst das Ausführen von Komponententests sowohl auf Ihrem eigenen Computer (Windows) als auch auf dem Build-Server (Linux).

Als Nebeneffekt lernen Sie, wie Sie portablen Code schreiben.

Ein weiterer positiver Effekt ist, dass die Verwendung verschiedener Compiler mehr Warnungen generiert und somit mehr Fehler aufdeckt.

UPDATE : An alle Linux-Fans, die diese Antwort abgelehnt haben: Ich sage nicht, dass jeder unter Windows entwickeln sollte! Aber mit der Plattform , die Sie sehr gut kennen , ist produktiver als eine Menge Zeit verbringen auf eine neue Plattform zu lernen.

Sjoerd
quelle
Könnte der Downvoter bitte erklären, warum er downvotiert hat?
Sjoerd
Meine Vermutung wäre, weil Sie die Frage nicht beantworten. Das Problem besteht darin, an einem vorhandenen Linux-Projekt zu arbeiten. Das erstmalige Portieren nach Windows und dann zurück ist keine praktikable Lösung.
tdammers
-1: Wenn das eine Option wäre, hätte das OP nicht sein ursprüngliches Problem. Wenn Sie auf Windows entwickeln, werden Sie mit allen Kosten der Windows-Entwicklung (wie der schrecklichen Softwareinstallation aus dem 18. Jahrhundert) konfrontiert. Außerdem müssen Sie das Makefile schreiben und Ihre Anwendung mit gdb debuggen, wenn etwas nicht vollständig portierbar ist.
Thiton
@tdammers Das Auschecken der Quellen und das Erstellen eines Projekts aus * .cpp funktioniert in vielen Fällen. Selbst wenn die Einrichtung einige Stunden in Anspruch nimmt, ist dies viel weniger als das Erlernen einer völlig anderen Entwicklungsumgebung.
Sjoerd
1
Auf der anderen Seite erscheint es natürlich und lohnenswert, mehr über die Plattform zu lernen, auf der Sie arbeiten sollten.
Basile Starynkevitch
4

Ihr Problem wurde in der Linux-Welt schon oft gelöst. Im Gegensatz zu den Windows / Microsoft-Tools wird es jedoch nicht auf einem silbernen Teller mit einer Beilage aus Extras weitergereicht. Möglicherweise müssen Sie etwas arbeiten, um es zu bekommen.

Ich benutze einen kommerziellen Editor (Visual Slick Edit) für dieses Problem. Eclipse mit dem CDT-Plugin ist ein Open-Source-Weg, der eine berechtigte große Fangemeinde hat. (Nicht gut für mich, da ich oft ADA-Unterstützung benötige)

Was ich nicht mache, ist zu versuchen, die Makefiles in eine Art Projekt umzuwandeln. Ich verwende die eingebauten Systeme der IDE und füge bei Bedarf manuell Dateien hinzu / entferne sie. Ich bin mir sicher, dass ich das Skript schreiben könnte, aber die Zeit ist es wahrscheinlich nicht wert. Dafür fand ich Eclipse ein bisschen weniger brauchbar als Slickedit (Das hätte sich leicht (und wahrscheinlich) geändert, seit ich das letzte Mal geschaut habe)

Linux hat eine große Auswahl an Werkzeugen, Leute, die wissen, wie gut sie mich in allen Aspekten der Bearbeitung übertreffen, Referenzen usw., nur eine steile Lernkurve. Ich bin mir sicher, dass Emacs auch alles kann, obwohl er es noch nie benutzt hat.

mattnz
quelle
3
"Ihr Problem wurde in der Linux-Welt schon oft gelöst. Im Gegensatz zu den Windows / Microsoft-Tools wird es jedoch nicht auf einem silbernen Teller mit einer Beilage aus Extras weitergereicht." Es ist also noch nicht vollständig gelöst.
quant_dev
4
@quant_dev. Zu Recht oder zu Unrecht ist es ungewöhnlich, dass ein Teil der Linux-Software versucht, jedem Benutzer alles zu bieten. Es ist üblicher, ein Modell zu haben, bei dem jedes Stück eine kleine Sache gut macht und der Endbenutzer zusammenstellt, was von ihm benötigt wird, um seine Probleme zu lösen. Für einen Windows-Benutzer gilt das Problem als nicht gelöst, für einen Linux-Benutzer ist es, wer Recht hat, offensichtlich denken Sie, dass Sie es sind, ich weiß es nicht, und die meisten Linux-Benutzer denken, dass sie es sind. Es ist ein bisschen hart, mir eine -1 zu geben, nur weil ich mit der Welt nicht einverstanden bin.
Mattnz
3

Für das, was es wert ist, haben Sie unter Linux bessere Build-Systeme als einfaches altes GNU-make (was oft mit der schrecklichen Autoconf einhergeht ), zum Beispiel omake und viele andere ( cmake, scons...).

Basile Starynkevitch
quelle
3

Ein Vorschlag, wie mühsam es ist, mit grep nach Code zu suchen: Richten Sie Bash-Aliase in Ihrer .bashrc-Datei ein. Dann ist es nur ein einziger Befehl:

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

Es gibt wahrscheinlich bessere Möglichkeiten, den Befehl zu schreiben, aber die Idee ist dieselbe. Möchten Sie den Code suchen? Schreiben Sie einen Alias ​​namens searchCode. Denken Sie daran, dass Unix-Tools, obwohl sie langwierig und kompliziert sind, auch verwendet werden können, um Ihnen das Leben zu erleichtern.

Timmah
quelle
3

Mein 2c als jemand, der C ++ auf beiden Plattformen entwickelt hat und beide mag.

1) Makefiles sind schmerzhaft - der beste Rat, den ich Ihnen geben kann, ist, wenn möglich, auf ein anderes Build-System zu wechseln.

2) Zum Bearbeiten und Durchsuchen von Code gibt es einige recht nützliche Tools. Sicher, sie sind nicht integriert, aber es spielt keine Rolle, wenn es darum geht, Dinge zu erledigen. vim + ctags + grep bringt Sie einfach dorthin. Natürlich gibt es auch IDEs, aber ehrlich gesagt hat mir nichts gefallen, was ich ausprobiert habe: Eclipse + CDT, KDevelop, Code :: Block. Sie können jedoch zu einem anderen Schluss kommen.

3) Halten Sie sich zum Debuggen einfach an die Befehlszeile gdb. Sicher, es ist ziemlich hinter Windbg, wenn es um Features geht, aber für die meisten Zwecke ist es in Ordnung. Die grafischen Frontends (ddd, KDbg) waren beim letzten Versuch ziemlich fehlerhaft, aber auch hier haben sich die Dinge möglicherweise geändert :)

Das Fazit lautet: Ja, Sie müssen einige Lernanstrengungen unternehmen, aber danach sind Sie genauso produktiv wie unter Windows.

Nemanja Trifunovic
quelle
Ich laufe oft gdbvon innen emacs(unter Linux) und es hilft sehr.
Basile Starynkevitch
1

Zu all den anderen guten Ratschlägen, die Sie bereits erhalten haben, möchte ich ein paar Links hinzufügen, jeweils zu ack und pss .

Sie richten sich an Programmierer, die sich speziell um den Quellcode kümmern müssen und versuchen, grep zu übertreffen.

Francesco
quelle
0

Tolle Antworten. Hinzufügen zu ihnen,

Als ich diesen Schritt machte, war der Fehler, den ich gemacht habe, der Versuch, in den Code zu springen, ohne dem GNU-Build-System die gebotene Sorgfalt zu widmen. Dieses kam zurück, um mich zu beißen, als ich Codeänderungen vornehmen wollte. Verbringen Sie ein paar Tage, um zu verstehen, wie die Tools von AutoMake / AutoConf / Make funktionieren. Danach werden Sie sehr schnell sein.

In Bezug auf Tools - Eclipse + CDT / GDB + DDD ist in der Tat ein langer Weg.

Subu Sankara Subramanian
quelle
-1

Hier einige Ratschläge, um die Arbeit zu erleichtern:

  1. Von Anfang an beginnen. Dies bedeutet, dass Sie zuerst Bash-Skript als Makefile-Ersatz verwenden und dann einfache Makefiles, sobald Sie Abhängigkeiten benötigen. Halte es am Anfang einfach. Ihr Makefile muss nicht mit 15 verschiedenen Unix-Plattformen umgehen, sondern muss nur mit Abhängigkeiten kompiliert werden. (Ihr anfängliches Makefile sieht folgendermaßen aus: all: g ++ -o main main.cpp) (Ein komplexeres Beispiel finden Sie unter http://sivut.koti.soon.fi/~terop/Makefile - wenn Sie von vorne beginnen , kopiere einfach die Datei in das Projekt, ändere Dateinamen, mkdir objs Verzeichnis, ändere die gewünschten Bibliotheken)
  2. Vergiss die IDE. Es wird dich nur langsamer machen. Erfahren Sie, wie Sie den Code lesen und die Dateihierarchie Ihres Projekts berücksichtigen. Normale Kommandozeilen-Tools wie 'cd dir' und 'emacs foo.cpp' müssen so automatisch sein, dass Sie nicht zweimal darüber nachdenken, sie einzugeben.
  3. Vergessen Sie Syntaxhervorhebung und Intellisense. Es wird niemals so funktionieren, wie es in Visual Studio funktioniert, und die Hinweise, die es gibt, werden Sie nur verwirren, da es anders ist, als Sie es gewohnt sind. Lerne, dich nicht auf sie zu verlassen.
  4. Gdb ist ein guter Debugger. Sie erhalten einen Call-Stack. Versuchen Sie nicht einmal, den Code zu umgehen, er wird nicht sehr gut funktionieren. Benutze auch valgrind. Haltepunkte sind auch gut, aber verlassen Sie sich nicht zu sehr auf sie. nur selten mit gdb verwendet.
  5. Wenn es sich bei Ihrer Kompilation nicht nur um ein einfaches 'make' in der Shell handelt, müssen Sie Ihren Bearbeitungszyklus für das Kompilieren, Debuggen und Bearbeiten überdenken.
  6. Dies ist ein Trick, den Visual Studio nicht ausführen kann: Zeigen Sie sowohl die Header-Datei als auch die CPP-Datei gleichzeitig auf dem Bildschirm an, sodass beide sichtbar sind, ohne mit Registerkarten zwischen ihnen zu wechseln. Emacs kann das. So kann man notepad. Visual Studio oder IDE können nicht.
  7. Lerne Emacs-Tastenkombinationen. Es wird dich schneller machen. Ein netter Hinweis ist, dass sich alle Tasten ganz in der Nähe der Tastatur befinden. Die Befehlssequenzen sind länger, aber es ist immer noch schneller, sie einzugeben.
  8. Es gibt einen einfachen Trick, um die Definition zu ersetzen: Schreiben Sie den Code in dieselbe Datei und verwenden Sie esc- <und Cs :: myfunction in Emacs, um die gewünschte Funktion zu finden. Der Prozess ist anders, wenn Sie viele kurze Dateien verwendet haben - Ihr Code wird anders aussehen. (Lernen Sie Strg-F im Editor und Sie werden auf die Idee kommen). Aber Sie müssen es definitiv nicht in der Shell tun.
  9. Die Startzeit des Texteditors ist sehr wichtig. Wenn es länger als 1 Sekunde dauert, um es zu öffnen, ist es nicht gut. Jede IDE ist aufgrund dieser Anforderung defekt. Notizblock und Emacs sind in Ordnung.
  10. goto-line in emacs ist ein wichtiges Feature für die Programmierung. Binde es an einen Schlüssel. Ich benutze Cx g
tp1
quelle
1
-1 für "schreibe den Code in dieselbe Datei": Du machst wohl Witze! Und wie können Sie zugeben, dass Sie "nicht einmal versuchen, den Code zu umgehen" und dennoch darauf bestehen, dass "Gdb ein guter Debugger ist"?
Sjoerd
@sjoerd: Dies sind nur Techniken, die wir für richtig befunden haben. Es ist vielleicht nicht das, was andere Leute verwenden, aber sie funktionieren gut in einer Linux-Umgebung - größere Programme müssen notwendigerweise größere Dateien verwenden. Mit 10 Jahren Erfahrung in der Programmierung muss er nicht mehr im Code herumlaufen - er weiß bereits, wie die Programmausführung funktioniert, und benötigt nicht die Hilfe, die der schrittweise Code bietet.
tp1