本章原英文文档：
构建常见的项目类型
本章描述如何设置基于Qt的应用程序、库和插件的三种常见项目类型的qmake项目项目文件。虽然所有的项目类型使用大量相同的变量，但是它们中的每一个都使用项目特定的变量来自定义输出文件。
这里不会描述特定于平台的变量。更多详细修改请查看 和 .
绑定一个应用程序
app模板告诉qmake生成将要构建应用程序的Makefile.使用这个模板，可以用下边的任何一个选项添加到CONFIG变量定义来指定应用程序的类型：
| 选项 | 描述 |
| windows | 这个应用程序是一个window Gui应用程序 |
| console | 仅限于应用程序模板：这个应用程序是一个windows控制台应用程序 |
| testcase | 应用程序是一个 |
当使用这个模板时，下面的qmake系统变量可以被识别。你可以在.pro文件里使用这些变量指定应用程序相关的信息。
-应用程序头文件的列表。
-应用程序c++源文件的列表。
- 应用程序UI文件的列表（用Qt Designer创建的）
-应用程序Lex 源文件的列表
- 应用程序Yacc 源文件的列表
- 应用程序可执行文件的名称。它默认是项目文件的名称。（如果需要扩展名，会自动添）
- 存放目标可执行程序的文件夹 。
- 应用程序需要的额外添加的预处理定义列表。
- 应用程序所需要的额外包含路径列表。
- 应用程序所依赖的搜索路径。
- 用于找到提供文件的搜索路径
- 只用于windows ：应用程序要链接的.def文件
- 只用于windows ：应用程序的资源文件。
- 只用于windows ：应用程序要链接的资源文件。
你只需要使用你有值的系统变量。例如，如果你没有额外的 INCLUDEPATH那么就不需要指定它。qmake将会自动添加必须的默认值。一个示例项目文件可能像下边这样
TEMPLATE = appDESTDIR = c:/helloappHEADERS += hello.hSOURCES += hello.cppSOURCES += main.cppDEFINES += USE_MY_STUFFCONFIG += release
由于这些项都是单值，像模板或目标目录，我们使用“=”;但对于多值我们使用 "+=" 来添加到现有类型项。使用“=”用新值替换变量的值。例如，如果我们这样写DEFINES=USE_MY_STUFF,其它的所有定义都会被删除
构建测试用例
一个测试用例项目是用于作为一个自动测试运行的app项目。通过添加testcase到CONFIG变量可以把任何app标记为测试用例。
对于testcase项目，qmake会在生成的Makefile里插入一个检查目标。这个目标将会运行这个应用程序。如果它终止退出代码等于0这个测试被认为通过。
检查目标会通过自动递归 项目。这意味着它可能会发出一个使检查命令从SUBDIRS项目内部来运行一个完整的测试套件。
检查目标的运行可能会被一些Makefile变量自定义。这些变量是
| 变量 | 描述 |
| TESTUNNER | 在每个测试命令前添加一个命令或shell片段。例如， use-case 是一个 “timeout" 用于如果它在一个指定的时间内没有完成，将被终止测试。 |
| TESTARGS | 每附加到每个测试命令的附加参数。例如，它可能有用的传递附加参数从测试设置输出文件和格式化。（就像 支持的 -o filename，format选项） |
注意： 当调用make工具而不是在.pro文件里，这些变量必须被设置。大多数make工具支持在命令行直接设置Makefile变量
# 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"
测试用例项目可以在CONFIG选项中使用下面的配置，更进一步的自定义设置。
| 选项 | 描述 |
| insignificat_test | 在检查期间测试退出代码将被忽略 |
测试用例会被经常使用 或 编写，但这并不需要使用 CONFIG+=testcase 和 make check。 唯一主要的需要是测试程序以零退出代码为成功，用非零退出表示失败。
构建库
lib模板告诉qmqke生成一个将要构建一个库的makefile。当使用这个模板，除了app模板支持的的系统变量，也支持VERSION变量。在你的.pro文件里使用这些变量指定这个库的相关信息。
当使用lib模板时，下边的选项可以添加到CONFIG变量来确定构建库的类型：
| 选项 | 描述 |
| dll | 这个库是一个共享库(dll). |
| staticlib | 这个库是一个静态库。 |
| plugin | 这个库是一个插件。 |
也可以定义下边的选项用来提供库的附加信息。
VERSION - 目标库的版本号。如例 2.3.1
库的目标文件名是依赖于平台的。例如，在X11和Mac OS X，库的名字将用lib作为前缀。在windows平台，文件名没有前缀。
构建插件
使用lib库来构建插件，就像前一章描述的一样。这用来告诉qmake为工程生成一个Makefile， 将为每一个平台构建一个适当的插件，通常以库的形式。与普通的库一样，VERSION变量指定插件的信息。
VERSION - 目标库的版本号. 如 2.3.1.
构建Qt Designer 插件
使用一组特定的配置设置来构建Qt Designer插件，这些配置依赖于系统对Qt的配置。为了方便，通过在 变量里添加designer来启动这些设置。例如：
QT += widgets designer
基于插件项目的更多示例，请查看
在Debug和Release模式下构建和安装
有时，它是必要在debug和release两种模式下构建一个项目。尽管变量可以同时保存debug和release两个选项，但是只有最后指定的选项会被应用。
在两种模式下构建
为了启动项目在两种模式下均构建，你必须把 debug_and_release 选项添加到CONFIG变量：
CONFIG += debug_and_releaseCONFIG(debug, debug|release) { TARGET = debug_binary} else { TARGET = release_binary}
上面的代码片段作用域修改在每个模式下的构建目标用来确保结果目标拥有不同的名字。为目标提供不同的名字确保两者不会被彼此覆盖。
当使用qmake处理项目文件时。它将会生成一个makefile规则，用以允许项目在两种模式下构建。可以通过下面的方式调用：
make all
在项目文件里可以把build_all选项添加到CONFIG变量，用来确保项目默认是在两种模式下生成：
CONFIG += build_all
这样允许Makefile可以使用默认的规则处理
make
在两种模式下安装
build_all选项确保在安装规则被调用时将安装指向的两个目标版本：
make install
也可以根据目标平台自定义构建目标的名字。例如，一个库或插件可以在windows和Unix平台使用不同的命名习惯。
CONFIG(debug, debug|release) { mac: TARGET = $$join(TARGET,,,_debug) win32: TARGET = $$join(TARGET,,d)} 在上面代码片段的默认行为是修改在debug模式下进行构建生成的目标名字。可以把else语句添加到作用域用于在release模式下做同样的事。目标名字未被修改，保持原样。