IDE C auf OpenBSD-current

mogbo

Banned
Hallo,
welche IDE würde ihr einem C Anfänger empfehlen, die auf OpenBSD(-current) stabil läuft. Hat jemand eine Ahnung was die OpenBSD Entwickler nutzen? Habe mit code::blocks und netbeans die Erfahrung gemacht, dass zwar Packete existieren, diese aber nicht wirklich stabil laufen, zumindest auf current.

Meine Anforderungen kenne ich nicht, hoffe ihr wisst was ihr euch anfangs von einer IDE gewünscht hättet
 
Die meisten OpenBSD-Entwickler nutzen vi / vim oder mg / emacs.

Fuer OpenBSD und c braucht man eigentlich keine IDE. Falls es doch eine sein soll, koenntest Du mal geany ausprobieren. Die ist relativ leichtgewichtig und soll auch stabil sein und per plugins erweiterbar. Bluefish faellt mir auch nocht ein. QT-Creator waere auch noch etwas, wenn auch um einiges schwergewichtiger. Diese IDE habe ich eine Zeit lang unter OpenBSD fuer ein spezielles Projekt genutzt und lief bei mir sehr stabil. Mit code:blocks habe ich unter jedem OS schlechte Erfahrungen bezueglich Stabilitaet gemacht.
 
Wenn Du mit C beginnst, reicht vollkommen ein gut eingestellter vim.

Es gibt in C soviel zu lernen und zu probieren, dass man seine Energie nicht auch noch mit kryptischen IDEs vergeuden sollte

Das ist natürlich nur meine ganz persönliche Meinung, die sicher auch nicht die der Mehrheit ist;-)
 
Die meisten OpenBSD-Entwickler nutzen vi / vim oder mg / emacs.
Wenn Du mit C beginnst, reicht vollkommen ein gut eingestellter vim.
Vielen dank, damit kann ich gut leben

Fuer OpenBSD und c braucht man eigentlich keine IDE.
Hat das einen speziellen Hintergrund?

Werd ich mir mal im Hinterkopf behalten
 
Wenn man ein Supergedächtnis hat und alle Signaturen auswendig lernt, dann braucht man keine IDE. Andernfalls ist der schnelle Wechsel zwischen Header- und C-Dateien oder sinnvolle Integration eines Debuggers Gold wert.
 
Selber habe ich mit Geany gute Erfahrungen gemacht. Es gibt einige sinnvolle plugins für Geany. Ein IDE für C wäre jetzt doch wie mit Kanonen auf Spatzen zu schießen. Schließlich wird in der Regel mit C keine GUI Programmierung vorgenommen. EIne IDE ist sinnvoll, wenn GUI Programmierung einen visuellen Formulardesigner erfordert. Qt hat das und Netbeans für Swing Gui Forms auch. Da ist es dann ja auch sinnvoll. Syntax Highlight und Codevervollständigung wären sinnvoll, eine Code Schnipsel Verwaltung fände ich gut. Für C würde jeder einfache Texteditor reichen, Geany jedoch kann man sinnvoll vorkonfigurieren, so das einem doch dei Arbeit etwas erleichtert wird.
 
Ob man nun eine komplette IDE oder einen einfachen Editor will, ist letztendlich eine Frage der individuellen Arbeitsweise. Ich habe jahrelang auch nur Vim genutzt, bin dann aber vor inzwischen etwa 3 Jahren auf die Jetbrains IDE-Familie gewechselt. Vor allem das sehr gute Codeverständnis der Tools, was wesentlich besser als cscope und co. ist, war ausschlaggebend. Dinge wie Debugger-Integration nutze ich hingegen kaum bis gar nicht.

Ich habe es nun nicht probiert, aber wahrscheinlich dürfte Jetbrains Clion auf OpenBSD funktionieren. Das ist letztendlich einfach nur eine ganz normale Java-Anwendung, die problemlos mit OpenJDK (sollte allerdings einigermaßen aktuell sein) läuft. Allerdings muss man auf nicht offiziell unterstützten Plattformen eventuell das Startscript einmal treten und man verliert einige auf native Bibliotheken zurückgreifende Funktionen. Die offizielle Anleitung für FreeBSD müsste auch auf OpenBSD anwendbar sein: https://intellij-support.jetbrains.com/hc/en-us/articles/206525024-How-to-start-CLion-on-FreeBSD-
 
