|
Home · All Classes · Main Classes · Grouped Classes · Modules · Functions | |
[Previous: qmake Function Reference] [Contents]
qmake has a system of persistant information, this allows you to set a variable in qmake once, and each time qmake is invoked this value can be queried. Use the following to set a property in qmake:
qmake -set VARIABLE VALUE
The appropriate variable and value should be substituted for VARIABLE and VALUE.
To retrieve this information back from qmake you can do:
qmake -query VARIABLE qmake -query #queries all current VARIABLE/VALUE pairs..
This information will be saved into a QSettings object (meaning it will be stored in different places for different platforms). As VARIABLE is versioned as well, you can set one value in an older version of qmake, and newer versions will retrieve this value. However, if you set VARIABLE for a newer version of qmake, the older version will not use this value. You can however query a specific version of a variable if you prefix that version of qmake to VARIABLE, as in the following example:
qmake -query "1.06a/VARIABLE"
qmake also has the notion of builtin properties, for example you can query the installation of Qt for this version of qmake with the QT_INSTALL_PREFIX property:
qmake -query "QT_INSTALL_PREFIX"
These built-in properties cannot have a version prefixed to them as they are not versioned, and each version of qmake will have its own built-in set of these values. The list below outlines the built-in properties:
Finally, these values can be queried in a project file with a special notation such as:
QMAKE_VERS = $$[QMAKE_VERSION]
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:
Note: The QMAKESPEC path will automatically be added to the INCLUDEPATH system variable.
It is common on Unix to also use the build tool to install applications and libraries; for example, by invoking make install. For this reason, qmake has the concept of an install set, an object which contains instructions about the way part of a project is to be installed. For example, a collection of documentation files can be described in the following way:
documentation.path = /usr/local/program/doc documentation.files = docs/*
The path member informs qmake that the files should be installed in /usr/local/program/doc (the path member), and the files member specifies the files that should be copied to the installation directory. In this case, everything in the docs directory will be coped to /usr/local/program/doc.
Once an install set has been fully described, you can append it to the install list with a line like this:
INSTALLS += documentation
qmake will ensure that the specified files are copied to the installation directory. If you require greater control over this process, you can also provide a definition for the extra member of the object. For example, the following line tells qmake to execute a series of commands for this install set:
unix:documentation.extra = create_docs; mv master.doc toc.doc
The unix scope (see Scopes and Conditions) ensures that these particular commands are only executed on Unix platforms. Appropriate commands for other platforms can be defined using other scope rules.
Commands specified in the extra member are executed before the instructions in the other members of the object are performed.
If you append a built-in install set to the INSTALLS variable and do not specify files or extra members, qmake will decide what needs to be copied for you. Currently, the only supported built-in install set is target:
target.path = /usr/local/myprogram INSTALLS += target
In the above lines, qmake knows what needs to be copied, and will handle the installation process automatically.
The cache file is a special file qmake reads to find settings not specified in the qmake.conf file, project files, or at the command line. If -nocache is not specified when qmake is run, it will try to find a file called .qmake.cache in parent directories of the current directory. If it fails to find this file, it will silently ignore this step of processing.
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, no other libraries are linked to, 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 static library will require. To help with this situation, qmake attempts to follow a library's dependencies where appropriate, but this behavior must be explicitly enabled by following two steps.
The first step is to enable dependency tracking in the library itself. To do this you must tell qmake to save information about the 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 ending in .prl which will save some meta-information about the library. This metafile is just like an ordinary project file, but only contains internal variable declarations. You are free to view this file and, if it is deleted, qmake will know to recreate it when necessary, either when the project file is later read, or if a dependent library (described below) has changed. When installing this library, by specifying it as a target in an INSTALLS declaration, qmake will automatically copy the .prl file to the installation path.
The second step in this process is to enable reading of this meta information in the applications that use the static library:
CONFIG += link_prl
When this is enabled, qmake will process all libraries linked to by the application and find their meta-information. qmake will use this to determine the relevant linking information, specifically adding values to the application project file's list of DEFINES as well as LIBS. Once qmake has processed this file, it will then look through the newly introduced libraries in the LIBS variable, and find their dependent .prl files, continuing until all libraries have been resolved. At this point, the Makefile is created as usual, and the libraries are linked explicitlyy against the application.
The internals of the .prl file are left closed so they can easily change later. They are not designed to be changed by hand, should only be created by qmake, and should not be transferred between operating systems as they may contain platform-dependent information.
Under normal circumstances qmake will try to use appropriate file extensions for your platform. However, it is sometimes necessary to override the default choices for each platform and explicitly define file extensions for qmake to use. This is achieved by redefining certain built-in variables; for example the extension used for moc files can be redefined with the following assignment in a project file:
QMAKE_EXT_MOC = .mymoc
The following variables can be used to redefine common file extensions recognized by qmake:
All of the above accept just the first value, so you must assign to it just one value that will be used throughout your project file. There are two variables that accept a list of values:
qmake tries to do everything expected of a cross-platform build tool. 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.
Customization of the Makefile output is performed through an object-style API as found in other places in qmake. Objects are defined automatically by specifying their members; for example:
mytarget.target = .buildfile mytarget.commands = touch $$mytarget.target mytarget.depends = mytarget2 mytarget2.commands = @echo Building $$mytarget.target
The definitions above define a qmake target called mytarget, containing a Makefile target called .buildfile which in turn is generated with the touch command. Finally, the .depends member specifies that mytarget depends on mytarget2, another target that is defined afterwards. mytarget2 is a dummy target; it is only defined to echo some text to the console.
The final step is to instruct qmake that this object is a target to be built:
QMAKE_EXTRA_TARGETS += mytarget mytarget2
This is all you need to do to actually build custom targets. Of course, you may want to tie one of these targets to the qmake build target. To do this, you simply need to include your Makefile target in the list of PRE_TARGETDEPS.
For convenience, there is also a method of customizing projects for new compilers or preprocessors:
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
With the above definitions, you can use a drop-in replacement for moc if one is available. The commands is executed on all arguments given to the NEW_HEADERS variable (from the input member), and the result is written to the file defined by the output member; this file is added to the other source files in the project. Additionally, qmake will execute depend_command to generate dependency information, and place this information in the project as well.
These commands can easily be placed into a cache file, allowing subsequent project files to add arguments to NEW_HEADERS.
[Previous: qmake Function Reference] [Contents]
| Copyright © 2008 Trolltech | Trademarks | Qt 4.3.5 |