Mit Verlaub, aber ich verwende meine IDE auf der Plattform, wo ich am komfortabelsten und besten arbeiten kann. Die entwickelte Software selbst kann dann auf der jeweiligen Plattform laufen, wo sie soll. Und meinetwegen auch bauen, obwohl das meistens auf dem schnellen Buildserver gemacht wird, der Performance halber bei größeren Projekten.
Mit der IDE zu der Produktzielplattform mitzuziehen, warum sollte man das machen? Wer entwickelt für Android mit einer IDE auf einem Android-System? Ganz zu schweigen von Embedded-Systemen... Nur weil Windows selbst auch ein Desktop ist, ist das kein Grund, da anders zu denken. Kann man alles von Remote machen. bauen, deployen, testen, debuggen.
Ich teste die Software auch unter den anderen Plattformen, ich compile sie nicht nur dafür. Außerdem wechsele ich zwischen den Plattformen hin und her, vor allem auf meinem Privatrechner. Die ganzen Spiele spiele ich bspw. nur unter Windows, deswegen sind auch Programme wie Teamspeak und Steam bei mir nur unter Windows installiert und nicht unter Linux. Über die Chatfunktionen dieser Programme treffe ich meine Freunde für Multiplayerspiele, wenn ich aber warten muss, dann benutze ich den Leerlauf und tue noch ein bisschen Coden und schon brauche ich die IDE auch unter Windows.
Mit der IDE zu der Produktzielplattform mitzuziehen, warum sollte man das machen?
Würden die KDevelop Entwickler das machen, dann hätte der Windows Port weitaus weniger Bugs. Es macht also Sinn auch mal damit unter der anderen Zielplattform zu arbeiten.
Meine Spiele spiele ich nicht Remote, auch wenn's mit NVidia Shield Lösungen dafür gäbe, aber da müsste ich dann einen weiteren Rechner vorhalten. Das kannst du also vergessen.
Mein privater Rechner läuft primär unter Windows. Andere Betriebssysteme laufen dann unter VirtalBox. Falls ich Code unter einem anderem Betriebssystem testen muss, was selten passiert, wird kurzerhand ein virtuelles System gestartet. Das funktioniert für mich am besten. Für Dualboot habe ich keinen Nerv mehr. Und Cross Compiler muss ich auch keine nutzen.
> Crossplattformentwicklungen
Mit Verlaub, aber ich verwende meine IDE auf der Plattform, wo ich am komfortabelsten und besten arbeiten kann. Die entwickelte Software selbst kann dann auf der jeweiligen Plattform laufen, wo sie soll. Und meinetwegen auch bauen, obwohl das meistens auf dem schnellen Buildserver gemacht wird, der Performance halber bei größeren Projekten.
Mit der IDE zu der Produktzielplattform mitzuziehen, warum sollte man das machen? Wer entwickelt für Android mit einer IDE auf einem Android-System? Ganz zu schweigen von Embedded-Systemen...
Nur weil Windows selbst auch ein Desktop ist, ist das kein Grund, da anders zu denken. Kann man alles von Remote machen. bauen, deployen, testen, debuggen.
Das ist deine Arbeitsweise.
Ich teste die Software auch unter den anderen Plattformen, ich compile sie nicht nur dafür.
Würden die KDevelop Entwickler das machen, dann hätte der Windows Port weitaus weniger Bugs.Außerdem wechsele ich zwischen den Plattformen hin und her, vor allem auf meinem Privatrechner.
Die ganzen Spiele spiele ich bspw. nur unter Windows, deswegen sind auch Programme wie Teamspeak und Steam bei mir nur unter Windows installiert und nicht unter Linux.
Über die Chatfunktionen dieser Programme treffe ich meine Freunde für Multiplayerspiele, wenn ich aber warten muss, dann benutze ich den Leerlauf und tue noch ein bisschen Coden und schon brauche ich die IDE auch unter Windows.
Es macht also Sinn auch mal damit unter der anderen Zielplattform zu arbeiten.
Meine Spiele spiele ich nicht Remote, auch wenn's mit NVidia Shield Lösungen dafür gäbe, aber da müsste ich dann einen weiteren Rechner vorhalten. Das kannst du also vergessen.
Mein privater Rechner läuft primär unter Windows. Andere Betriebssysteme laufen dann unter VirtalBox. Falls ich Code unter einem anderem Betriebssystem testen muss, was selten passiert, wird kurzerhand ein virtuelles System gestartet. Das funktioniert für mich am besten. Für Dualboot habe ich keinen Nerv mehr. Und Cross Compiler muss ich auch keine nutzen.
Intessant, was du so machst. Hätte ich nicht gedacht.