Für C++ kann QtCreator inzwischen tatsächlich mit CLion mithalten, in den letzten paar Releases hat deren Clang integration die von CLion gefühlt überholt. Andererseits mag ich diese Java-basierten Monster allgemein nicht, die fühlen sich für mich immer so träge an.
Allerdings kommt QtCreator mit reinem C nicht so gut klar, man kann zwar dem Code Model mitteilen, dass es sich um reines C handelt, aber der Rest der IDE tut noch immer so als wäre es C++. Daher wäre auch meine Empfehlung, einfach vim oder einen fortgeschrittenen grafischen Editor wie gEdit oder Kate zu verwenden. Solange der Editor ein Plugin-System hat ist ihm normalerweise auch recht schnell das Einlesen von ctags-Dateien beigebracht, damit hat man dann auch einen Index und kann schnell zwischen Deklarationen und Definitionen springen etc.
 
Nochmal danke an alle

Daher wäre auch meine Empfehlung, einfach vim oder einen fortgeschrittenen grafischen Editor wie gEdit oder Kate zu verwenden. Solange der Editor ein Plugin-System hat ist ihm normalerweise auch recht schnell das Einlesen von ctags-Dateien beigebracht, damit hat man dann auch einen Index und kann schnell zwischen Deklarationen und Definitionen springen etc.
Ich werde für meine C Anfänge nun wohl erstmal vi wählen und schauen wie weit ich damit komme, ob ich künftig dann auf vim wechseln werde (http://www.alexeyshmalko.com/2014/using-vim-as-c-cpp-ide/) wird sich hoffentlich schnell rauskristalisieren.
 
vi hat kein Pluginsystem im eigentlichen Sinne.
Bis auf syntaxhighlighting, was ich ohnehin höchstens zum debuggen und nicht zum Schreiben verwende sah ich bisher keinen Sinn der für vim spricht. Da ich aus guter Quelle erfahren habe, dass sich die Sprachfeatures in Grenzen halten, werde ich auch erstmal für den Lerneffekt auf Wortvervollständigungen verzichten.

Die restlichen Einstellungen, welche im Guide genutzt werden sind auch in einer .exrc möglich, somit ist vim eher Zukunftsmusik (sobald ich halt auf plugins "angewiesen" bin).

Da ich wohl anfangs in einer OpenBSD-VM programmieren werde ist mir vi doppelt recht, denn es liegt simpel und einfach schon im Baseinstall und wird somit nach meiner Erfahrung niemals buggy. Seit vmd hab ich wirklich gefallen an Wegwerf-VMs gefunden (trial and error).
 
Für vi / vim kann ich vier gut gemeinte Tipps geben:


1: vim mag auf den ersten Blick kryptische Kommandos haben, aber es ist eine Sprache. Einmal als Beispiel:
    • 'gq' -> Formatiere neu.
    • 'ap' -> "A Paragraph", also Kommando auf einen Absatz anwenden.
    • 'gqap' -> "Format a Paragraph", also den aktuellen Absatz neu konfigurieren.
Es ist daher eine gute Idee sich klarzumachen welche grundsätzlichen Elemente vim unterstützt und wie sie kombiniert werden können. Dann sind Dinge wie ''ay5j gar nicht mehr so schlimm, wie sie auf den ersten Blick erscheinen mögen. Dazu gehört auch die Sprache zu sprechen, wie sie gedacht ist. Also Navigation über h, j, k und l und nicht über die Cursortasten. Und auch die Hand von der Maus zu lassen.


2: Nehme vim und nicht vi. Ich weiß, nun kommen gleich die Puristen. "vi reicht mir seit fast 40 Jahren!". Oder "Unix wurde in ed geschrieben!". Vielleicht sogar "Ich habe eine magnetische Nadel und eine 8 Zoll Diskette!". Nur unter dem Strich ist vim nach heutigen Maßstäben wesentlich komfortabler und auch logischer aufgebaut als der klassische vi. Vor allem kann man einfach mal ":set nocompatible" eingeben, und schon muss man sich nicht mehr vor nun wirklich fast 40 Jahren getroffenen, aus Ressourcenmangel resultierenden Designentscheidungen und zu Features avancierten Bugs rumärgern.


3: Beginne mit einer leeren .vimrc und baue deine eigene Konfiguration, sprich übernehme nicht ungesehen irgendwelche fertigen Konfigurationen aus dem Netz. Denn vim ist extrem konfigurierbar, insgesamt sind es weit über 1000 vorgegebene Optionen, dazu kommt die Möglichkeiten mit Scripten nahezu alles was das Herz begehrt umzusetzen. vim lässt sich damit wie kaum ein anderes Tool an den eigenen Workflow anpassen, was sich andere Leute für ihren Workflow ausgedacht haben, passt daher in den meisten Fällen nicht auf einen selbst.


4: Sei mit Plugins / Scripten vorsichtig. Jedes Script macht den Editor langsamer, manchmal beeinflussen sie sich auch gegenseitig, was dann zu schwer erkennbaren Problemen führt. Das wird hoffentlich mit vim 8.0 mittelfristig besser. Ich habe außerdem für mich mal geschworen, dass ich nur noch in Vimscript geschriebene Scripte nehme und nichts mehr in Perl, Python, Ruby, TCL oder Schlimmeren. Damit umgeht man schon mal die unendlichen Freuden nicht mehr funktionierender Scripte, weil sich in irgendeinem defekten Interpreter mal wieder was inkompatibel geändert hat. Oder das man das halbe Debian-Repo installieren muss, weil der minimale und an sich ausreichende vim den Interpreter für eine der benötigten Sprachen nicht hat. Außerdem sollten Scripte grundsätzlich per Plugin-Manager installiert werden, denn damit kann man sie schmerzfrei aktualisieren und auch wieder entfernen. vim 8.0 bringt endlich eine eingebaute Lösung mit, ich nutze aber noch Pathogen.


Und zum Schluss, in Widerspruch zu Tipp 3, hier meine vim-Konfiguration: https://github.com/Yamagi/vimrc
 
Da möchte ich doch mal fachlich begründeten Einspruch erheben:

2: Nehme vim und nicht vi. Ich weiß, nun kommen gleich die Puristen. "vi reicht mir seit fast 40 Jahren!".

Der nvi ist weit unter 40 Jahren alt und für manche Dinge eben deutlich schmerzfreier zu benutzen als Vim; zumal davon auszugehen ist, dass sich die Bedienung von nvi in absehbarer Zeit nicht noch zwanzigmal ändern wird, während in der Vim-Welt ja nicht mal ein Konsens über den Umgang mit Plugins gefunden werden kann. Als ich noch Vim benutzt habe, waren Pluginmanager noch selten, heute gibt es allein drei oder vier aktiv gepflegte gleichzeitig. Dazu kommt, dass Vim eben nicht gleich Vim ist. Es ist höchst unwahrscheinlich, dass du auf zwei verschiedenen Systemen einen mit identischen Flags kompilierten Vim vorfindest, und davon hängt dann eben auch ab, wie gut deine Konfiguration dort funktioniert.

Dazu kommt, dass die Sprachfunktionen von Vim nicht gerade zu den besten zählen (ich krame jetzt mal ganz bewusst nicht meinen Vergleichseditor heraus ;)), gerade bei der Codeeinrückung scheint er eher nach Zufall als nach Logik zu arbeiten. Ich ganz persönlich empfinde Vim als ziemlich nervig und habe ihn bei mir grundsätzlich nicht mehr installiert.
 
