|
|
              
qmake Common ProjectsThis chapter describes how to set up qmake project files for three common project types that are based on Qt. Although all kinds of projects use many of the same variables, each of them use project-specific variables to customize output files. Platform-specific variables are not described here; we refer the reader to the Deploying Qt Applications document for information on issues such as building universal binaries for Mac OS X and handling Visual Studio manifest files. Building an ApplicationThe app TemplateThe app template tells qmake to generate a Makefile that will build an application. With this template, the type of application can be specified by adding one of the following options to the CONFIG variable definition:
When using this template the following qmake system variables are recognized. You should use these in your .pro file to specify information about your application.
You only need to use the system variables that you have values for, for instance, if you do not have any extra INCLUDEPATHs then you do not need to specify any, qmake will add in the default ones needed. For instance, an example project file might look like this: TEMPLATE = app DESTDIR = c:/helloapp HEADERS += hello.h SOURCES += hello.cpp SOURCES += main.cpp DEFINES += QT_DLL CONFIG += qt warn_on release For items that are single valued, e.g. the template or the destination directory, we use "="; but for multi-valued items we use "+=" to add to the existing items of that type. Using "=" replaces the item's value with the new value, for example if we wrote DEFINES=QT_DLL, all other definitions would be deleted. Building a TestcaseA testcase project is an app project intended to be run as an automated test. Any app may be marked as a testcase by adding the value testcase to the CONFIG variable. For testcase projects, qmake will insert a check target into the generated Makefile. This target will run the application. The test is considered to pass if it terminates with an exit code equal to zero. The check target automatically recurses through SUBDIRS projects. This means it is possible to issue a make check command from within a SUBDIRS project to run an entire test suite. The execution of the check target may be customized by certain Makefile variables. These variables are:
Note that these must be set while invoking the make tool, and not set in the .pro file. Most make tools support the setting of Makefile variables directly on the command-line: # 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" Testcase projects may be further customized with the following CONFIG options:
Testcases will often be written with QTestLib or QtQuickTest, but that is not a requirement to make use of CONFIG+=testcase and make check. The primary requirement is only that the test program exit with a zero exit code on success, and a non-zero exit code on failure. Building a LibraryThe lib TemplateThe lib template tells qmake to generate a Makefile that will build a library. When using this template, in addition to the system variables mentioned above for the app template the VERSION variable is supported. You should use these in your .pro file to specify information about the library. When using the lib template, the following options can be added to the CONFIG variable to determine the type of library that is built:
The following option can also be defined to provide additional information about the library.
The target file name for the library is platform-dependent. For example, on X11 and Mac OS X, the library name will be prefixed by lib; on Windows, no prefix is added to the file name. Building a PluginPlugins are built using the lib template, as described in the previous section. This tells qmake to generate a Makefile for the project that will build a plugin in a suitable form for each platform, usually in the form of a library. As with ordinary libraries, the VERSION variable is used to specify information about the plugin.
Building a Qt Designer PluginQt Designer plugins are built using a specific set of configuration settings that depend on the way Qt was configured for your system. For convenience, these settings can be enabled by adding designer to the project's CONFIG variable. For example: See the Qt Designer Examples for more examples of plugin-based projects. Building and Installing in Debug and Release ModesSometimes, it is necessary to build a project in both debug and release modes. Although the CONFIG variable can hold both debug and release options, the debug option overrides the release option. Building in Both ModesTo enable a project to be built in both modes, you must add the debug_and_release option to your project's CONFIG definition: CONFIG += debug_and_release
CONFIG(debug, debug|release) {
TARGET = debug_binary
} else {
TARGET = release_binary
}
The scope in the above snippet modifies the build target in each mode to ensure that the resulting targets have different names. Providing different names for targets ensures that one will not overwrite the other. When qmake processes the project file, it will generate a Makefile rule to allow the project to be built in both modes. This can be invoked in the following way: make all The build_all option can be added to the CONFIG variable in the project file to ensure that the project is built in both modes by default: CONFIG += build_all This allows the Makefile to be processed using the default rule: make Installing in Both ModesThe build_all option also ensures that both versions of the target will be installed when the installation rule is invoked: make install It is possible to customize the names of the build targets depending on the target platform. For example, a library or plugin may be named using a different convention on Windows to the one used on Unix platforms: CONFIG(debug, debug|release) {
mac: TARGET = $$join(TARGET,,,_debug)
win32: TARGET = $$join(TARGET,,d)
}
The default behavior in the above snippet is to modify the name used for the build target when building in debug mode. An else clause could be added to the scope to do the same for release mode; left as it is, the target name remains unmodified. |
