Hypercell ein ] Hypercell aus ] Zeige Navigation ] Verstecke Navigation ]
c++.net  
   

Die mobilen Seiten von c++.net:
https://m.c-plusplus.net

  
C++ Forum :: Linux/Unix ::  Cross Development, bzw. womit entwickeld für Linux?     Zeige alle Beiträge auf einer Seite Auf Beitrag antworten
Autor Nachricht
dadiduck
Mitglied

Benutzerprofil
Anmeldungsdatum: 10.08.2016
Beiträge: 22
Beitrag dadiduck Mitglied 10:49:12 30.01.2017   Titel:   Cross Development, bzw. womit entwickeld für Linux?            Zitieren

Hallo,
ich werde in Zukunft wohl auch für Ubuntu entwicklen müssen/dürfen und suche nach Entwicklungsumgebungen f. Linux. Zu Hause bin ich seit Jahren meist auf Windows (neben 2 Embedded OS-Systemen). Sprache ist C/C++

Es gibt da ja unterschiedliche Ansätze. MS hat ein Plugin für VS, ähnlich zu
dem von http://sysprogs.com, mit dem sich unter Windows Entwickeln & Debuggen lässt. VS hat eine Verbindung zu einem Linux-System, compiliert wird dann tatsächlich auf dem Target-System. (es gibt wohl noch 1-2 weitere Anbieter von solchen Plugins)

Dann gibt es ja auch den VSCode von MS, der auf diversen Plattformen läuft (hab ich aber noch nicht getestet).

Wie / womit entwickelt ihr für Linux? Wie gesagt, ich bin jetzt schon Jahre die MS-Umgebung gewohnt, auf vi, emacs usw. wollte ich nur in "Notfällen" zurückgreifen müssen :-)
icarus2
Mitglied

Benutzerprofil
Anmeldungsdatum: 20.09.2009
Beiträge: 1735
Beitrag icarus2 Mitglied 12:25:44 30.01.2017   Titel:              Zitieren

CLion von JetBrains ist (auf Linux) die beste IDE fuer C und C++, die ich kenne. Allgemein hat JetBrains tolle IDEs.

Alles andere wie Eclipse oder CodeBlocks ist einfach nur Bullshit - da ist man mit vim (und ein paar Plugins) besser bedient.
RHBaum
Mitglied

Benutzerprofil
Anmeldungsdatum: 09.04.2003
Beiträge: 1324
Beitrag RHBaum Mitglied 12:35:50 30.01.2017   Titel:              Zitieren

Die Frage ist, wie "tief" du auf Linux(besonderheiten) eingehen musst.

Programmierst Du auf ner "abstrakten" Ebene, also wo Du bibs verwendest, die dir Plattformuanbhängigkeiten bieten (z.b. boost, Qt und co), dann würd ich weiter unter deinem bisherigen System entwickeln (windows + VS) aber extensiven gebrauch von Buildgeneratoren und Konfig Managment Tools machen (cmake, qmake, gradle und co ...).

Dann kannst deine Programme schon unter windows entwickeln und musst unter Linux nur noch mittels den builgeneratoren bauen und "testen".
Falls doch mal unter linux dann ne Besonderheit Debuggen musst, kann man "fix" mit dem gdb auf kommandozeile rumeiern. Ist zwar nicht schnell und intuitiv, aber schneller als ne IDE aufzusetzen.

Hast mehr mit Linux zu tun oder musst Linux spezifische Dinge tun, dann ist das einarbeiten in ne IDE dein geringstes Problem .-)

WIe gesagt mit Buildgeneratoren hasst ne gute grundlage für plattformunabhaengige Konfigurationen, die geben dir dann auch die "Struktur" deiner Projekte vor.
Die IDE ist muss dann nur noch externe Builds unterstützen (das tun eh die meisten) ... und ist geschmackssache.
Eclipse, KDevelop, QtCreator netbeans + C++ Plugin etc, geht alles ....

Ciao ..
dadiduck
Mitglied

Benutzerprofil
Anmeldungsdatum: 10.08.2016
Beiträge: 22
Beitrag dadiduck Mitglied 13:20:36 30.01.2017   Titel:              Zitieren

Hallo,
also die Linux-Box (so nenne ich die HW mal) soll bestehende Embedded-Systeme ersetzten. Ich werde also diverse HW-Schnittstellen ansprechen (z.B. serielle Ports), Netzwerk-Programmieren (TCP-Sockets), wohl wird auch Multithreading zu benutzen sein.

"Tief" ist relativ, aber ich denke, das ist schon relativ systemnah.....

