Hallo! Ich brauch mal in paar Tipps von euch, damit ich da nicht stunden mit Programmen installieren und testen vergeude. Die Problemstellung: ich möchte ein Programm (C++) schreiben, welches sowohl unter Linux wie auch unter Windows läuft (also für das jeweilige Betriebssystem kompiliert und nicht mit Wine oder so!). Da stellt sich die Frage, was ich für eine Toolchain verwenden soll. Ich habe mir gedacht, ich installier Eclipse mit CDT und als Compiler: MinGW. Für die graphische Oberfläche würde ich gerne die GTK-Libs verwenden. Ist es damit (problemlos) möglich solche Programme zu erstellen und unter einem Betriebssystem für Linux und Windows zu kompilieren? Braucht man da noch etwas (Cross Compiler) oder ist der schon dabei? Oder ist es einfacher die Toolchain auf beiden Betriebssystemen zu installieren und das Projekt zu öffnen im jeweiligen Betriebssystem und dort kompilieren? Ich habe da null Erfahrung und würde gerne etwas von euch hören! Vielen Dank!
kein_plan wrote: > unter einem Betriebssystem für Linux und Windows zu kompilieren? Braucht > man da noch etwas (Cross Compiler) oder ist der schon dabei? Oder ist es > einfacher die Toolchain auf beiden Betriebssystemen zu installieren und > das Projekt zu öffnen im jeweiligen Betriebssystem und dort kompilieren? Für mich war es immer einfacher auf jedem OS eine eigene Toolchain zu haben. Schon alleine des Debuggings wegen.
wxWidgets ist wie Gtk oder auch Qt ein plattformunabhängiges GUI-Toolkit, aber es hilft ebensowenig beim Erzeugen von Binaries für andere Plattformen. Für die bräuchte es einen "Cross-Platform"-Compiler (keinen Crosscompiler, denn die Prozessorarchitektur bleibt ja i.d.R. die selbe), der sowohl die unterschiedlichen Betriebssystemlibraries nebst zugehöriger Headerdateien vorhält als auch unterschiedlichen Startupcode zu den Binaries linkt sowie die unterschiedlichen OS-Loaderformate unterstützt. Es gibt wohl Systeme, die so etwas können; der Basic-Compiler "RealBasic" soll sowohl MacOS-, Linux- als auch Windows-Binaries erzeugen können. Weniger Probleme hat man aber mit Sicherheit mit nativen Toolchains, alleine schon des Testens und Debuggens wegen.
Qt ist ganz schmerzlos. Es gab/gib Win32 Installer von Trolltech, welche gleich auch noch MinGW installierten, da hat man dann gleich alles was man braucht, um Qt-Software unter Windows zu kompilieren. Unter Linux reicht es meistens, die Qt-Pakete der jeweiligen Distribution zu installieren. Ich würde sowieso Qt gegenüber GTK bevorzugen, der Code ist weniger hässlich und der GUI-Editor ist definitiv besser, lizenztechnisch gibt es auch keinen Grund mehr, GTK Qt vorzuziehen. Crosscompilieren ist häufig eher mühsamer. Mit MinGW kann man allerdings ganz gut auf einer Linuxkiste Windowssaftware Crosscompilieren.
Und mit Wine kannst du deine crosscompilierten Win32 Binaries gleich auch noch auf der Linuxkiste testen. Ersetzt aber nicht wirklich Tests auf dem echten Windows.
> lizenztechnisch gibt es auch keinen Grund mehr, GTK Qt vorzuziehen.
Naja, QT ist GPL, d.H. um das in Komerzieller Software einzusetzen muss
man zahlen. Ist zwar recht billig im Vergleich zur Zeitersparnis, die
die QT mit sich bringt, ist aber trotzdem erstmal eine Investition...
Der TE wollte ja eh GTK verwenden, wahrscheinlich hat er da schon
Erfahrung mit... in dem Fall würd ich für Windows MinGW verwenden, und
den Rest der Entwicklungsumgebung (eclipse etc...) braucht er dann eh
nur unter Linux.
> Naja, QT ist GPL, d.H. um das in Komerzieller Software einzusetzen muss > man zahlen. Ist zwar recht billig im Vergleich zur Zeitersparnis, die > die QT mit sich bringt, ist aber trotzdem erstmal eine Investition... Schwachfug. Um QT in kommerzieller einzusetzen, muss man halt den Quellcode offen legen. GNU GPL Software kann verkauft werden ist also auch für kommerzielle Software geeignet.
OK, dann werde ich wohl auf den beiden Systemen eine eigene Toolchein vorsehen. Das mit GTK war eigentlich nur mal ein Vorschlag, damit man eine Diskussionsgrundlage hat. Aber ich sehe, dass ich eher QT nehmen sollte. Ich habe (wie auch jemand vorgeschlagen hat) auch was von wxWidgets gehört. Wie ist das denn im Vergleich zu QT? Dann würde ich Eclipse + CDT (IDE), MinGW (Compiler) und QT für die Oberfläche nehmen, kommt das gut? Gibts ja alles für Windows und Linux... Vielen Dank bis hie hin für die tolle Unterstützung
@Rufus: >wxWidgets ist wie Gtk oder auch Qt ein plattformunabhängiges >GUI-Toolkit, aber es hilft ebensowenig beim Erzeugen von Binaries für >andere Plattformen. Für die bräuchte es einen "Cross-Platform"-Compiler >(keinen Crosscompiler, denn die Prozessorarchitektur bleibt ja i.d.R. >die selbe), der sowohl die unterschiedlichen Betriebssystemlibraries >nebst zugehöriger Headerdateien vorhält als auch unterschiedlichen >Startupcode zu den Binaries linkt sowie die unterschiedlichen >OS-Loaderformate unterstützt. Zwei Anmerkungen: 1. Crosscompiler ist nicht fest definiert" Meistens wird damit aber ein Compiler bezeichnet, der für eine andere Plattform, also durchaus auch den gleichen Prozessor, compiliert. 2. Weder wxWidgets noch Gtk noch Qt sind plattformunabhängig, sie sind plattformübergreifend, also nicht auf allen Plattformen lauffähig, sondern nur auf einigen. Bitte etwas präziser!
Gibt es einen besonderen Grund, dass Du C++ verwenden mußt? Mit JAVA hättest Du dieses Problem gar nicht!
> Dann würde ich Eclipse + CDT (IDE), MinGW (Compiler) und QT für die > Oberfläche nehmen, kommt das gut? Gibts ja alles für Windows und > Linux.. MinGW brauchst du nur für Windows. Für Linux nimmst du den normalen gcc. Was Eclipse betrifft, keine Ahnung, benutze ich nicht. > Naja, QT ist GPL, d.H. um das in Komerzieller Software einzusetzen muss > man zahlen. Aha. Muss ich wohl die (L)GPL nochmals genau durchlesen.
Wie Miu schon meinte: GPL heisst nicht, dass man das nicht kommerziell einsetzen kann. Man kann das auch verkaufen. Nur muss man dann den Quellcode kostenfrei zur Verfügung stellen, sobald Du das Programm verkaufst / öffentlich verfügbar machst. Wenn man das nicht will gibt es von Qt auch eine Version die nicht unter der GPL steht, dann kannst Du Deinen Quellcode geheimhalten. Die meisten Firmen bei denen Du arbeitest werden Dir nicht erlauben, den Quellcode offenzulegen, wegen Firmengeheimnissen, KnowHow soll bewahrt werden etc.
GTKmm haette noch den Vorteil, dass es relativ modernes C++ ist. Damit wuerde dein Programm uebrigens auch unter Mac OS X laufen. Die groesste Gefahr die dann noch besteht, ist, dass du aus Versehen Datentypen die groesser als 1 Byte sind byte-weise liest oder schreibst, also sowas wie int n = 42; write(reinterpret_cast<char*>(&n), sizeof(n)); Wenn du plattformuebergreifend programmieren moechtest, musst du sowas vermeiden, weil die Byte-Reihenfolge in C++ unspezifiziert ist (Stichworte sind Big endian, Little Endian).
Hallo, wie wäre es mit FLTK? Ich selbst verwende es sehr gerne. Eigene GUI-Objekte lassen sich überraschend einfach erstellen. Vorteil=Nachteil: die GUI sieht unter WIN genau so aus wie unter Linux Nachteil: es sind nicht sooo viele GUI-Elemente vorhanden -> Vorteil: standalone EXE zwischen 300-500kB (unter Windows) www.fltk.org mfg Weinga-Unity
> 2. Weder wxWidgets noch Gtk noch Qt sind plattformunabhängig, sie sind > plattformübergreifend, also nicht auf allen Plattformen lauffähig, > sondern nur auf einigen. Es gibt keine Software, die auf allen Plattformen lauffähig ist, also braucht man dafür auch keinen eigenen Begriff. > GTKmm haette noch den Vorteil, dass es relativ modernes C++ ist. > > Damit wuerde dein Programm uebrigens auch unter Mac OS X laufen. Das würde es mit Qt aber auch. Schön bei Qt ist, daß es sich sehr gut in den jeweiligen Desktop einpasst, sowohl optisch, als auch funktional. Es ist auch recht einfach, Programme zu schreiben, die unter Linux, Windows und MacOS laufen, da Qt viele Plattformeigenschaften hinter entsprechenden Klassen wegkapselt. Ich schreibe mit Qt Software, die unter Linux und Windows laufen soll und habe mir dazu eine cross-build-Umgebung aufgesetzt. So kann ich unter Linux das Programm mit einem einzigen make-Aufruf sowohl für Linux, als auch für Windows übersetzen. Das geht durchaus. mingw ist zumindest bei Debian und den darauf basierenden Distros (ich verwende Kubuntu) schon als fertiges Paket verfügbar, sodaß man das nicht selbst bauen muß. Dann muß man sich, wenn man qmake (den Makefile-Generator von Qt) verwendet, noch ein qmake-Spec-File für die Cross-Übersetzung bauen. Die Windows-Version von Qt kann man sich bei www.trolltech.com als fertigen Installer runterladen und dann in Wine installieren, damit man alle Header und libs hat. Man muß nur darauf achten, unter Linux dieselbe Qt-Version zu verwenden, da ja einige Tools dabei sind wie uic und moc. Wenn man unter Linux baut, werden die dort installierten Tools dann auch für das Übersetzen für Windows verwendet, und das klappt u.U. nicht, wenn die Versionen da nicht gleich sind.
> Ich habe mir gedacht, ich installier Eclipse mit CDT und als > Compiler: MinGW. Für die graphische Oberfläche würde ich gerne die > GTK-Libs verwenden. Ich habe mit GTK+, GTKmm und GCC gute Erfahrungen gemacht. GTKmm ist ein sehr sauber gemachter C++-Wrapper für GTK+ und hält die oft kritisierten Castereien und Voidpointerkonstruktionen des C-APIs von GTK+ vom Programmierer komplett fern. > Braucht man da noch etwas (Cross Compiler) oder ist der schon dabei? Crossentwicklung habe ich nicht probiert. Die Linux-Version wird unter Linux kompiliert, die Windows-Version und Windows. Als Compiler unter Windows habe ich MinGW benutzt. Ich entwickle primär unter Linux, das Testen unter Windows ist aber kein Problem, da die unter Linux getestete Software praktisch immer auf Anhieb auch unter Windows lief.
du könntest auch Java + SWT nehmen... Java ist wie C++, in einigen Sachen sogar besser.
Wie wäre es mit Tcl/Tk für die Oberfläche? Das läuft problemlos auf Win/Linux/Mac und vor allem unter BSD-Lizenz. GUIs in C oder C++ zu schreiben, halte ich für viel zu umständlich und fehleranfällig. Einfach ist genial :-) Christoph - der praktisch nur noch in Tcl/Tk programmiert (auch Mikrocontroller)
> Christoph - der praktisch nur noch in Tcl/Tk programmiert (auch > Mikrocontroller) Ja Tcl/Tk ist cool und einfach! (alles ist ein string:-) ) Aber wie programmierst Du Mikrocontroller damit?
Emanuel B. wrote: >> Christoph - der praktisch nur noch in Tcl/Tk programmiert (auch >> Mikrocontroller) > > Ja Tcl/Tk ist cool und einfach! (alles ist ein string:-) ) > Aber wie programmierst Du Mikrocontroller damit? Ich habe im Prinzip einen kleinen, auf AVR-Controller zugeschnittenen Interpreter gebaut, der dann beliebigen Tcl-Code (sowohl im ControllerFlash, aber eben auch in externem Flash/RAM) ausführen kann. Port-Befehle etc. sind dann eben Tcl-Befehle, ebenso wie Interrupts. Das Schöne ist, dass man wirklich hervorragend Debuggen kann. Ebenso sind Eingriffe und komplette Änderungen des Codes "on-the-fly" möglich. Ich habe so deutlich reduzierte Entwicklungszeiten gegenüber C (alleine schon durch die entfallende Neukompilierung). Die wenigen wirklich zeitkritischen Dinge (und man ist erstaunt, wie wenig das sind :-) kann man Tcl-gewohnt kinderleicht als C-Funktionen einbinden. Die Ausführungsgeschwindigkeit ist selbst ohne vorcompilierten Code mehr als ausreichend und ich kann nun 99% aller Programme (PC UND Controller) im geliebten Tcl/Tk schreiben :-) Außerdem ist es angenehm, wenn man nicht auf jedes Byte Programmcode achten muss (z.B. mit nem AT45 mit 4MB Flash :-) Christoph - Einfach ist genial
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.