The Windows deployment tool windeployqt is designed to automate the process of creating a deployable folder containing the Qt-related dependencies libraries, QML imports, plugins, and translations required to run the application from that folder. It creates a sandbox for Universal Windows Platform UWP or an installation tree for Windows desktop applications, which can be easily bundled into an installation package.
It needs to be run within the build environment in order to function correctly. If a directory is passed with the --qmldir argument, windeployqt uses the qmlimportscanner tool to scan QML files inside the directory for QML import dependencies.
Identified dependencies are then copied to the executable's directory. In case Qt was built with the configure switch -relocatable turned off, windeployqt replaces the hardcoded local paths in Qt5Core. For Windows desktop applications, the required runtime files for the compiler are also copied to the deployable folder by default unless the option --no-compiler-runtime is specified. Otherwise, the shared libraries of the compiler runtime are used.
The application may require additional 3rd-party libraries for example, database libraries , which are not taken into account by windeployqt. If you later need to reconfigure and rebuild Qt from the same location, ensure that all traces of the previous configuration are removed by entering the build directory and running nmake distclean or mingwmake distclean before running configure again. First we must go into the directory that contains the application:.
Run qmake to create a new makefile for the application, and perform a clean build to create the statically linked executable:. You probably want to link against the release libraries, and you can specify this when invoking qmake.
Now, provided that everything compiled and linked without any errors, we should have a plugandpaint. To check that the application has the required libraries, copy the executable to a machine that does not have Qt or any Qt applications installed, and run it on that machine.
Remember that if your application depends on compiler specific libraries, these must still be redistributed along with your application. You can check which libraries your application is linking against by using the depends tool. For more information, read the Application Dependencies section. Since we cannot deploy plugins using the static linking approach, the application we have prepared is incomplete. It will run, but the functionality will be disabled due to the missing plugins.
To deploy plugin-based applications we should use the shared library approach. For this example, we assume that Qt is installed as a shared library, which is the default when installing Qt, in the C:pathtoQt directory. First, we must go into the directory that contains the application:. Now run qmake to create a new makefile for the application, and do a clean build to create the dynamically linked executable:.
If everything compiled and linked without any errors, we will get a plugandpaint. To deploy the application, we must make sure that we copy the relevant Qt DLLs corresponding to the Qt modules used in the application and the Windows platform plugin, qwindows.
In contrast to user plugins, Qt plugins must be put into subdirectories matching the plugin type. The correct location for the platform plugin is a subdirectory named platforms. Qt Plugins section has additional information about plugins and how Qt searches for them. Remember that if your application depends on compiler specific libraries, these must be redistributed along with your application.
For more information, see the Application Dependencies section. We'll cover the plugins shortly, but first we'll check that the application will work in a deployed environment: Either copy the executable and the Qt DLLs to a machine that doesn't have Qt or any Qt applications installed, or if you want to test on the build machine, ensure that the machine doesn't have Qt in its environment. But the application's functionality will still be missing since we have not yet deployed the associated plugins.
Plugins work differently to normal DLLs, so we can't just copy them into the same directory as our application's executable as we did with the Qt DLLs. When looking for plugins, the application searches in a plugins subdirectory inside the directory of the application executable. So to make the plugins available to our application, we have to create the plugins subdirectory and copy over the relevant DLLs:. Other plugins might be required depending on the features the application uses iconengines , imageformats.
In addition, the archive must contain the following compiler specific libraries assuming Visual Studio To verify that the application now can be successfully deployed, you can extract this archive on a machine without Qt and without any compiler installed, and try to run it. An alternative to putting the plugins in the plugins subdirectory is to add a custom search path when you start your application using QCoreApplication::addLibraryPath or QCoreApplication::setLibraryPaths.
One benefit of using plugins is that they can easily be made available to a whole family of applications. It's often most convenient to add the path in the application's main function, right after the QApplication object is created.
Once the path is added, the application will search it for plugins, in addition to looking in the plugins subdirectory in the application's own directory. Any number of additional paths can be added. When deploying an application compiled with Visual Studio, there are some additional steps to be taken. First, we need to copy the manifest file created when linking the application. This manifest file contains information about the application's dependencies on side-by-side assemblies, such as the runtime libraries.
The manifest file needs to be copied into the same folder as the application executable. You do not need to copy the manifest files for shared libraries DLLs , since they are not used. If the shared library has dependencies that are different from the application using it, the manifest file needs to be embedded into the DLL binary.
Since Qt 4. You can find more information about manifest files and side-by-side assemblies at the MSDN website.
After starting Windows or running an Autodesk product update the following message appears: Autodesk Desktop App This application failed to start because it could not find or load the Qt platform plugin 'Windows'. Reinstall the application may fix this problem. The Autodesk Desktop App is not able to start. To resolve this issue, uninstall and reinstall the Autodesk Desktop App: Uninstall. It doesn't know the path to the 'qgis directoryappsQt5plugins' directory, so you need to provide it before using the QgsApplication module imported from qgis.
So, HOW do I find the directory where qtcreator 4. Reply Quote 0 1 Reply Last reply. Then look for "PluginsPath" 2 I used sym-links, it ignores them. Had to do a copy. Hi, Qt Creator comes with its own version of Qt, it's in that one that it will look for plugins, not in one of Qt's version installation folder. Reply Quote 1 1 Reply Last reply. No good. It never loads them in ANY plugins directory. The most I can get it to do is stat the files. It never opens them.
Does any one know HOW to figure out what directory they are loaded from? Glad you found out and thanks for sharing. Where exactly is the plugin folder located? The instructions are correct.
Its turns out to be utterly irrelevant where qmake wants them, it does not use them. When installing an plugin, the user will not be building from source. Loading More Posts 15 Posts.
0コメント