Qt 工程 pro文件

转自：/article/5085877.html

工作中，感觉pro文件的有些内容真不太懂，现系统性的学习一下。于此备录，分享共勉。

为了更好的理解，先创建一个简单的工程作为实践。

【1】创建一个pro文件

1.1 新建proDemo工程。步骤如下：Qt Creator--->New Project--->应用程序--->Qt Widgets Application--->名称为：proDemo（创建路径自己拟定，本地为F:\Source\proStudy）--->类信息保持不变--->完成

1.2 提取pro文件。在工程目录下，把名称为proDemo且类型为pro的文件找到，内容如下所示：



不懂？呵呵~ 我也不懂，先学习一下，pro文件分析如下：



【2】模板变量

2.1 模板变量 TEMPLATE

模板变量作用告诉qmake为这个应用程序具体生成哪种makefile。下面是模板变量可供选择的值：

[1]app 模板变量的默认值。建立一个应用程序的makefile。

[2]lib 建立一个库的makefile。

[3]vcapp 建立一个应用程序的Visual Studio项目文件。

[4]vclib 建立一个库的VisualStudio项目文件。

[5]subdirs 这是一个特殊的模板，它可以创建一个能够进入特定目录且为一个项目文件生成makefile，还能为它再调用make的makefile。

由以上分析可知，模板变量值不同，生成的makefile文件也会随之改变。那么，默认的同时是最常用的app值，模板请参见下文。

2.2 app模板

　　app模板告诉qmake为建立一个应用程序生成一个makefile。

当使用这个模板时，设置下面这些qmake系统变量值是有效的。可以在你的.pro文件中使用它们为你的应用程序指定特定信息。

HEADERS - 应用程序中的所有头文件的列表。

SOURCES - 应用程序中的所有源文件的列表。

FORMS - 应用程序中的所有.ui文件（由Qt设计器生成）的列表。
LEXSOURCES - 应用程序中的所有lex源文件的列表。
YACCSOURCES - 应用程序中的所有yacc源文件的列表。
TARGET - 可执行应用程序的名称。默认值为项目文件的名称。（如果需要扩展名，会被自动加上。）
DESTDIR - 放置可执行程序目标的目录。
DEFINES - 应用程序所需的额外的预处理程序定义的列表。
INCLUDEPATH - 应用程序所需的额外的包含路径的列表。
DEPENDPATH - 应用程序所依赖的搜索路径。
VPATH - 寻找补充文件的搜索路径。
DEF_FILE - 只有Windows需要：应用程序所要连接的.def文件。
RC_FILE - 只有Windows需要：应用程序的资源文件。
RES_FILE - 只有Windows需要：应用程序所要连接的资源文件。

你只需要使用那些你已经有值的系统变量。例如，如果你不需要任何额外的INCLUDEPATH，那么你就不需要指定它，qmake会为所需的系统变量提供默认值。

例如，上例中的项目pro文件也可写成这样：



注意：如果条目是单值的，比如template或者目的目录DESTDIR（可执行文件或二进制文件的发布目录），我们是用“=”，但如果是多值条目，我们使用“+=”来为这个变量添加现有的条目值。

使用“=”会用新值替换原有的值。例如，如果我们写了DEFINES = QT_DLL，其它DEFINES所有的条目值都将被删除并用QT_DLL替代。

2.3 lib模板

　　lib模板告诉qmake为建立一个库而生成一个makefile。当使用这个模板时，除了app模板中提到的系统变量外，还有一个VERSION是被支持的。

你需要在为库指定特定信息的.pro文件中使用它们。VERSION - 目标库的版本号。比如，2.3.1。

2.4 subdirs模板

　　subdirs模板告诉qmake生成一个makefile，它可以进入到特定子目录并为这个目录中的项目文件生成makefile并且为它调用make。

在这个模板中只有一个系统变量SUBDIRS可以被识别。这个变量中包含了所要处理的含有项目文件的子目录的列表。这个项目文件的名称是和子目录同名的，这样qmake就可以发现它。

例如，如果子目里是“myapp”，那么在这个目录中的项目文件应该被叫做myapp.pro。

【3】配置变量CONFIG

　　配置变量CONFIG 指定了编译器所要使用的选项和所需要被连接的库。配置变量中可以添加任何东西，但只有下面这些选项可以被qmake识别。

3.1 控制编译器

下面这些选项控制着使用哪些编译器标志：

release - 应用程序将以release模式连编。如果“debug”被指定，它将被忽略。
debug - 应用程序将以debug模式连编（与release互斥）。

debug_and_release - 工程同时用调试和发布模式编译。
build_all - 如果指定是debug_and_release模式，工程默认是同时用调试和发布模式编译。
ordered - 使用subdirs模板时，本选项指定了子目录应该按照给出的顺序编译。
warn_on - 编译器会输出尽可能多的警告信息。如果“warn_off”被指定，它将被忽略。
warn_off - 编译器会输出尽可能少的警告信息（与warn_on互斥）。

