qt 5.6 qmake手册
(笔者翻译的qmake手册,多数是机翻,欢迎评论区纠错修正)
Qmake工具有助于简化跨不同平台开发项目的构建过程。它自动生成Makefile,因此创建每个Makefile只需要几行信息。您可以将qmake用于任何软件项目,无论它是否使用Qt编写。
Qmake根据项目文件中的信息生成Makefile。项目文件由开发人员创建,通常很简单,但也可以为复杂的项目创建更复杂的项目文件。
Qmake包含支持使用Qt进行开发的附加功能,自动包括moc和uic的构建规则。
Qmake还可以为Microsoft Visual Studio生成项目,而无需开发人员更改项目文件。
概览
qmake工具为您提供了一个面向项目的系统,用于管理应用程序、库和其他组件的构建过程。这种方法使您可以控制所使用的源文件,并允许简明地描述过程中的每个步骤,通常在单个文件中。qmake将每个项目文件中的信息扩展到一个Makefile,该Makefile执行编译和链接所需的命令。
描述项目
项目由project(.pro)文件的内容描述。qmake使用文件中的信息来生成包含构建每个项目所需的所有命令的Makefile。项目文件通常包含源文件和头文件的列表、一般配置信息和任意application-specific详细信息,例如要链接的额外库列表或要使用的额外包含路径列表。
项目文件可以包含许多不同的元素,包括注释、变量声明、内置函数和一些简单的控制结构。在大多数简单项目中,只需要用一些基本的配置选项、声明用于构建项目的源文件和头文件。有关如何创建简单项目文件的更多信息,请参阅入门。
您可以为复杂项目创建更复杂的项目文件。有关项目文件的概述,请参阅创建项目文件。有关可在项目文件中使用的变量和函数的详细信息,请参阅参考。
您可以使用应用程序或库项目模板来指定专门的配置选项来微调构建过程。有关详细信息,请参阅构建通用项目类型。
您可以使用Qt Creator新项目向导创建项目文件。您任意选择一个项目模板,Qt Creator使用默认值创建项目文件,使您能够构建和运行项目。您也可以修改项目文件以满足您的需求。
您可以使用qmake生成项目文件。有关qmake命令行选项的完整说明,请参阅运行qmake。
qmake的基本配置功能可以处理大多数跨平台项目。而且,使用一些特定于平台的变量可能很有用,甚至是必要的。有关详细信息,请参阅平台说明。
构建项目
对于简单的项目,您只需要在项目的根目录中运行qmake即可生成Makefile。然后,您可以运行平台的make工具来根据Makefile构建项目。
有关qmake在配置构建过程时使用的环境变量的更多信息,请参阅配置qmake。
使用第三方库
第三方库指南向您展示了如何在Qt项目中使用简单的第三方库。
预编译头文件
在大型项目中,可以利用预编译的头文件来加快构建过程。有关详细信息,请参阅使用预编译标头。
入门
本教程教您qmake的基础知识。本手册中的其他主题包含有关使用qmake的更详细信息。
一个简单案例
假设您刚刚完成了应用程序的基本实现,并且创建了以下文件:
hello.cpphello.hmain.cpp
您将在Qt发行版的examples/qmake/tutorial目录中找到这些文件。关于应用程序的设置,您唯一确定的是它是用Qt编写的。首先,使用您喜欢的纯文本编辑器,在examples/qmake/tutorial中创建一个名为hello.pro的文件。您需要做的第一件事是添加告诉qmake作为开发项目一部分的源文件和头文件。
我们将首先将源文件添加到项目文件中。为此,您需要使用SOURCES变量。只需使用SOURCES +=,并将hello. cpp放在后面。
SOURCES += hello.cpp
我们对项目中的每个源文件重复此操作,直到我们最终得到以下结果:
SOURCES += hello.cppSOURCES += main.cpp
如果您更喜欢使用类似Make的语法,一次列出所有文件,您可以像这样使用换行符转义:
SOURCES = hello.cpp \
main.cpp
现在源文件已在项目文件中列出,必须添加头文件。这些添加方式与源文件完全相同,只是我们使用的变量名是HEADERS。如下所示:
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
目标名称是自动设置的。它与项目文件名相同,但具有适合平台的后缀。例如,如果项目文件名为hello.pro,则目标在Windows上为hello.exe,在Unix上为hello。如果您想使用不同的名称,您可以在项目文件中设置它:
TARGET = helloworld
完成的项目文件应如下所示:
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
您现在可以使用qmake为您的应用程序生成Makefile。在项目目录的命令行中,键入以下内容:
qmake -o Makefile hello.pro
然后根据您使用的编译器键入make或nmake。
对于Visual Studio用户,qmake还可以生成Visual Studio项目文件。例如:
qmake -tp vc hello.pro vchello.pro
使应用程序可调试
应用程序的发布版本不包含任何调试符号或其他调试信息。在开发过程中,生成包含相关信息的应用程序调试版本很有用。这可以通过将debug添加到项目文件中的CONFIG变量中轻松实现。例如:
CONFIG += debug
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
像之前一样使用qmake生成Makefile。现在,在调试环境中运行应用程序时,您将获得有关应用程序的有用信息。
添加特定于平台的源文件
经过几个小时的编码,您可能已经开始使用应用程序中特定于平台的部分,并决定将依赖于平台的代码分开。因此,您现在有两个新文件要包含到您的项目文件中:hellowin.cpp和hellounix.cpp。我们不能只是将它们添加到SOURCES变量中,因为这会将两个文件都放在Makefile中。因此,我们需要在这里使用一个范围,该范围将根据我们正在构建的平台进行处理。
为Windows添加平台相关文件的简单范围如下所示:
win32 {
SOURCES += hellowin.cpp
}
在为Windows构建时,qmake会将hellowin.cpp添加到源文件列表中。在为任何其他平台构建时,qmake会忽略它。现在剩下要做的就是为Unix特定文件创建一个范围。
完成此操作后,您的项目文件应如下所示:
CONFIG += debug
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
win32 {
SOURCES += hellowin.cpp
}
unix {
SOURCES += hellounix.cpp
}
像之前一样使用qmake生成Makefile。
如果文件不存在,则停止qmake
如果某个文件不存在,您可能不希望创建Makefile。我们可以使用exists()函数检查文件是否存在。我们可以使用error()函数停止qmake的处理。这与范围的工作方式相同。只需将范围条件替换为函数。检查名为main. cpp的文件如下所示:
!exists( main.cpp ) {
error( “No main.cpp file found” )
}
“!”符号用于否定测试。也就是说,exists( main.cpp )如果文件存在则为真,!exists( main.cpp )如果文件不存在则为真。
CONFIG += debug
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
win32 {
SOURCES += hellowin.cpp
}
unix {
SOURCES += hellounix.cpp
}
!exists( main.cpp ) {
error( “No main.cpp file found” )
}
像之前一样使用qmake生成makefile。如果您临时重命名main.cpp,您将看到消息并且qmake将停止处理。
检查多个条件
假设您使用Windows,并且希望在命令行上运行应用程序时能够看到带有qDebug()的语句输出。要查看输出,您必须使用适当的控制台设置构建您的应用程序。我们可以轻松地将console放在CONFIG行上,以将此设置包含在Windows上的Makefile中。但是,假设我们只想在Windows上运行并且debug已经在CONFIG行上时添加CONFIG行。这需要使用两个嵌套范围。首先创建一个范围,然后在其中创建另一个。将要处理的设置放在第二个范围内,如下所示:
win32 {
debug {
CONFIG += console
}
}
嵌套范围可以使用冒号连接在一起,因此最终的项目文件如下所示:
CONFIG += debug
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
win32 {
SOURCES += hellowin.cpp
}
unix {
SOURCES += hellounix.cpp
}
!exists( main.cpp ) {
error( “No main.cpp file found” )
}
win32:debug {
CONFIG += console
}
至此,您现在已经完成了qmake的教程,并准备好为您的开发项目编写项目文件。
创建项目文件
项目文件包含qmake构建应用程序、库或插件所需的所有信息。通常,使用一系列声明来指定项目中的资源,对简单编程结构的支持使您可以为不同的平台和环境描述不同的构建过程。
项目文件元素
qmake使用的项目文件格式可用于支持简单和相当复杂的构建系统。简单的项目文件使用简单的声明风格,定义标准变量来指示项目中使用的源文件和头文件。复杂的项目可能使用控制流结构来微调构建过程。
以下部分描述了项目文件中使用的不同类型的元素。
变量
在项目文件中,变量用于保存字符串列表。在最简单的项目中,这些变量通知qmake要使用的配置选项,或者提供文件名和路径以在构建过程中使用。
Qmake在每个项目文件中查找某些变量,并使用这些变量的内容来确定应该写入Makefile的内容。例如,HEADERS和SOURCES变量中的值列表用于告诉qmake与项目文件位于同一目录中的头文件和源文件。
变量也可以在内部用于存储临时值列表,并且可以用新值覆盖或扩展现有的值列表。
以下片段说明了如何将值列表分配给变量:
HEADERS = mainwindow.h paintwidget.h
变量中的值列表以以下方式扩展:
SOURCES = main.cpp mainwindow.cpp \
paintwidget.cpp
CONFIG += console
注意:第一个赋值仅包括与HEADERS变量在同一行指定的值。第二个赋值使用反斜杠(\)将SOURCES变量中的值跨行拆分。
CONFIG变量是qmake在生成Makefile时使用的另一个特殊变量。它在常规配置中进行了阐述。在上面的片段中,console被添加到CONFIG中包含的现有值列表中。
下表列出了一些常用变量并描述了它们的内容。有关变量及其描述的完整列表,请参阅变量。
变量 | 内容 |
---|---|
CONFIG | 一般项目配置选项。 |
DESTDIR | 生成可执行文件或二进制文件的目录。 |
FORMS | 要由用户交互界面编译器(uic)处理的UI文件列表。 |
HEADERS | 构建项目时使用的标头(. h)文件的文件名列表。 |
QT | 项目中使用的Qt模块列表。 |
RESOURCES | 要包含在最终项目中的资源(. qrc)文件列表。有关这些文件的更多信息,请参阅Qt资源系统。 |
SOURCES | 构建项目时要使用的源代码文件列表。 |
TEMPLATE | 用于项目的模板。这决定了构建过程的输出是应用程序、库还是插件。 |
可以通过在变量名前加上“$$”来读取变量的内容。这可用于将一个变量的内容赋值给另一个变量:
TEMP_SOURCES = $$SOURCES
“$$”运算符广泛用于对字符串和值列表进行操作的内置函数。有关详细信息,请参阅qmake语言
引用的文本被视为变量持有的值列表中的单个项目。类似的方法用于处理包含空格的路径,特别是在为Windows平台定义INCLUDEPATH和LIBS变量时:
win32:INCLUDEPATH += “C:/mylibs/extra headers”
unix:INCLUDEPATH += “/home/user/extra headers”
空格
通常,空格分隔变量赋值中的值。要指定包含空格的值,您必须将值用双引号括起来:
DEST = “Program Files”
注释
您可以向项目文件添加注释。注释以“#”字符开头,并继续到同一行的末尾。例如:
# Comments usually start at the beginning of a line, but they
# can also follow other content on the same line.
要在变量赋值中包含“#”字符,必须使用内置LITERAL_HASH变量的内容。
内置功能和控制流程
qmake提供了许多内置函数来处理变量的内容。简单项目文件中最常用的函数是include()函数,它将文件名作为参数。给定文件的内容包含在使用include函数的地方的项目文件中。include函数最常用于包含其他项目文件:
include(other.pro)
通过范围提供对条件结构的支持,其行为类似于编程语言中的if语句:
win32 {
SOURCES += paintwidget_win.cpp
}
大括号内的赋值仅在条件为真时进行。在这种情况下,必须设置win32 CONFIG选项。这在Windows上会自动发生。左大括号必须与条件位于同一行。
通常需要循环的变量的更复杂操作由内置函数提供,例如find()、unique()和count()。提供这些函数以及许多其他函数来操作字符串和路径、支持用户输入和调用外部工具。有关使用函数的更多信息,请参阅qmake语言。有关所有函数的列表及其描述,请参阅替换函数和测试函数。
项目模板
TEMPLATE变量用于定义将要构建的项目类型。如果项目文件中没有声明这一点,qmake假定应该构建一个应用程序,并将为此目的生成一个适当的Makefile(或等效文件)。
下表总结了可用的项目类型,并描述了qmake将为每个项目生成的文件:
Template | qmake输出 |
---|---|
app (default) | Makefile来构建应用程序。 |
lib | Makefile来构建一个库。 |
aux | Makefile什么都不构建。如果不需要调用编译器来创建目标,请使用它,例如,你的项目是用解释语言编写的。 注意:此模板类型仅适用于基于Makefile的生成器。特别是,它不适用于vcxproj和Xcode生成器。 |
subdirs | Makefile包含使用SUBDIRS变量指定的子目录的规则。每个子目录都必须包含自己的项目文件。 |
vcapp | 用于构建应用程序的Visual Studio项目文件。 |
vclib | 用于构建库的Visual Studio项目文件。 |
vcsubdirs | 用于在子目录中构建项目的Visual Studio解决方案文件。 |
有关为使用app和lib模板的项目编写项目文件的建议,请参阅构建通用项目类型。
一般配置
CONFIG变量指定应配置项目的选项和功能。
项目可以在发布模式或调试模式下构建,也可以两者兼而有之。如果同时指定了调试和发布,则最后一个生效。如果您指定debug_and_release选项来构建项目的调试和发布版本,qmake生成的Makefile包含一个构建两个版本的规则。可以通过以下方式调用:
make all
将build_all选项添加到CONFIG变量会使此规则成为构建项目时的默认规则。
注意:CONFIG变量中指定的每个选项也可以用作范围条件。您可以使用内置的CONFIG()函数测试某些配置选项的存在。例如,以下行将函数显示为范围内的条件,以测试是否包含opengl选项在项目中:
CONFIG(opengl) {
message(Building with OpenGL support.)
} else {
message(OpenGL support is not available.)
}
这使得可以为release和debug构建定义不同的配置。有关详细信息,请参阅使用范围。
以下选项定义要构建的项目类型。注意:其中一些选项仅在相关平台上使用时生效。
选项 | 描述 |
---|---|
qt | 该项目是一个Qt应用程序,应该链接到Qt库。您可以使用QT变量来控制应用程序所需的任何其他Qt模块。默认情况下会添加此值,但您可以将其删除以将qmake用于非Qt项目。 |
x11 | 该项目是一个X11应用程序或库。如果目标使用Qt,则不需要此值。 |
应用程序和库项目模板为您提供了更专业的配置选项来微调构建过程。构建通用项目类型中详细解释了这些选项。
例如,如果您的应用程序使用Qt库并且您想在debug模式下构建它,您的项目文件将包含以下行:
CONFIG += qt debug
注意:您必须使用 “+=”, 而不是"=",否则qmake将无法使用Qt的配置来确定您的项目所需的设置。
声明Qt库
如果CONFIG变量包含qt值,则启用qmake对Qt应用程序的支持。这使得可以微调您的应用程序使用哪些Qt模块。这是通过QT变量实现的,该变量可用于声明所需的扩展模块。例如,我们可以通过以下方式启用XML和网络模块:
QT += network xml
注意:QT默认包含core和gui模块,因此上述声明将网络和XML模块添加到此默认列表中。以下赋值省略了默认模块,并且在编译应用程序源代码时会导致错误:
QT = network xml # T这将省略core和gui模块。
如果要在没有gui模块的情况下构建项目,则需要使用“-=”运算符将其排除在外。默认情况下,QT包含core和gui,因此以下行将导致构建最小的Qt项目:
QT -= gui # 只使用core模块。
有关可以添加到QT变量的Qt模块列表,请参阅QT。
配置特性
Qmake可以使用特性(. prf)文件中指定的额外配置特性进行设置。这些额外特性通常支持构建过程中使用的自定义工具。要向构建过程添加特性,请将特性名称(特性文件名)附加到CONFIG变量中。
例如,qmake可以配置构建过程以利用pkg-config支持的外部库,例如D-Bus和ogg库,如下行:
CONFIG += link_pkgconfig
PKGCONFIG += ogg dbus-1
有关添加功能的更多信息,请参阅添加新配置功能。
声明其他库
如果您在项目中使用除了Qt提供的库之外的其他库,则需要在项目文件中指定它们。
qmake搜索库和要链接的特定库的路径可以添加到LIBS变量中的值列表中。您可以指定库的路径或使用Unix样式表示法来指定库和路径。
例如,以下行显示了如何指定库:
LIBS += -L/usr/local/lib -lmath
可以使用INCLUDEPATH变量以类似的方式指定包含头文件的路径。
例如,要添加要搜索头文件的多个路径:
INCLUDEPATH = c:/msdev/include d:/stl/include
构建通用项目类型
本章介绍如何为基于Qt的三种常见项目类型设置qmake项目文件:应用程序、库和插件。尽管所有项目类型都使用许多相同的变量,但它们中的每一个都使用特定于项目的变量来自定义输出文件。
此处未描述特定于平台的变量。有关详细信息,请参阅Qt for Windows-部署和Qt for macOS。
构建应用程序
app模板告诉qmake生成一个将构建应用程序的Makefile。使用此模板,可以通过将以下选项之一添加到CONFIG变量定义来指定应用程序的类型:
选项 | 描述 |
---|---|
windows | 该应用程序是一个Windows GUI应用程序。 |
console | app仅模板:该应用程序是Windows控制台应用程序。 |
testcase | 该应用程序是一个自动化测试。 |
使用此模板时,将识别以下qmake系统变量。您应该在. pro文件中使用这些变量来指定有关您的应用程序的信息。有关其他与平台相关的系统变量,您可以查看平台说明。
HEADERS:应用程序的头文件列表。
SOURCES:应用程序的C++源文件列表。
FORMS:应用程序的UI文件列表(使用Qt Designer创建)。
LEXSOURCES:应用程序的Lex源文件列表。
YACCSOURCES:应用程序的Yacc源文件列表。
TARGET:应用程序可执行文件的名称。这默认为项目文件的名称。(扩展名,如果有,会自动添加)。
DESTDIR:放置目标可执行文件的目录。
DEFINES:定义应用程序所需的任何附加预处理器的列表。
INCLUDEPATH:应用程序所需的任何其他包含路径的列表。
DEPENDPATH:应用程序的依赖项搜索路径。
VPATH:查找提供文件的搜索路径。
DEF_FILE:仅限Windows:要链接到应用程序的. def文件。
您只需要使用您有值的系统变量。例如,如果您没有任何额外的INCLUDEPATHs,则无需指定任何INCLUDEPATHs。qmake将添加必要的默认值。示例项目文件可能如下所示:
TEMPLATE = app
DESTDIR = c:/helloapp
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
DEFINES += USE_MY_STUFF
CONFIG += release
对于单个值的项目,例如模板或目标目录,我们使用“=”;但是对于多值项目,我们使用“+=”来添加到该类型的现有项目中。使用“=”将变量值替换为新值。例如,如果我们写DEFINES=USE_MY_STUFF,所有其他定义都将被删除。
构建测试用例
测试用例项目是一个app项目,旨在作为自动化测试运行。任何app都可以通过将值testcase添加到CONFIG变量来标记为测试用例。
对于测试用例项目,qmake会在生成的Makefile中插入一个check目标。此目标将运行应用程序。如果测试以等于零的退出代码终止,则认为测试通过。
check目标自动递归到SUBDIRS项目中。这意味着可以从SUBDIRS项目中发出make check命令来运行整个测试套件。
check目标的执行可以由某些Makefile变量自定义。这些变量是:
变量 | 描述 |
---|---|
TESTRUNNER | 附加到每个测试命令的命令或shell片段。一个示例用例是“超时”脚本,如果测试未在指定时间内完成,它将终止测试。 |
TESTARGS | 附加到每个测试命令的附加参数。例如,传递附加参数以设置测试的输出文件和格式可能很有用(例如-o filename,format选项由QTestLib支持)。 |
注意:变量必须在调用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选项进一步定制测试用例项目:
选项 | 描述 |
---|---|
insignificant_test | 在make check期间,测试的退出代码将被忽略。 |
测试用例通常使用QTest或TestCase编写,但这并不是使用CONFIG+=testcase和make check的要求。唯一的主要要求是测试程序在成功时退出代码为零,在失败时退出代码为非零。
构建库(lib)
lib模板告诉qmake生成一个将构建库的Makefile。使用此模板时,除了app模板支持的系统变量外,还支持VERSION变量。使用. pro文件中的变量来指定有关库的信息。
使用lib模板时,可以将以下选项添加到CONFIG变量中以确定构建的库的类型:
选项 | 描述 |
---|---|
dll | 该库是一个共享库(dll)。 |
staticlib | 该库是一个静态库。 |
plugin | 该库是一个插件。 |
还可以定义以下选项以提供有关库的附加信息。
VERSION:目标库的版本号。例如,2.3.1。
库的目标文件名取决于平台。例如,在X11、macOS和iOS上,库名称将以lib为前缀。在Windows上,文件名不添加前缀。
构建插件
插件是使用lib模板构建的,如上一节所述。这告诉qmake为项目生成一个Makefile,该项目将为每个平台构建一个合适形式的插件,通常是库的形式。与普通库一样,VERSION变量用于指定有关插件的信息。
VERSION:目标库的版本号。例如,2.3.1。
构建Qt设计器插件
Qt Designer插件是使用一组特定的配置设置构建的,这些设置取决于为您的系统配置Qt的方式。为方便起见,可以通过将designer添加到QT变量来启用这些设置。例如:
QT += widgets designer
有关基于插件的项目的更多示例,请参阅Qt Designer示例。
在调试和发布模式下构建和安装
有时,需要在调试和发布模式下构建项目。虽然CONFIG变量可以同时包含debug和release选项,但只应用最后指定的选项。
两种模式的构建
要使项目能够以两种模式构建,您必须将debug_and_release选项添加到CONFIG变量中:
CONFIG += debug_and_release
CONFIG(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
可以根据目标平台自定义构建目标的名称。例如,可以使用与Unix平台上使用的不同约定在Windows上命名库或插件:
CONFIG(debug, debug|release) {
mac: TARGET = $$join(TARGET,_debug)
win32: TARGET = $$join(TARGET,d)
}
上面代码片段中的默认行为是在调试模式下构建时修改用于构建目标的名称。可以将else子句添加到范围以对发布模式执行相同的操作。保持原样,目标名称保持不变。
运行qmake
qmake的行为可以在运行时通过在命令行上指定各种选项来自定义。这些允许对构建过程进行微调,提供有用的诊断信息,并可用于为您的项目指定目标平台。
命令语法
用于运行qmake的语法采用以下简单形式:
qmake [mode] [options] files
操作模式(Operating Modes)
qmake支持两种不同的操作模式。在默认模式下,qmake使用项目文件中的信息生成Makefile,但也可以使用qmake生成项目文件。如果要显式设置模式,必须在所有其他选项之前指定。mode可以是以下两个值中的任何一个:
-makefile
qmake输出将是一个Makefile。
-project
qmake输出将是一个项目文件。
注意:可能需要编辑创建的文件。例如,添加QT变量以适应项目所需的模块。
您可以使用options来指定常规设置和特定于模式的设置。仅适用于Makefile模式的选项在Makefile模式选项部分中描述,而影响项目文件创建的选项在项目模式选项部分中描述。
文件(files)
files参数表示一个或多个项目文件的列表,以空格分隔。
一般选项(General Options)
可以在命令行上为qmake指定广泛的选项,以便自定义构建过程,并覆盖您平台的默认设置。以下基本选项提供了使用qmake的帮助,指定qmake写入输出文件的位置,并控制将写入控制台的调试信息的级别:
- -help:Qmake将介绍这些功能并提供一些有用的帮助。
- -o file:qmake输出将被定向到file。如果未指定此选项,qmake将尝试为其输出使用合适的文件名,具体取决于它运行的模式。
- 如果指定了’-',则输出被定向到标准输出。
- -d:qmake将输出调试信息。多次添加-d会增加冗长。
用于项目的模板通常由项目文件中的TEMPLATE变量指定。您可以使用以下选项覆盖或修改它:
- -t tmpl:qmake将使用tmpl覆盖任何set TEMPLATE变量,但仅在处理. pro文件之后。
- -tp prefix:qmake会将prefix添加到TEMPLATE变量中。
警告信息的级别可以微调,以帮助您发现项目文件中的问题:
- -Wall:qmake将报告所有已知警告。
- -Wnone:qmake不会生成任何警告信息。
- -Wparser:qmake只会生成解析器警告。这将提醒您解析项目文件时的常见陷阱和潜在问题。
- -Wlogic:qmake将警告您的项目文件中的常见陷阱和潜在问题。例如,qmake将报告列表中多次出现的文件和丢失的文件。
Makefile模式选项(Makefile Mode Options)
qmake -makefile [options] files
在Makefile模式下,qmake将生成一个用于构建项目的Makefile。此外,在此模式下可以使用以下选项来影响项目文件的生成方式:
- -after:qmake将在指定文件之后处理命令行上给出的分配。
- -nocache:qmake将忽略.qmake.cache文件。
- -nodepend:qmake不会生成任何依赖信息。
- -cache file:qmake将使用file作为缓存文件,忽略找到的任何其他. qmake.cache文件。
- -spec spec:qmake将使用spec作为平台和编译器信息的路径,并忽略QMAKESPEC的值。
您也可以在命令行上传递qmake分配。它们在指定的所有文件之前被处理。例如,以下命令从test.pro生成一个Makefile:
qmake -makefile -o Makefile “CONFIG+=test” test.pro
然而,也可以省略一些指定的选项,因为它们是默认值:
qmake “CONFIG+=test” test.pro
如果您确定要在指定文件之后处理变量,则可以传递-after选项。指定此选项后,命令行上-after选项之后的所有分配将被推迟到指定文件被解析之后。
项目模式选项(Project Mode Options)
qmake -project [options] files qmake-project[选项]文件
在项目模式下,qmake将生成一个项目文件。此外,您可以在此模式下提供以下选项:
- -r:qmake将递归地查看提供的目录。
- -nopwd:qmake不会在您当前的工作目录中查找源代码。它只会使用指定的files。
在这种模式下,files参数可以是文件或目录的列表。如果指定了一个目录,它将被包含在DEPENDPATH变量中,来自那里的相关代码将被包含在生成的项目文件中。如果给出了一个文件,它将被附加到正确的变量中,这取决于它的扩展名。例如,UI文件被添加到FORMS,C++文件被添加到SOURCES。
您也可以在此模式下在命令行上传递分配。这样做时,这些分配将放在生成的项目文件的最后。
平台说明
许多跨平台项目可以通过基本的qmake配置特性来处理。然而,在某些平台上,利用特定于平台的特性有时是有用的,甚至是必要的。qmake知道其中许多特性,这些特性可以通过仅在相关平台上生效的特定变量来访问。
macOS和iOS
这些平台特有的功能包括支持创建通用二进制文件、框架和捆绑包。
源和二进制包
源包中提供的qmake版本的配置与二进制包中提供的版本略有不同,因为它使用不同的功能规范。源包通常使用macx-g++规范,二进制包通常配置为使用macx-xcode规范。
每个包的用户可以通过使用-spec选项调用qmake来覆盖此配置(有关详细信息,请参阅运行qmake)。例如,要使用二进制包中的qmake在项目目录中创建Makefile,请调用以下命令:
qmake -spec macx-g++
使用框架
qmake能够自动生成构建规则,用于链接macOS上标准框架目录中的框架,位于/Library/Frameworks/。
需要向构建系统指定标准框架目录以外的目录,这是通过将链接器选项附加到QMAKE_LFLAGS变量来实现的,如下例所示:
QMAKE_LFLAGS += -F/path/to/framework/directory/
框架本身通过将-framework选项和框架名称附加到LIBS变量来链接:
LIBS += -framework TheFramework
创建框架
可以配置任何给定的库项目,以便生成的库文件放置在框架中,准备部署。为此,请将项目设置为使用lib模板并将lib_bundle选项添加到CONFIG变量中:
TEMPLATE = lib
CONFIG += lib_bundle
libCONFIG+=lib_bundle
使用QMAKE_BUNDLE_DATA变量指定与库关联的数据。这包含将与库包一起安装的项目,通常用于指定头文件的集合,如下例所示:
FRAMEWORK_HEADERS.version = Versions
FRAMEWORK_HEADERS.files = path/to/header_one.h path/to/header_two.h
FRAMEWORK_HEADERS.path = Headers
QMAKE_BUNDLE_DATA += FRAMEWORK_HEADERS
您使用FRAMEWORK_HEADERS变量来指定特定框架所需的标头。将其附加到QMAKE_BUNDLE_DATA变量可确保将有关这些标头的信息添加到将与库包一起安装的资源集合中。此外,框架名称和版本由QMAKE_FRAMEWORK_BUNDLE_NAME和QMAKE_FRAMEWORK_VERSION变量指定。默认情况下,用于这些变量的值从TARGET和VERSION变量中获取。
有关部署应用程序和库的更多信息,请参阅Qt for macOS-部署。
创建和移植Xcode项目
macOS上的开发人员可以利用qmake对Xcode项目文件的支持,如Qt for macOS留档中所述。通过运行qmake从现有的qmake项目文件生成Xcode项目。例如:
qmake -spec macx-xcode project.pro
注意:如果稍后在磁盘上移动项目,则必须再次运行qmake来处理项目文件并创建新的Xcode项目文件。
同时支持两个构建目标
实现这一点目前是不可行的,因为Active Build Configurations的Xcode概念在概念上不同于构建目标的qmake想法。
择了调试或发布构建配置来选择特定的库文件。qmake调试和发布设置控制哪些库文件链接到可执行文件。
目前无法从qmake生成的Xcode项目文件在Xcode配置设置中设置文件。库在Xcode构建系统的框架和库阶段的链接方式。
此外,选定的Active Build Configuration存储在. pbxuser文件中,该文件由Xcode在第一次加载时生成,而不是由qmake创建。
Windows
此平台特有的功能包括支持Windows资源文件(提供或自动生成)、创建Visual Studio项目文件以及在部署使用Visual Studio 2005或更高版本开发的Qt应用程序时处理清单文件。
添加Windows资源文件
本节介绍如何使用qmake处理Windows资源文件以将其链接到应用程序可执行文件(EXE)或动态链接库(DLL)。qmake可以选择自动生成适当填充的Windows资源文件。
链接的Windows资源文件可能包含许多可以通过其EXE或DLL访问的元素。但是,应该使用Qt资源系统以platform-independent的方式访问链接的资源。但是链接的Windows资源文件的一些标准元素由Windows本身访问。例如,在Windows资源管理器中,文件属性的版本选项卡由资源元素填充。此外,EXE的程序图标是从这些元素中读取的。因此,Qt创建的Windows EXE或DLL同时使用这两种技术是一种很好的做法:通过Qt资源系统链接platform-independent资源,并通过Windows资源文件添加Windows特定的资源。
通常,资源定义脚本(. rc文件)被编译为Windows资源文件。在Microsoft工具链中,RC工具生成一个.res文件,该文件可以与Microsoft链接器链接到EXE或DLL。MinGW工具链使用Windres工具生成一个.o文件,该文件可以与MinGW链接器链接到EXE或DLL。
通过设置系统变量VERSION和RC_ICONS中的至少一个来触发qmake对适当填充的. rc文件的可选自动生成。生成的.rc文件被自动编译和链接。添加到.rc文件中的元素由系统变量QMAKE_TARGET_COMPANY、QMAKE_TARGET_DESCRIPTION、QMAKE_TARGET_COPYRIGHT、QMAKE_TARGET_PRODUCT、RC_CODEPAGE、RC_ICONS、RC_LANG和VERSION定义。
如果这些元素不够,qmake有两个系统变量RC_FILE和RES_FILE直接指向外部创建的. rc或.res文件。通过设置这些变量之一,指定的文件将链接到EXE或DLL。
注意:如果设置了RC_FILE或RES_FILE,则阻止qmake生成. rc文件。在这种情况下,qmake不会对给定的.rc文件或.res或.o文件进行进一步更改;与.rc文件生成相关的变量无效。
创建Visual Studio项目文件
本节介绍如何将现有的qmake项目导入Visual Studio。qmake能够获取项目文件并创建包含开发环境所需的所有必要信息的Visual Studio项目。这是通过将qmake项目模板设置为vcapp(用于应用程序项目)或vclib(用于库项目)来实现的。
这也可以使用命令行选项进行设置,例如:
qmake -tp vc
可以在子目录中递归生成.vcproj文件,在主目录中生成.sln文件,方法是键入:
qmake -tp vc -r
每次更新项目文件时,都需要运行qmake来生成更新的Visual Studio项目。
注意:如果您使用的是Visual Studio加载项,请选择Qt>import from. pro file以导入.pro文件。
清单文件
部署使用Visual Studio 2005或更高版本构建的Qt应用程序时,请确保正确处理链接应用程序时创建的清单文件。这对于生成DLL的项目会自动处理。
可以通过对CONFIG变量的以下赋值来删除应用程序可执行文件的清单嵌入:
CONFIG -= embed_manifest_exe
此外,可以通过对CONFIG变量的以下赋值来删除DLL的清单嵌入:
CONFIG -= embed_manifest_dll
Windows部署指南中对此进行了更详细的讨论。
qmake语言
许多qmake项目文件使用name = value和name += value定义列表简单地描述了项目使用的源文件和头文件。qmake还提供了其他运算符、函数和范围,可用于处理变量声明中提供的信息。这些高级功能允许从单个项目文件为多个平台生成Makefile。
运算符
在许多项目文件中,赋值(=)和追加(+=)运算符可用于包含有关项目的所有信息。典型的使用模式是将值列表分配给变量,并根据各种测试的结果追加更多值。由于qmake使用默认值定义某些变量,因此有时需要使用删除(-=)运算符来过滤掉不需要的值。以下部分描述如何使用运算符来操作变量的内容。
赋值
“=”运算符为变量赋值:
TARGET = myapp
上面的行将TARGET变量设置为myapp。这将用myapp覆盖之前为TARGET设置的任何值。
追加值
“+=”运算符将新值附加到变量中的值列表中:
DEFINES += USE_MY_STUFF
上面的行将USE_MY_STUFF附加到要放入生成的Makefile的预处理器定义列表中。
删除值
“-=”运算符从变量的值列表中删除一个值:
DEFINES -= USE_MY_STUFF
上面的行从预处理器定义列表中删除了USE_MY_STUFF,这些预处理器定义将被放入生成的Makefile中。
添加唯一值
“*=”运算符将值添加到变量中的值列表中,但前提是它还不存在。这可以防止值多次包含在变量中。例如:
DEFINES *= USE_MY_STUFF
在上面的行中,USE_MY_STUFF只有在尚未定义的情况下才会添加到预处理器定义的列表中。请注意,unique()函数也可以用来确保一个变量只包含每个值的一个实例。
替换值
“~=”运算符将与正则表达式匹配的任何值替换为指定值:
DEFINES ~= s/QT_[DT].+/QT
在上一行中,列表中以QT_D或QT_T开头的任何值都将替换为QT。
引用变量
“$$”运算符用于提取变量的内容,可用于在变量之间传递值或将其提供给函数:
EVERYTHING = $$SOURCES $$HEADERS
message(“The project contains the following files:”)
message($$EVERYTHING)
变量可用于存储环境变量的内容。这些可以在运行qmake时进行评估,或者包含在生成的Makefile中,以便在构建项目时进行评估。
要在运行qmake时获取环境值的内容,请使用“$$ (…)”运算符:
DESTDIR = $$(PWD)
message(The project will be installed in $$DESTDIR)
在上面的赋值中,在处理项目文件时读取PWD环境变量的值。
要在处理生成的Makefile时获取环境值的内容,请使用“$ (…)”运算符:
DESTDIR = $$(PWD)
message(The project will be installed in $$DESTDIR)
DESTDIR = $(PWD)
message(The project will be installed in the value of PWD)
message(when the Makefile is processed.)
在上面的赋值中,处理项目文件时立即读取PWD的值,但在生成的Makefile中,将$(PWD)赋值给DESTDIR。这使得构建过程更加灵活,只要在处理Makefile时正确设置环境变量。
访问qmake属性
特殊的“$$ […]”运算符可用于访问qmake属性:
message(Qt version: $$[QT_VERSION])
message(Qt is installed in $$[QT_INSTALL_PREFIX])
message(Qt resources can be found in the following locations:)
message(Documentation: $$[QT_INSTALL_DOCS])
message(Header files: $$[QT_INSTALL_HEADERS])
message(Libraries: $$[QT_INSTALL_LIBS])
message(Binary files (executables): $$[QT_INSTALL_BINS])
message(Plugins: $$[QT_INSTALL_PLUGINS])
message(Data files: $$[QT_INSTALL_DATA])
message(Translation files: $$[QT_INSTALL_TRANSLATIONS])
message(Settings: $$[QT_INSTALL_CONFIGURATION])
message(Examples: $$[QT_INSTALL_EXAMPLES])
有关详细信息,请参阅配置qmake。
此运算符可访问的属性通常用于使第三方插件和组件能够集成到Qt中。例如,如果在Qt Designer的项目文件中进行了以下声明,则可以将Qt Designer插件与Qt Designer的内置插件一起安装:
target.path = $$[QT_INSTALL_PLUGINS]/designer
INSTALLS += target
作用域(Scopes)
作用域类似于过程编程语言中的if语句。如果某个条件为真,则处理作用域内的声明。
作用域语法
作用域由一个条件组成,后跟同一行上的左大括号、一系列命令和定义,以及新行上的右大括号:
<condition> {
<command or definition>
…
}
左大括号必须与条件写在同一行上。作用域可以连接以包含多个条件,如以下部分所述。
作用域和条件
作用域被写成一个条件,后跟一对大括号中包含的一系列声明。例如:
win32 {
SOURCES += paintwidget_win.cpp
}
上面的代码会在为Windows平台构建时将paintwidget_win.cpp文件添加到生成的Makefile中列出的源代码中。为其他平台构建时,定义将被忽略。
给定作用域内使用的条件也可以被否定以提供一组替代声明,仅当原始条件为假时才会处理。例如,要在为除Windows之外的所有平台构建时处理某些内容,请像这样否定作用域:
!win32 {
SOURCES -= paintwidget_win.cpp
}
作用域可以嵌套以组合多个条件。例如,要仅在启用调试时包含某个平台的特定文件,请编写以下内容:
macx {
CONFIG(debug, debug|release) {
HEADERS += debugging.h
}
}
为了节省编写许多嵌套作用域,您可以使用“:”运算符嵌套作用域。上面示例中的嵌套作用域可以通过以下方式重写:
macx:CONFIG(debug, debug|release) {
HEADERS += debugging.h
}
您还可以使用“:”运算符来执行单行条件分配。例如:
win32:DEFINES += USE_MY_STUFF
仅当为Windows平台构建时,上面的行将USE_MY_STUFF添加到DEFINES变量。通常,“:”运算符的行为类似于逻辑AND运算符,将许多条件连接在一起,并要求所有条件都为真。
还有一“|”运算符,它的作用类似于逻辑OR运算符,将许多条件连接在一起,并且只要求其中一个为真。
win32|macx {
HEADERS += debugging.h
}
您还可以使用else作用域为作用域内的声明提供替代声明。如果前面作用域的条件为假,则处理每个else作用域。这允许您在与其他作用域结合使用时编写复杂的测试(如上所述由“:”运算符分隔)。例如:
win32:xml {
message(Building for Windows)
SOURCES += xmlhandler_win.cpp
} else:xml {
SOURCES += xmlhandler.cpp
} else {
message(“Unknown configuration”)
}
配置和作用域
存储在CONFIG变量中的值由qmake特殊处理。每个可能的值都可以用作作用域的条件。例如,CONFIG持有的值列表可以使用opengl值进行扩展:
CONFIG += opengl
作为此操作的结果,将处理任何测试opengl的作用域。我们可以使用此功能为最终的可执行文件命名:
opengl {
TARGET = application-gl
} else {
TARGET = application
}
此功能可以轻松更改项目的配置,而不会丢失特定配置可能需要的所有自定义设置。在上面的代码中,处理第一个作用域内的声明,最终的可执行文件将被称为application-gl。但是,如果未指定opengl,则处理第二个作用域内的声明,最终的可执行文件将被称为application。
由于可以将您自己的值放在CONFIG行上,这为您提供了一种方便的方法来自定义项目文件和微调生成的Makefile。
平台作用域值
除了在许多作用域条件中使用的win32、macx和unix值之外,还可以使用作用域测试各种其他内置平台和编译器特定的值。这些基于Qt的mkspecs目录中提供的平台规范。例如,项目文件中的以下行显示了linux-g++规范的当前使用和测试规范:
message($$QMAKESPEC)
linux-g++ {
message(Linux)
}
您可以测试任何其他平台编译器组合,只要mkspecs目录中存在规范即可。
变量
项目文件中使用的许多变量都是qmake在生成Makefile时使用的特殊变量,例如DEFINES、SOURCES和HEADERS。此外,您可以创建变量供自己使用。qmake在遇到对该名称的赋值时创建具有给定名称的新变量。例如:
MY_VARIABLE = value
对您自己的变量所做的事情没有限制,因为qmake将忽略它们,除非它在处理作用域时需要评估它们。
您还可以通过在变量名称前加上“$$”来将当前变量的值分配给另一个变量。例如:
MY_DEFINES = $$DEFINES
现在MY_DEFINES变量包含项目文件中此时DEFINES变量中的内容。这也相当于:
MY_DEFINES = $${DEFINES}
第二种表示法允许您将变量的内容附加到另一个值,而不用空格分隔两者。例如,以下操作将确保最终可执行文件的名称将包含正在使用的项目模板:
TARGET = myproject_$${TEMPLATE}
替换函数
qmake提供了一系列内置函数,以允许处理变量的内容。这些函数处理提供给它们的参数,并返回一个值或值列表。要将结果分配给变量,请使用带有此类函数的“$$”运算符,就像将一个变量的内容分配给另一个变量一样:
HEADERS = model.h
HEADERS += $$OTHER_HEADERS
HEADERS = $$unique(HEADERS)
这种类型的函数应该在赋值的右侧使用(即作为操作数)。
您可以定义自己的函数来处理变量的内容,如下所示:
defineReplace(functionName){
#function code
}
以下示例函数将变量名作为其唯一参数,使用eval()内置函数从变量中提取值列表,并编译文件列表:
defineReplace(headersAndSources) {
variable = $$1
names = $$eval($$variable)
headers =
sources =
for(name, names) {
header = $${name}.h
exists($$header) {
headers += $$header
}
source = $${name}.cpp
exists($$source) {
sources += $$source
}
}
return($$headers $$sources)
}
测试函数
qmake提供了内置函数,可以在编写作用域时用作条件。这些函数不返回值,而是指示成功或失败:
count(options, 2) {
message(Both release and debug specified.)
}
这种类型的函数只能在条件表达式中使用。
可以定义自己的函数来为作用域提供条件。以下示例测试列表中的每个文件是否存在,如果它们都存在则返回true,如果不存在则返回false:
defineTest(allFiles) {
files = $$ARGS
for(file, files) {
!exists($$file) {
return(false)
}
}
return(true)
}
高级用法
添加新特性
qmake允许您创建自己的features,这些功能可以通过将它们的名称添加到CONFIG变量指定的值列表中来包含在项目文件中。功能是.prf文件中自定义函数和定义的集合,可以驻留在许多标准目录之一中。这些目录的位置定义在许多地方,qmake在查找.prf文件时按以下顺序检查每个目录:
在QMAKEFEATURES环境变量中列出的目录中,其中包含由平台路径列表分隔符(Unix的冒号,Windows的分号)分隔的目录列表。
在QMAKEFEATURES属性变量中列出的目录中,该变量包含由平台路径列表分隔符分隔的目录列表。
在驻留在mkspecs目录中的功能目录中。mkspecs目录可以位于QMAKEPATH环境变量中列出的任何目录下方,该环境变量包含由平台路径列表分隔符分隔的目录列表。例如:$QMAKEPATH/mkspecs/<features>。
在位于QMAKESPEC环境变量提供的目录下方的功能目录中。例如:$QMAKESPEC/<features>。
在驻留在data_install/mkspecs目录中的功能目录中。例如:data_install/mkspecs/<features>。
在作为QMAKESPEC环境变量指定的目录的临近目录中。例如:$QMAKESPEC/…/<features>。
在以下功能目录中搜索功能文件:
features/unix、features/win32或features/macx,具体取决于使用的平台
features/
例如,考虑项目文件中的以下分配:
CONFIG += myfeatures
通过对CONFIG变量的添加,qmake将在完成对项目文件的解析后,在上面列出的位置搜索myfeatures.prf文件。在Unix系统上,它将查找以下文件:
$QMAKEFEATURES/myfeatures.prf(对于QMAKEFEATURES环境变量中列出的每个目录)
$$QMAKEFEATURES/myfeatures.prf(对于QMAKEFEATURES属性变量中列出的每个目录)
myfeatures.prf(在项目的根目录中)
$QMAKEPATH/mkspecs/features/unix/myfeatures.prf和$QMAKEPATH/mkspecs/features/myfeatures.prf(对于QMAKEPATH环境变量中列出的每个目录)
$QMAKESPEC/features/unix/myfeatures.prf和$QMAKESPEC/features/myfeatures.prf
data_install/mkspecs/features/unix/myfeatures.prf和data_install/mkspecs/features/myfeatures.prf
$QMAKESPEC/…/features/unix/myfeatures.prf和$QMAKESPEC/…/features/myfeatures.prf
注意:.prf文件的名称必须小写。
安装文件
在Unix上,也经常使用构建工具来安装应用程序和库;例如,通过调用make install。因此,qmake有一个install set的概念,一个包含有关项目一部分安装方式的说明的对象。例如,可以通过以下方式描述留档文件的集合:
documentation.path = /usr/local/program/doc
documentation.files = docs/*
path成员通知qmake文件应该安装在/usr/local/program/doc(路径成员)中,files成员指定应该复制到安装目录的文件。在这种情况下,docs目录中的所有内容都将被复制到/usr/local/program/doc。
完整描述安装集后,您可以将其附加到安装列表中,如下所示:
INSTALLS += documentation
qmake将确保指定的文件被复制到安装目录。如果您需要对此过程进行更多控制,您还可以为对象的extra成员提供定义。例如,以下行告诉qmake为此安装集执行一系列命令:
unix:documentation.extra = create_docs; mv master.doc toc.doc
create_docsmv master. doc toc.doc
unix范围确保这些特定命令仅在Unix平台上执行。可以使用其他范围规则定义其他平台的适当命令。
extra成员中指定的命令在执行对象其他成员中的指令之前执行。
如果您将内置安装集附加到INSTALLS变量并且没有指定files或extra成员,qmake将决定需要为您复制什么。目前,支持target和dlltarget安装集。例如:
target.path = /usr/local/myprogram
INSTALLS += target
在上面的几行中,qmake知道需要复制什么,并将自动处理安装过程。
添加自定义目标
qmake试图完成跨平台构建工具所期望的一切。当您确实需要运行特殊的平台相关命令时,这通常并不理想。这可以通过对不同qmake后端的特定说明来实现。
Makefile输出的自定义是通过对象样式API执行的,如qmake中的其他地方所示。对象通过指定其成员自动定义。例如:
mytarget.target = .buildfile
mytarget.commands = touch $$mytarget.target
mytarget.depends = mytarget2
mytarget2.commands = @echo Building $$mytarget.target
上面的定义定义了一个名为mytarget的qmake目标,其中包含一个名为.buildfile的Makefile目标,该目标又由touch()函数生成。最后,.depends成员指定mytarget依赖于mytarget2,这是后来定义的另一个目标。mytarget2是一个虚拟目标。它只被定义为将一些文本回显到控制台。
最后一步是使用QMAKE_EXTRA_TARGETS变量来指示qmake这个对象是要构建的目标:
QMAKE_EXTRA_TARGETS += mytarget mytarget2
这就是实际构建自定义目标所需要做的一切。当然,您可能希望将这些目标之一绑定到qmake build target。为此,您只需将Makefile目标包含在PRE_TARGETDEPS的列表中。
自定义目标规范支持以下成员:
成员 | 描述 |
---|---|
commands | 用于生成自定义构建目标的命令。 |
CONFIG | 自定义构建目标的特定配置选项。可以设置为recursive以指示应在Makefile中创建规则以调用子目标特定Makefile中的相关目标。此成员默认为每个子目标创建一个条目。 |
depends | 自定义生成目标所依赖的现有生成目标。 |
recurse | 指定在Makefile中创建规则以调用特定于子目标的Makefile时应使用哪些子目标。此成员仅在CONFIG中设置了recursive时使用。典型值为“Debug”和“Release”。 |
recurse_target | 指定应通过子目标Makefile为Makefile中的规则构建的目标。此成员添加了类似于$(MAKE) -f Makefile.[subtarget] [recurse_target]的内容。此成员仅在CONFIG中设置了recursive时使用。 |
target | 自定义构建目标的名称。 |
添加编译器
可以自定义qmake以支持新的编译器和预处理器:
new_moc.output = moc_${QMAKE_FILE_BASE}.cpp
new_moc.commands = moc ${QMAKE_FILE_NAME} -o ${QMAKE_FILE_OUT}
new_moc.depend_command = g++ -E -M ${QMAKE_FILE_NAME} | sed “s,^.*: ,”
new_moc.input = NEW_HEADERS
QMAKE_EXTRA_COMPILERS += new_moc
使用上述定义,如果moc可用,您可以使用下拉式替换。该命令对给定给NEW_HEADERS变量的所有参数执行(来自input成员),并将结果写入由output成员定义的文件。该文件被添加到项目中的其他源文件中。此外,qmake将执行depend_command以生成依赖信息,并将此信息也放置在项目中。
成员 | 描述 |
---|---|
commands | 用于从输入生成输出的命令。 |
CONFIG | 自定义编译器的特定配置选项。有关详细信息,请参阅CONFIG表。 |
depend_command | 指定用于生成输出依赖项列表的命令。 |
dependency_type | 指定输出的文件类型。如果是已知类型(如TYPE_C、TYPE_UI、TYPE_QRC),则作为这些类型的文件之一进行处理。 |
depends | 指定输出文件的依赖项。 |
input | 指定应使用自定义编译器处理的文件的变量。 |
name | 自定义编译器正在做什么的描述。这仅用于某些后端。 |
output | 从自定义编译器创建的文件名。 |
output_function | 指定用于指定要创建的文件名的自定义qmake函数。 |
variables | 指示此处指定的变量在pro文件中称为$(VARNAME)时替换为$(QMAKE_COMP_VARNAME)。 |
variable_out | 应添加从输出创建的文件的变量。 |
CONFIG成员支持以下选项:
选项 | 描述 |
---|---|
combine | 表示所有输入文件都组合成一个输出文件。 |
target_predeps | 指示应将输出添加到PRE_TARGETDEPS的列表中。 |
explicit_dependencies | 输出的依赖项仅从依赖成员和其他任何地方生成。 |
no_link | 指示不应将输出添加到要链接的对象列表中。 |
依赖库
通常,当链接到一个库时,qmake依靠底层平台来知道这个库链接到哪些其他库,并让平台把它们拉进来。然而,在许多情况下,这是不够的。例如,当静态链接一个库时,没有链接到其他库,因此没有创建对这些库的依赖关系。然而,稍后链接到这个库的应用程序需要知道在哪里可以找到静态库所需的符号。qmake尝试跟踪库的依赖关系,如果您明确启用跟踪。
第一步是在库本身中启用依赖项跟踪。为此,您必须告诉qmake保存有关库的信息:
CONFIG += create_prl
这只与lib模板相关,对于所有其他模板将被忽略。启用此选项后,qmake将创建一个以. prl结尾的文件,该文件将保存有关库的一些元信息。这个元文件就像一个普通的项目文件,但只包含内部变量声明。安装此库时,通过在INSTALLS声明中将其指定为目标,qmake将自动将.prl文件复制到安装路径。
此过程的第二步是在使用静态库的应用程序中启用读取此元信息:
CONFIG += link_prl
启用后,qmake将处理应用程序链接到的所有库并找到它们的元信息。qmake将使用它来确定相关的链接信息,特别是将值添加到应用程序项目文件的DEFINES以及LIBS列表中。一旦qmake处理了这个文件,它将浏览LIBS变量中新引入的库,并找到它们的依赖. prl文件,一直持续到所有库都被解析。此时,Makefile照常创建,库被显式链接到应用程序。
. prl文件应仅由qmake创建,不应在操作系统之间传输,因为它们可能包含与平台相关的信息。
使用预编译标头
预编译头文件(PCH)是一些编译器支持的一种性能特性,用于编译稳定的代码体,并将代码的编译状态存储在二进制文件中。在后续编译过程中,编译器将加载存储的状态,并继续编译指定的文件。每次后续编译都更快,因为稳定的代码不需要重新编译。
Qmake支持在某些平台和构建环境中使用预编译的标头,包括:
- Windows
- nmake
- Visual Studio项目(VS 2008及更高版本)
- macOS and iOS macOS和iOS
- Makefile
- Xcode
- Unix
- GCC 3.4 and above GCC 3.4及以上
将预编译标头添加到您的项目
预编译的标头必须包含在整个项目中稳定和静态的代码。典型的预编译标头可能如下所示:
// Add C includes here
#if defined __cplusplus
// Add C++ includes here
#include <stdlib>
#include <iostream>
#include <vector>
#include <QApplication> // Qt includes
#include <QPushButton>
#include <QLabel>
#include “thirdparty/include/libmain.h”
#include “my_stable_class.h”
…
#endif
注意:预编译头文件需要将C包含与C++包含分开,因为C文件的预编译头文件可能不包含C++代码。
项目选项
要使您的项目使用预编译的标头,您只需要在项目文件中定义PRECOMPILED_HEADER变量:
PRECOMPILED_HEADER = stable.h PRECOMPILED_HEADER
qmake将处理其余的,以确保预编译头文件的创建和使用。您不需要在HEADERS中包含预编译头文件,因为如果配置支持预编译头文件,qmake将执行此操作。
针对Windows(和Windows CE)的MSVC和g++规范默认启用precompile_header。
使用此选项,您可以在使用预编译标头时触发项目文件中的条件块以添加设置。例如:
precompile_header:!isEmpty(PRECOMPILED_HEADER) {
DEFINES += USING_PCH
}
关于可能存在问题的说明
在某些平台上,预编译头文件的文件名后缀与其他目标文件的文件名后缀相同。例如,以下声明可能会导致生成两个同名的不同目标文件:
PRECOMPILED_HEADER = window.h
SOURCES = window.cpp
为避免此类潜在冲突,请为将要预编译的头文件指定独特的名称。
示例项目
您可以在Qt发行版的examples/qmake/precompile目录中找到以下源代码:
mydialog.ui
下图在Qt Creator Design模式下显示mydiog. ui文件。您可以在编辑模式下查看代码。
stable.h
/* Add C includes here */
#if defined __cplusplus
/* Add C++ includes here */
# include <iostream>
# include <QApplication>
# include <QPushButton>
# include <QLabel>
#endif
myobject.h
#include <QObject>
class MyObject : public QObject
{
public:
MyObject();
~MyObject();
};
myobject.cpp
#include <iostream>
#include <QDebug>
#include <QObject>
#include “myobject.h”
- MyObject::MyObject()
- QObject()
{
std::cout << “MyObject::MyObject()\n”;
}
util.cpp
void util_function_does_nothing()
{
// Nothing here…
int x = 0;
++x;
}
main.cpp
#include <QApplication>
#include <QPushButton>
#include <QLabel>
#include “myobject.h”
#include “mydialog.h”
int main(int argc, char **argv)
{
QApplication app(argc, argv);
MyObject obj;
MyDialog dialog;
dialog.connect(dialog.aButton, SIGNAL(clicked()), SLOT(close()));
dialog.show();
return app.exec();
}
precompile.pro
TEMPLATE = app
LANGUAGE = C++
CONFIG += console precompile_header
CONFIG -= app_bundle
# Use Precompiled headers (PCH)
PRECOMPILED_HEADER = stable.h
HEADERS = stable.h \
mydialog.h \
myobject.h
SOURCES = main.cpp \
mydialog.cpp \
myobject.cpp \
util.cpp
FORMS = mydialog.ui
配置qmake
属性
qmake有一个持久配置系统,允许您在qmake中设置一次属性,并在每次调用qmake时查询它。您可以在qmake中设置属性,如下所示:
qmake -set PROPERTY VALUE
应将适当的属性和值替换为PROPERTY和VALUE。
您可以从qmake检索此信息,如下所示:
qmake -query PROPERTY
qmake -query #queries all current PROPERTY/VALUE pairs
注意:qmake -query列出了除了您使用qmake -set PROPERTY VALUE设置的属性之外的内置属性。
此信息将保存到QSettings对象中(这意味着它将存储在不同平台的不同位置)。
以下列表总结了built-in属性:
- QMAKE_SPEC:主机mkspec的短名称,在主机构建期间解析并存储在QMAKESPEC变量中
- QMAKE_VERSION:qmake的当前版本
- QMAKE_XSPEC:目标mkspec的短名称,在目标构建期间解析并存储在QMAKESPEC变量中
- QT_HOST_BINS:主机可执行文件的位置
- QT_HOST_DATA:qmake使用的主机可执行文件的数据位置
- QT_HOST_PREFIX:所有主机路径的默认前缀
- QT_INSTALL_ARCHDATA:一般architecture-dependent Qt数据的位置
- QT_INSTALL_BINS:Qt二进制文件的位置(工具和应用程序)
- QT_INSTALL_CONFIGURATION-Qt设置的位置。不适用于Windows
- QT_INSTALL_DATA:一般architecture-independentQt数据的位置
- QT_INSTALL_DOCS:留档地点
- QT_INSTALL_EXAMPLES:示例的位置
- QT_INSTALL_HEADERS:所有头文件的位置
- QT_INSTALL_IMPORTS:QML 1. x扩展的位置
- QT_INSTALL_LIBEXECS:运行时库所需的可执行文件的位置
- QT_INSTALL_LIBS:库的位置
- QT_INSTALL_PLUGINS:Qt插件的位置
- QT_INSTALL_PREFIX:所有路径的默认前缀
- QT_INSTALL_QML:QML 2. x扩展的位置
- QT_INSTALL_TESTS:Qt测试用例的位置
- QT_INSTALL_TRANSLATIONS:Qt字符串的翻译信息的位置
- QT_SYSROOT:目标构建环境使用的sysroot
- QT_VERSION:Qt版本。我们建议您使用$$Q.< module>.version查询Qt模块特定的版本号。
例如,您可以使用QT_INSTALL_PREFIX属性查询此版本qmake的Qt安装情况:
qmake -query “QT_INSTALL_PREFIX”
您可以查询项目文件中的属性值,如下所示:
QMAKE_VERS = $$[QMAKE_VERSION]
QMAKESPEC
Qmake需要一个平台和编译器描述文件,其中包含许多用于生成适当Makefile的默认值。标准Qt发行版附带了许多这样的文件,位于Qt安装的mkspecs子目录中。
QMAKESPEC环境变量可以包含以下任何内容:
- 包含qmake.conf文件的目录的完整路径。在这种情况下,qmake将从该目录中打开qmake.conf文件。如果该文件不存在,qmake将退出并出现错误。
- platform-compiler组合的名称。在这种情况下,qmake将在编译Qt时指定的数据通路的mkspecs子目录指定的目录中搜索(参见QLibraryInfo::DataPath)。
注意:QMAKESPEC路径将自动添加到INCLUDEPATH系统变量中。
缓存文件
缓存文件是qmake读取的一个特殊文件,用于查找qmake.conf文件、项目文件或命令行中未指定的设置。当qmake运行时,它会在当前目录的父目录中查找一个名为.qmake.cache的文件,除非您指定-nocache。如果qmake找不到这个文件,它将静默忽略这一步的处理。
如果qmake找到一个.qmake.cache文件,那么它将在处理项目文件之前先处理这个文件。
文件扩展名
在正常情况下,qmake会尝试为您的平台使用适当的文件扩展名。但是,有时需要覆盖每个平台的默认选项并显式定义要使用的文件扩展名。这是通过重新定义某些内置变量来实现的。例如,可以在项目文件中使用以下赋值重新定义用于moc文件的扩展名:
QMAKE_EXT_MOC = .mymoc
以下变量可用于重新定义qmake识别的常用文件扩展名:
- QMAKE_EXT_MOC修改放置在包含的moc文件上的扩展名。
- QMAKE_EXT_UI修改用于Qt Designer UI文件的扩展名(通常在FORMS中)。
- QMAKE_EXT_PRL修改放置在库依赖文件上的扩展名。
- QMAKE_EXT_LEX更改Lex文件中使用的后缀(通常在LEXSOURCES中)。
- QMAKE_EXT_YACC更改Yacc文件中使用的后缀(通常在YACCSOURCES中)。
- QMAKE_EXT_OBJ更改用于生成的目标文件的后缀。
以上所有内容都只接受第一个值,因此您必须仅为其分配一个将在整个项目文件中使用的值。有两个变量接受值列表:
- QMAKE_EXT_CPP使qmake将所有带有这些后缀的文件解释为C++源文件。
- QMAKE_EXT_H使qmake将所有带有这些后缀的文件解释为C和C++头文件。
参考
参考部分详细描述了可用于qmake项目文件的变量和函数。
变量引用
Variables描述了qmake在为项目配置构建过程时识别的变量。
函数引用
qmake函数有两种类型:替换函数和测试函数。替换函数返回一个值列表,而测试函数返回一个布尔结果。这些函数在两个地方实现:基本功能作为内置函数提供。更复杂的函数在功能文件库(. prf)中实现。
这些功能根据其类型分为几类:
- 替换函数
- 测试函数
变量
qmake的基本行为受到定义每个项目构建过程的变量声明的影响。其中一些声明了每个平台通用的资源,例如头文件和源文件。其他用于自定义特定平台上编译器和链接器的行为。
特定于平台的变量遵循它们扩展或修改的变量的命名模式,但在它们的名称中包含相关平台的名称。例如,QMAKE_LIBS可用于指定项目需要链接的库列表,QMAKE_LIBS_X11可用于扩展或覆盖此列表。
CONFIG
指定项目配置和编译器选项。这些值由qmake内部识别并具有特殊含义。
以下CONFIG值控制编译标志:
选项 | 描述 |
---|---|
release | 该项目将以发布模式构建。如果还指定了debug,则最后一个生效。 |
debug | 该项目将在调试模式下构建。 |
debug_and_release | 该项目准备在调试和发布模式下构建。 |
debug_and_release_target | 此选项默认设置。如果还设置了debug_and_release,则调试和发布版本最终会在单独的调试和发布目录中。 |
build_all | 如果指定了debug_and_release,则默认情况下,项目以调试和发布模式构建。 |
autogen_precompile_source | 自动生成一个.cpp文件,其中包含.pro文件中指定的预编译头文件。 |
ordered | 使用subdirs模板时,此选项指定应按照给定顺序处理列出的目录。 |
precompile_header | 启用对在项目中使用预编译标头的支持。 |
warn_on | 编译器应尽可能少输出警告。 |
warn_off | 异常支持已启用。默认设置。 |
exceptions | 异常支持被禁用。 |
exceptions_off | RTTI支持已启用。默认情况下,使用编译器默认值。 |
rtti | RTTI支持被禁用。默认情况下,使用编译器默认值。 |
rtti_off | STL支持已启用。默认情况下,使用编译器默认值。 |
stl | STL支持被禁用。默认情况下,使用编译器默认值。 |
stl_off | 线程支持已启用。当CONFIG包含qt时启用,这是默认值。 |
thread | 线程支持已启用。当CONFIG包含qt时启用,这是默认值。 |
c++11 | C++11支持已启用。如果编译器不支持C++11,此选项无效。默认情况下,支持被禁用。 |
c++14 | C++14支持已启用。如果编译器不支持C++14,此选项无效。默认情况下,支持被禁用。 |
当您使用debug_and_release选项(这是Windows下的默认设置)时,项目将被处理三次:一次生成“元”Makefile,另外两次生成Makefile. Debug和Makefile.Release。
在后面的过程中,build_pass和相应的debug或release选项被附加到CONFIG。这使得执行特定于构建的任务成为可能。例如:
build_pass:CONFIG(debug, debug|release) {
unix: TARGET = $$join(TARGET,_debug)
else: TARGET = $$join(TARGET,d)
}
作为手动编写构建类型条件的替代方法,一些变量提供特定于构建的变体,例如QMAKE_LFLAGS_RELEASE除了一般的QMAKE_LFLAGS。这些应该在可用时使用。
元Makefile使子构建可通过debug和release目标调用,并通过all目标调用组合构建。当使用build_allCONFIG选项时,组合构建是默认值。否则,集合中最后指定的CONFIG选项(debug,release)确定默认值。在这种情况下,您可以显式调用all目标以一次构建这两个配置:
make all
注意:生成Visual Studio和Xcode项目时的细节略有不同。
链接库时,qmake依靠底层平台来了解该库链接的其他库。但是,如果静态链接,除非我们使用以下CONFIG选项,否则qmake将无法获取此信息:
选项 | 描述 |
---|---|
create_prl | 此选项使qmake能够跟踪这些依赖项。启用此选项后,qmake将创建一个扩展名为.prl的文件,该文件将保存有关库的元信息(有关详细信息,请参阅Library Dependents)。 |
link_prl | 启用此选项后,qmake将处理应用程序链接到的所有库并查找它们的元信息(有关详细信息,请参阅Library Dependents)。 |
注意:构建静态库时需要create_prl选项,而使用静态库时需要link_prl。
以下选项定义应用程序或库类型:
选项 | 描述 |
---|---|
qt | 目标是Qt应用程序或库,需要Qt库和头文件。Qt库的正确包含和库路径将自动添加到项目中。这是默认定义的,可以使用\l{#qt}{QT}变量进行微调。 |
x11 | 目标是X11应用程序或库。正确的包含路径和库将自动添加到项目中。 |
testcase | 目标是自动化测试。检查目标将被添加到生成的Makefile以运行测试。仅在生成Makefile时相关。 |
insignificant_test | 自动化测试的退出代码将被忽略。仅当还设置了testcase时才相关。 |
windows | 目标是一个Win32窗口应用程序(仅限应用程序)。正确的包含路径、编译器标志和库将自动添加到项目中。 |
console | 目标是Win32控制台应用程序(仅限应用程序)。正确的包含路径、编译器标志和库将自动添加到项目中。 |
shared | 目标是一个共享对象/DLL。正确的包含路径、编译器标志和库将自动添加到项目中。请注意,dll也可以在所有平台上使用;将创建一个带有目标平台适当后缀(. dll或.so)的共享库文件。 |
dll | |
static | 目标是一个静态库(仅限lib)。正确的编译器标志将自动添加到项目中。 |
staticlib | |
plugin | 目标是一个插件(仅限lib)。这也启用了dll。 |
designer | 目标是Qt Designer的插件。 |
no_lflags_merge | 确保存储在LIBS变量中的库列表在使用之前不会减少为唯一值列表。 |
这些选项仅定义Windows上的特定功能:
选项 | 描述 |
---|---|
flat | 使用vcapp模板时,这将把所有源文件放入源组,头文件放入头组,无论它们位于哪个目录。关闭此选项将根据它们所在的目录对源/头组中的文件进行分组。默认情况下这是打开的。 |
embed_manifest_dll | 在作为库项目的一部分创建的DLL中嵌入清单文件。 |
embed_manifest_exe | 在作为应用程序项目的一部分创建的EXE中嵌入清单文件。 |
有关嵌入清单文件的选项的更多信息,请参阅平台说明。
以下选项仅对macOS有效:
选项 | 描述 |
---|---|
app_bundle | 将可执行文件放入捆绑包中(这是默认值)。 |
lib_bundle | 将库放入库包中。 |
包的构建过程也受QMAKE_BUNDLE_DATA变量内容的影响。
以下选项仅在Linux/Unix平台上生效:
选项 | 描述 |
---|---|
largefile | 包括对大文件的支持。 |
separate_debug_info | 将库的调试信息放在单独的文件中。 |
解析范围时也将检查CONFIG变量。您可以为此变量分配任何内容。
例如:
CONFIG += console newstuff
…
newstuff {
SOURCES += new.cpp
HEADERS += new.h
}
DEFINES
qmake将此变量的值添加为编译器C预处理器宏(-D选项)。
例如:
DEFINES += USE_MY_STUFF
DEF_FILE
注意:此变量仅在使用app模板时在Windows上使用。
指定要包含在项目中的.def文件。
DEPENDPATH
指定要查找以解决依赖项的所有目录的列表。此变量在爬取included文件时使用。
DEPLOYMENT_PLUGIN
注意:此变量仅在Windows CE平台上使用。
指定将部署的Qt插件。Qt中可用的所有插件都可以显式部署到设备。有关完整列表,请参阅静态插件。
注意:不会自动将插件部署到Windows CE设备。如果应用程序依赖于插件,则必须手动指定这些插件。
例如,以下定义将jpeg image eformat插件上传到Windows CE设备上的plugins目录:
DEPLOYMENT_PLUGIN += qjpeg
DESTDIR
指定放置目标文件的位置。
例如:
DESTDIR = …/…/lib
DISTFILES
指定要包含在dist目标中的文件列表。此功能仅受UnixMake规范支持。
例如:
DISTFILES += …/program.txt
DLLDESTDIR
注意:此变量仅适用于Windows目标。
指定复制目标dll的位置。
FORMS
指定在编译之前要由uic处理的UI文件(请参阅Qt设计手册)。构建这些UI文件所需的所有依赖项、标头和源文件将自动添加到项目中。
例如:
FORMS = mydialog.ui \
mywidget.ui \
myconfig.ui
GUID
指定在.vcproj文件中设置的GUID。GUID通常是随机确定的。但是,如果您需要固定的GUID,可以使用此变量进行设置。
此变量仅特定于.vcproj文件;否则将被忽略。
HEADERS
定义项目的头文件。
qmake自动检测标头中的类是否需要moc,并将适当的依赖项和文件添加到项目中以生成和链接moc文件。
例如:
HEADERS = myclass.h \
login.h \
mainwindow.h
ICON
此变量仅在Mac OS上用于设置应用程序图标。有关详细信息,请参阅应用程序图标留档。
IDLSOURCES
此变量仅在Windows上用于生成Visual Studio项目以将指定文件放入生成文件文件夹中。
INCLUDEPATH
指定编译项目时应搜索的#include目录。
例如:
INCLUDEPATH = c:/msdev/include d:/stl/include
要指定包含空格的路径,请使用Whitesspace中描述的技术引用路径。
win32:INCLUDEPATH += “C:/mylibs/extra headers”
unix:INCLUDEPATH += “/home/user/extra headers”
INSTALLS
指定执行make install或类似安装过程时将安装的资源列表。列表中的每个项目通常都定义有属性,这些属性提供有关它将安装在哪里的信息。
例如,以下target.path定义描述了构建目标将安装在哪里,并且INSTALLS分配将构建目标添加到要安装的现有资源列表中:
target.path += $$[QT_INSTALL_PLUGINS]/imageformats
INSTALLS += target
有关详细信息,请参阅安装文件。
此变量还用于指定将哪些附加文件部署到嵌入式设备。
对于Windows CE,默认部署目标路径是%CSIDL_PROGRAM_FILES%\target,通常会扩展为\Program Files\target。
LEXIMPLS
指定Lex实现文件的列表。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
LEXOBJECTS
指定中间Lex对象文件的名称。此变量的值通常由qmake处理,很少需要修改。
LEXSOURCES
指定Lex源文件的列表。所有依赖项、标头和源文件都将自动添加到项目中以构建这些lex文件。
例如:
LEXSOURCES = lexer.l LEXOURCES=lexer. l
LIBS
指定要链接到项目中的库列表。如果使用Unix-l(库)和-L(库路径)标志,qmake会在Windows上正确处理库(即将库的完整路径传递给链接器)。qmake必须存在库才能找到-l库所在的目录。
例如:
unix:LIBS += -L/usr/local/lib -lmath
win32:LIBS += c:/mylibs/math.lib
要指定包含空格的路径,请使用Whitesspace中描述的技术引用路径。
win32:LIBS += “C:/mylibs/extra libs/extra.lib”
unix:LIBS += “-L/home/user/extra libs” -lextra
默认情况下,存储在LIBS中的库列表在使用前被简化为唯一名称列表。要更改此行为,请将no_lflags_merge选项添加到CONFIG变量中:
CONFIG += no_lflags_merge
LITERAL_HASH
每当变量声明中需要文字哈希字符(#)时,都会使用此变量,可能作为文件名的一部分或传递给某个外部应用程序的字符串。
例如:
# To include a literal hash character, use the $$LITERAL_HASH variable:
urlPieces = http://doc.qt.io/qt-5/qtextdocument.html pageCount
message($$join(urlPieces, $$LITERAL_HASH))
通过以这种方式使用LITERAL_HASH,可以使用#字符为message()函数构造一个URL以打印到控制台。
MAKEFILE
指定生成的Makefile的名称。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
MAKEFILE_GENERATOR
指定生成Makefile时要使用的Makefile生成器的名称。此变量的值通常由qmake内部处理,很少需要修改。
MSVCPROJ_*
这些变量由qmake内部处理,不应修改或使用。
MOC_DIR
指定应放置所有中间moc文件的目录。
例如:
unix:MOC_DIR = …/myproject/tmp
win32:MOC_DIR = c:/myproject/tmp
OBJECTS
此变量从SOURCES变量自动填充。每个源文件的扩展名都替换为. o(Unix)或.obj(Win32)。您可以将对象添加到列表中。
OBJECTS_DIR
指定应放置所有中间对象的目录。
例如:
unix:OBJECTS_DIR = …/myproject/tmp
win32:OBJECTS_DIR = c:/myproject/tmp
POST_TARGETDEPS
列出目标所依赖的库。一些后端,例如Visual Studio和Xcode项目文件的生成器,不支持此变量。通常,这些构建工具在内部支持此变量,它对于显式列出依赖的静态库很有用。
此列表放置在所有内置(和$$PRE_TARGETDEPS)依赖项之后。
PRE_TARGETDEPS
列出目标所依赖的库。一些后端,例如Visual Studio和Xcode项目文件的生成器,不支持此变量。通常,这些构建工具在内部支持此变量,它对于显式列出依赖的静态库很有用。
此列表放置在所有内置依赖项之前。
PRECOMPILED_HEADER
指示用于创建预编译头文件的头文件,以提高项目的编译速度。目前仅在某些平台(Windows-所有MSVC项目类型、Apple-Xcode、Makefile、Unix-gcc 3.3及更高版本)上支持预编译头文件。
PWD
指定指向包含正在解析的当前文件的目录的完整路径。在编写项目文件以支持影子构建时,这对于引用源代码树中的文件很有用。
另请参见_PRO_FILE_PWD_。
注意:不要尝试覆盖此变量的值。
OUT_PWD
指定指向qmake放置生成的Makefile的目录的完整路径。
注意:不要尝试覆盖此变量的值。
QMAKE
指定qmake程序本身的名称并放置在生成的Makefile中。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKESPEC
一个系统变量,包含生成Makefile时使用的qmake配置的完整路径。此变量的值会自动计算。
注意:不要尝试覆盖此变量的值。
QMAKE_AR_CMD
注意:此变量仅在Unix平台上使用。
指定创建共享库时要执行的命令。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_BUNDLE_DATA
注意:此变量仅用于macOS和iOS。
指定将与库包一起安装的数据,通常用于指定头文件的集合。
例如,以下行将path/to/header_one.h和path/to/header_two.h添加到包含有关框架提供的标头的信息的组中:
FRAMEWORK_HEADERS.version = Versions
FRAMEWORK_HEADERS.files = path/to/header_one.h path/to/header_two.h
FRAMEWORK_HEADERS.path = Headers
QMAKE_BUNDLE_DATA += FRAMEWORK_HEADERS
最后一行将有关标头的信息添加到将与库包一起安装的资源集合中。
当lib_bundle选项添加到CONFIG变量时,将创建库包。
有关创建库包的更多信息,请参阅平台说明。
QMAKE_BUNDLE_EXTENSION
注意:此变量仅用于macOS和iOS。
指定用于库包的扩展名。这允许使用自定义扩展名而不是标准的.framework目录扩展名创建框架。
例如,以下定义将产生一个扩展名为.myframework的框架:
QMAKE_BUNDLE_EXTENSION = .myframework
QMAKE_CC
指定构建包含C源代码的项目时将使用的C编译器。只需要指定编译器可执行文件的文件名,只要它在处理Makefile时位于PATH变量中包含的路径上。
QMAKE_CFLAGS
指定用于构建项目的C编译器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。可以分别通过修改QMAKE_CFLAGS_DEBUG和QMAKE_CFLAGS_RELEASE变量来调整特定于调试和发布模式的标志。
QMAKE_CFLAGS_DEBUG
指定调试版本的C编译器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_CFLAGS_RELEASE
指定发布版本的C编译器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_CFLAGS_SHLIB
注意:此变量仅在Unix平台上使用。
指定用于创建共享库的编译器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_CFLAGS_THREAD
指定用于创建多线程应用程序的编译器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_CFLAGS_WARN_OFF
此变量仅在设置了warn_off CONFIG选项时使用,此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_CFLAGS_WARN_ON
此变量仅在设置了warn_onCONFIG选项时使用,此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_CLEAN
指定生成文件的列表(例如通过moc和uic)和要由make clean删除的目标文件。
QMAKE_CXX
指定构建包含C++源代码的项目时将使用的C++编译器。只需要指定编译器可执行文件的文件名,只要它在处理Makefile时位于PATH变量中包含的路径上。
QMAKE_CXXFLAGS
指定用于构建项目的C++编译器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。可以分别通过修改QMAKE_CXXFLAGS_DEBUG和QMAKE_CXXFLAGS_RELEASE变量来调整特定于调试和发布模式的标志。
QMAKE_CXXFLAGS_DEBUG
指定调试版本的C++编译器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_CXXFLAGS_RELEASE
指定发布版本的C++编译器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_CXXFLAGS_SHLIB
指定用于创建共享库的C++编译器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_CXXFLAGS_THREAD
指定用于创建多线程应用程序的C++编译器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_CXXFLAGS_WARN_OFF
指定用于抑制编译器警告的C++编译器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_CXXFLAGS_WARN_ON
指定C++编译器标志,用于生成编译器警告。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_DISTCLEAN
指定要由make distclean删除的文件列表。
QMAKE_EXTENSION_SHLIB
包含共享库的扩展。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
注意:更改扩展的特定于平台的变量会覆盖此变量的内容。
QMAKE_EXTENSION_STATICLIB
包含共享静态库的扩展。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_EXT_MOC
包含对包含的moc文件使用的扩展名。
另请参阅文件扩展名。
QMAKE_EXT_UI
包含Qt Designer UI文件上使用的扩展名。
另请参阅文件扩展名。
QMAKE_EXT_PRL
包含用于创建的PRL文件的扩展名。
另请参阅文件扩展名、库依赖项。
QMAKE_EXT_LEX
包含用于提供给Lex的文件的扩展名。
另请参阅文件扩展名、LEXSOURCES。
QMAKE_EXT_YACC
包含对提供给Yacc的文件使用的扩展名。
另请参阅文件扩展名、YACCSOURCES。
QMAKE_EXT_OBJ
包含用于生成的目标文件的扩展名。
另请参阅文件扩展名。
QMAKE_EXT_CPP
包含应解释为源代码C++文件的后缀。
另请参阅文件扩展名。
QMAKE_EXT_H
包含应解释为C头文件的文件的后缀。
另请参阅文件扩展名。
QMAKE_EXTRA_COMPILERS
指定附加编译器或预处理器的列表。
另请参阅添加编译器。
QMAKE_EXTRA_TARGETS
指定其他qmake目标的列表。
另请参阅添加自定义目标。
QMAKE_FAILED_REQUIREMENTS
包含失败需求列表。此变量的值由qmake设置,无法修改。
另请参见requires()和要求。
QMAKE_FRAMEWORK_BUNDLE_NAME
注意:此变量仅用于macOS和iOS。
在框架项目中,此变量包含要用于构建的框架的名称。
默认情况下,此变量包含与TARGET变量相同的值。
有关创建框架和库包的更多信息,请参阅创建框架。
QMAKE_FRAMEWORK_VERSION
注意:此变量仅用于macOS和iOS。
对于构建目标是macOS或iOS框架的项目,此变量用于指定将应用于构建的框架的版本号。
默认情况下,此变量包含与VERSION变量相同的值。
有关创建框架的更多信息,请参阅创建框架。
QMAKE_HOST
提供有关运行qmake的主机的信息。例如,您可以从QMAKE_HOST.arch检索主机体系结构。
关键字 | 值 |
---|---|
.arch | 主机架构 |
.os | 主机操作系统 |
.cpu_count | 可用cpus数量 |
.name | 主机名 |
.version | 主机操作系统版本号 |
.version_string | 主机操作系统版本字符串 |
win32-g++:contains(QMAKE_HOST.arch, x86_64):{
message(“Host is 64bit”)
…
}
QMAKE_INCDIR
指定附加到INCLUDEPATH的系统标头路径列表。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_INCDIR_EGL
指定在构建支持OpenGL/ES或OpenVG的目标时要添加到INCLUDEPATH的EGL头文件的位置。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_INCDIR_OPENGL
指定在构建支持OpenGL的目标时要添加到INCLUDEPATH的OpenGL头文件的位置。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
如果OpenGL实现使用EGL(大多数OpenGL/ES系统),那么QMAKE_INCDIR_EGL也可能需要设置。
QMAKE_INCDIR_OPENGL_ES2
此变量指定在构建支持OpenGL ES 2的目标时要添加到INCLUDEPATH的OpenGL头文件的位置。
该变量的值通常由qmake或qmake. conf处理,很少需要修改。
如果OpenGL实现使用EGL(大多数OpenGL/ES系统),那么QMAKE_INCDIR_EGL也可能需要设置。
QMAKE_INCDIR_OPENVG
指定在构建支持OpenVG的目标时要添加到INCLUDEPATH的OpenVG头文件的位置。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
如果OpenVG实现使用EGL,那么QMAKE_INCDIR_EGL也可能需要设置。
QMAKE_INCDIR_X11
注意:此变量仅在Unix平台上使用。
指定构建X11目标时要添加到INCLUDEPATH的X11头文件路径的位置。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_INFO_PLIST
注意:此变量仅用于macOS和iOS平台。
指定要包含在macOS和iOS应用程序包中的属性列表文件.plist的名称。
在.plist文件中,您可以定义一些变量,例如@EXECUTABLE@,qmake将替换为实际的可执行文件名。其他变量包括@ICON@、@TYPEINFO@、@LIBRARY@和@SHORT_VERSION@。
如果构建iOS,并且.plist文件包含密钥NSPhotoLibraryUsageDescription,qmake将在构建中包含一个额外的插件,该插件添加了照片访问支持(例如,QFile/QFileDialog)。有关此密钥的更多信息,请参阅Apple的Info.plist留档。
注意:大多数时候,默认的Info.plist已经足够好了。
QMAKE_LFLAGS
指定传递给链接器的一组通用标志。如果您需要更改用于特定平台或项目类型的标志,请为此目的使用专用变量之一而不是此变量。
QMAKE_LFLAGS_CONSOLE
注意:此变量仅在Windows上使用。
指定用于构建控制台程序的链接器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LFLAGS_DEBUG
指定调试版本的链接器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LFLAGS_PLUGIN
指定用于构建插件的链接器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LFLAGS_RPATH
注意:此变量仅在Unix平台上使用。
指定使用QMAKE_RPATHDIR中的值所需的链接器标志。
该变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LFLAGS_REL_RPATH
指定在QMAKE_RPATHDIR中启用相对路径所需的链接器标志。
该变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_REL_RPATH_BASE
指定动态链接器理解为引用可执行文件或库的位置的字符串。
该变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LFLAGS_RPATHLINK
指定使用QMAKE_RPATHLINKDIR中的值所需的链接器标志。
该变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LFLAGS_RELEASE
指定发布版本的链接器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LFLAGS_APP
指定用于构建应用程序的链接器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LFLAGS_SHLIB
指定用于构建共享库的链接器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LFLAGS_SONAME
指定用于设置共享对象名称的链接器标志,例如. so或.dll。此变量的值通常由qmake或qmake.conf处理,很少需要修改。
QMAKE_LFLAGS_THREAD
指定用于构建多线程项目的链接器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LFLAGS_WINDOWS
注意:此变量仅在Windows上使用。
指定用于构建Windows GUI项目(即非控制台应用程序)的链接器标志。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LIBDIR
指定系统库路径列表。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LIBDIR_FLAGS
注意:此变量仅在Unix平台上使用。
指定所有前缀为-L的库目录的位置。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LIBDIR_EGL
指定EGL库目录的位置,当EGL与OpenGL/ES或OpenVG一起使用时。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LIBDIR_OPENGL
指定OpenGL库目录的位置。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
如果OpenGL实现使用EGL(大多数OpenGL/ES系统),那么QMAKE_LIBDIR_EGL也可能需要设置。
QMAKE_LIBDIR_OPENVG
指定OpenVG库目录的位置。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
如果OpenVG实现使用EGL,则可能还需要设置QMAKE_LIBDIR_EGL。
QMAKE_LIBDIR_X11
注意:此变量仅在Unix平台上使用。
指定X11库目录的位置。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LIBS
指定所有项目库。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LIBS_EGL
指定使用OpenGL/ES或OpenVG构建Qt时的所有EGL库。此变量的值通常由qmake或qmake. conf处理,很少需要修改。通常的值是-lEGL。
QMAKE_LIBS_OPENGL
指定所有OpenGL库。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
如果OpenGL实现使用EGL(大多数OpenGL/ES系统),那么QMAKE_LIBS_EGL也可能需要设置。
QMAKE_LIBS_OPENGL_ES1, QMAKE_LIBS_OPENGL_ES2 QMAKE_LIBS_OPENGL_ES1 QMAKE_LIBS_OPENGL_ES2
这些变量指定OpenGL ES 1和OpenGL ES 2的所有OpenGL库。
这些变量的值通常由qmake或qmake. conf处理,很少需要修改。
如果OpenGL实现使用EGL(大多数OpenGL/ES系统),那么QMAKE_LIBS_EGL也可能需要设置。
QMAKE_LIBS_OPENVG
指定所有OpenVG库。此变量的值通常由qmake或qmake. conf处理,很少需要修改。通常的值是-lOpenVG。
一些OpenVG引擎是在OpenGL之上实现的。这将在配置时被检测到,QMAKE_LIBS_OPENGL将被隐式添加到QMAKE_LIBS_OPENVG,无论OpenVG库在哪里链接。
如果OpenVG实现使用EGL,则可能还需要设置QMAKE_LIBS_EGL。
QMAKE_LIBS_THREAD
注意:此变量仅在Unix平台上使用。
指定构建多线程目标时需要链接的所有库。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LIBS_X11
注意:此变量仅在Unix平台上使用。
指定所有X11库。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LIB_FLAG
如果指定了lib模板,则此变量不为空。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LINK_SHLIB_CMD
指定创建共享库时要执行的命令。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_LN_SHLIB
指定创建共享库链接时要执行的命令。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_OBJECTIVE_CFLAGS
指定用于构建项目的目标C/C++编译器标志。这些标志用于QMAKE_CFLAGS和QMAKE_CXXFLAGS之外。
QMAKE_POST_LINK
指定将TARGET链接在一起后要执行的命令。此变量通常为空,因此不会执行任何内容。
注意:此变量对Xcode项目不产生影响。
QMAKE_PRE_LINK
指定在将TARGET链接在一起之前要执行的命令。此变量通常为空,因此不会执行任何内容。
注意:此变量对Xcode项目不产生影响。
QMAKE_PROJECT_NAME
注意:此变量仅用于Visual Studio项目文件。
为IDE生成项目文件时确定项目的名称。默认值为目标名称。此变量的值通常由qmake处理,很少需要修改。
QMAKE_MAC_SDK
此变量在构建通用二进制文件时在macOS上使用。
QMAKE_MACOSX_DEPLOYMENT_TARGET
此变量仅在macOS上构建时生效。在该平台上,变量将被转发到MACOSX_DEPLOYMENT_TARGET环境变量,由编译器或链接器解释。有关详细信息,请参阅在macOS上部署应用程序文档。
QMAKE_MAKEFILE
指定要创建的Makefile的名称。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_QMAKE
包含qmake可执行文件的abosolute路径。
注意:不要尝试覆盖此变量的值。
QMAKE_RESOURCE_FLAGS
此变量用于自定义在使用它的每个构建规则中传递给资源编译器的选项列表。例如,以下行确保每次调用rcc时,-threshold和-compress选项都与特定值一起使用:
QMAKE_RESOURCE_FLAGS += -threshold 0 -compress 9
QMAKE_RPATHDIR
注意:此变量仅在Unix平台上使用。
指定在链接时添加到可执行文件的库路径列表,以便在运行时优先搜索这些路径。
当指定了相对路径时,qmake会将它们转换成动态链接器理解为相对于引用的可执行文件或库的位置的形式。这仅受某些平台(目前Linux和基于Darwin的平台)的支持,并且可以通过检查是否设置了QMAKE_REL_RPATH_BASE来检测。
QMAKE_RPATHLINKDIR
指定静态链接器用于搜索共享库的隐式依赖项的库路径列表。有关详细信息,请参阅ld(1)的手册页。
QMAKE_RUN_CC
指定构建对象所需的单个规则。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_RUN_CC_IMP
指定构建对象所需的单个规则。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_RUN_CXX
指定构建对象所需的单个规则。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_RUN_CXX_IMP
指定构建对象所需的单个规则。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_SONAME_PREFIX
如果已定义,此变量的值将用作附加到构建的共享库的SONAME标识符的路径。SONAME是动态链接器稍后将用于引用库的标识符。通常,此引用可以是库名称或完整库路径。在OS X和iOS上,可以使用以下占位符相对指定路径:
占位符 | 效果 |
---|---|
@rpath | 扩展到由当前进程可执行文件或引用库中的LC_RPATH mach-o命令定义的路径。 |
@executable_path | 展开到当前进程可执行位置。 |
@loader_path | 展开到引用的可执行文件或库位置。 |
在大多数情况下,使用@rpath就足够了,建议使用:
# <project root>/project.pro
QMAKE_SONAME_PREFIX = @rpath
但是,也可以使用不同的占位符或绝对路径指定前缀,例如以下之一:
# <project root>/project.pro
QMAKE_SONAME_PREFIX = @executable_path/…/Frameworks
QMAKE_SONAME_PREFIX = @loader_path/Frameworks
QMAKE_SONAME_PREFIX = /Library/Frameworks
有关详细信息,请参阅dyld在动态库安装名称上留档。
QMAKE_TARGET
指定项目目标的名称。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
QMAKE_TARGET_COMPANY
仅限Windows。指定项目目标的公司;这用于将公司名称放入应用程序的属性中。这仅在设置了VERSION或RC_ICONS变量且未设置RC_FILE和RES_FILE变量时使用。
QMAKE_TARGET_DESCRIPTION
仅限Windows。指定项目目标的描述;这用于将描述放入应用程序的属性中。这仅在设置了VERSION或RC_ICONS变量而未设置RC_FILE和RES_FILE变量时使用。
QMAKE_TARGET_COPYRIGHT
仅限Windows。指定项目目标的版权信息;这用于将版权信息放入应用程序的属性中。这仅在设置了VERSION或RC_ICONS变量且未设置RC_FILE和RES_FILE变量时使用。
QMAKE_TARGET_PRODUCT
仅限Windows。指定项目目标的产品;这用于将产品放入应用程序的属性中。这仅在设置了VERSION或RC_ICONS变量而未设置RC_FILE和RES_FILE变量时使用。
QT
指定项目使用的Qt模块。有关要为每个模块添加的值,请参阅模块留档。
默认情况下,QT包含core和gui,确保无需进一步配置即可构建标准GUI应用程序。
如果要在没有Qt GUI模块的情况下构建项目,则需要使用“-=”运算符排除gui值。以下行将导致构建最小的Qt项目:
QT -= gui # Only the core module is used.
如果您的项目是Qt Designer插件,请使用值uiplugin指定将项目构建为库,但具有对Qt Designer的特定插件支持。有关详细信息,请参阅构建和安装插件。
QTPLUGIN
指定要与应用程序链接的静态Qt插件的名称列表,以便它们可作为内置资源使用。
Qmake会自动添加使用的Qt模块通常需要的插件(请参阅QT)。默认值被调整为最佳的开箱即用体验。有关可用插件的列表以及覆盖自动链接的方法,请参阅静态插件。
此变量目前在链接Qt的共享/动态构建或链接库时无效。它可能在以后用于部署动态插件。
QT_VERSION
包含Qt的当前版本。
QT_MAJOR_VERSION
包含Qt的当前主要版本。
QT_MINOR_VERSION
包含Qt的当前次要版本。
QT_PATCH_VERSION
包含Qt的当前补丁版本。
RC_FILE
指定应用程序的资源文件的名称。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
RC_CODEPAGE
仅限Windows。指定应在生成的. rc文件中指定的代码页。这仅在设置了VERSION或RC_ICONS变量而未设置RC_FILE和RES_FILE变量时使用。
RC_DEFINES
仅限Windows。qmake将此变量的值添加为RC预处理器宏(/d选项)。如果未设置此变量,则使用DEFINES变量。
RC_DEFINES += USE_MY_STUFF
RC_ICONS
仅限Windows。指定应包含在生成的. rc文件中的图标。这仅在未设置RC_FILE和RES_FILE变量时使用。有关生成.rc文件的更多详细信息,请参阅平台说明。
RC_LANG
仅限Windows。指定应在生成的. rc文件中指定的语言。这仅在设置了VERSION或RC_ICONS变量而未设置RC_FILE和RES_FILE变量时使用。
RC_INCLUDEPATH
指定传递给Windows资源编译器的包含路径。
RCC_DIR
指定Qt资源编译器输出文件的目录。
例如:
unix:RCC_DIR = …/myproject/resources
win32:RCC_DIR = c:/myproject/resources
REQUIRES
指定作为条件评估的值列表。如果任何条件为假,则qmake在构建时跳过此项目(及其SUBDIRS)。
注意:如果您想在构建时跳过项目或子项目,我们建议使用requires()函数。
RESOURCES
指定目标的资源集合文件(qrc)的名称。有关资源集合文件的更多信息,请参阅Qt资源系统。
RES_FILE
指定目标编译的Windows资源文件的名称。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
SIGNATURE_FILE
注意:此变量仅在Windows CE上使用。
指定应使用哪个签名文件对项目目标进行签名。
注意:此变量将使用-signature选项覆盖您在配置中指定的设置。
SOURCES
指定项目中所有源文件的名称。
例如:
SOURCES = myclass.cpp \
login.cpp \
mainwindow.cpp
另请参见HEADERS。
SUBDIRS
当与subdirs模板一起使用时,此变量指定包含需要构建的项目部分的所有子目录或项目文件的名称。使用此变量指定的每个子目录都必须包含自己的项目文件。
建议每个子目录中的项目文件与子目录本身具有相同的基本名称,因为这使得省略文件名成为可能。例如,如果子目录名为myapp,则该目录中的项目文件应称为myapp.pro。
或者,您可以在任何目录中指定. pro文件的相对路径。强烈建议您仅指定当前项目的父目录或其子目录中的路径。
例如:
SUBDIRS = kernel \
tools \
myapp
如果您需要确保子目录按照指定的顺序构建,请更新CONFIG变量以包含ordered选项:
CONFIG += ordered
可以通过为SUBDIRS元素提供额外的修饰符来修改SUBDIRS的默认行为。支持的修饰符是:
修改 | 效果 |
---|---|
.subdir | 使用指定的子目录而不是SUBDIRS值。 |
.file | 显式指定子项目pro文件。不能与.subdir修饰符结合使用。 |
.depends | 此子项目依赖于指定的子项目。 |
.makefile | 子项目的makefile。仅在使用makefile的平台上可用。 |
.target | 用于与此子项目相关的makefile目标的基本字符串。仅在使用makefile的平台上可用。 |
例如,定义两个子目录,它们都位于与SUBDIRS值不同的目录中,并且其中一个子目录必须先于另一个子目录构建:
SUBDIRS += my_executable my_library
my_executable.subdir = app
my_executable.depends = my_library
my_library.subdir = lib
TARGET
指定目标文件的名称。默认包含项目文件的基本名称。
例如:
TEMPLATE = app
TARGET = myapp
SOURCES = main.cpp
上面的项目文件将在unix上生成一个名为myapp的可执行文件,在Windows上生成一个名为myapp.exe的可执行文件。
TARGET_EXT
指定TARGET的扩展名。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
TARGET_x
使用主版本号指定TARGET的扩展名。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
TARGET_x.y.z
使用版本号指定TARGET的扩展名。此变量的值通常由qmake或qmake. conf处理,很少需要修改。
TEMPLATE
指定生成项目时要使用的模板的名称。允许的值是:
选项 | 描述 |
---|---|
app | 创建用于构建应用程序的Makefile(默认值)。有关详细信息,请参阅构建应用程序。 |
lib | 创建用于构建库的Makefile。有关详细信息,请参阅构建库。 |
subdirs | 创建用于在子目录中构建目标的Makefile。使用SUBDIRS变量指定子目录。 |
aux | 创建一个不构建任何东西的Makefile。如果不需要调用编译器来创建目标,请使用它,例如,因为您的项目是用解释语言编写的。 注意:此模板类型仅适用于基于Makefile的生成器。特别是,它不适用于vcxproj和Xcode生成器。 |
vcapp | 仅限Windows。为Visual Studio创建应用程序项目。有关详细信息,请参阅创建Visual Studio项目文件。 |
vclib VC | 仅限Windows。为Visual Studio创建一个库项目。 |
例如:
EMPLATE = lib
SOURCES = main.cpp
TARGET = mylib
可以通过使用-t命令行选项指定新的模板类型来覆盖模板。这会在处理. pro文件后覆盖模板类型。对于使用模板类型来确定如何构建项目的.pro文件,有必要在命令行上声明TEMPLATE,而不是使用-t选项。
TRANSLATIONS
指定包含将用户交互界面文本翻译成非本地语言的翻译(. ts)文件列表。
有关Qtinternationalization(国际化)和本地化(本地化)的更多信息,请参阅Qt语言学家手册。
UI_DIR
指定应放置来自uic的所有中间文件的目录。
例如:
nix:UI_DIR = …/myproject/ui
win32:UI_DIR = c:/myproject/ui
VERSION
如果指定了app模板,则指定应用程序的版本号,如果指定了lib模板,则指定库的版本号。
在Windows上,如果未设置RC_FILE和RES_FILE变量,则触发. rc文件的自动生成。生成的.rc文件将包含FILEVERSION和PRODUCTVERSION条目,其中填充了主要、次要、补丁级别和内部版本号。每个数字必须在0到65535之间。有关.rc文件生成的更多详细信息,请参阅平台说明。
例如:
win32:VERSION = 1.2.3.4 # major.minor.patch.build
else:VERSION = 1.2.3 # major.minor.patch
VERSION_PE_HEADER
仅限Windows。指定版本号,Windows链接器通过 /VERSION选项放入. exe或.dll文件的标题中。只能指定主要和次要版本。如果未设置VERSION_PE_HEADER,它会从VERSION(如果已设置)回退到主要和次要版本。
VERSION_PE_HEADER = 1.2
VER_MAJ
如果指定了lib模板,则指定库的主要版本号。
VER_MIN
如果指定了lib模板,则指定库的次要版本号。
VER_PAT
如果指定了lib模板,则指定库的补丁版本号。
VPATH
告诉qmake在哪里搜索它无法打开的文件。例如,如果qmake查找SOURCES并找到无法打开的条目,它会查看整个VPATH列表以查看是否可以自行找到该文件。
另请参见依赖路径。
WINRT_MANIFEST
指定要传递给Windows Runtime上的应用程序清单的参数。允许的值是:
成员 | 描述 |
---|---|
architecture | 目标体系结构。默认为VCPROJ_ARCH。 |
background | 平铺背景颜色。默认为green。 |
capabilities | 指定要添加到功能列表的功能。 |
capabilities_device | 指定要添加到功能列表的设备功能(位置、网络摄像头等)。 |
default_language | 应用程序的默认语言代码。默认为“en”。 |
dependencies | 指定包所需的依赖项。 |
description | 包描述。默认为Default package description。 |
foreground | 平铺前景(文本)颜色。默认为light。此选项仅适用于Windows 8和Windows RT上的Windows应用商店应用程序。 |
iconic_tile_icon | iconic磁贴模板图标的图像文件。mkspec提供的默认值。 |
iconic_tile_small | 小iconic瓷砖模板徽标的图像文件。mkspec提供的默认值。 |
identity | 应用程序的唯一ID。默认为重用现有生成的清单UUID,如果不存在,则生成新UUID。 |
logo_30x30 | 大小为30x30像素的logo图像文件。这在Windows Phone上不受支持。 |
logo_41x41 | 大小为41x41像素的logo图像文件。这仅在Windows Phone上受支持。 |
logo_70x70 | 大小为70x70像素的logo图像文件。这在Windows Phone上不受支持。 |
logo_71x71 | 大小为71x71像素的logo图像文件。这仅在Windows Phone上受支持。 |
logo_150x150 | 大小为150x150像素的logo图像文件。所有Windows应用商店应用平台都支持这一点。 |
logo_310x150 | 大小为310x150像素的logo图像文件。所有Windows应用商店应用平台都支持这一点。 |
logo_310x310 | 大小为310x310像素的logo图像文件。所有Windows应用商店应用平台都支持这一点。 |
logo_620x300 | 大小为620x300像素的闪屏图像文件。这在Windows Phone上不受支持。 |
logo_480x800 | 大小为480x800像素的Splash sceen图像文件。这仅在Windows Phone上受支持。 |
logo_large | 大logo图像文件。这必须是150x150像素。所有Windows应用商店应用平台都支持。mkspec提供的默认值。 |
logo_medium | 中logo图像文件。对于Windows Phone,图像的像素大小必须为71x71,对于其他Windows Store App平台为70x70。mkspec提供的默认值。 |
logo_small | 小logo图像文件。对于Windows Phone,图像的像素大小必须为44x44,对于其他Windows Store App平台为30x30。mkspec提供的默认值。 |
logo_splash | 闪屏图像文件。对于Windows Phone,图像的像素大小必须为480x800,对于其他Windows Store App平台为620x300。mkspec提供的默认值。 |
logo_store | Windows应用商店的logo图像文件。mkspec提供的默认值。 |
logo_wide | 宽logo图像文件。这必须是310x150像素。所有Windows应用商店应用平台都支持。mkspec提供的默认值。 |
name | 显示给用户的包的名称。默认为TARGET。 |
phone_product_id | 产品的GUID。默认值为WINRT_MANIFEST。身份。(仅限Windows Phone) |
phone_publisher_id | 发布者的GUID。默认为无效的GUID。(仅限Windows Phone) |
publisher | 显示发布者的名称。默认为Default publisher display name。 |
publisher_id | 发布者的专有名称(默认值:CN=MyCN)。 |
target | 目标的名称(. exe)。默认为TARGET。 |
version | 包的版本号。默认为1.0.0.0。 |
minVersion | 运行包所需的最低Windows版本。默认为环境变量UCRTVersion。 |
maxVersionTested | 测试包的最大Windows版本。默认为WINRT_MANIFEST.minVersion |
您可以使用这些值的任意组合。
例如:
WINRT_MANIFEST.publisher = MyCompany
WINRT_MANIFEST.logo_store = someImage.png
WINRT_MANIFEST.capabilities += internetClient
WINRT_MANIFEST.capabilities_device += location
此外,可以使用WINRT_MANIFEST指定输入清单文件。
例如:
WINRT_MANIFEST = someManifest.xml.in
注意:logo_small、logo_medium和logo_large所需的图像大小取决于目标平台。如果提供了指定大小的描述,则会覆盖一般描述。
YACCSOURCES
指定要包含在项目中的Yacc源文件列表。所有依赖项、标头和源文件都将自动包含在项目中。
例如:
YACCSOURCES = moc.y
_PRO_FILE_
包含正在使用的项目文件的路径。
例如,以下行导致将项目文件的位置写入控制台:
message($$PRO_FILE)
注意:不要尝试覆盖此变量的值。
_PRO_FILE_PWD_
包含包含正在使用的项目文件的目录的路径。
例如,以下行将包含项目文件的目录的位置写入控制台:
message($$PRO_FILE_PWD)
注意:不要尝试覆盖此变量的值。
替换函数
Qmake提供了在配置过程中处理变量内容的函数。这些函数称为替换函数。通常,它们返回您可以分配给其他变量的值。您可以通过在函数前加上$运算符来获取这些值。替换函数可以分为内置函数和函数库。
另请参见测试函数。
内置替换函数
基本替换函数作为内置函数实现。
absolute_path(path[, base])
返回path的绝对路径。
如果未指定base,则使用当前目录作为基本目录。
例如,以下调用返回字符串"/home/johndoe/myproject/readme.txt":
message($$absolute_path(“readme.txt”, “/home/johndoe/myproject”))
另见clean_path(),relative_path()。
basename(variablename)
返回variablename中指定的文件的基本名称。
例如:
FILE = /etc/passwd
FILENAME = $$basename(FILE) #passwd
cat(filename[, mode])
返回filename的内容。您可以为mode指定以下选项:
blob:将文件的全部内容作为一个值返回
lines:将每一行作为单独的值返回(没有行尾)
true(默认值)和false将文件内容作为单独的值返回,根据qmake值列表拆分规则拆分(如在变量分配中)。如果mode是false,则将仅包含换行符的值插入到列表中以指示文件中的换行符位置。
clean_path(path)
返回path,目录分隔符规范化(转换为“/”)并删除冗余分隔符,并且“.”s和“…”s已解析(尽可能)。此函数是围绕QDir::cleanPath的包装器。
另见absolute_path(),relative_path(),shell_path(),system_path()。
dirname(file)
返回指定文件的目录名部分。例如:
FILE = /etc/X11R6/XF86Config
DIRNAME = $$dirname(FILE) #/etc/X11R6
enumerate_vars
返回所有已定义变量名称的列表。
escape_expand(arg1 [, arg2 …, argn])
接受任意数量的参数。它扩展每个参数的转义序列\n、\r、\t并将参数作为列表返回。
注意:如果您指定要按字面意思展开的字符串,则需要转义反斜杠,如以下代码片段所示:
message(“First line$$escape_expand(\\n)Second line”)
find(variablename, substr)
返回variablename中与正则表达式substr匹配的所有值。
MY_VAR = one two three four
MY_VAR2 = $$join(MY_VAR, " -L", -L) -Lfive
MY_VAR3 = $$member(MY_VAR, 2) $$find(MY_VAR, t.*)
MY_VAR2将包含’ -Lone -Ltwo -Lthree -Lfour -Lfive’‘,MY_VAR3将包含’ three two three’。
first(variablename)
返回variablename的第一个值。
例如,以下调用返回firstname:
CONTACT = firstname middlename surname phone
message($$first(CONTACT))
另请参见last()。
format_number(number[, options…])
以options指定的格式返回number。您可以指定以下选项:
- ibase=n将输入的基数设置为n
- obase=n将输出的基数设置为n
- width=n将输出的最小宽度设置为n。如果输出短于width,则用空格填充
- zeropad用零而不是空格填充输出
- padsign在输出中为正值添加一个空格
- alwayssign在输出中的正值前面加上一个加号
- leftalign将填充放在输出值的右侧
目前不支持浮点数。
例如,以下调用将十六进制数BAD转换为002989:
message($$format_number(BAD, ibase=16 width=6 zeropad))
fromfile(filename, variablename)
将filename评估为qmake项目文件并返回分配给variablename的值。
另请参见infile()。
getenv(variablename)
返回环境变量variablename的值。这主要相当于$(variablename)语法。但是,getenv函数支持名称中带有括号的环境变量。
join(variablename, glue, before, after)
将variablename的值与glue连接起来。如果该值不为空,则此函数的before为前缀,after为后缀。variablename是唯一必需的字段,其他默认为空字符串。如果您需要在glue、之前的或之后的中编码空格,则必须引用它们。
last(variablename)
返回variablename的最后一个值。
例如,以下调用返回phone:
CONTACT = firstname middlename surname phone
message($$last(CONTACT))
另请参见first()。
list(arg1 [, arg2 …, argn])
接受任意数量的参数。它创建一个唯一命名的变量,其中包含参数列表,并返回该变量的名称。您可以使用该变量编写循环,如以下代码片段所示
for(var, $$list(foo bar baz)) {
…
}
而不是:
values = foo bar baz
for(var, values) {
…
}
lower(arg1 [, arg2 …, argn])
接受任意数量的参数并将它们转换为小写。
另请参见upper()。
member(variablename, position)
返回variablename中的项目列表中给定position处的值。如果在指定的位置找不到项目,则返回一个空字符串。variablename是唯一必需的字段。如果未指定,position默认为0,导致返回列表中的第一个值。
prompt(question)
显示指定的question,并返回从标准输入读取的值。
quote(string)
将整个string转换为单个实体并返回结果。这只是将字符串用双引号括起来的一种奇特方式。
re_escape(string)
返回带有反斜杠转义的每个特殊正则表达式字符的string。此函数是对QRegExp::escape.的包装器。
relative_path(filePath[, base])
返回相对于base的filePath的路径。如果未指定base,则为当前项目目录。此函数是围绕QDir::relativeFilePath()的包装器。
另见absolute_path(),clean_path()。
replace(string, old_string, new_string)
在作为string提供的变量的内容中将old_string的每个实例替换为new_string。例如,代码
MESSAGE = This is a tent.
message($$replace(MESSAGE, tent, test))
打印消息:
This is a test.
sprintf(string, arguments…)
将%1-%9替换为函数arguments的逗号分隔列表中传递的参数,并返回处理后的字符串。
resolve_depends(variablename, prefix)
这是您通常不需要的内部函数。
reverse(variablename)
以相反的顺序返回variablename的值。
section(variablename, separator, begin, end)
返回variablename值的一部分。此函数是围绕QString::section的包装器。
例如,以下调用输出surname:
CONTACT = firstname:middlename:surname:phone
message($$section(CONTACT, :, 2, 2))
shadowed(path)
将项目源目录的路径映射到构建目录。此函数返回path用于源内构建。如果path指向源树之外,它将返回一个空字符串。
shell_path(path)
将path中的所有目录分隔符转换为与构建项目时使用的shell(即make工具调用的shell)兼容的分隔符。例如,当使用Windows shell时,斜杠会转换为反斜杠。
另请参见system_path()。
shell_quote(arg)
对构建项目时使用的shell引用arg。
size(variablename)
返回variablename的值数。
sort_depends(variablename, prefix)
这是您通常不需要的内部函数。
split(variablename, separator)
将variablename的值拆分为单独的值,并将它们作为列表返回。此函数是围绕QString::split的包装器。
例如:
CONTACT = firstname:middlename:surname:phone
message($$split(CONTACT, 😃)
system(command[, mode])
您可以使用system函数的此变体从命令中获取stdout并将其分配给变量。
例如:
UNAME = $$system(uname -s)
contains( UNAME, [lL]inux ):message( This looks like Linux ($$UNAME) to me )
另请参见system()的测试变体。
system_path(path)
将path中的所有目录分隔符转换为与system()函数用于调用命令的shell兼容的分隔符。例如,斜杠被转换为Windows shell的反斜杠。
另请参见shell_path()。
另请参见shell_quote()。
system_quote(arg)
system()函数使用的shell引用arg。
unique(variablename)
返回variablename中删除重复条目的值列表。例如:
ARGS = 1 2 3 2 5 1
ARGS = $$unique(ARGS) #1 2 3 5
upper(arg1 [, arg2 …, argn])
接受任意数量的参数并将它们转换为大写。
另请参见low()。
val_escape(variablename)
以能够将它们解析为qmake代码的方式转义variablename的值。
测试函数
测试函数返回一个布尔值,您可以在范围的条件部分进行测试。测试函数可以分为内置函数和函数库。
另请参见替换函数。
内置测试函数
基本测试函数作为内置函数实现。
cache(variablename, [set|add|sub] [transient] [super|stash], [source variablename])
这是您通常不需要的内部函数。
CONFIG(config)
此函数可用于测试放置在CONFIG变量中的变量。这与作用域相同,但具有额外的优势,即可以传递第二个参数来测试活动配置。由于值的顺序在CONFIG变量中很重要(即,最后一组将被视为互斥值的活动配置),可以使用第二个参数来指定要考虑的一组值。例如:
CONFIG = debug
CONFIG += release
CONFIG(release, debug|release):message(Release build!) #will print
CONFIG(debug, debug|release):message(Debug build!) #no print
因为release被认为是活动设置(用于特征解析),所以它将是用于生成构建文件的CONFIG。在常见情况下,不需要第二个参数,但对于特定的互斥测试,它是无价的。
contains(variablename, value)
如果变量variablename包含值value,则成功;否则失败。可以为参数值指定正则表达式。
您可以使用范围检查此函数的返回值。
contains( drivers, network ) {
# drivers contains ‘network’
message( “Configuring for network build…” )
HEADERS += network.h
SOURCES += network.cpp
}
仅当drivers变量包含值network时,才会处理范围的内容。如果是这种情况,则将适当的文件添加到SOURCES和HEADERS变量中。
count(variablename, number)
如果变量variablename包含具有指定number值的列表,则成功;否则失败。
此函数用于确保仅在变量包含正确数量的值时才处理作用域内的声明。例如:
options = $$find(CONFIG, “debug”) $$find(CONFIG, “release”)
count(options, 2) {
message(Both release and debug specified.)
}
debug(level, message)
检查qmake是否在指定的调试级别运行。如果是,它返回true并打印调试消息。
defined(name[, type])
测试是否定义了函数或变量name。如果省略type,则检查所有函数。要仅检查变量或特定类型的函数,请指定type。它可以具有以下值:
- Test:只检查测试函数
- Replace:只检查替换函数
- Var:只检查变量
equals(variablename, value)
测试variablename是否等于字符串value。
例如:
TARGET = helloworld
equals(TARGET, “helloworld”) {
message(“The target assignment was successful.”)
}
error(string)
此函数从不返回值。qmake将string作为错误消息显示给用户并退出。此函数应仅用于不可恢复的错误。
例如:
error(An error has occurred in the configuration process.)
eval(string)
使用qmake语法规则评估字符串的内容并返回true。字符串中可以使用定义和赋值来修改现有变量的值或创建新定义。
例如:
eval(TARGET = myapp) {
message($$TARGET)
}
注意:引号可以用来分隔字符串,如果不需要返回值可以丢弃。
exists(filename)
测试具有给定filename的文件是否存在。如果该文件存在,则函数成功;否则失败。如果为文件名指定了正则表达式,如果任何文件与指定的正则表达式匹配,则此函数成功。
例如:
exists( $(QTDIR)/lib/libqt-mt* ) {
message( “Configuring for multi-threaded Qt…” )
CONFIG += thread
}
注意:“/”应用作目录分隔符,无论使用的平台如何。
export(variablename)
将variablename的当前值从函数的本地上下文导出到全局上下文。
files(pattern[, recursive=false])
展开指定的通配符模式并返回文件名列表。如果recursive为真,则此函数下降到子目录。
for(iterate, list)
启动一个循环,遍历list中的所有值,依次将iterate设置为每个值。为方便起见,如果list为1…10,则iterate将遍历值1到10。
LIST = 1 2 3
for(a, LIST):exists(file.$${a}):message(I see a file.$${a}!)
greaterThan(variablename, value)
测试variablename的值是否大于value。首先,此函数尝试进行数值比较。如果至少有一个操作数无法转换,则此函数进行字符串比较。
例如:
ANSWER = 42
greaterThan(ANSWER, 1) {
message(“The answer might be correct.”)
}
不可能直接将两个数字作为字符串进行比较。作为一种解决方法,构造带有非数字前缀的临时值并比较它们。
VALUE = 123
TMP_VALUE = x$$VALUE
greaterThan(TMP_VALUE, x456): message(“Condition may be true.”)
if(condition)
评估condition。它用于对布尔表达式进行分组。
例如:
if(linux-g++*|macx-g++*):CONFIG(debug, debug|release) {
message(“We are on Linux or Mac OS, and we are in debug mode.”)
}
include(filename)
将filename指定的文件的内容包含到包含它的当前项目中。如果包含filename,此函数成功;否则失败。包含的文件将立即处理。
您可以使用此函数作为范围的条件来检查文件是否包含在内。例如:
include( shared.pri )
OPTIONS = standard custom
!include( options.pri ) {
message( “No custom build options specified” )
OPTIONS -= custom
}
infile(filename, var, val)
如果文件filename(由qmake本身解析时)包含值为val的变量var,则成功;否则失败。如果您没有指定val,该函数将测试文件中是否分配了var。
isActiveConfig
这是CONFIG函数的别名。
isEmpty(variablename)
如果变量variablename为空,则成功;否则失败。这相当于count( variablename, 0 )。
例如:
isEmpty( CONFIG ) {
CONFIG += warn_on debug
}
isEqual
这是equals函数的别名。
lessThan(variablename, value)
测试variablename的值是否小于value。作为大于()工作。
例如:
ANSWER = 42
lessThan(ANSWER, 1) {
message(“The answer might be wrong.”)
}
load(feature)
加载由feature指定的特性文件(.prf),除非该特性已经加载。
log(message)
在控制台上打印一条消息。与message函数不同,既不添加文本也不附加换行符。
另请参见message()。
message(string)
总是成功,并将string作为一般消息显示给用户。与error()函数不同,此函数允许处理继续。
message( “This is a message” )
上面的行导致“这是一条消息”写入控制台。引号的使用是可选的,但建议使用。
注意:默认情况下,消息会为qmake为给定项目生成的每个Makefile写入。如果您想确保每个项目只出现一次消息,请结合范围测试build_pass变量以在构建期间过滤掉消息。例如:
!build_pass:message( “This is a message” )
mkpath(dirPath)
创建目录路径dirPath。此函数是QDir::makepath函数的包装器。
requires(condition)
评估condition。如果条件为假,qmake在构建时跳过此项目(及其SUBDIRS)
注意:您也可以为此目的使用REQUIRES变量。但是,我们建议改用此函数。
system(command)
在辅助shell中执行给定的command。如果命令以零退出状态返回,则成功;否则失败。您可以使用范围检查此函数的返回值。
例如:
system(“ls /bin”): HAS_BIN = TRUE
另请参阅system()的替换变体。
touch(filename, reference_filename)
更新filename的时间戳以匹配reference_filename的时间戳。
unset(variablename)
从当前上下文中删除variablename。
例如:
NARF = zort
unset(NARF)
!defined(NARF, var) {
message(“NARF is not defined.”)
}
warning(string)
始终成功,并将string作为警告消息显示给用户。
write_file(filename, [variablename, [mode]])
将variablename的值写入名为filename的文件,每个值位于单独的行上。如果未指定variablename,则创建一个空文件。如果mode是append并且该文件已存在,则附加到它而不是替换它。
测试函数库
复杂的测试函数在. prf文件库中实现。
packagesExist(packages)
使用PKGCONFIG机制来确定给定的包在项目解析时是否存在。
这对于可选地启用或禁用功能很有用。例如:
packagesExist(sqlite3 QtNetwork QtDeclarative) {
DEFINES += USE_FANCY_UI
}
然后,在代码中:
#ifdef USE_FANCY_UI
// Use the fancy UI, as we have extra packages available
#endif
prepareRecursiveTarget(target)
通过准备遍历所有子目录的目标来促进创建类似于install目标的项目范围目标。例如:
TEMPLATE = subdirs
SUBDIRS = one two three
prepareRecursiveTarget(check)
具有have_no_default或no_<target>_target的子目录。CONFIG从此目标中排除:
two.CONFIG += no_check_target
您必须手动将准备好的目标添加到QMAKE_EXTRA_TARGETS:
QMAKE_EXTRA_TARGETS += check
要使目标全局化,需要将上面的代码包含到每个subdirs子项目中。此外,要使这些目标做任何事情,非subdirs子项目需要包含相应的代码。实现这一点的最简单方法是创建自定义功能文件。例如:
# <project root>/features/mycheck.prf
equals(TEMPLATE, subdirs) {
prepareRecursiveTarget(check)
} else {
check.commands = echo hello user
}
QMAKE_EXTRA_TARGETS += check
需要将功能文件注入到每个子项目中,例如通过. qmake.conf:
CONFIG += mycheck
qtCompileTest(test)
构建一个测试项目。如果测试通过,则返回true,并将config_<test>添加到CONFIG变量中。否则,返回false。
要使此功能可用,您需要加载相应的功能文件:
# <project root>/project.pro
load(configure)
这也将变量QMAKE_CONFIG_TESTS_DIR到项目父目录的config.tests子目录。加载功能文件后可以覆盖此值。
在测试目录中,每个测试必须有一个子目录,其中包含一个简单的qmake项目。以下代码片段说明了项目的. pro文件:
# <project root>/config.tests/test/test.pro
SOURCES = main.cpp
LIBS += -ltheFeature
# Note that the test project is built without Qt by default.
以下代码片段说明了项目的主要. cpp文件:
// <project root>/config.tests/test/main.cpp
#include <TheFeature/MainHeader.h>
int main() { return featureFunction(); }
以下代码片段显示了测试的调用:
# <project root>/project.pro
qtCompileTest(test)
如果测试项目构建成功,则测试通过。
测试结果会自动缓存,这也使它们可用于所有子项目。因此,建议在顶级项目文件中运行所有配置测试。
要抑制缓存结果的重用,请将CONFIG+=recheck传递给qmake。
另请参见load()。
qtHaveModule(name)
检查是否存在由name指定的Qt模块。有关可能值的列表,请参阅QT。
ustom
}
infile(filename, var, val)
如果文件filename(由qmake本身解析时)包含值为val的变量var,则成功;否则失败。如果您没有指定val,该函数将测试文件中是否分配了var。
isActiveConfig
这是CONFIG函数的别名。
isEmpty(variablename)
如果变量variablename为空,则成功;否则失败。这相当于count( variablename, 0 )。
例如:
isEmpty( CONFIG ) {
CONFIG += warn_on debug
}
isEqual
这是equals函数的别名。
lessThan(variablename, value)
测试variablename的值是否小于value。作为大于()工作。
例如:
ANSWER = 42
lessThan(ANSWER, 1) {
message(“The answer might be wrong.”)
}
load(feature)
加载由feature指定的特性文件(.prf),除非该特性已经加载。
log(message)
在控制台上打印一条消息。与message函数不同,既不添加文本也不附加换行符。
另请参见message()。
message(string)
总是成功,并将string作为一般消息显示给用户。与error()函数不同,此函数允许处理继续。
message( “This is a message” )
上面的行导致“这是一条消息”写入控制台。引号的使用是可选的,但建议使用。
注意:默认情况下,消息会为qmake为给定项目生成的每个Makefile写入。如果您想确保每个项目只出现一次消息,请结合范围测试build_pass变量以在构建期间过滤掉消息。例如:
!build_pass:message( “This is a message” )
mkpath(dirPath)
创建目录路径dirPath。此函数是QDir::makepath函数的包装器。
requires(condition)
评估condition。如果条件为假,qmake在构建时跳过此项目(及其SUBDIRS)
注意:您也可以为此目的使用REQUIRES变量。但是,我们建议改用此函数。
system(command)
在辅助shell中执行给定的command。如果命令以零退出状态返回,则成功;否则失败。您可以使用范围检查此函数的返回值。
例如:
system(“ls /bin”): HAS_BIN = TRUE
另请参阅system()的替换变体。
touch(filename, reference_filename)
更新filename的时间戳以匹配reference_filename的时间戳。
unset(variablename)
从当前上下文中删除variablename。
例如:
NARF = zort
unset(NARF)
!defined(NARF, var) {
message(“NARF is not defined.”)
}
warning(string)
始终成功,并将string作为警告消息显示给用户。
write_file(filename, [variablename, [mode]])
将variablename的值写入名为filename的文件,每个值位于单独的行上。如果未指定variablename,则创建一个空文件。如果mode是append并且该文件已存在,则附加到它而不是替换它。
测试函数库
复杂的测试函数在. prf文件库中实现。
packagesExist(packages)
使用PKGCONFIG机制来确定给定的包在项目解析时是否存在。
这对于可选地启用或禁用功能很有用。例如:
packagesExist(sqlite3 QtNetwork QtDeclarative) {
DEFINES += USE_FANCY_UI
}
然后,在代码中:
#ifdef USE_FANCY_UI
// Use the fancy UI, as we have extra packages available
#endif
prepareRecursiveTarget(target)
通过准备遍历所有子目录的目标来促进创建类似于install目标的项目范围目标。例如:
TEMPLATE = subdirs
SUBDIRS = one two three
prepareRecursiveTarget(check)
具有have_no_default或no_<target>_target的子目录。CONFIG从此目标中排除:
two.CONFIG += no_check_target
您必须手动将准备好的目标添加到QMAKE_EXTRA_TARGETS:
QMAKE_EXTRA_TARGETS += check
要使目标全局化,需要将上面的代码包含到每个subdirs子项目中。此外,要使这些目标做任何事情,非subdirs子项目需要包含相应的代码。实现这一点的最简单方法是创建自定义功能文件。例如:
# <project root>/features/mycheck.prf
equals(TEMPLATE, subdirs) {
prepareRecursiveTarget(check)
} else {
check.commands = echo hello user
}
QMAKE_EXTRA_TARGETS += check
需要将功能文件注入到每个子项目中,例如通过. qmake.conf:
CONFIG += mycheck
qtCompileTest(test)
构建一个测试项目。如果测试通过,则返回true,并将config_<test>添加到CONFIG变量中。否则,返回false。
要使此功能可用,您需要加载相应的功能文件:
# <project root>/project.pro
load(configure)
这也将变量QMAKE_CONFIG_TESTS_DIR到项目父目录的config.tests子目录。加载功能文件后可以覆盖此值。
在测试目录中,每个测试必须有一个子目录,其中包含一个简单的qmake项目。以下代码片段说明了项目的. pro文件:
# <project root>/config.tests/test/test.pro
SOURCES = main.cpp
LIBS += -ltheFeature
# Note that the test project is built without Qt by default.
以下代码片段说明了项目的主要. cpp文件:
// <project root>/config.tests/test/main.cpp
#include <TheFeature/MainHeader.h>
int main() { return featureFunction(); }
以下代码片段显示了测试的调用:
# <project root>/project.pro
qtCompileTest(test)
如果测试项目构建成功,则测试通过。
测试结果会自动缓存,这也使它们可用于所有子项目。因此,建议在顶级项目文件中运行所有配置测试。
要抑制缓存结果的重用,请将CONFIG+=recheck传递给qmake。
另请参见load()。
qtHaveModule(name)
检查是否存在由name指定的Qt模块。有关可能值的列表,请参阅QT。