qmake 教程
qmake的介绍
qmake的介绍
qmake是Trolltech公司创建的用来为不同的平台和编译器书写Makefile的工具。
手写Makefile是比较困难并且容易出错的，尤其是需要给不同的平台和编译器组合写几个Makefile。使用qmake，开发者创建一个简单的“项目”文件并且运行qmake生成适当的Makefile。qmake会注意所有的编译器和平台的依赖性，可以把开发者解放出来只关心他们的代码。Trolltech公司使用qmake作为Qt库和Qt所提供的工具的主要连编工具。
qmake也注意了Qt的特殊需求，可以自动的包含moc和uic的连编规则。
安装qmake
安装qmake
当Qt被连编的时候，默认情况下qmake也会被连编。
这一部分解释如何手工连编qmake。如果你已经有了qmake，可以跳过这里，请看10分钟学会使用qmake。
手动安装qmake
在手工连编Qt之前，下面这些环境变量必须被设置：
· QMAKESPEC
这个必须设置为你所使用的系统的平台和编译器的组合。
举例来说，加入你使用的是Windows和Microsoft Visual Studio，你应该把环境变量设置为win32-msvc。如果你使用的是Solaris和g++，你应该把环境变量设置为solaris-g++。
当你在设置QMAKESPEC时，可以从下面的可能的环境变量列表中进行选择：
aix-64 hpux-cc irix-032 netbsd-g++ solaris-cc unixware7-g++ aix-g++ hpux-g++ linux-cxx openbsd-g++ solaris-g++ win32-borland aix-xlc hpux-n64 linux-g++ openunix-cc sunos-g++ win32-g++ bsdi-g++ hpux-o64 linux-icc qnx-g++ tru64-cxx win32-msvc dgux-g++ hurd-g++ linux-kcc reliant-64 tru64-g++ win32-watc freebsd-g++ irix-64 macx-pbuilder reliant-cds ultrix-g++ win32-visa hpux-acc irix-g++ macx-g++ sco-g++ unixware-g hpux-acc irix-n32 solaris-64 unixware7-cc
envvar是下面之一时，环境变量应该被设置到qws/envvar：
linux-arm-g++ linux-generic-g++ linux-mips-g++ linux-x86-g++ linux-freebsd-g++ linux-ipaq-g++ linux-solaris-g++ qnx-rtp-g++
· QTDIR
这个必须设置到Qt被（或者将被）安装到的地方。比如，c:/qt和/local/qt。
一旦环境变量被设置到qmake目录，$QTDIR/qmake，比如C:/qt/qmake，现在根据你的编译器运行make或者nmake。
当编译完成时，qmake已经可以使用了。
10分钟学会使用qmake
创建一个项目文件
qmake使用储存在项目（.pro）文件中的信息来决定Makefile文件中该生成什么。
一个基本的项目文件包含关于应用程序的信息，比如，编译应用程序需要哪些文件，并且使用哪些配置设置。
这里是一个简单的示例项目文件：
SOURCES = hello.cpp
HEADERS = hello.h
CONFIG += qt warn_on release
我们将会提供一行一行的简要解释，具体细节将会在手册的后面的部分解释。
SOURCES = hello.cpp
这一行指定了实现应用程序的源程序文件。在这个例子中，恰好只有一个文件，hello.cpp。大部分应用程序需要多个文件，这种情况下可以把文件列在一行中，以空格分隔，就像这样：
SOURCES = hello.cpp main.cpp
另一种方式，每一个文件可以被列在一个分开的行里面，通过反斜线另起一行，就像这样：
SOURCES = hello.cpp /
main.cpp
一个更冗长的方法是单独地列出每一个文件，就像这样：
SOURCES += hello.cpp
SOURCES += main.cpp
这种方法中使用“+=”比“=”更安全，因为它只是向已有的列表中添加新的文件，而不是替换整个列表。
HEADERS这一行中通常用来指定为这个应用程序创建的头文件，举例来说：
HEADERS += hello.h
列出源文件的任何一个方法对头文件也都适用。
CONFIG这一行是用来告诉qmake关于应用程序的配置信息。
CONFIG += qt warn_on release
在这里使用“+=”，是因为我们添加我们的配置选项到任何一个已经存在中。这样做比使用“=”那样替换已经指定的所有选项是更安全的。
CONFIG一行中的qt部分告诉qmake这个应用程序是使用Qt来连编的。这也就是说qmake在连接和为编译添加所需的包含路径的时候会考虑到Qt库的。
CONFIG一行中的warn_on部分告诉qmake要把编译器设置为输出警告信息的。
CONFIG一行中的release部分告诉qmake应用程序必须被连编为一个发布的应用程序。在开发过程中，程序员也可以使用debug来替换release，稍后会讨论这里的。
项目文件就是纯文本（比如，可以使用像记事本、vim和xemacs这些编辑器）并且必须存为“.pro”扩展名。应用程序的执行文件的名称必须和 项目文件的名称一样，但是扩展名是跟着平台而改变的。举例来说，一个叫做“hello.pro”的项目文件将会在Windows下生成 “hello.exe”，而在Unix下生成“hello”。
生成Makefile
当你已经创建好你的项目文件，生成Makefile就很容易了，你所要做的就是先到你所生成的项目文件那里然后输入：
Makefile可以像这样由“.pro”文件生成：
qmake -o Makefile hello.pro
对于Visual Studio的用户，qmake也可以生成“.dsp”文件，例如：
qmake -t vcapp -o hello.dsp hello.pro
qmake教程
qmake教程介绍
这个教程可以教会你如何使用qmake。我们建议你看完这个教程之后读一下qmake手册。
开始很简单
让我们假设你已经完成了你的应用程序的一个基本实现，并且你已经创建了下述文件：
· hello.cpp
· hello.h
· main.cpp
你可以在qt/qmake/example中发现这些文件。你对这个应用程序的配置仅仅知道的另一件事是它是用Qt写的。首先，使用你所喜欢的纯文本编辑器，在qt/qmake/tutorial中创建一个叫做hello.pro的文件。你所要做的第一件事是添加一些行来告诉qmake关于你所开发的项目中的源文件和头文件这一部分。
我们先把源文件添加到项目文件中。为了做到这点，你需要使用SOURCES变量。只要用SOURCES +=来开始一行，并且把hello.cpp放到它后面。你需要写成这样：
SOURCES += hello.cpp
我们对项目中的每一个源文件都这样做，直到结束：
SOURCES += hello.cpp
SOURCES += 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
最后一步是设置CONFIG变量。因为这是一个Qt应用程序，我们需要把“qt”放到CONFIG这一行中，这样qmake才会在连接的时候添加相关的库，并且保证moc和uic的连编行也被包含到Makefile中。
最终完成的项目文件应该是这样的：
CONFIG += qt
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
你现在可以使用qmake来为你的应用程序生成Makefile。在你的应用程序目录中，在命令行下输入：
qmake -o Makefile hello.pro
然后根据你所使用的编译器输入make或者nmake。
使应用程序可以调试
应用程序的发布版本不包含任何调试符号或者其它调试信息。在开发过程中，生成一个含有相关信息的应用程序的调试版本是很有用处的。通过在项目文件的CONFIG变量中添加“debug”就可以很简单地实现。
例如：
CONFIG += qt debug
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
像前面一样使用qmake来生成一个Makefile并且你就能够调试你的应用程序了。
添加特定平台的源文件
在编了几个小时的程序之后，你也许开始为你的应用程序编写与平台相关的部分，并且决定根据平台的不同编写不同的代码。所以现在你有两个信文件要包含到你的项目文件中－hello_win.cpp和hello_x11.cpp。我们不能仅仅把这两个文件放到SOURCES变量中，因为那样的话会把这两个文件都加到Makefile中。所以我们在这里需要做的是根据qmake所运行的平台来使用相应的作用域来进行处理。
为Windows平台添加的依赖平台的文件的简单的作用域看起来就像这样：
win32 {
SOURCES += hello_win.cpp
}
所以如果qmake运行在Windows上的时候，它就会把hello_win.cpp添加到源文件列表中。如果qmake运行在其它平台上的时候，它会很简单地把这部分忽略。现在接下来我们要做的就是添加一个X11依赖文件的作用域。
当你做完了这部分，你的项目文件应该和这样差不多：
CONFIG += qt debug
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
win32 {
SOURCES += hello_win.cpp
}
x11 {
SOURCES += hello_x11.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 += qt debug
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
win32 {
SOURCES += hello_win.cpp
}
x11 {
SOURCES += hello_x11.cpp
}
!exists( main.cpp ) {
error( "No main.cpp file found" )
}
像前面一样使用qmake来生成Makefile。如果你临时改变main.cpp的名称，你会看到信息，并且qmake会停止处理。
检查多于一个的条件
假设你使用Windows并且当你在命令行运行你的应用程序的时候你想能够看到qDebug()语句。除非你在连编你的程序的时候使用console设置，你不会看到输出。我们可以很容易地把console添加到CONFIG行中，这样在Windows下，Makefile就会有这个设置。但是如果告诉你我们只是想在当我们的应用程序运行在Windows下并且当debug已经在CONFIG行中的时候，添加console。这需要两个嵌套的作用域；只要生成一个作用域，然后在它里面再生成另一个。把设置放在最里面的作用域里，就像这样：
win32 {
debug {
CONFIG += console
}
}
嵌套的作用域可以使用冒号连接起来，所以最终的项目文件看起来像这样：
CONFIG += qt debug
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
win32 {
SOURCES += hello_win.cpp
}
x11 {
SOURCES += hello_x11.cpp
}
!exists( main.cpp ) {
error( "No main.cpp file found" )
}
win32:debug {
CONFIG += console
}
就这些了！你现在已经完成了qmake的教程，并且已经准备好为你的开发项目写项目文件了。
qmake概念
介绍qmake
qmake是用来为不同的平台的开发项目创建makefile的Trolltech开发一个易于使用的工具。qmake简化了makefile的生成，所以为了创建一个makefile只需要一个只有几行信息的文件。qmake可以供任何一个软件项目使用，而不用管它是不是用Qt写的，尽管它包含了为支持Qt开发所拥有的额外的特征。
qmake基于一个项目文件这样的信息来生成makefile。项目文件可以由开发者生成。项目文件通常很简单，但是如果需要它是非常完善的。不用修改项目文件，qmake也可以为为Microsoft Visual Studio生成项目。
qmake的概念
QMAKESPEC环境变量
举例来说，如果你在Windows下使用Microsoft Visual Studio，然后你需要把QMAKESPEC环境变量设置为win32-msvc。如果你在Solaris上使用gcc，你需要把QMAKESPEC环境变量设置为solaris-g++。
在qt/mkspecs中的每一个目录里面，都有一个包含了平台和编译器特定信息的qmake.conf文件。这些设置适用于你要使用qmake的任何项目，请不要修改它，除非你是一个专家。例如，假如你所有的应用程序都必须和一个特定的库连接，你可以把这个信息添加到相应的qmake.conf文件中。
项目(.pro)文件
一个项目文件是用来告诉qmake关于为这个应用程序创建makefile所需要的细节。例如，一个源文件和头文件的列表、任何应用程序特定配置、例如一个必需要连接的额外库、或者一个额外的包含路径，都应该放到项目文件中。
“#”注释
你可以为项目文件添加注释。注释由“#”符号开始，一直到这一行的结束。
模板
模板变量告诉qmake为这个应用程序生成哪种makefile。下面是可供使用的选择：
· app - 建立一个应用程序的makefile。这是默认值，所以如果模板没有被指定，这个将被使用。
· lib - 建立一个库的makefile。
· vcapp - 建立一个应用程序的Visual Studio项目文件。
· vclib - 建立一个库的Visual Studio项目文件。
· subdirs - 这是一个特殊的模板，它可以创建一个能够进入特定目录并且为一个项目文件生成makefile并且为它调用make的makefile。
“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会为所需的提供默认值。例如，一个实例项目文件也许就像这样：
TEMPLATE = app
DESTDIR = c:/helloapp
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
DEFINES += QT_DLL
CONFIG += qt warn_on release
如果条目是单值的，比如template或者目的目录，我们是用“=”，但如果是多值条目，我们使用“+=”来为这个类型添加现有的条目。使用“=”会用新值替换原有的值，例如，如果我们写了DEFINES=QT_DLL，其它所有的定义都将被删除。
“lib”模板
“lib”模板告诉qmake为建立一个库而生成makefile。当使用这个模板时，除了“app”模板中提到系统变量，还有一个VERSION是被支持的。你需要在为库指定特定信息的.pro文件中使用它们。
· VERSION - 目标库的版本号，比如，2.3.1。
“subdirs”模板
“subdirs”模板告诉qmake生成一个makefile，它可以进入到特定子目录并为这个目录中的项目文件生成makefile并且为它调用make。
在这个模板中只有一个系统变量SUBDIRS可以被识别。这个变量中包含了所要处理的含有项目文件的子目录的列表。这个项目文件的名称是和子目录同名的，这样qmake就可以发现它。例如，如果子目里是“myapp”，那么在这个目录中的项目文件应该被叫做myapp.pro。
CONFIG变量
配置变量指定了编译器所要使用的选项和所需要被连接的库。配置变量中可以添加任何东西，但只有下面这些选项可以被qmake识别。
下面这些选项控制着使用哪些编译器标志：
· release - 应用程序将以release模式连编。如果“debug”被指定，它将被忽略。
· debug - 应用程序将以debug模式连编。
· warn_on - 编译器会输出尽可能多的警告信息。如果“warn_off”被指定，它将被忽略。
· warn_off - 编译器会输出尽可能少的警告信息。
下面这些选项定义了所要连编的库/应用程序的类型：
· qt - 应用程序是一个Qt应用程序，并且Qt库将会被连接。
· thread - 应用程序是一个多线程应用程序。
· x11 - 应用程序是一个X11应用程序或库。
· windows - 只用于“app”模板：应用程序是一个Windows下的窗口应用程序。
· console - 只用于“app”模板：应用程序是一个Windows下的控制台应用程序。
· dll - 只用于“lib”模板：库是一个共享库（dll）。
· staticlib - 只用于“lib”模板：库是一个静态库。
· plugin - 只用于“lib”模板：库是一个插件，这将会使dll选项生效。
例如，如果你的应用程序使用Qt库，并且你想把它连编为一个可调试的多线程的应用程序，你的项目文件应该会有下面这行：
CONFIG += qt thread debug
注意，你必须使用“+=”，不要使用“=”，否则qmake就不能正确使用连编Qt的设置了，比如没法获得所编译的Qt库的类型了。
qmake高级概念
qmake高级概念
迄今为止，我们见到的qmake项目文件都非常简单，仅仅是一些name = value和name += value的列表行。qmake提供了很多更强大的功能，比如你可以使用一个简单的项目文件来为多个平台生成makefile。
操作符
到目前为止，你已经看到在项目文件中使用的=操作符和+=操作符。这里能够提供更多的可供使用的操作符，但是其中的一些需要谨慎地使用，因为它们也许会比你期待的改变的更多。
“=”操作符
这个操作符简单分配一个值给一个变量。使用方法如下：
TARGET = myapp
这将会设置TARGET变量为myapp。这将会删除原来对TARGET的任何设置。
“+=”操作符
这个操作符将会向一个变量的值的列表中添加一个值。使用方法如下：
DEFINES += QT_DLL
这将会把QT_DLL添加到被放到makefile中的预处理定义的列表中。
“-=”操作符
这个操作符将会从一个变量的值的列表中移去一个值。使用方法如下：
DEFINES -= QT_DLL
这将会从被放到makefile中的预处理定义的列表中移去QT_DLL。
“*=”操作符
这个操作符仅仅在一个值不存在于一个变量的值的列表中的时候，把它添加进去。使用方法如下：
DEFINES *= QT_DLL
只用在QT_DLL没有被定义在预处理定义的列表中时，它才会被添加进去。
“~=”操作符
这个操作符将会替换任何与指定的值的正则表达式匹配的任何值。使用方法如下：
DEFINES ~= s/QT_[DT].+/QT
这将会用QT来替代任何以QT_D或QT_T开头的变量中的QT_D或QT_T。
作用域
作用域和“if”语句很相似，如果某个条件为真，作用域中的设置就会被处理。作用域使用方法如下：
win32 {
DEFINES += QT_DLL
}
上面的代码的作用是，如果在Windows平台上使用qmake，QT_DLL定义就会被添加到makefile中。如果在Windows平台以外的平台上使用qmake，这个定义就会被忽略。你也可以使用qmake执行一个单行的条件/任务，就像这样：
win32:DEFINES += QT_DLL
比如，假设我们想在除了Windows平台意外的所有平台处理些什么。我们想这样使用作用域来达到这种否定效果：
!win32 {
DEFINES += QT_DLL
}
CONFIG行中的任何条目也都是一个作用域。比如，你这样写：
CONFIG += warn_on
你将会得到一个称作“warn_on”的作用域。这样将会使在不丢失特定条件下可能所需的所有自定义设置的条件下，很容易地修改项目中的配置。因为你可能把你自己的值放到CONFIG行中，这将会为你的makefile而提供给你一个非常强大的配置工具。比如：
CONFIG += qt warn_on debug
debug {
TARGET = myappdebug
}
release {
TARGET = myapp
}
在上面的代码中，两个作用域被创建，它们依赖于CONFIG行中设置的是什么。在这个例子中，debug在CONFIG行中，所以TARGET变量被设置为myappdebug。如果release在CONFIG行中，那么TARGET变量将会被设置为myapp。
当然也可以在处理一些设置之前检查两个事物。例如，如果你想检查平台是否是Windows并且线程设置是否被设定，你可以这样写：
win32 {
thread {
DEFINES += QT_THREAD_SUPPORT
}
}
为了避免写出许多嵌套作用域，你可以这样使用冒号来嵌套作用域：
win32:thread {
DEFINES += QT_THREAD_SUPPORT
}
一旦一个测试被执行，你也许也要做else/elseif操作。这种情况下，你可以很容易地写出复杂的测试。这需要使用特殊的“else”作用域，它可以和其它作用域进行组合（也可以向上面一样使用冒号），比如：
win32:thread {
DEFINES += QT_THREAD_SUPPORT
} else:debug {
DEFINES += QT_NOTHREAD_DEBUG
} else {
warning("Unknown configuration")
}
变量
到目前为止我们遇到的变量都是系统变量，比如DEFINES、SOURCES和HEADERS。你也可以为你自己创建自己的变量，这样你就可以在作用域中使用它们了。创建自己的变量很容易，只要命名它并且分配一些东西给它。比如：
MY_VARIABLE = value
现在你对你自己的变量做什么是没有限制的，同样地，qmake将会忽略它们，除非需要在一个作用域中考虑它们。
你也可以通过在其它任何一个变量的变量名前加$$来把这个变量的值分配给当前的变量。例如：
MY_DEFINES = $$DEFINES
现在MY_DEFINES变量包含了项目文件在这点时DEFINES变量的值。这也和下面的语句一样：
MY_DEFINES = $${DEFINES}
第二种方法允许你把一个变量和其它变量连接起来，而不用使用空格。qmake将允许一个变量包含任何东西（包括$(VALUE)，可以直接在makefile中直接放置，并且允许它适当地扩张，通常是一个环境变量）。无论如何，如果你需要立即设置一个环境变量，然后你就可以使用$$()方法。比如：
MY_DEFINES = $$(ENV_DEFINES)
这将会设置MY_DEFINES为环境变量ENV_DEFINES传递给.pro文件地值。另外你可以在替换的变量里调用内置函数。这些函数（不会和下一节中列举的测试函数混淆）列出如下：
join( variablename, glue, before, after )
这将会在variablename的各个值中间加入glue。如果这个变量的值为非空，那么就会在值的前面加一个前缀before和一个后缀after。只有variablename是必须的字段，其它默认情况下为空串。如果你需要在glue、before或者after中使用空格的话，你必须提供它们。
member( variablename, position )
这将会放置variablename的列表中的position位置的值。如果variablename不够长，这将会返回一个空串。variablename是唯一必须的字段，如果没有指定位置，则默认为列表中的第一个值。
find( variablename, substr )
这将会放置variablename中所有匹配substr的值。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”，并且MYVAR3将会包含“three two three”。
system( program_and_args )
这将会返回程序执行在标准输出/标准错误输出的内容，并且正像平时所期待地分析它。比如你可以使用这个来询问有关平台的信息。
UNAME = $$system(uname -s)
contains( UNAME, [lL]inux ):message( This looks like Linux ($$UNAME) to me )
测试函数
qmake提供了可以简单执行，但强大测试的内置函数。这些测试也可以用在作用域中（就像上面一样），在一些情况下，忽略它的测试值，它自己使用测试函数是很有用的。
contains( variablename, value )
如果value存在于一个被叫做variablename的变量的值的列表中，那么这个作用域中的设置将会被处理。例如：
contains( CONFIG, thread ) {
DEFINES += QT_THREAD_SUPPORT
}
如果thread存在于CONFIG变量的值的列表中时，那么QT_THREAD_SUPPORT将会被加入到DEFINES变量的值的列表中。
count( variablename, number )
如果number与一个被叫做variablename的变量的值的数量一致，那么这个作用域中的设置将会被处理。例如：
count( DEFINES, 5 ) {
CONFIG += debug
}
error( string )
这个函数输出所给定的字符串，然后会使qmake退出。例如：
error( "An error has occured" )
文本“An error has occured”将会被显示在控制台上并且qmake将会退出。
exists( filename )
如果指定文件存在，那么这个作用域中的设置将会被处理。例如：
exists( /local/qt/qmake/main.cpp ) {
SOURCES += main.cpp
}
如果/local/qt/qmake/main.cpp存在，那么main.cpp将会被添加到源文件列表中。
注意可以不用考虑平台使用“/”作为目录的分隔符。
include( filename )
项目文件在这一点时包含这个文件名的内容，所以指定文件中的任何设置都将会被处理。例如：
include( myotherapp.pro )
myotherapp.pro项目文件中的任何设置现在都会被处理。
isEmpty( variablename )
这和使用count( variablename, 0 )是一样的。如果叫做variablename的变量没有任何元素，那么这个作用域中的设置将会被处理。例如：
isEmpty( CONFIG ) {
CONFIG += qt warn_on debug
}
message( string )
这个函数只是简单地在控制台上输出消息。
message( "This is a message" )
文本“This is a message”被输出到控制台上并且对于项目文件的处理将会继续进行。
system( command )
特定指令被执行并且如果它返回一个1的退出值，那么这个作用域中的设置将会被处理。例如：
system( ls /bin ) {
SOURCES += bin/main.cpp
HEADERS += bin/main.h
}
所以如果命令ls /bin返回1，那么bin/main.cpp将被添加到源文件列表中并且bin/main.h将被添加到头文件列表中。
infile( filename, var, val )
如果filename文件（当它被qmake自己解析时）包含一个值为val的变量var，那么这个函数将会返回成功。你也可以不传递第三个参数（val），这时函数将只测试文件中是否分配有这样一个变量var。
qmake Command Reference
qmake Command Reference
· About This Reference
· Command Line Options
· System Variables
· Functions
· Environment Variables and Configuration
About This Reference
This reference is a detailed index of all command line options, configurations and internal variables used by the cross-platform makefile generation utility qmake.
In addition to the variables and functions described in the following sections, qmake project files may also include comments. Comments begin with the '#' symbol and run to the end of the line.
Command Line Options
Syntax
qmake [options] files
Options
The following options can be specified on the command line to qmake:
· -o file
qmake output will be directed to file. if this argument is not specified, then qmake will try to guess a suitable name. If '-' is specified, output is directed to stdout.
· -unix
qmake will run in unix mode. In this mode, Unix file naming and path conventions will be used, additionally testing for unix (as a scope) will succeed. This is the default mode on all Unices.
· -macx
qmake will run in Mac OS X mode. In this mode, Unix file naming and path conventions will be used, additionally testing for macx (as a scope) will succeed. This is the default mode on Mac OS X.
· -win32
qmake will run in win32 mode. In this mode, Windows file naming and path conventions will be used, additionally testing for win32 (as a scope) will succeed. This is the default mode on Windows.
· -d
qmake will output (hopefully) useful debugging information.
· -t tmpl
qmake will override any set TEMPLATE variables with tmpl.
· -help
qmake will go over these features and give some useful help.
There are also warning options that can help to find problems in your project file:
· -Wall
With this qmake will turn on all known warnings.
· -Wnone
No warning information will be generated by qmake.
· -Wparser
qmake will only generate parser warnings, this will alert you to common pitfalls, and potential problems in the parsing of your .pro files.
· -Wlogic
Again qmake will warn of common pitfalls, and potential problems. This can include (but not limited to) checking if a file is placed into a list of files multiple times, if a file cannot be found, etc.
qmake supports two different modes of operation. The first mode, which is the default is makefile generation. In this mode, qmake will take a .pro file and turn it into a makefile. Creating makefiles is covered by this reference guide, there is another mode which generates .pro files.
To toggle between these modes you must specify in the first argument what mode you want to use. If no mode is specified, qmake will assume you want makefile mode. The available modes are:
· -makefile
qmake output will be a makefile (Makefile mode).
· -project
qmake output will be a project file (Project file mode).
Makefile Mode
In Makefile mode qmake will generate a makefile. Additionally you may supply the following arguments in this mode:
· -after
qmake will process assignments given on the commandline after the specified files.
· -nocache
qmake will ignore the .qmake.cache file.
· -nodepend
qmake will not generate any dependency information.
· -cache file
qmake will use file as the cache file, ignoring any other .qmake.cache file found
· -spec spec
qmake will use spec as a path to platform-compiler information and QMAKESPEC will be ignored.
The files argument can be a list of one or more project files, separated by spaces. You may also pass qmake assignments on the command line here and they will be processed before all files specified, for example:
qmake -makefile -unix -o Makefile "CONFIG+=test" test.pro
If however you are certain you want your variables processed after the the files specified, then you may pass the -after argument. When this is specified all assignments on the commandline after the -after option will be postponed until after the specified files are parsed.
This will generate a Makefile, from test.pro with Unix pathnames. However many of these arguments aren't necessary as they are the default. Therefore the line can be simplified on Unix to:
qmake "CONFIG+=test" test.pro
Projectfile Mode
In Projectfile mode qmake will generate a project file. Additionally, you may supply the following arguments in this mode:
· -r
qmake will look through supplied directories recursively
· -nopwd
qmake will not look in your current working directory for source code and only use the specified files
The files argument can be a list of files or directories. If a directory is specified, then it will be included in the DEPENDPATH variable and relevant code from there will be included in the generated project file, if a file is given it will go into the correct variable depending on extension (i.e. .ui files go into FORMS, .cpp files go into SOURCES, etc). Here too you may pass assignments on the commandline, when doing so these assignments will be placed last in the generated .pro file.
System Variables
· Frequently Used System Variables
· Rarely Used System Variables
Frequently Used System Variables
The following variables are recognized by qmake and are used most frequently when creating project files.
CONFIG
The CONFIG variable specifies project configuration and compiler options. The values will be recognized internally by qmake and have special meaning. They are as follows.
These CONFIG values control compilation flags:
· release - Compile with optimization enabled, ignored if "debug" is specified
· debug - Compile with debug options enabled
· warn_on - The compiler should emit more warnings than normally, ignored if "warn_off" is specified
· warn_off - The compiler should only emit severe warnings.
These options define the application/library type:
· qt - The target is a Qt application/library and requires the Qt header files/library. The proper include and library paths for the Qt library will automatically be added to the project.
· opengl - The target requires the OpenGL (or Mesa) headers/libraries. The proper include and library paths for these libraries will automatically be added to the project.
· thread - The target is a multi-threaded application or library. The proper defines and compiler flags will automatically be added to the project.
· x11 - The target is a X11 application or library. The proper include paths and libraries will automatically be added to the project.
· windows - The target is a Win32 window application (app only). The proper include paths,compiler flags and libraries will automatically be added to the project.
· console - The target is a Win32 console application (app only). The proper include paths, compiler flags and libraries will automatically be added to the project.
· dll - The target is a shared object/DLL.The proper include paths, compiler flags and libraries will automatically be added to the project.
· staticlib - The target is a static library (lib only). The proper compiler flags will automatically be added to the project.
· plugin - The target is a plugin (lib only). This enables dll as well.
The CONFIG variable will also be checked when resolving scopes. You may assign anything to this variable.
For example:
CONFIG += qt console newstuff
...
newstuff {
SOURCES += new.cpp
HEADERS += new.h
}
DEFINES
qmake adds the values of this variable as compiler C preprocessor macros (-D option).
For example:
DEFINES += USE_MY_STUFF QT_DLL
DEF_FILE
This is only used on Windows when using the 'app' template.
Specifies a .def file to be included in the project.
DESTDIR
Specifies where to put the target file.
For example:
DESTDIR = ../../lib
DLLDESTDIR
Specifies where to copy the target dll.
HEADERS
Defines the header files for the project.
qmake will generate dependency information (unless -nodepend is specified on the command line) for the specified headers. qmake will also automatically detect if moc is required by the classes in these headers, and add the appropriate dependencies and files to the project for generating and linking the moc files.
For example:
HEADERS = myclass.h /
login.h /
mainwindow.h
See also SOURCES.
INCLUDEPATH
This variable specifies the #include directories which should be searched when compiling the project. Use ';' or a space as the directory separator.
For example:
INCLUDEPATH = c:/msdev/include d:/stl/include
FORMS
This variable specifies the .ui files (see Qt Designer) to be processed through uic before compiling. All dependencies, headers and source files required to build these .ui files will automatically be added to the project.
For example:
FORMS = mydialog.ui /
mywidget.ui /
myconfig.ui
LEXSOURCES
This variable contains a list of lex source files. All dependencies, headers and source files will automatically be added to the project for building these lex files.
For example:
LEXSOURCES = lexer.l
LIBS
This variable contains a list of libraries to be linked into the project. If you are more comfortable with the Unix convension of -L/-l flags you are free to use them in a cross-platform manner and qmake will do the correct thing with these libraries on Windows (namely this means passing the full path of the library to the linker). The only limitation to this is the library must exist, for qmake to find which directory a -l lib lives in.
For example:
unix:LIBS += -lmath -L/usr/local/lib
win32:LIBS += c:/mylibs/math.lib
MOC_DIR
This variable specifies the directory where all intermediate moc files should be placed.
For example:
unix:MOC_DIR = ../myproject/tmp
win32:MOC_DIR = c:/myproject/tmp
OBJECTS_DIR
This variable specifies the directory where all intermediate objects should be placed.
For example:
unix:OBJECTS_DIR = ../myproject/tmp
win32:OBJECTS__DIR = c:/myproject/tmp
UI_DIR
This variable specifies the directory where all intermediate files from uic should be placed. This variable overrides both UI_SOURCES_DIR and UI_HEADERS_DIR.
For example:
unix:UI_DIR = ../myproject/ui
win32:UI_DIR = c:/myproject/ui
UI_HEADERS_DIR
This variable specifies the directory where all declaration files (as generated by uic) should be placed.
For example:
unix:UI_HEADERS_DIR = ../myproject/ui/include
win32:UI_HEADERS_DIR = c:/myproject/ui/include
UI_SOURCES_DIR
This variable specifies the directory where all implementation files (as generated by uic) should be placed.
For example:
unix:UI_SOURCES_DIR = ../myproject/ui/src
win32:UI_SOURCES_DIR = c:/myproject/ui/src
REQUIRES
This is a special variable processed by qmake. If the contents of this variable do not appear in CONFIG by the time this variable is assigned, then a minimal makefile will be generated that states what dependencies (the values assigned to REQUIRES) are missing.
This is mainly used in Qt's build system for building the examples.
SOURCES
This variable contains the name of all source files in the project.
For example:
SOURCES = myclass.cpp /
login.cpp /
mainwindow.cpp
See also HEADERS
SUBDIRS
This variable, when used with the 'subdir' TEMPLATE contains the names of all subdirectories to look for a project file.
For example:
SUBDIRS = kernel /
tools
TARGET
This specifies the name of the target file.
For example:
TEMPLATE = app
TARGET = myapp
SOURCES = main.cpp
The project file above would produce an executable named 'myapp' on unix and 'myapp.exe' on windows.
TEMPLATE
This variable contains the name of the template to use when generating the project. The allowed values are:
· app - Creates a makefile for building applications (the default)
· lib - Creates a makefile for building libraries
· subdirs - Creates a makefile for building targets in subdirectories
· vcapp - win32 only Creates an application project file
· vclib - win32 only Creates a library project file
For example:
TEMPLATE = lib
SOURCES = main.cpp
TARGET = mylib
VERSION
This variable contains the version number of the library if the 'lib' TEMPLATE is specified.
For example:
VERSION = 1.2.3
DISTFILES
This variable contains a list of files to be included in the dist target. This feature is supported by UnixMake specs only.
For example:
DISTFILES += ../program.txt
YACCSOURCES
This variable contains a list of yacc source files to be included in the project. All dependencies, headers and source files will automatically be included in the project.
For example:
YACCSOURCES = moc.y
Rarely Used System Variables
The following variables are also recognized by qmake but are either internal or very rarely used.
DESTDIR_TARGET
This variable is set internally by qmake, which is basically the DESTDIR variable with the TARGET variable appened at the end. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
DSP_TEMPLATE
This variable is set internally by qmake, which specifies where the dsp template file for basing generated dsp files is stored. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
LEXIMPLS
This variable contains a list of lex implementation files. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
LEXOBJECTS
This variable contains the names of intermediate lex object files.The value of this variable is typically handled by qmake and rarely needs to be modified.
MAKEFILE
This variable specifies the name of the makefile which qmake should use when outputting the dependency information for building a project. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
MAKEFILE_GENERATOR
This variable contains the name of the makefile generator to use when generating a makefile. The value of this variable is typically handled internally by qmake and rarely needs to be modified.
OBJECTS
This variable is generated from the SOURCES variable. The extension of each source file will have been replaced by .o (Unix) or .obj (Win32). The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
OBJMOC
This variable is set by qmake if files can be found that contain the Q_OBJECT macro. OBJMOC contains the name of all intermediate moc object files. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
PRECOMPH
This variable contains a list of header files that require some sort of pre-compilation step (such as with moc). The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE
This variable contains the name of the qmake program itself and is placed in generated makefiles. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKESPEC
This variable contains the name of the qmake configuration to use when generating makefiles. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified. Use the QMAKESPEC environment variable instead.
QMAKE_AIX_SHLIB
If this variable is not empty, then this variable tells qmake to generate the TARGET as an AIX shared library.
QMAKE_APP_FLAG
This variable is empty unless the 'app' TEMPLATE is specified. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified. Use the following instead:
app {
#conditional code for 'app' template here
}
QMAKE_APP_OR_DLL
This variable is empty unless the 'app' or 'dll' TEMPLATE is specified. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_AR_CMD
This is used on Unix platforms only
This variable contains the command for invoking the program which creates, modifies and extracts archives. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CFLAGS_DEBUG
This variable contains the flags for the C compiler in debug mode.The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CFLAGS_MT
This variable contains the compiler flags for creating a multi-threaded application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CFLAGS_MT_DBG
This variable contains the compiler flags for creating a debuggable multi-threaded application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CFLAGS_MT_DLL
This is used on Windows only
This variable contains the compiler flags for creating a multi-threaded dll. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CFLAGS_MT_DLLDBG
This is used on Windows only
This variable contains the compiler flags for creating a debuggable multi-threaded dll. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CFLAGS_RELEASE
This variable contains the compiler flags for creating a non-debuggable application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CFLAGS_SHLIB
This is used on Unix platforms only
This variable contains the compiler flags for creating a shared library. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CFLAGS_THREAD
This variable contains the compiler flags for creating a multi-threaded application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CFLAGS_WARN_OFF
This variable is not empty if the warn_off TEMPLATE option is specified. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CFLAGS_WARN_ON
This variable is not empty if the warn_on TEMPLATE option is specified. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CLEAN
This variable contains any files which are not generated files (such as moc and uic generated files) and object files that should be removed when using "make clean".
QMAKE_CXXFLAGS_DEBUG
This variable contains the C++ compiler flags for creating a debuggable application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CXXFLAGS_MT
This variable contains the C++ compiler flags for creating a multi-threaded application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CXXFLAGS_MT_DBG
This variable contains the C++ compiler flags for creating a debuggable multi-threaded application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CXXFLAGS_MT_DLL
This is used on Windows only
This variable contains the C++ compiler flags for creating a multi-threaded dll. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CXXFLAGS_MT_DLLDBG
This is used on Windows only
This variable contains the C++ compiler flags for creating a multi-threaded debuggable dll. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CXXFLAGS_RELEASE
This variable contains the C++ compiler flags for creating an application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CXXFLAGS_SHLIB
This variable contains the C++ compiler flags for creating a shared library. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CXXFLAGS_THREAD
This variable contains the C++ compiler flags for creating a multi-threaded application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CXXFLAGS_WARN_OFF
This variable contains the C++ compiler flags for suppressing compiler warnings. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_CXXFLAGS_WARN_ON
This variable contains C++ compiler flags for generating compiler warnings. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_EXTENSION_SHLIB
This variable contains the extention for shared libraries. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_FAILED_REQUIREMENTS
This variable contains the list of requirements that were failed to be met when qmake was used. For example, the sql module is needed and wasn't compiled into Qt. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_FILETAGS
This variable contains the file tags needed to be entered into the makefile, such as SOURCES and HEADERS. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_HPUX_SHLIB
This is used on Unix platforms only
If this variable is not empty then this variable tells qmake to generate the TARGET as an HPUX shared library. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_HPUX_SHLIBS
This is used on Unix platforms only
If this variable is not empty then this variable tells qmake to generate the TARGET as an HPUX shared library. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_INCDIR
This variable contains the location of all known header files to be added to INCLUDEPATH when building an application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
TARGETDEPS
All libraries that the target depends on can be listed in this variable. Some backends do not support this, these include MSVC Dsp, and ProjectBuilder .pbproj files. Generally this is support internally by these build tools, this is usefull for explicitly listing dependant static libraries.
QMAKE_INCDIR_OPENGL
This variable contains the location of OpenGL header files to be added to INCLUDEPATH when building an application with OpenGL support. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_INCDIR_QT
This variable contains the location of all known header file paths to be added to INCLUDEPATH when building a Qt application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_INCDIR_THREAD
This variable contains the location of all known header file paths to be added to INCLUDEPATH when building a multi-threaded application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_INCDIR_X11
This is used on Unix platforms only
This variable contains the location of X11 header file paths to be added to INCLUDEPATH when building a X11 application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_CONSOLE
This is used on Windows only
This variable contains link flags when building console programs. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_CONSOLE_DLL
This is used on Windows only
This variable contains link flags when building console dlls. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_DEBUG
This variable contains link flags when building debuggable applications. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_PLUGIN
This variable contains link flags when building plugins. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_QT_DLL
This variable contains link flags when building programs that use the Qt library built as a dll. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_RELEASE
This variable contains link flags when building applications for release. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_SHAPP
This variable contains link flags when building applications which are using the 'app' template. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_SHLIB
This variable contains link flags when building shared libraries The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_SONAME
This variable specifies the name of shared objects, such as .so or .dll. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_THREAD
This variable contains link flags when building multi-threaded projects. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_WINDOWS
This is used on Windows only
This variable contains link flags when building windows projects. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LFLAGS_WINDOWS_DLL
This is used on Windows only
This variable contains link flags when building windows dll projects. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBDIR
This variable contains the location of all known library directories.The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBDIR_FLAGS
This is used on Unix platforms only
This variable contains the location of all library directory with -L prefixed. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
VPATH
This variable tells qmake where to search for files it cannot open. With this you may tell qmake where it may look for things like SOURCES, and if it finds an entry in SOURCES that cannot be opened it will look through the entire VPATH list to see if it can find the file on its own.
See also DEPENDPATH.
DEPENDPATH
This variable contains the list of all directories to look in to resolve dependencies. This will be used when crawling through 'included' files.
QMAKE_LIBDIR_OPENGL
This variable contains the location of the OpenGL library directory.The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBDIR_QT
This variable contains the location of the Qt library directory.The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBDIR_X11
This is used on Unix platforms only
This variable contains the location of the X11 library directory.The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS
This variable contains all project libraries. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_CONSOLE
This is used on Windows only
This variable contains all project libraries that should be linked against when building a console application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_OPENGL
This variable contains all OpenGL libraries. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_OPENGL_QT
This variable contains all OpenGL Qt libraries.The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_QT
This variable contains all Qt libraries.The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_QT_DLL
This is used on Windows only
This variable contains all Qt libraries when Qt is built as a dll. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_QT_OPENGL
This variable contains all the libraries needed to link against if OpenGL support is turned on. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_QT_THREAD
This variable contains all the libraries needed to link against if thread support is turned on. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_RT
This is used with Borland compilers only
This variable contains the runtime library needed to link against when building an application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_RTMT
This is used with Borland compilers only
This variable contains the runtime library needed to link against when building a multi-threaded application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_THREAD
This is used on Unix platforms only
This variable contains all libraries that need to be linked against when building a multi-threaded application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_WINDOWS
This is used on Windows only
This variable contains all windows libraries.The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_X11
This is used on Unix platforms only
This variable contains all X11 libraries.The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIBS_X11SM
This is used on Unix platforms only
This variable contains all X11 session management libraries. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LIB_FLAG
This variable is not empty if the 'lib' template is specified. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LINK_SHLIB_CMD
This variable contains the command to execute when creating a shared library. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_LN_SHLIB
This variable contains the command to execute when creating a link to a shared library. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_MAKEFILE
This variable contains the name of the makefile to create. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_MOC_SRC
This variable contains the names of all moc source files to generate and include in the project. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_QMAKE
This variable contains the location of qmake if it is not in the path. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_QT_DLL
This variable is not empty if Qt was built as a dll. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_RUN_CC
This variable specifies the individual rule needed to build an object. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_RUN_CC_IMP
This variable specifies the individual rule needed to build an object. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_RUN_CXX
This variable specifies the individual rule needed to build an object. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_RUN_CXX_IMP
This variable specifies the individual rule needed to build an object. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
QMAKE_TARGET
This variable contains the name of the project target. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
RC_FILE
This variable contains the name of the resource file for the application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
RES_FILE
This variable contains the name of the resource file for the application. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
SRCMOC
This variable is set by qmake if files can be found that contain the Q_OBJECT macro. SRCMOC contains the name of all the generated moc files. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
TARGET_EXT
This variable specifies the target's extension. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
TARGET_x
This variable specifies the target's extension with a major version number. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
TARGET_x.y.z
This variable specifies the target's extension with version number. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
UICIMPLS
This variable contains a list of the generated implementation files by UIC. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
UICOBJECTS
This variable is generated from the UICIMPLS variable. The extension of each file will have been replaced by .o (Unix) or .obj (Win32). The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
VER_MAJ
This variable contains the major version number of the library, if the 'lib' template is specified.
VER_MIN
This variable contains the minor version number of the library, if the 'lib' template is specified.
VER_PAT
This variable contains the patch version number of the library, if the 'lib' template is specified.
QMAKE_EXT_MOC
This variable changes the extention used on included moc files.
See also File Extensions.
QMAKE_EXT_UI
This variable changes the extention used on /e Designer UI files.
See also File Extensions.
QMAKE_EXT_PRL
This variable changes the extention used on created PRL files.
See also File Extensions, Library Dependencies.
QMAKE_EXT_LEX
This variable changes the extention used on files given to lex.
See also File Extensions, LEXSOURCES.
QMAKE_EXT_YACC This variable changes the extention used on files given to yacc.
See also File Extensions, YACCSOURCES.
QMAKE_EXT_OBJ
This variable changes the extention used on generated object files.
See also File Extensions.
QMAKE_EXT_CPP
This variable changes the interpretation of all suffixes in this list of values as files of type C++ source code.
See also File Extensions.
QMAKE_EXT_H
This variable changes the interpretation of all suffixes in this list of values as files of type C header files.
See also File Extensions.
YACCIMPLS
This variable contains a list of yacc source files. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
YACCOBJECTS
This variable contains a list of yacc object files. The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified.
Functions
qmake recognizes the following functions:
include( filename )
This function will include the contents of filename into the current project at the point where was included. The function succeeds if filename was included, otherwise it fails. You can check the return value of this function using a scope.
For example:
include( shared.pri )
OPTIONS = standard custom
!include( options.pri ) {
message( "No custom build options specified" )
OPTIONS -= custom
}
exists( file )
This function will test if file exists. If the file exists, then it will succeed; otherwise it will fail. You can specify a regular expression in file and it will succeed if any file matches the regular expression specified.
For example:
exists( $(QTDIR)/lib/qt-mt* ) {
message( "Configuring for multi-threaded Qt..." )
CONFIG += thread
}
contains( variablename, value )
This function will succeed if the variable variablename contains the value value. You can check the return value of this function using a scope.
For example:
contains( drivers, network ) {
# drivers contains 'network'
message( "Configuring for network build..." )
HEADERS += network.h
SOURCES += network.cpp
}
count( variablename, number )
This function will succeed if the variable variablename contains number elements, otherwise it will fail. You can check the return value of this function using a scope.
For example:
MYVAR = one two three
count( MYVAR, 3 ) {
# always true
}
infile( filename, var, val )
This function will succeed if the file filename (when parsed by qmake itself) contains the variable var with a value of val. You may also not pass in a third argument (val) and the function will only test if var has been assigned to in the file.
isEmpty( variablename )
This function will succeed if the variable variablename is empty (same as count(variable, 0)).
system( command )
This function will execute command in a secondary shell and will succeed if the command exits with an exit status of 1. You can check the return value of this function using a scope.
For example:
system(ls /bin):HAS_BIN=FALSE
message( string )
This function will always succeed, and will display the given string to the user.
error( string )
This function will never return a value. It will display the given string to the user, and then exit qmake. This function should only be used for very fatal configurations.
For example:
release:debug:error(You can't have release and debug at the same time!)
Environment Variables and Configuration
QMAKESPEC
qmake requires a platform and compiler description file which contains many default values used to generate appropriate makefiles. The standard Qt distribution comes with many of these files, located in the 'mkspecs' subdirectory of the Qt installation.
The QMAKESPEC environment variable can contain any of the following:
· A complete path to a directory containing a qmake.conf file. In this case qmake will open the qmake.conf file from within that directory. If the file does not exist, qmake will exit with an error.
· The name of a platform-compiler combination. In this case, qmake will search in the directory specified by the QTDIR environment variable.
Note: the QMAKESPEC path will automatically be added to the INCLUDEPATH system variable.
INSTALLS
It is common on UNIX to be able to install from the same utility as you build with (e.g make install). For this qmake has introduce the concept of an install set. The notation for this is quite simple, first you fill in an "object" in qmake for example:
documentation.path = /usr/local/program/doc
documentation.files = docs/*
In this way you are telling qmake several things about this install, first that you plan to install to /usr/local/program/doc (the path member), second that you plan to copy everything in the docs directory. Once this is done you may insert it in the install list:
INSTALLS += documentation
Now qmake will take over making sure the correct things are copied to the specified places. If however you require greater control you may use the 'extra' member of the object:
unix:documentation.extra = create_docs; mv master.doc toc.doc
Then qmake will run the things in extra (this is of course platform specific, so you may need to test for your platform first, this case we test for unix). Then it will do the normal processings of the files member. Finally if you appened a builtin install to INSTALLS qmake (and do not specify a files or extra member) will decide what needs to be copied for you, currently the only supported builtin is target:
target.path = /usr/local/myprogram
INSTALLS += target
With this qmake will know what you plan need copied, and do this for you.
Cache File
The cache file (mentioned above in the options) is a special file qmake will read to find settings not specified in the qmake.conf file, the .pro file, or the command line. If -nocache is specified, qmake will try to find a file called .qmake.cache in parent directories. If it fails to find this file, it will silently ignore this step of processing.
Library Dependencies
Often when linking against a library qmake relies on the underlying platform to know what other libraries this library links against, and lets the platform pull them in. In many cases, however, this is not sufficent. For example when statically linking a library there are no libraries linked against, and therefore no dependencies to those libraries are created - however an application that later links against this library will need to know where to find the symbols that the linked in library will require. To help with this situation qmake will follow a library's dependencies when it feels appropriate, however this behaviour must be enabled in qmake. To enable requires two steps. First, you must enable it in the library - to do this you must tell qmake to save information about this library:
CONFIG += create_prl
This is only relevant to the lib template, and will be ignored for all others. When this option is enabled qmake will create a file (called a .prl file) which will save some meta information about the library. This metafile is itself just a qmake project file, but with all internal variables. You are free to view this file, and if deleted qmake will know to recreate it when necesary (either when the .pro file is later read, or if a dependent library (described below) has changed). When installing this library (by using target in INSTALLS, above) qmake will automatically copy the .prl file to your install path.
The second step to enabling this processing is to turn on reading of the meta information created above:
CONFIG += link_prl
When this is turned on qmake will process all libraries linked to, and find their meta information. With this meta information qmake will figure out what is relevant to linking, specifically it will add to your list of DEFINES as well as LIBS. Once qmake has processed this file, it will then look through the newly introduced LIBS and find their dependent .prl files, and continue until all libraries have been resolved. At this point the makefile is created as usual, and the libraries are linked explicity against your program.
The internals of the .prl file are left closed so they can easily change later. It is not designed to be changed by hand however, and should only be created by qmake - these .prl files should also not be transfered from operating system to operating system as they may be platform dependent (like a makefile).
File Extensions
Under normal circumstances qmake will try to use appropriate file extensions for your platform. There may be times, however, that you would like to override the behavior of these extensions. To do this, you must modify builtin variables in your .pro file, which will in turn changes qmake's interpretation of these files. You may do this as:
QMAKE_EXT_MOC = .mymoc
The variables are as follows:
· QMAKE_EXT_MOC - This modifies the extension placed on included moc files.
· QMAKE_EXT_UI - This modifies the extension used for designer UI files (usually in FORMS).
· QMAKE_EXT_PRL - This modifies the extension placed on library dependency files.
· QMAKE_EXT_LEX - This changes the suffix used in files (usually in LEXSOURCES).
· QMAKE_EXT_YACC - This changes the suffix used in files (usually in YACCSOURCES).
· QMAKE_EXT_OBJ - This changes the suffix used on generated object files.
All the above accept just the first value, so you must assign to it one value that will be used through your makefile. There are two variables that accept a list of values, they are:
· QMAKE_EXT_CPP - Changes interpretation all files with these suffixes to be C++ source files.
· QMAKE_EXT_H - Changes interpretation all files with these suffixes to be C header files.
Customizing Makefile Output
qmake often tries to be all things to all build tools, this is often less than ideal when you really need to run special platform dependent commands. This can be achieved with specific instructions to the different qmake backends (currently this is only supported by the UNIX generator).
The interfaces to customizing the Makefile are done through "objects" as in other places in qmake. The notation for this is quite simple, first you fill in an "object" in qmake for example:
mytarget.target = .buildfile
mytarget.commands = touch $$mytarget.target
mytarget.depends = mytarget2
mytarget2.commands = @echo Building $$mytarget.target
The information above defines a qmake target called mytarget which contains a Makefile target called .buildfile, .buildfile is generated by 'touch .buildfile', and finally that this Makefile target depends on the qmake target mytarget2. Additionally we've defined the qmake target mytarget2 which simply echo's something to stdout.
The final step to making use of the above is to instruct qmake that this is actually an object used by the target building parts of qmake by:
QMAKE_EXTRA_UNIX_TARGETS += mytarget mytarget2
This is all you need to do to actually build custom targets in qmake, of course you may want to tie one of these targets to actually building the qmake build target. To do this, you simply need to include your Makefile target in the list of TARGETDEPS.