Hallo Forum,
Ich suche eine textbasierte IDE unter debian mit der ich c Programme
schreiben und debuggen kann ähnlich wie mit Turbo C++ von Borland
damals.
Textbasiert deshalb weil ich Programme sowohl auf dem raspberry per
putty (also remote) schreiben und debuggen möchte, gleichzeitig aber
auch auf dem pc im einer VMware damit arbeiten möchte. Eclipse möchte
und kann ich nicht nutzen da die Himbeere nicht an einem Fernseher
angeschlossen ist, remote per vnc arbeiten braucht zu viel Ressourcen
und die virtuelle Maschine ist auch nicht groß.
Gibt es da etwas ausser emacs ? Oder ist emacs das einzig sinnvolle ?
Mit der IDE möchte ich c/h Dateien so erstellen das das makefile
erstellt wird und ich auch einigermaßen komfortabel debuggen kann. Kann
ich das mit emacs relativ einfach machen ? Wie ist die Einarbeitung in
emacs ? Ist die Bedienbarkeit ähnlich wie z.b. von nano ?
Ich würde das sicher mit dem EMACS machen, aber vielleicht nur weil ich
seit jeher fast alles mit dem EMACS mache.
Ein Makefile schreibe ich immer selber (was ja für einen einfachen Fall
auch kein Drama ist), aber der Rest geht alles mit EMACS:
Editieren (sehr effektiv, wenn man den EMACS kennt, bis dahin aber sehrt
gewöhnungsbedürftig), Kompilieren direkt aus dem EMACS heraus (M-x
compile...), Debuggen (M-x gdb...), shell aufrufen in einem
EMACS-Fenster, Kommandozeilenkommandos in den Text schreiben lassen oder
Textpassagen durch Kommandos filtern, ...
Man muß sich halt mal in Ruhe damit beschäftigen, weil alles etwas
anders ist. Aber es lohnt sich - unter anderem deshalb, weil es den
EMACS praktisch auf jedem System gibt, und man die Kommandos für fast
alle Zwecke nutzen kann (Mails, alle Arten von Quelltext, LaTeX, ...).
Man arbeitet sich also nicht mühsam in etwas ein, um dann nur C-Dateien
zu schreiben, und für alles wieder ein anders Tool nehmen zu müssen.
>raspberry per putty (also remote) schreiben und debuggen möchte,
schreiben MÖCHTE? wer möchte denn sowas?
ok, Debuggen versteh ich, gibts dafür keine Remote-debugger???
Es gibt im weiten Netz genügend Anleitungen die Beschreiben wie man
Eclipse für die Remote-Entwicklung auf dem Pi einsetzten kann.
Remote-Debugging selbstverständlich inklusive. Emacs in allen Ehren,
aber ich glaube an den Komfort von Eclipse auf einem halbwegs
leistungsstarken Rechner kommt man nur mit sehr, sehr viel Übung.
Schon mal an einen Cross-Compiler gedacht?
Eclipse bietet mit dem Remote-Developement-Tools-Plugin sehr komfortable
Möglichkeiten. Die kompilierst auf deinem Rechner und überträgst das
Programm innerhalb der Eclipse-IDE dann z.B. per SSH auf deinen RPi.
Debuggen ist über den gdbserver auf dem RPi ebenfalls über Eclipse
möglich.
Stichwörter nach denen du dafür mal googlen solltest:
arm-linux-gnueabihf --> Die toolchain
Plugins für Eclipse:
Remote Developement Tools
File System Explorer
C/C++ Developement Tooling
Zum Remote-Entwickeln über ssh nehm ich die IDE "bash".
Einfach zu Bedienen, man kann
- Quelltext editieren
(vi source.c, joe source.c, emacs source.c, nano source.c, ... je nach
Geschmack)
- Makefiles editieren
(sh. oben)
- Kompilieren (make)
- debuggen (gdb)
- Hat tolle (naja) refactoring tools: "sed -e s...", "perl -pi.bak -e"
- Volle Integration verschiedenster VCS (rcs, cvs, svn, git, ...)
- ...
- Ist sogut wie immer vorinstalliert :)
Erstmal danke für die brauchbaren antworten.
Wie gesagt möchte ich eclipse nicht unbedingt nutzen weil ich ohne
grafische Oberfläche auskommen möchte.
Zudem möchte ich das alles mit so wenig Ressourcen wie möglich machen,
gleichzeitig aber ohne viel Aufwand platformübergreifend arbeiten können
(daher auch die virtuelle Maschine auf meinem pc).
Die Idee mit dem Crosscompilen ist mir auch gekommen ist. Aber macht für
mich erstmal nicht soviel Sinn da ich ja zwei komplette Systeme habe mit
Compiler und debugger für die entsprechende platform.
Also 'sehr gewöhnungsbedürftig' hört sich erstmal suboptimal an, zumal
ich das schon öfters gelesen hab. Selbst wenn man mit den emacs (wenn
man erstmal drin ist) alles machen kann.
Ich glaube ich werd wohl mit nano, makefile und gdb so hantieren und
mich dann mal in emacs einlesen.
Schade, ich hätte gedacht das es ähnlich dem Turbo c++ sowas für Linux
bzw debian gibt.
Zumal es an textbasierten Werkzeugen unter Linux ja mehr gibt als die
Anzahl an Disketten die man bräuchte um Windows 7 per Diskette zu
installieren.
> Man muß sich halt mal in Ruhe damit beschäftigen, weil alles etwas> anders ist. Aber es lohnt sich - unter anderem deshalb, weil es den> EMACS praktisch auf jedem System gibt, und man die Kommandos für fast> alle Zwecke nutzen kann (Mails, alle Arten von Quelltext, LaTeX, ...).
Böse Zungen behaupten auch, das eigentlich EMACS das Betriebsystem bzw.
die Shell wäre und alles andere (wie das BS) nur störender Unterbau
wäre.
> Zudem möchte ich das alles mit so wenig Ressourcen wie möglich machen
Zu Zeiten, als Grossrechner noch Hauptspeicher im deutlich einstelligen
Megabytebereich hatten, deutete man den Begriff "EMACS" als Abkürzung
für
"Eight Megabytes And Constantly Swapping"
Emacs konnte ich noch nie leiden und Nano verwendet wirre shortcuts.
Wenn du was vernünftiges haben willst, dann nimm einfach vim.
SSH kann aber auch grafische Anwendungen übertragen, falls du unbedingt
ne GUI brauchst (für gvim oder vim-qt z.B.).
K. Salomo schrieb:> Wenn du was vernünftiges haben willst, dann nimm einfach vim.
Wenn es um:
themason schrieb:> ähnlich wie mit Turbo C++ von Borland> damals
geht, dann nimm "joe".
Der benutzt ähnliche, CP/M-Wordstar inspirierte, Tastenkürzel wie die
Borland-IDEs damals.
oder http://www.rhide.com/
Das ist dann wenigstens Bunt :)
@Karl Heinz buchegger
Lach :) Schöne akronyme und Gerüchte :)
Na ja, wenn man sich anschaut wie sich das alles entwickelt hat und
welche 'Lager' sich im laufe der Zeit gebildet haben kann man das schon
glauben :)
@Ernst b.
Genauso sowas wie im Bild hatte ich gedacht. Das ist rhide wenn ich das
richtig gesehen hab ?
Danke an die konstruktiven antworten.
themason schrieb:> @Karl Heinz buchegger>> Lach :) Schöne akronyme und Gerüchte :)
Ach was. Wieder andere Gerüchte wollen wissen, dass es sich bei EMACS um
eine Abkürzung für Escape - Meta - Alt - Control und Shift handle. Also
die Sondertasten, die man benötigt und ohne deren Einsatz und
Beherrschung man EMACS nicht bedienen könne.
:-)
Karl Heinz schrieb:> Ach was. Wieder andere Gerüchte wollen wissen, dass es sich bei EMACS um> eine Abkürzung für Escape - Meta - Alt - Control und Shift handle. Also> die Sondertasten, die man benötigt und ohne deren Einsatz und> Beherrschung man EMACS nicht bedienen könne.
Ja wie!? Und wenn ich jetzt einen Tablet PC mit Touch-Display habe? Dann
muss ich doch wohl hoffentlich nicht zur Bildschirmtastatur greifen?
Im Windows Store habe ich allerdings noch keine EMACS Version für WinRT
gefunden :-(
Karl Heinz schrieb:> Böse Zungen behaupten auch, das eigentlich EMACS das Betriebsystem bzw.> die Shell wäre und alles andere (wie das BS) nur störender Unterbau> wäre.
Noch bösere Zungen behaupten, daß EMACs ein super Betriebssystem sei,
dem allerdings leider noch ein guter Editor fehle.
Hobbyist schrieb:> Ja wie!? Und wenn ich jetzt einen Tablet PC mit Touch-Display habe? Dann> muss ich doch wohl hoffentlich nicht zur Bildschirmtastatur greifen?
Zur Bedienung eines Texteditors?
Hobbyist schrieb:> Ja wie!? Und wenn ich jetzt einen Tablet PC mit Touch-Display habe? Dann> muss ich doch wohl hoffentlich nicht zur Bildschirmtastatur greifen?
Anbei ein Bild von einem Android-Tablet (Notes 10.1) mit ssh-Sitzung
(ConnectBot) zu meinem Server daheim, dort läuft der EMACS und ist mit
dem ganzen ALT- und Ctrl-Gedöns einwandfrei bedienbar.
Das geht allerdings nicht mit der Original-Tastatur, sondern mit
"Hacker's Keyboard".
Das ist jetzt sicher nichts, wo man ein paar Tausend Zeilen Quelltext
schmiedet. Aber um eben mal schnell was zu machen, reicht es allemal.
Alternativ kann man natürlich auch jederzeit eine Bluetooth- oder
USB-Tastatur nehmen...
rakudah schrieb:> Mit X-Forwarding kannst du X11 Programme auf dem Pi ausführen und deren> Ausgabe auf deinen Rechner umleiten. Wäre ressourcenschonender als VNC.
War früher so, bzw. ist bei "alten" X11-Programmen noch so.
Also bei Programmen, die wirklich noch die X11-Server-Funktionen zum
Zeichnen, Text rendern usw. verwenden.
Aktuelle Toolkits rendern ihre ganze Oberfläche Client-Seitig (damit die
tollen Theme-Engines, Anti-Aliasing bei Fonts usw) funktionieren, und
tauschen nur Pixeldaten mit dem X11-Server aus.. unkomprimiert (da
normalerweise über SHM u.Ä.). Da ist VNC dann schneller.
Über 100MB Ethernet aufwärts ist editieren aber auch über das Netz sehr
zügig, ich mache das regelmäßig mit Cubieboard und OLinuxIno.
Nür mit DSL dazwischen ist es zäh, geht aber auch zur Not.
Εrnst B✶ schrieb:> rakudah schrieb:>> Mit X-Forwarding kannst du X11 Programme auf dem Pi ausführen und deren>> Ausgabe auf deinen Rechner umleiten. Wäre ressourcenschonender als VNC.>> War früher so, bzw. ist bei "alten" X11-Programmen noch so.> Also bei Programmen, die wirklich noch die X11-Server-Funktionen zum> Zeichnen, Text rendern usw. verwenden.
Das ist heute immer noch so.
> Aktuelle Toolkits rendern ihre ganze Oberfläche Client-Seitig (damit die> tollen Theme-Engines, Anti-Aliasing bei Fonts usw) funktionieren, und> tauschen nur Pixeldaten mit dem X11-Server aus..
Welches denn zum Beispiel? Zumindest Qt tut das nicht. Fontrendering mit
Antialiasing wird tatsächlich Client-seitig gemacht. Allerdings wird ja
nicht z.B. beim Scrollen der Text jedesmal komplett neu gerendert,
sondern steckt in einer Pixmap, die dann bequem serverseitig verschoben
wird.
