Материал из Wiki.crossplatform.ru

Внимание: Актуальная версия перевода документации находится здесь

__NOTOC__

[ Развертывание приложений на Qt / Windows ]

[править] Развертывание приложения на Qt / Windows

Этот документ описывает, как определить, какие файлы вы должны включить в ваш дистрибутив, и о том, как убедиться, что приложение найдет их во время выполнения. Мы продемонстрируем процедуры на примере развертывания приложения Plug & Paint , которое находится в каталоге примеров Qt.

Содержание:

• Статическая сборка
  • Статическая сборка Qt
  • Сборка приложения со статической версией Qt
• Разделяемые (динамические) библиотеки
  • Сборка Qt как разделяемых библиотек
  • Сборка приложения с разделяемыми библиотеками Qt
  • Создание пакета приложения
  • Visual Studio 2005
• Зависимости приложения
  • Дополнительные библиотеки
  • Плагины Qt

[править] Статическая сборка

Если вы хотите сохранить вещи простыми имея только несколько файлов для развертывания, т.е. автономно-исполняемые объедененными с DLL от конкретного компилятора, то вы должны собрать все статически..

[править] Статическая сборка Qt

Прежде, чем вы сможете собрать ваше приложение вы должны убедится, что Qt собрано статически. Чтобы сделать это, перейдите в командную строку и введите следующее:

 cd C:\path\to\Qt
 configure -static <любые другие необходимые вам параметры>

Не забудьте определить любые другие параметры, которые вам нужны, такие как драйверы баз данных, в качестве аргументов для configure. Как только configure закончит работу, введите следующее:

 nmake sub-src

Это соберет Qt статически. Заметьте, что в отличие от динамической сборки, в результате статической сборки библиотеки Qt будут без номера версии, например, QtCore4.lib будет QtCore.lib. Кроме того, мы использовали nmake во всех примерах, но если вы используете MinGW вместо него вы должны воспользоваться mingw32-make.

[править] Сборка приложения со статической версией Qt

Как только закончится сборка Qt мы можем собрать приложение Plug & Paint. Сначала мы должны перейти в директорию, которая содержит приложение:

 cd examples\tools\plugandpaint

Затем мы длжны запустить qmake, чтобы создать новый makefile для приложения, и сделать чистую сборку, чтобы создать статически связаный исполняемый файл:

 nmake clean
 qmake -config release
 nmake

Вы, наверное, хотите линковать снова библиотеки в release режиме, и вы можете указать это при вызове qmake. Теперь, при условии, что все скомпилировалось и с линковалось без ошибок, вы должны получить файл plugandpaint.exe , который будет готов к развертыванию.  Один простой способ проверить, что приложение действительно можно запустить автономно, заключается в том, чтобы скопировать его на машину, которая не имеет Qt или Qt приложения не установлены, и запустить его на этой машине.

Помните, что если ваше приложение зависит от библиотек компилятора, они должны быть распространены вместе с вашим приложением. Вы можете проверить какие libraries your application is linking against by using the depends tool. For more information, see the Application Dependencies section.

The Plug & Paint example consists of several components: The application itself ( Plug & Paint), and the Basic Tools and Extra Filters plugins. 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.

[править] Shared Libraries

We have two challenges when deploying the Plug & Paint 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.

[править] Building Qt as a Shared Library

We assume that you already have installed Qt as a shared library, which is the default when installing Qt, in the C:\path\to\Qt directory. For more information on how to build Qt, see the Installation documentation.

[править] Linking the Application to Qt as a Shared Library

After ensuring that Qt is built as a shared library, we can build the Plug & Paint application. First, we must go into the directory that contains the application:

 cd examples\tools\plugandpaint

Now run 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 ..\plugandpaintplugins
 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 plugin files.

[править] Creating the Application Package

To deploy the application, we must make sure that we copy the relevant Qt DLL (corresponding to the Qt modules used in the application) as well as the executable to the same directory in the release subdirectory.

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 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.

If the application starts without any problems, then we have successfully made a dynamically linked version of the Plug & Paint 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 Plug & Paint application, would have to include the following files:

In addition, the archive must contain the following compiler specific libraries depending on your version of 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 QApplication::addLibraryPath() or QApplication::setLibraryPaths().

 qApp->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.

[править] Visual Studio 2005

When deploying an application compiled with Visual Studio 2005 there are some additional considerations that need to be handled.

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 different dependencies than the application using it, the manifest file needs to be embedded into the DLL binary. In Qt 4.1.3 and later we have the following CONFIG options for embedding manifests:

 embed_manifest_dll
 embed_manifest_exe

To use the options, add

 CONFIG += embed_manifest_exe

to your .pro file. The embed_manifest_dll option is enabled by default.

You can find more information about manifest files and side-by-side assemblies at the MSDN website.

There are two ways to include the run time libraries: by bundling them directly with your application or by installing them on the end-user's system.

To bundle the run time libraries with your application, copy the directory

 <Visual Studio Install Path>\VC\redist\<Architecture>\Microsoft.VC80.CRT

into the folder where your executable is, so that you are including a Microsoft.VC80.CRT directory alongside your application's executable. If you are bundling the runtimes and also need to deploy plugins you have to remove the manifest from the plugins (embedded as a resource) by adding this to the pro file of the plugins you are compiling:

 CONFIG-=embed_manifest_dll

If this is not done, plugins will not load on some systems.

To install the run time 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.

For example, on an 32-bit x86-based system, you would include the vcredist_x86.exe executable. The vcredist_IA64.exe and vcredist_x64.exe executables provide the appropriate libraries for the IA64 and 64-bit x86 architectures, respectively.

[править] Application Dependencies

[править] Additional 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:

When looking at the plugin DLLs the exact same dependencies are listed.

[править] Qt Plugins

Your application may also depend on one or more Qt plugins, such as the JPEG image format plugin or a SQL driver plugin. Be sure to distribute any Qt plugins that you need with your application.

The search path for Qt plugins (as well as a few other paths) is hard-coded into the QtCore library. By default, the first plugin search path will be hard-coded to be a plugins subdirectory of the Qt installation:

 C:<path to Qt>\plugins

Pre-determined paths like this 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:

• Using QApplication::addLibraryPath() or QApplication::setLibraryPaths().
• Using a third party installation utility to change the hard-coded paths in the QtCore library.
• Using qt.conf. This is the recommended approach since it provides the most flexibility.

[ Deploying Qt Applications ]