Für eine grafische Qt Oberfläche suche ich eine Möglichkeit diese auch für Windows zu kompilieren, da der Kunde nun auch Windows (Mindestens windows 10 haben will). Normalerweise kompiliere ich alles in einer Docker Buildumgebung für diverse Linux Distributionen oder generiere im Container ein Appimage. Das geht auch dank Qemu für verschiedene Architekturen gut (Dann wird der ganze Docker Container mit QEMU ausgeführt und man kann ein Debian ARM container auf AMD64 laufen lassen).
Nach ein bisschen Recherche habe festestellt, dass es keine Möglichkeit zu geben scheint einen Windows Container unter Linux auszufüren.
Ich habe das bisher immer mit MSYS2 und Windows gemacht. Weiß jemand, ob es von Microsoft ein Image oder eine Umgebung gibt, die kostenlos nur zum Bauen von Software zur Verfügung gestellt wird. Ich will es ja nur laufen lassen und den Buildserver damit verbinden.
Weiß jemand, ob
es von Microsoft ein Image oder eine Umgebung gibt, die kostenlos nur
zum Bauen von Software zur Verfügung gestellt wird.
Es gibt eine kostenlose Windows-Version, die man drei Jahre lang verwenden kann. Das ist die 180-Tage-Testversion der Serverversion, die kann man ohne Anmeldung bei MS herunterladen.
Nach der Installation muss das Ding einmal das Internet sehen können, um sich zu "aktivieren", der Spaß muss dann alle 180 Tage wiederholt werden
(das geht mit "slmgr -rearm" aus einer Konsole mit Administratorrechten heraus, danach ist ein Reboot fällig).
Und das geht dann über etwa drei Jahre Gesamtlaufzeit.
Man braucht keinen "Key" und auch kein Microsoft-Konto dafür.
Diese Testversion kann man beliebig oft auf beliebig vielen Rechnern installieren, die 180 Tage zählen ab Installationsdatum.
für Windows zu kompilieren, da der Kunde nun auch Windows (Mindestens
windows 10 haben will).
Wo ist Dein Problem? Du stellst dem Kunden die Kosten für die Windows Build Umgebung mit in Rechnung und damit ist der Drops gelutscht. Das wird einfach in den Preis für die "Windows App" mit eingerechnet und gut is.
Das Hauptproblem ist es, die ganzen Libraries (Qt) und ihre Abhängigkeiten zusammen zu stellen.
Eine sehr gute Möglichkeit ist es, https://conan.io/ zu verwenden. Das kann dir vollautomatisch alle Abhängigkeiten für beliebige Plattformen herunterladen und dann kannst du dagegen linken. Du legst ein Profil für die Zielplattform an und wählst dieses für den Buildprozess aus und bekommst vollautomagisch alle Bibliotheken installiert.
In der Praxis ist es schon etwas fummelig bis es dann wirklich funktioniert, viele Pakete (Recipes) sind nicht wirklich gut auf Cross-Kompilieren ausgelegt. Kann also sein dass man diese reparieren muss. Aber wenn man das einmal hat funktioniert es wirklich gut und erspart viel Arbeit. Funktioniert auch sehr gut für CI-Builds.
Ich hatte das mal benutzt um eine Anwendung mit GLFW, Vulkan, Boost und diversen weiteren Bibliotheken unter Linux zu kompilieren für Linux, Windows, Mac OS, und Yocto Linux (ARM). Es gab gewisse Startschwierigkeiten aber als es dann lief war es super. Das ist schon ein paar Jahre her, wahrscheinlich funktioniert es mittlerweile besser.
Auch ohne Cross-Compilieren ist conan super, jede C/C++ Anwendung welche Bibliotheken braucht kann davon profitieren - man legt eine conanfile.txt, trägt die gewünschten Bibliotheken ein, passt die CMakeLists an, lässt "conan install" laufen und schwupps ist alles da, in exakt der gewünschten Version für die gewünschte Zielplattform für den gewünschten Compiler und die gewünschten Build-Optionen der Library selbst.
Die ISOs für Installationsmedien von Windows 10 und auch 11 kann man kostenfrei bei Microsoft downloaden. Zur kostenfreien und dauerhaften Aktivierung mit einer digitalen Lizenz von Microsoft gibt es auch noch immer entsprechende Tools im Web zu finden, weil eine Windows 10/11 Installation alles dafür enthält und Microsoft die Überprüfung der Aktivierung noch immer nicht richtig im Griff hat.
Man darf die ganz normalen ISO Images von Windows 10 drei Monate lang kostenlos verwenden. Und selbst danach funktioniert die Installation mindestens ein ganzes Jahr weiter. Nur ein paar klickibunti Einstellungen werden nach den drei Monaten blockiert.
Genausowenig wie man für ein Linux-Binary eine Build-Umgebung auf Linux
braucht, braucht man für ein Windows-Binary eine Build-Umgebung auf
Windows.
Ja, theoretisch. Dann schau dir mal an, wie viele Abhängigkeiten Qt unter Umständen haben kann. Bis man das alles funktionsfähig zusammen hat ... und dass auch noch regelmäßig aktualisiert ... kann ich gut verstehen, dass jemand lieber eine komplette Windows Installation nimmt und Qt nach Schema F installiert. Man bekommt so auch viel leichter Hilfe, wenn mal etwas nicht klappt.
Genausowenig wie man für ein Linux-Binary eine Build-Umgebung auf Linux
braucht, braucht man für ein Windows-Binary eine Build-Umgebung auf
Windows.
Zum Testen hat ein echtes Windows allerdings schon Vorteile, weil unter wine dann doch nicht alles so gut funktioniert. Meine Vulkan-Anwendung damals hat allerdings super unter wine funktioniert, interessant!
Ob man damit auch QT-Oberflaechen hinbekommt weiss ich nicht...
Meine Erfahrung mit Cross Compilation und Qt waren vollkommen ernüchternd daher bin ich aus MSYS2 umgestiegen. Da sind eben alle Pakete per Pacman installierbar. Qt hat eben jede Menge Legacy Schrott und braucht Plugins für Bilddateien. Die muss man dann händisch in die richtigen Ordner schrieben und hat kein windeployqt.
Für einfache Programme ist das sicher alles kein Problem aber ein großes Projekt ist eine Qual. Es gibt dafür noch mxe womit man sich eine ganze Buildumgebung bauen kann.
Die waren früher (zur aktuellen weiß ich nix) nämlich auch hervorragend.
Man bekommt auch noch alte (wenigsten 2016), wenn man sich das aus irgendwelchen Gründen antun will. 2022 entspricht einem Windows 10 aus in etwa der Zeit, kann also nicht den allerneuesten Schnickschnack, hat aber schon ein --endlich-- brauchbares Konsolenfenster.
Bei allen drei Versionen, 2016, 2019 und 2022 gilt die gleiche 180-Tage-Testdauer und gibt es die gleiche sechsfache Verlängerbarkeit, die auf die gleiche Weise mit "slmgr -rearm" erreicht wird.
Im Oktober wird es 2025 geben. So wie es aussieht, wird wohl auch diese Version kein TPM erzwingen, so daß man sie, anders als Windows 11, auch noch auf etwas älterer Hardware verwenden kann. Ob sich die CPU-Anforderungen jetzt großartig von denen von 2022 unterscheiden werden, habe ich mir nicht näher angesehen.
Nach ein bisschen Recherche habe festestellt, dass es keine Möglichkeit
zu geben scheint einen Windows Container unter Linux auszufüren.
Wenn du es kompliziert haben möchtest, es soll Leute geben die eine VM in einem Container auf Linux ausführen, welche dann ein Windows als Gastsystem ausführt. Uff ...
Halte ich für deine Anwendung für übertrieben. Lieber den Container weglassen und Windows direkt als Gastsystem in einer VM ausführen.
Ich habe das bisher immer mit MSYS2 und Windows gemacht. Weiß jemand, ob
es von Microsoft ein Image oder eine Umgebung gibt, die kostenlos nur
zum Bauen von Software zur Verfügung gestellt wird.
Von irgend welchen Fummeleien mit Windows-Lizenzen würde ich die Finger lassen. Das wäre mir für eine kommerzielle Entwicklung zu riskant. Ist halt blöd wenn die sich kostenlos erschlichene Windows-Version zufällig genau dann den Betrieb einstellt wenn du sie dringend brauchst.
Die paar Kröten für eine Windows-Lizenz sollten für eine kommerzielle Entwicklung schon drin sein. Dazu mal ketzerisch gefragt, wo und wie willst du die Windows-Version deiner Software debuggen wenn du nur irgendwo einen Build-Server nutzt? Da wirst du schon ein Windows haben müssen.
Von irgend welchen Fummeleien mit Windows-Lizenzen würde ich die Finger
lassen.
repetitio ad nauseam:
Genau die braucht es mit den 180-Tage-Testversionen der Server nicht.
Statt irgendwelchen windigen Gestalten Geld für eine fragwürdige Lizenz in den Rachen zu werfen, ist das eine saubere, legale und unproblematische Lösung. Und man kann die Testversion sooft einsetzen, wie man Lust drauf hat, nacheinander, gleichzeitig, völlig egal. Nach Ablauf des effektiv dreijährigen Testzeitraums kann man die gleiche Testversion wieder verwenden, auch das ist unproblematisch.
Alter Falter, was geht mit Microsoft ab? Da packen die irgendwelche Dummy Dateien für Python rein. Ick gloob et hackt!
Man installiert eine jungfreudige Windows 10 Installation, will ein Python Skript testen und es passiert nichts! Nicht mal python --version wirft irgendwas aus, keine Fehlermeldung, einfach gar nichts...
Man installiert eine jungfreudige Windows 10 Installation, will ein
Python Skript testen
Das würde ich lieber in Linux machen, oder in einer VM mit Linux bzw. im Emulator.
Python-Datei-Leichen oder -Dummies können immer mal vorkommen, je nach dem..
Dieses Problem, wie auch das mit der Version ist bei Linuxen weniger nervig bzw. gar nicht vorhanden.
Eine sinnvolle Fehlermeldung ausgeben, nämlich "install python first", statt "Der Befehl "python" ist entweder falsch geschrieben oder
konnte nicht gefunden werden."
Offenbar ist MS der Ansicht, Nutzer dieser Skriptsprache an die Hand nehmen zu müssen, statt sie mit der üblichen Fehlermeldung zu überfordern.
Das ist immerhin besser, als wenn MS eine eigene Python-Version ausliefert, so hat es lange Zeit Apple gemacht, und das war dann gnadenlos veraltet:
Man installiert eine jungfreudige Windows 10 Installation, will ein
Python Skript testen und es passiert nichts! Nicht mal python --version
wirft irgendwas aus, keine Fehlermeldung, einfach gar nichts...
Bei mir wird bei --version angezeigt:
"Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Manage App Execution Aliases."
...und wenn ich nur python ohne Parameter ausführe öffnet sich der Microsoft Store über den ich python 3 dann installieren kann.
Und unter "Aliase für die App-Ausführung" in den Windows-Einstellungen kann ich diese Art Symlink auch in der Tat deaktivieren.
Bei mir passiert nichts. gar nichts. weder dein Text noch ein Microsoft Store.
edit: Bei Aufruf ohne Argumente wird das Icon vom Microsoft Store in der Taskleiste unterstrichen. Das ist mir bisher nicht aufgefallen. Geh ich mit der Maus drüber sehe ich diese kleine Vorschau. Wenn man sich Mühe gibt kann man dort irgendwas mit Python3.7 erahnen. Das ist aber schon alles. Anklicken oder öffnen kann ich den Microsoft Store nicht, dieses Icon lässt sich nicht maximieren. Benötigt man dazu ein Microsoft Konto? "Apps" kannte ich bisher nur von Android. Auf Windows habe ich "Programme" noch nie einen App Store gebraucht..
Wie auch immer - Dreck! Braucht kein Mensch.. Das schlimmste ist der falsche Return Code. Ich kann auch python.exe haha_datei_existiert_gar_nicht.py ausführen ohne Fehlermeldung.
Ich empfinde das mit diesen Aliasen auch als großen Murks. Das hat uns in der Firma viele Nerven gekostet, da Windows diesen Aliasen manchmal, nicht immer, Vorzug vor einem händisch installierten (kopiert + Path gesetzt) Python gegeben hat.
Ich deaktiviere deswegen grundsätzliche alle dieser "Aliase", geht über "Einstellungen"
Das Problem ist das Versionschaos das es nach Python 2.7 gab und 3.x nicht richtig kompatibel war. MS ist da auch nur getriebener und man soll mit den virtuellen Environments arbeiten.
Eine globale 3.x Installation funktioniert nicht für alle Programme, selbst die 3er Versionen sind ja unterschiedlich.