Spricht irgendwas gegen diese Plugins für VS? Auf den ersten (und zweiten) Blick scheint mir der Ansatz für einen Windows-Programmierer ziemlich attraktiv....
RHBaum
Mitglied

Benutzerprofil
Anmeldungsdatum: 09.04.2003
Beiträge: 1324
Beitrag RHBaum Mitglied 13:28:03 30.01.2017   Titel:              Zitieren

Naja, nativ debuggen ist immer noch was anderes als cross compilieren und remote debuggen.
Wenn wirklich "systemnah" unterwegs sein willst, wär es sicher von vorteil, gleich auf dem System nen debugger zu haben ...
Allerdings kenn ich mich mit Remote Debuggen ned wirklich gut aus ... Da können andere sicher bessere Tips geben.

Linux/Unix an sich ist schon spannend, besonders wenn man nur unter windows unterwegs war. Wenn das System wirklich besser kennen und verstehen lernen willst, sollest auch komplett da drunter entwicklen ....
Ich weiss nicht wie Performant deine BOX ist und obs Spass damit macht.
Soll das Teil eigentlich ne eigene GUI haben oder eher headless laufen ?

Zitat:
(z.B. serielle Ports), Netzwerk-Programmieren (TCP-Sockets), wohl wird auch Multithreading

Gibts für alles plattformunabhaengige Libs für (boost z.b.). Ist noch nix bei, weswegen man auf plattformunabhaengigkeit verzichten sollte ...

Ciao ...


Zuletzt bearbeitet von RHBaum am 13:37:06 30.01.2017, insgesamt 1-mal bearbeitet
dot
Mitglied

Benutzerprofil
Anmeldungsdatum: 20.05.2004
Beiträge: 6751
Beitrag dot Mitglied 14:10:20 30.01.2017   Titel:              Zitieren

Ich verwend unter Linux normalerweise Code::Blocks. Wenn ich das nächste Mal wieder mal mehr unter Linux arbeiten muss, werd ich mir vermutlich VS Code anschaun...

_________________
one point of view will never reveal the entire scene.
RHBaum
Mitglied

Benutzerprofil
Anmeldungsdatum: 09.04.2003
Beiträge: 1324
Beitrag RHBaum Mitglied 16:24:42 30.01.2017   Titel:              Zitieren

ups, da hab ich wohl was mit vsCode verwechselt ^^

wie gesagt lern mit Build-generatoren umzugehen, dann ist die IDE eher geschmackssache.
Erfahrungen haben wir mit:
eclipse - geht, aber es ist zeimlich viel Aufwand(geklicke) ein funktionierendes Eclispe-Projekt aus nem cmake zu erzeugen ... und norwalerweisse checkt man IDE Spezifisches zeugs ja nicht ein ....
Syntax Highlighting und CodeVervollständigung kommen fast an VS ran.
fühlt sich auch etwas "lahm" an

QtCreator / codeblocks / Anjuta - passt von der struktur her eher zu cmake/qmake projekten, also weniger IDE spezifisches zeugs zu pflegen ...
Hat so alles seine Vor und Nachteile ....
Syntax Highlighting und Assistenten sind lange ned so wie in VS.

CLion - hab ich nur kurz angetestet, ist selber cmake basierend, hab aber probleme gehabt, generische out of source builds in das projekt zu importieren ...
Ist sicher die Beste Lösung wenn du "nur" für das Zielsystem Projekte erzeugen willst.
Und war ne Weile her, als ich mir das angeschaut hab ...
Kosten beachten.

Ciao ...
Tuxist
Mitglied

Benutzerprofil
Anmeldungsdatum: 18.02.2007
Beiträge: 153
Beitrag Tuxist Mitglied 23:58:28 19.04.2017   Titel:              Zitieren

Schaue dir mal kdevelop an kommt visualstudio am nächsten würde ich mal behaupten.

https://www.kdevelop.org/
C++ Forum :: Linux/Unix ::  Cross Development, bzw. womit entwickeld für Linux?   Auf Beitrag antworten

Zeige alle Beiträge auf einer Seite




Nächstes Thema anzeigen
Vorheriges Thema anzeigen
Sie können Beiträge in dieses Forum schreiben.
Sie können auf Beiträge in diesem Forum antworten.
Sie können Ihre Beiträge in diesem Forum nicht bearbeiten.
Sie können Ihre Beiträge in diesem Forum nicht löschen.
Sie können an Umfragen in diesem Forum nicht mitmachen.

Powered by phpBB © 2001, 2002 phpBB Group :: FI Theme

c++.net ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de Werbekostenerstattung verdient werden kann.

Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info und www.c-plusplus.net enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt (vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden. Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.