This chapter describes how to set up qmake project files for three common project types that are based on Qt: application, library, and plugin. Although all project types use many of the same variables, each of them uses project-specific variables to customize output files.
Platform-specific variables are not described here. For more information, see Qt for Windows - 部署 and Qt for macOS .
The
app
template tells qmake to generate a Makefile that will build an application. With this template, the type of application can be specified by adding one of the following options to the
CONFIG
variable definition:
| 选项 | 描述 |
|---|---|
| windows | 应用程序是 Windows GUI 应用程序。 |
| console |
app
仅模板：应用程序是 Windows 控制台应用程序。
|
| testcase | 应用程序是 自动化测试 . |
When using this template, the following qmake system variables are recognized. You should use these in your .pro file to specify information about your application. For additional platform-dependent system variables, you could have a look at the 平台注意事项 .
You only need to use the system variables that you have values for. For example, if you do not have any extra INCLUDEPATHs then you do not need to specify any. qmake will add the necessary default values. An example project file might look like this:
TEMPLATE = app DESTDIR = c:/helloapp HEADERS += hello.h SOURCES += hello.cpp SOURCES += main.cpp DEFINES += USE_MY_STUFF CONFIG += release
For items that are single valued, such as the template or the destination directory, we use "="; but for multi-valued items we use "+=" to
add
to the existing items of that type. Using "=" replaces the variable value with the new value. For example, if we write
DEFINES=USE_MY_STUFF
, all other definitions are deleted.
A testcase project is an
app
project intended to be run as an automated test. Any
app
may be marked as a testcase by adding the value
testcase
到
CONFIG
变量。
For testcase projects, qmake will insert a
check
target into the generated Makefile. This target will run the application. The test is considered to pass if it terminates with an exit code equal to zero.
The
check
target automatically recurses through
SUBDIRS
projects. This means it is possible to issue a
make check
command from within a SUBDIRS project to run an entire test suite.
The execution of the
check
target may be customized by certain Makefile variables. These variables are:
| 变量 | 描述 |
|---|---|
| TESTRUNNER | A command or shell fragment prepended to each test command. An example use-case is a "timeout" script which will terminate a test if it does not complete within a specified time. |
| TESTARGS |
Additional arguments appended to each test command. For example, it may be useful to pass additional arguments to set the output file and format from the test (such as the
-o filename,format
option supported by
QTestLib
).
|
注意：
The variables must be set while invoking the
make
tool, not in the .pro file. Most
make
tools support the setting of Makefile variables directly on the command-line:
# Run tests through test-wrapper and use xunitxml output format. # In this example, test-wrapper is a fictional wrapper script which terminates # a test if it does not complete within the amount of seconds set by "--timeout". # The "-o result.xml,xunitxml" options are interpreted by QTestLib. make check TESTRUNNER="test-wrapper --timeout 120" TESTARGS="-o result.xml,xunitxml"
Testcase projects may be further customized with the following
CONFIG
选项：
| 选项 | 描述 |
|---|---|
| insignificant_test |
The exit code of the test will be ignored during
make check
.
|
Test cases will often be written with
QTest
or
TestCase
, but it is not a requirement to make use of
CONFIG+=testcase
and
make check
. The only primary requirement is that the test program exit with a zero exit code on success, and a non-zero exit code on failure.
The
lib
template tells qmake to generate a Makefile that will build a library. When using this template, the
VERSION
variable is supported, in addition to the system variables that the
app
template supports. Use the variables in your .pro file to specify information about the library.
当使用
lib
template, the following options can be added to the
CONFIG
variable to determine the type of library that is built:
| 选项 | 描述 |
|---|---|
| dll | 库是 DLL 共享库。 |
| staticlib | 库是静态库。 |
| plugin | 库是插件。 |
The following option can also be defined to provide additional information about the library.
The target file name for the library is platform-dependent. For example, on X11, macOS, and iOS, the library name will be prefixed by
lib
. On Windows, no prefix is added to the file name.
Plugins are built using the
lib
template, as described in the previous section. This tells qmake to generate a Makefile for the project that will build a plugin in a suitable form for each platform, usually in the form of a library. As with ordinary libraries, the
VERSION
variable is used to specify information about the plugin.
Qt Designer
plugins are built using a specific set of configuration settings that depend on the way Qt was configured for your system. For convenience, these settings can be enabled by adding
designer
到
QT
variable. For example:
QT += widgets designer
见 Qt Designer 范例 for more examples of plugin-based projects.
Sometimes, it is necessary to build a project in both debug and release modes. Although the
CONFIG
variable can hold both
debug
and
release
options, only the option that is specified last is applied.
To enable a project to be built in both modes, you must add the
debug_and_release
选项到
CONFIG
变量：
CONFIG += debug_and_release
CONFIG(debug, debug|release) {
TARGET = debug_binary
} else {
TARGET = release_binary
}
The scope in the above snippet modifies the build target in each mode to ensure that the resulting targets have different names. Providing different names for targets ensures that one will not overwrite the other.
When qmake processes the project file, it will generate a Makefile rule to allow the project to be built in both modes. This can be invoked in the following way:
make all
The
build_all
option can be added to the
CONFIG
variable in the project file to ensure that the project is built in both modes by default:
CONFIG += build_all
This allows the Makefile to be processed using the default rule:
make
The
build_all
option also ensures that both versions of the target will be installed when the installation rule is invoked:
make install
It is possible to customize the names of the build targets depending on the target platform. For example, a library or plugin may be named using a different convention on Windows from the one used on Unix platforms:
CONFIG(debug, debug|release) {
mac: TARGET = $$join(TARGET,,,_debug)
win32: TARGET = $$join(TARGET,,d)
}
The default behavior in the above snippet is to modify the name used for the build target when building in debug mode. An
else
clause could be added to the scope to do the same for release mode. Left as it is, the target name remains unmodified.