3.2 连编类型

下面这些选项定义了所要连编的库/应用程序的类型：

qt - 应用程序是一个Qt应用程序，并且Qt库将会被链接。
thread - 应用程序是一个多线程应用程序。
x11 - 应用程序是一个X11应用程序或库。
windows - 只用于“app”模板：应用程序是一个Windows下的窗口应用程序。
console - 只用于“app”模板：应用程序是一个Windows下的控制台应用程序。
dll - 只用于“lib”模板：库是一个共享库（dll）。
staticlib - 只用于“lib”模板：库是一个静态库。
plugin - 只用于“lib”模板：库是一个插件，这将会使dll选项生效。

例如，如果你的应用程序使用Qt库，并且你想把它连编为一个可调试的多线程的应用程序，你的项目文件应该会有下面这行：



注意，你必须使用“+=”，不要使用“=”，否则qmake就不能正确使用连编Qt的设置了，比如没法获得所编译的Qt库的类型了。

3.3 声明QT库模块

如果CONFIG变量值中包含了qt这个值，qmake支持了qt的程序（因为qmake也可以用在非qt程序的编译）这就要调整一些你程序中使用的qt的模块，而QT变量，正是达到这个目的的。QT是用来声明使用到的一些额外的模块，例如：通过下面的方法使得xml和网络模块有效：



注意：默认情况下，qt包含了core 和 gui 模块，所以上面的声明仅仅是添加xml和网络模块到默认的列表中。

比如，下面的语句就是忽略了默认模块，当编译程序源码时候会导致错误：



假如你想编译一个不需要gui模块的工程，你需要用“-=”操作符来去除包含。

例如：下面的语句就是小型的Qt工程会被编译



下面的罗列显示了QT变量可以使用的选项，并解释了相应的特点：

core (included by default) QtCore module 核心模块
gui (included by default) QtGui module 界面模块
network QtNetwork module 支持网络模块
opengl　　　　 QtOpenGL module 支持opengl图像编程
sql QtSql module 支持sql数据库驱动
svg QtSvg module 支持svg矢量图形
xml QtXml module 支持xml模块
qt3support Qt3Support module 支持qt3类

注意：添加opengl到QT变量里面，等价于往CONFIG变量里面添加。

所以对于Qt应用程序来说，没必要同时往QT变量和CONFIG变量里面添加opengl选项。

3.4 关于 CONFIG（debug, debug|release）语法

CONFIG变量可以同时定义 debug 和 release，但只有一个处于active（当两个互斥的值都出现时，最后设置的处于active状态）

什么意思？怎么理解呢？请看如下：



如上写法，release处于active状态。胡说吧！你咋知道呢？嗯哼？不信咱们用上面的工程测试一下。

[1] 还原测试现场。把工程文件夹proDemo同级的目录及文件删除干净（为了验证准确性，先还原测试实验现场，以下类似做法意义相同）。

[2] 修改内容。把工程中的pro类型文件改为下面的内容：



[3] 编译构建。首先把工程qmake一下，然后构建。

好，完成测试操作。激动人心的时刻到了！这个时候，我们会发现proDemo同级目录生成了appFile文件夹。

打开此文件夹，发现有两个文件：proDemo.exe 和 proDemo.exe.embed.manifest

坏了！从pro文件来看，我们debug和release版本生成的目标文件名称是相同的（即TARGET值）。肿么办呢？为了验证是release版本的可执行程序！

这样吧！我们在上级目录即proStudy文件夹中搜索*pdb文件（调试debug版本必生成的文件），没有搜索到。OK！那就说明是Release版本。

其实，另外一种办法，我们会发现proDemo工程文件夹同级目录下也会生成一个build-proDemo-Desktop_Qt_5_3_MSVC2010_OpenGL_32bit-Debug名称的文件夹（说明一点：刚刚构建程序时QT Creator的模式是Debug），而这个文件夹中会有debug和release两个文件夹，你会发现debug文件是空的，而release文件夹中才有内容。这点也可以说明刚刚的确生成的是release版本。

但是，上面的写法，debug 和 release都可以通过测试，而且阅读比较费劲，反正总感觉迷惑性太强，如何处理呢？建议写法如下：



这种情况下，我们再来分析一下：

[1] 还原现场。清空proDemo工程目录下除过proDemo而外的其他文件夹（同上）。

[2] 切换模式。分别切换Debug和Release版本：



[3] 编译构建。各自执行qmake，并进行构建，再运行，可以看到同样的窗体：



好勒~ 尽管，看起来是同样的窗体，但是，要理解是两个完全不同版本的应用程序。