Ich bleibe auch bei Vi. Die Gründe wurden hier schon benannt. Er ist bei der Grundinstallation schon mit an Bord. Ich habe mich gerade dazu entschlossen, meinem OpenBSD Workshop ein Kapitel über Vi zu spendieren und eine Befehlsreferenz für die Basics hinzuzufügen.
 
Ja, gut. Wenn man nvi als Grundlage nimmt und Elvis mal ignoriert, sind es erst 23 Jahre. Davon inzwischen 17 ohne Release, wobei die Releases nach 1.79 sowieso keine nennenswerte Verbreitung mehr gefunden haben. Alle nennenswerten nvi-Nutzer haben das Ding daher de facto geforkt und eigene Änderungen eingefügt, wodurch nvi in der Praxis oft ungleich nvi ist. Wobei das zugegeben kaum auffällt. Aber hey, zumindest FreeBSDs Fork hat inzwischen "with sufficient multibyte encoding support" und ab 11.0 kann ich endlich meinen Namen eintippen, speichern und wieder laden ohne das es Fehlermeldungen hagelt. Es geht eben voran... :)

Im Ernst: Nichts gegen vi. Wenn jemand damit glücklich ist, warum nicht. Aber im Jahr 2017 mit klassischem vi zu beginnen verlangt dann in meinen Augen doch eine Menge Masochismus, vim zumindest etwas weniger. Wenn ich mein Muskelgedächtnis noch mal neu prägen könnte, würde es aber gleich ein ganz anderer Editor werden. Sublime und seine Klone stellen da z.B. eine interessante Wahl da.
 
