Es gibt sicher noch einige welche davon Gebrauch machen, auch über die OpenSource-Welt hinaus. Was natürlich kein Grund ist "den alten Krempel" noch weiter zu supporten.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 01. Jun 2015 um 15:37.
Der Path sowie die DLL gibt es im Qt4.8.x nicht: platforms\qwindows.dll, Qt5Widgets.dll,icudtXX.dll, icuinXX.dll, icuucXX.dll müssen aber im Qt5 mitgeliefert werden. Das ganze geht dann noch mit einigen anderen DLLs weiter, wo früher ein QtCore4.dll, QtGui4.dll genügt haben.
Und das hast du noch nicht bemerkt? Das sind schon gravierende Unterschiede. ;-) Ich habe letztens bei einem Kunden einen Schnellschuss gewagt gehabt, weil er einen Sonderwunsch hatte, und selbst mit dem hinzufügen der fehlenden DLLs wollte die Anwendung nicht laufen. Kurzum auf Qt4.8.x umgestellt, Rebuild, fehlenden 2 DLLs hinüber kopiert und lief sofort. Erkenntnis für mich: so einfach ist das mit der Umstellung und dem Deploy'n dann doch nicht.
Und das hast du noch nicht bemerkt? Das sind schon gravierende Unterschiede. ;-)
Vielleicht muss er sich nicht auf der Windows-Plattform darum herumschlagen. ;-) Ich muss das zum Glück auch nur selten (zweimal für kurze Tests), aber ein
windeployqt release
hat mir alles abgenommen. War aber auch nur für Tests.
Ist es nicht. Sorry, aber dann solltest du dich mal mit den Grundlagen des dynamischen Linkens oder der Programmierung überhaupt beschäftigen. Oder auch der Frage "wie funktioniert ein Programmstart?". Die Plugins wie qwindows.dll etc. werden erst zur Laufzeit bei Bedarf geladen. Deshalb tauchen sie auch logischerweise bei ldd oder DependencyWalker nirgens auf. Liest man jedoch die Qt Doku, oder nutzt strace bzw. die Tools von Sysinternals sieht man sofort was wann geladen wird.
Und wenn man die Qt Doku nicht nur liest, sondern auch noch versteht, stellt man fest, dass die Architektur und die Deisgnentscheidung für Lighthouse ein Meilensprung war im Vergleich zu dem Gewühl von Qt4.
Wer braucht den alten Krempel denn noch.
Es gibt sicher noch einige welche davon Gebrauch machen, auch über die OpenSource-Welt hinaus. Was natürlich kein Grund ist "den alten Krempel" noch weiter zu supporten.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 01. Jun 2015 um 15:37.Kunden bedingt werde ich es für Erweiterungen an bestehender Software auch weiter verwenden. Für neue Projekte setze ich schon länger auf Qt5.
Ja, das Ausrollen von Qt5-Anwendungen ist ein wenig komplexer, als mit Qt4. Das sollte man wissen.
Inwiefern? Ich hab da jetzt noch keinen Unterschied festgestellt.
Der Path sowie die DLL gibt es im Qt4.8.x nicht: platforms\qwindows.dll, Qt5Widgets.dll,icudtXX.dll, icuinXX.dll, icuucXX.dll
müssen aber im Qt5 mitgeliefert werden. Das ganze geht dann noch mit einigen anderen DLLs weiter, wo früher ein QtCore4.dll,
QtGui4.dll genügt haben.
Und das hast du noch nicht bemerkt? Das sind schon gravierende Unterschiede. ;-)
Ich habe letztens bei einem Kunden einen Schnellschuss gewagt gehabt, weil er einen Sonderwunsch hatte,
und selbst mit dem hinzufügen der fehlenden DLLs wollte die Anwendung nicht laufen. Kurzum auf Qt4.8.x umgestellt,
Rebuild, fehlenden 2 DLLs hinüber kopiert und lief sofort.
Erkenntnis für mich: so einfach ist das mit der Umstellung und dem Deploy'n dann doch nicht.
Ich muss das zum Glück auch nur selten (zweimal für kurze Tests), aber einhat mir alles abgenommen. War aber auch nur für Tests.
Unter Windows verwende ich MinGW und
habe eine Batch Datei in der u.a. drin steht:
cd bin
copy %QTDIR%\bin\icudt51.dll
copy %QTDIR%\bin\icuin51.dll
copy %QTDIR%\bin\icuuc51.dll
copy %QTDIR%\bin\libgcc_s_dw2-1.dll
rem copy %QTDIR%\bin\libstdc++-6.dll
copy %QTDIR%\bin\libwinpthread-1.dll
copy %QTDIR%\bin\Qt5CLucene.dll
copy %QTDIR%\bin\Qt5Concurrent.dll
copy %QTDIR%\bin\Qt5Core.dll
copy %QTDIR%\bin\Qt5Declarative.dll
copy %QTDIR%\bin\Qt5Designer.dll
copy %QTDIR%\bin\Qt5DesignerComponents.dll
copy %QTDIR%\bin\Qt5Gui.dll
copy %QTDIR%\bin\Qt5Help.dll
copy %QTDIR%\bin\Qt5Multimedia.dll
copy %QTDIR%\bin\Qt5MultimediaQuick_p.dll
copy %QTDIR%\bin\Qt5MultimediaWidgets.dll
copy %QTDIR%\bin\Qt5Network.dll
copy %QTDIR%\bin\Qt5OpenGL.dll
copy %QTDIR%\bin\Qt5PrintSupport.dll
copy %QTDIR%\bin\Qt5Qml.dll
copy %QTDIR%\bin\Qt5Quick.dll
copy %QTDIR%\bin\Qt5QuickParticles.dll
copy %QTDIR%\bin\Qt5QuickTest.dll
copy %QTDIR%\bin\Qt5Script.dll
copy %QTDIR%\bin\Qt5ScriptTools.dll
copy %QTDIR%\bin\Qt5Sensors.dll
copy %QTDIR%\bin\Qt5SerialPort.dll
copy %QTDIR%\bin\Qt5Sql.dll
copy %QTDIR%\bin\Qt5Svg.dll
copy %QTDIR%\bin\Qt5Test.dll
copy %QTDIR%\bin\Qt5V8.dll
copy %QTDIR%\bin\Qt5WebKit.dll
copy %QTDIR%\bin\Qt5WebKitWidgets.dll
copy %QTDIR%\bin\Qt5Widgets.dll
copy %QTDIR%\bin\Qt5Xml.dll
copy %QTDIR%\bin\Qt5XmlPatterns.dll
qt5widgets.dll muss nur ausgeliefert werden, wenn auch dagegen gelinkt wurde. Bei konsolen- oder qml-basierten Anwendungen wírd die nicht benötigt.
Hab das automatisiert https://github.com/strahlex/Qt-Deployment-Scripts
Beispiele:
https://github.com/strahlex/deployment-scripts
Ist es nicht. Sorry, aber dann solltest du dich mal mit den Grundlagen des dynamischen Linkens oder der Programmierung überhaupt beschäftigen. Oder auch der Frage "wie funktioniert ein Programmstart?". Die Plugins wie qwindows.dll etc. werden erst zur Laufzeit bei Bedarf geladen. Deshalb tauchen sie auch logischerweise bei ldd oder DependencyWalker nirgens auf. Liest man jedoch die Qt Doku, oder nutzt strace bzw. die Tools von Sysinternals sieht man sofort was wann geladen wird.
Und wenn man die Qt Doku nicht nur liest, sondern auch noch versteht, stellt man fest, dass die Architektur und die Deisgnentscheidung für Lighthouse ein Meilensprung war im Vergleich zu dem Gewühl von Qt4.