现在看看proDemo目录下会多出这样两个文件夹：demo_Debug 和 demo_Release，在其各自目录下，可以分别发现可执行程序proDemo_Debug和proDemo_Release，即刚刚两个窗体应用程序。

同时，会发现再没有生成appFile文件夹，这点也可以验证DESTDIR 后面的“=”与 “+=”的作用区别。

那么，再回头看 CONFIG（debug, debug|release）这种语法是什么含义呢？

注解：两个参数，前者是要判断active的选项，后者是互斥的选项的一个集合。

有人觉得难道这么麻烦？上面的例子中，生成两种版本的应用程序，我们通过对Qt Creator构建模式进行了切换，那么想直接生成呢？

可以直接加选项build_all。比如，可以把pro文件改为这样的内容：



然后清空工程文件夹同级其它目录，再qmake一下，编译后，可以看到不用切换Qt Creator情况下，也我们一次性同时生成了两种版本的可执行程序。

【3】Qt Creator创建工程的pro文件

　　下面分别把Qt Creator新建的不同类型工程默认的pro文件罗列一下，可以参考学习：

　　3.1 新建proDemo1工程（注意：模板选择，项目：应用程序；Qt Widgets Application）。步骤如下：Qt Creator--->New Project--->应用程序--->Qt Widgets Application--->名称为：proDemo1（创建路径自己拟定，本地为F:\Source\proStudy）--->类信息保持不变--->完成。对应的pro文件如下：



　　此pro文件其实与本文第一张图片相同。因为所建工程相同，默认pro文件也相同。

　　3.2 新建proDemo2工程（注意：模板选择，项目：应用程序；Qt Quick Application）。步骤如下：Qt Creator--->New Project--->应用程序--->Qt Quick Application--->名称为：proDemo2（创建路径自己拟定，本地为F:\Source\proStudy）--->Qt Quick component set : Qt Quick Controls1.2--->完成。对应的pro文件如下：



　　此pro文件利用include引入了pri类型的文件。

　　3.3 新建proDemo3工程（注意：模板选择，项目：应用程序；Qt 控制台应用）。步骤如下：Qt Creator--->New Project--->应用程序--->Qt 控制台应用--->名称为：proDemo3（创建路径自己拟定，本地为F:\Source\proStudy）--->类信息保持不变--->完成。对应的pro文件如下：



　　此pro文件去掉了CONFIG配置变量默认的app_bundle项，由于是控制台应用程序。

　　3.4 新建proDemo4工程（注意：模板选择，项目：库；C++库）。步骤如下：Qt Creator--->New Project--->库--->C++ 库--->名称为：proDemo4（创建路径自己拟定，本地为F:\Source\proStudy）--->类型：共享库--->其他项均默认--->完成。对应的pro文件如下：



　　此pro文件添加了unix环境的控制。

　　3.5 新建proDemo5工程（注意：模板选择，项目：库；C++库）。步骤如下：Qt Creator--->New Project--->库--->C++ 库--->名称为：proDemo5（创建路径自己拟定，本地为F:\Source\proStudy）--->类型：静态链接库--->其他项均默认--->完成。对应的pro文件如下：



　　此pro文件与3.4工程的最大区别是为配置变量CONFIG添加了staticlib值，因为工程类型选择为静态链接库。

　　3.6 新建proDemo6工程（注意：模板选择，项目：库；C++库）。步骤如下：Qt Creator--->New Project--->库--->C++ 库--->名称为：proDemo6（创建路径自己拟定，本地为F:\Source\proStudy）--->类型：Qt Plugin--->其他项均默认--->完成。对应的pro文件如下：



　　此pro文件添加其他文件OTHER_FILES配置变量，另外，配置变量CONFIG添加了plugin值，因为工程类型选择为Qt Plugin。

　　3.7 新建proDemo7工程（注意：模板选择，项目：其他项目；Qt单元测试）。步骤如下：Qt Creator--->New Project--->其他项目--->Qt单元测试--->名称为：proDemo7（创建路径自己拟定，本地为F:\Source\proStudy）--->其他项均默认--->完成。对应的pro文件如下：



　　此pro文件为QT变量添加testlib值。

　　3.8 新建proDemo8工程（注意：模板选择，项目：其他项目；Qt4设计师自定义控件）。步骤如下：Qt Creator--->New Project--->其他项目--->Qt4设计师自定义控件--->名称为：proDemo8（创建路径自己拟定，本地为F:\Source\proStudy）--->控件类：customControl--->其他项全部默认--->完成。对应的pro文件如下：



　　此pro文件中当Qt版本大于4.0时为QT变量添加值designer。

　　备注：整理上文使用本地环境Qt 5.3.2 + Qt Creator3.2.1