Ich bin ja nun wirklich ein Fan vom vi - und bin sogar der Meinung, dass jeder der sich mit unixoiden OS befasst die Basics von vi kennen sollte - obwohl ich damit meine Mitmenschen auch ziemlich nerve;-)

Aber ich würde niemals auf die Idee kommen, außer bei der Installstion - bevor ich ein pkg install vim - absetzen kann, den vi statt dem vim zu nehmen!
Install vim und kopieren meiner .vimrc sind die ersten Dinge die ich bei der Installstion mache, sobald die Kiste im Netz ist.

Aber freiwillig und ohne Not den vi statt den vim zu nutzen?

Wozu soll das gut sein?
 
Wozu soll das gut sein?

Zum Ressourcensparen, weil man den ganzen Featureblödsinn vom Vim einfach mal nicht braucht, wenn man nur mal eben ein bisschen Konfiguration oder Code editieren will. Gerade unter BSD wird ja gern nicht zur größten Keule gegriffen. (Den mg von OpenBSD finde ich allerdings ebenso befremdlich wie den ee von FreeBSD. Irgendwie nichts für mich.)
 
Naja ... ein make install von vim auf einer langsamen Maschine ist natürlich schon nervend - aber mit Binaries ist das ja kein Thema mehr.
 
Aber freiwillig und ohne Not den vi statt den vim zu nutzen?
Vim ist nicht in der base von OpenBSD enthalten und findet sich somit niemals auf einem System außerhalb meines Desktops, selbst dort eher in einer VM

Auf dem Desktop gebe ich dir recht, leider war ich bisher auf keines der Features von vim wirklich heiß, somit wurde es auch nicht installiert und vi genutzt, ob sich das nun mit C ändert ist gut möglich, aber setze ich mir auf keinen Fall als Ziel

Aber im Jahr 2017 mit klassischem vi zu beginnen verlangt dann in meinen Augen doch eine Menge Masochismus, vim zumindest etwas weniger.
Der innere Nerd schreit nach vi/vim, die Vernunft ist dann nichtmehr zu hören
 
Äh, mit Verlaub, aber 94 MiB RAM im Leerbetrieb sind nun kein "Leichtgewicht".
Na gut, gefühltes Leichtgewicht (im Vergleich zu IDEs)! :rolleyes: Tatsächlich interessieren mich derartige Sachverhalte eher wenig. Hauptsache es ist gut, schnell und zuverlässig, - und das trifft zu!

Nachtrag: Tatsächlich wundert mich die Geschwindigkeit von SublimeText ein wenig da es intern wohl eine Menge Python verwendet was vermutlich auch der Grund für den hohen Speicherbedarf ist.
 
Zuletzt bearbeitet:
Zurück
Oben