< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" "http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd">

Qt4.7.0文档翻译：配置qmake的环境，Configuring qmake’s Environment

属性

qmake有一个持久存储信息的系统，这允许你只需要在qmake 中对一个变量设置一次，以后每次调用时都能查询到这个值。使用下面的方法来在qmake 中设置一个属性：

 qmake -set 变量 值

应当使用适当的变量和值来替换命令中的变量和值。

你可以这样从 qmake 中查询这个信息：

 qmake -query 变量

 qmake -query #查询当前所有的变量／值对……

注意：qmake -query只会列出你以前使用qmake -set 变量 值设置的变量。

这个信息将会保存到一个QSettings对象中（意味着它在不同的平台上将保存在不同的地方）。由于变量也是有版本的，所以你可以在一个旧版本的qmake里设置一个值，在新版本里就能获取这个值。然而，如果你为一个新版本的qmake设置变量，那么旧版本将不使用这个值。然而，如果你将qmake的版本号加在变量的前面，那么你可以查询一个指定版本的变量，像下面这个例子一样：

 qmake -query “1.06a/变量“

qmake还支持查询内置属性,例如,你可以使用QT_INSTALL_PREFIX属性来查询这个版本的qmake使用的Qt的安装路径｡

 qmake -query “QT_INSTALL_PREFIX”

这些内置的属性不能加上版本号前缀使用，因为它们没有版本，并且每个版本的qmake都会有它自己的内置属性的集合。下面的列表汇总了内置的属性：

• •.QT_INSTALL_PREFIX - 这个qmake 使用的Qt 版本的位置 

• •.QT_INSTALL_DATA - 这个版本的Qt 的数据的位置（本座查了一下，/usr/lib/qt4） 

• •.QMAKE_VERSION - 当前qmake的版本 

最后，可以在项目文件中使用一种特殊的表示方法来查询这些值，比如：

 QMAKE_VERS = $$[QMAKE_VERSION]

QMAKESPEC

qmake需要一个平台和编译器描述文件，这个文件包含很多默认值，qmake用它们来生成合适的Makefile。标准的Qt 发布中有很多这样的文件，位于Qt 安装目录的mkspecs子目录中。

QMAKESPEC环境可以包含下面的东西中的任意一个：

• •.到一个包含一个qmake.conf文件的目录的完整路径。在这种情况下，qmake会打开那个目录下的qmake.conf文件。如果那个文件不存在，qmake就会报告错误并且退出。 

• •.一个平台-编译器组合的名字。是一个组合的名字。在这种情况下，qmake会在编译Qt 时指定的数据路径(查看QLibraryInfo::DataPath)中的mkspecs子目录下搜索。 

注意：QMAKESPEC路径会自动地添加到INCLUDEPATH系统变量中。

INSTALLS

