此文档编制描述部署过程为 Windows 。参考 插件和描绘 范例应用程序透过文档演示部署过程。
Windows 部署工具
windeployqt
被设计成自动化创建可部署文件夹的过程，包含
Qt
相关要求依赖 (库、QML 导入、插件、及翻译)，以从该文件夹运行应用程序。它为 Windows 桌面应用程序创建安装树，可以很容易地捆绑到安装包中。
工具可以找到在
QTDIR/bin/windeployqt
. It needs to be run within the build environment in order to function correctly. When using Qt Installer, the script
QTDIR/bin/qtenv2.bat
应该是用来设置它的。
windeployqt
接受
.exe
文件或目录包含
.exe
文件作为自变量，且会扫描可执行文件的依赖。若目录的传递是采用
--qmldir
自变量，
windeployqt
使用
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 Qt6Core.dll by relative ones.
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). In the case of release builds using Microsoft Visual C++, these consist of the Visual C++ Redistributable Packages, which are intended for recursive installation by the application's installer on the target machine. 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.
Additional arguments are described in the tools' help output:
Usage: windeployqt [options] [files]
Qt Deploy Tool 6.0.0
The simplest way to use windeployqt is to add the bin directory of your Qt
installation (e.g. <QT_DIR\bin>) to the PATH variable and then run:
windeployqt <path-to-app-binary>
If ICU, etc. are not in the bin directory, they need to be in the PATH
variable. If your application uses Qt Quick, run:
windeployqt --qmldir <path-to-app-qml-files> <path-to-app-binary>
Options:
-?, -h, --help Displays help on commandline options.
--help-all Displays help including Qt specific options.
-v, --version Displays version information.
--dir <directory> Use directory instead of binary directory.
--qmake <path> Use specified qmake instead of qmake from PATH.
--libdir <path> Copy libraries to path.
--plugindir <path> Copy plugins to path.
--debug Assume debug binaries.
--release Assume release binaries.
--pdb Deploy .pdb files (MSVC).
--force Force updating files.
--dry-run Simulation mode. Behave normally, but do not
copy/update any files.
--no-patchqt Do not patch the Qt6Core library.
--ignore-library-errors Ignore errors when libraries cannot be found.
--no-plugins Skip plugin deployment.
--no-libraries Skip library deployment.
--qmldir <directory> Scan for QML-imports starting from directory.
--qmlimport <directory> Add the given path to the QML module search
locations.
--no-quick-import Skip deployment of Qt Quick imports.
--translations <languages> A comma-separated list of languages to deploy
(de,fi).
--no-translations Skip deployment of translations.
--no-system-d3d-compiler Skip deployment of the system D3D compiler.
--compiler-runtime Deploy compiler runtime (Desktop only).
--no-virtualkeyboard Disable deployment of the Virtual Keyboard.
--no-compiler-runtime Do not deploy compiler runtime (Desktop only).
--json Print to stdout in JSON format.
--no-opengl-sw Do not deploy the software rasterizer library.
--list <option> Print only the names of the files copied.
Available options:
source: absolute path of the source files
target: absolute path of the target files
relative: paths of the target files, relative
to the target directory
mapping: outputs the source and the relative
target, suitable for use within an
Appx mapping file
--verbose <level> Verbose level (0-2).
Qt libraries can be added by passing their name (-xml) or removed by passing
the name prepended by --no- (--no-xml). Available libraries:
bluetooth concurrent core declarative designer designercomponents gui qthelp
multimedia multimediawidgets multimediaquick network nfc opengl openglwidgets
positioning printsupport qml qmltooling quick quickparticles quickwidgets script
scripttools sensors serialport sql svg svgwidgets test websockets widgets xml
webenginecore webengine webenginewidgets 3dcore 3drenderer 3dquick
3dquickrenderer 3dinput 3danimation 3dextras geoservices webchannel serialbus
webview
Arguments:
[files] Binaries or directory containing the binary.
要构建静态应用程序，静态构建 Qt 通过配置 Qt 采用
-static
:
cd C:\path\to\Qt configure -static <any other options you need>
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
mingw32-make distclean
先于运行
configure
再次。
As an example, this section will build the 插件和描绘 example statically.
一旦 Qt 完成构建，就会构建 插件和描绘 应用程序。首先，必须进入包含应用程序的目录：
cd examples\tools\plugandpaint
运行
qmake
to create a new makefile for the application, and perform a clean build to create the statically linked executable:
nmake clean
qmake -config release
nmake
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.exe
file that is ready for deployment. 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
应用程序依赖
章节。
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.
We have two challenges when deploying the 插件和描绘 application using the shared libraries approach: The Qt runtime has to be correctly redistributed along with the application executable, and the plugins have to be installed in the correct location on the target system so that the application can find them.
For this example, we assume that Qt is installed as a shared library, which is the default when installing Qt, in the C:\path\to\Qt 目录。
After ensuring that Qt is built as a shared library, we can build the 插件和描绘 application. First, we must go into the directory that contains the application:
cd examples\tools\plugandpaint
现在运行
qmake
to create a new makefile for the application, and do a clean build to create the dynamically linked executable:
nmake clean
qmake -config release
nmake
This builds the core application, the following will build the plugins:
cd ..\plugandpaint/plugins nmake clean qmake -config release nmake
If everything compiled and linked without any errors, we will get a
plugandpaint.exe
executable and the
pnp_basictools.dll
and
pnp_extrafilters.dll
插件文件。
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.dll
, as well as the executable to the same directory tree in the
release
子目录。
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 插件
section has additional information about plugins and how Qt searches for them.
If dynamic OpenGL is used, you may additionally want to include the library required software-based OpenGL, if the application is compatible with it.
If Qt was configured to link against ICU or OpenSSL, the respective DLL's need to be added to the
release
folder, too. But the binary packages for Qt on Windows do require this. For more details, see also
第 3 方库
.
Remember that if your application depends on compiler specific libraries, these must be redistributed along with your application. You can check which libraries your application is linking against by using the
depends
tool. For more information, see the
应用程序依赖
章节。
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.
If the application starts without any problems, then we have successfully made a dynamically linked version of the 插件和描绘 application. 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:
plugins\pnp_basictools.dll plugins\pnp_extrafilters.dll
An archive distributing all the Qt DLLs and application specific plugins required to run the 插件和描绘 application, would have to include the following files:
| 组件 | 文件名 | |
|---|---|---|
| 可执行文件 |
plugandpaint.exe
|
|
| 基本工具插件 |
plugins\pnp_basictools.dll
|
|
| ExtraFilters 插件 |
plugins\pnp_extrafilters.dll
|
|
| Qt Windows 平台插件 |
platforms\qwindows.dll
|
|
| Qt Windows Vista 风格插件 |
styles\qwindowsvistastyle.dll
|
|
| Qt Core 模块 |
Qt6Core.dll
|
|
| Qt GUI 模块 |
Qt6Gui.dll
|
|
| Qt Widgets 模块 |
Qt6Widgets.dll
|
|
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 16 (2019)):
| 组件 | 文件名 | |
|---|---|---|
| C 运行时 |
vcruntime140.dll
|
|
| C++ 运行时 |
msvcp160.dll
|
|
若使用动态 OpenGL，则存档还可能包含：
| 组件 | 文件名 | |
|---|---|---|
| OpenGL 软件渲染器库 | opengl32sw.dll | |
最后，若 Qt 被配置为使用 ICU，存档必须包含：
| 文件名 | ||
|---|---|---|
| icudtXX.dll | icuinXX.dll | icuucXX.dll |
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 () 或 QCoreApplication::setLibraryPaths ().
QCoreApplication::addLibraryPath("C:/some/other/path");
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. The following
CONFIG
options are available for embedding manifests:
embed_manifest_dll embed_manifest_exe
Both options are enabled by default. To remove
embed_manifest_exe
, add
CONFIG -= embed_manifest_exe
to your .pro file.
You can find more information about manifest files and side-by-side assemblies at the Side-by-side Assemblies documentation page .
The correct way to include the runtime libraries with your application is to ensure that they are installed on the end-user's system.
To install the runtime libraries on the end-user's system, you need to include the appropriate Visual C++ Redistributable Package (VCRedist) executable with your application and ensure that it is executed when the user installs your application.
The redistributable is named
vc_redist.x64.exe
(64-bit) and can be found in the folder
<Visual Studio install path>/VC/redist/<language-code>
.
Alternatively, it can be downloaded from the web, for example https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads .
注意： The application you ship must be compiled with exactly the same compiler version against the same C runtime version. This prevents deploying errors caused by different versions of the C runtime libraries.
Depending on configuration, compiler specific libraries must be redistributed along with your application.
You can check which libraries your application is linking against by using the Dependency Walker tool. All you need to do is to run it like this:
depends <application executable>
This will provide a list of the libraries that your application depends on and other information.
When looking at the release build of the Plug & Paint executable (
plugandpaint.exe
) with the
depends
tool, the tool lists the following immediate dependencies to non-system libraries:
| Qt | Visual Studio 16 (2019) | MinGW |
|---|---|---|
|
|
When looking at the plugin DLLs the exact same dependencies are listed.
All Qt GUI applications require a plugin that implements the
Qt Platform Abstraction
(QPA) layer in Qt. For Windows, the name of the platform plugin is
qwindows.dll
. This file must be located within a specific subdirectory (by default,
platforms
) under your distribution directory. Alternatively, it is possible to adjust the search path Qt uses to find its plugins, as described below.
Your application may also depend on one or more Qt plugins, such as the print support plugin, the JPEG image format plugin or a SQL driver plugin. Be sure to distribute any Qt plugins that you need with your application. Similar to the platform plugin, each type of plugin must be located within a specific subdirectory (such as
printsupport
,
imageformats
or
sqldrivers
) within your distribution directory.
The libraries are relocatable unless Qt was built with the configure switch
-relocatable
turned off. The search paths for Qt plugins are relative to the location of the
QtCore
library and no further steps are required to ensure plugins are found after installing the application on the target machine.
For non-relocatable builds, additional steps must be taken to ensure plugins are found after the application has been installed on the target machine.
In this case, the search path for Qt plugins is hard-coded into the QtCore library. By default, the plugins subdirectory of the Qt installation is the first plugin search path. However, pre-determined paths like the default one have certain disadvantages. For example, they may not exist on the target machine. For that reason, you need to examine various alternatives to make sure that the Qt plugins are found:
qt.conf
. This approach is the recommended if you have executables in different places sharing the same plugins.
If you add a custom path using QApplication::addLibraryPath it could look like this:
QCoreApplication::addLibraryPath("C:/customPath/plugins");
Then QCoreApplication::libraryPaths () 会返回像以下这样的：
C:/customPath/plugins
C:/Qt/%VERSION%/plugins
E:/myApplication/directory
The executable will look for the plugins in these directories and the same order as the QStringList 返回通过 QCoreApplication::libraryPaths (). The newly added path is prepended to the QCoreApplication::libraryPaths () which means that it will be searched through first. However, if you use QCoreApplication::setLibraryPaths (), you will be able to determine which paths and in which order they will be searched.
The 如何创建 Qt 插件 document outlines the issues you need to pay attention to when building and deploying plugins for Qt applications.