在 Unix 上，使用构建工具来安装程序和库是很平常的；例如，执行make install。由于这个原因，qmake有一个安装集的概念，这个对象包含了一些关于项目的哪一部分要被安装的指令。例如，一组文档文件可以用下面的方式描述：

 documentation.path = /usr/local/program/doc

 documentation.files = docs/*

path成员告诉qmake文件应当被安装到/usr/local/program/doc（path成员），而files成员指定了应当被复制到安装目录中去的文件。在这个例子里，docs目录中的所有东西都会被复制到/usr/local/program/doc。

一旦完整地描述了一个安装集，你就可以用这样的一行将它追加到安装列表中：

 INSTALLS += documentation

qmake将会确保指定的文件被复制到安装目录中。如果你想对这个过程进行更有力的控制，你还可以为这个对象定义一个extra成员。例如，下面的这一行告诉qmake为这个安装集执行一系列的命令：

 unix:documentation.extra = create_docs; mv master.doc toc.doc

unix作用域(查看作用域和条件)确保这些特殊的命令只在Unix 平台上执行。适合其它平台的命令可以使用其它作用域规则来定义。

extra成员中指定的命令会在对象的其它成员中的指令处理之前执行。

如果你将一个内置的安装集追加到INSTALLS变量中，而不指定files或者extra成员，那么qmake将会为你决定需要复制什么东西。目前，支持的唯一的内置安装集就是target：

 target.path = /usr/local/我的程序

 INSTALLS += target

在上面的几行里，qmake知道需要复制什么东西，会自动地处理安装过程。

缓存文件

缓存文件是一个特殊文件，qmake从中读取没有在qmake.conf文件、项目文件或者命令行指定的设置信息。如果在运行qmake的时候没有指定-nocache选项，那么它会尝试在当前目录的那些上级目录里寻找一个.qmake.cache文件。如果它没有找到这个文件，那么它会忽略这一步的处理过程。

如果它找到了一个.qmake.cache文件，那么它会在处理项目文件之前处理这个文件。

库依赖

在与一个库做链接时,qmake经常依赖下层的平台来得知这个库与哪些库链接,并且让平台将它们引入｡然而,在很多情况下,这是低效的｡例如,当静态链接一个库时,没有与其它库链接,因此就没有创建到那些库的依赖｡然而,稍后与这个库做链接的程序将会需要知道去哪里找到这个静态库需要的符号｡为了应对这种情况,qmake尝试在适当的时候跟踪这个库的依赖,但是必须按照两个步骤来显式地启用这个行为｡

第一步是在库自身启用依赖跟踪。要做到这一点，你必须告诉qmake要保存这个库的信息：

 CONFIG += create_prl

这只对lib模板有效,当使用其它模板时会被忽略｡当使用这个选项时,qmake会创建一个扩展名为.prl的文件,它会保存这个库的一些元信息｡这个元文件就像一个普通的项目文件一样,但是只包含内部变量的定义｡你可以随意查看这个文件,如果它被删除了,那么qmake会在需要的时候重新创建它,或者是在稍后读取这个项目文件的时候,或者是在一个依赖库(下面描述)发生改变的时候｡当你通过将它指定为INSTALLS声明中的一个目标的方法来安装这个库的时候,qmake会自动地将这个.prl文件复制到安装路径中｡

这个过程中的第二步就是在使用这个静态库的程序里面启用对这个元信息的读取：

 CONFIG += link_prl

当这个选项被启用时,qmake将会处理这个程序链接到的所有的库,并且查找它们的元信息｡qmake会使用这个来确定相关的链接信息,尤其是将一些值添加到程序的项目文件的DEFINES和LIBS列表里｡一旦qmake处理完了这个文件,它会检查LIBS变量中新引入的库,找到它们依赖的.prl文件,继续这个过程直到解决了所有的库的依赖关系｡在这个时候,照常地创建Makefile,而那些库会显式地与这个程序链接起来｡

.prl文件的内部格式是封闭的，这样它们随后可以轻易改变。它们不是设计为让你手动修改的，它们只应当由qmake来生成，不应当在操作系统之间传递，因为它们可能包含与平台相关的信息。

文件扩展名

在一般情况下，qmake会尝试使用适合于你的平台的文件扩展名。然而，有些时候有必要为每个平台覆盖掉默认的选项并且显式地定义文件扩展名以让qmake使用。这是通过重新定义特定的内置变量来实现的；例如，可以在项目文件中使用以下赋值语句来重定义用于moc文件的扩展名：

 QMAKE_EXT_MOC = .mymoc

以下变量可用来重定义qmake使用的普通文件的扩展名：

• •.QMAKE_EXT_MOC – 这个变量修改那些被包含的moc 文件的扩展名。 

• •.QMAKE_EXT_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++头文件来解释。 

自定义Makefile 的输出

qmake努力做到一个跨平台的构建工具应当做到的任何事情。当你实在需要运行特殊的与平台相关的命令时，事情通常就不那么完美了。这件事情可以针对不同的qmake后端来采用特殊的指令来完成。

就像在qmake的其它地方一样，对 Makefile 的自定义输出也是通过一个面向对象风格的应用编程接口来实现的。当指定一些对象的成员时，这些对象也被自动定义；例如：

 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，这个对象是一个要被构建的目标：

 QMAKE_EXTRA_TARGETS += mytarget mytarget2

这就是你为了构建自定义目标时所需要做的全部事情。当然，你可能想要将这些目标中的一个与qmake构建目标绑定。要做到这一点，你只需要简单地将你的Makefile 目标包含到PRE_TARGETDEPS列表中。

下面的表格中列出的是你可以在QMAKE_EXTRA_TARGETS 变量中使用的选项的概述。

CONFIG 选项的成员列表：

为了方便，也可以为新的编译器或者预处理器对项目进行自定义设置：

 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来生成依赖信息,并且将这个信息也放到项目中｡

这些命令可以轻易地放到一个缓存文件中，允许后面的项目文件向NEW_HEADERS里添加新的参数。

下面的表格是你可以在QMAKE_EXTRA_COMPILERS 变量中使用的选项的概述。

与CONFIG 选项相关的成员列表：

与CONFIG 选项相关的成员列表：

注意：与Symbian平台相关：在Symbian 平台上，不支持生成要链接的对象，所以应当一直为附加编译器定义CONFIG的no_link选项或者variable_out变量。