qmake Platform Notes
Many cross-platform projects can be handled by the qmake's basic configuration features. On some platforms, it is sometimes useful, or even necessary, to take advantage of platform-specific features. qmake knows about many of these features, and these can be accessed via specific variables that only have an effect on the platforms where they are relevant.
Mac OS X
Features specific to this platform include support for creating universal binaries, frameworks and bundles.
Source and Binary Packages
The version of qmake supplied in source packages is configured slightly differently to that supplied in binary packages in that it uses a different feature specification. Where the source package typically uses the macx-g++ specification, the binary package is typically configured to use the macx-xcode specification.
Users of each package can override this configuration by invoking qmake with the -spec option (see Running qmake for more information). This makes it possible, for example, to use qmake from a binary package to create a Makefile in a project directory with the following command line invocation:
qmake -spec macx-g++
qmake is able to automatically generate build rules for linking against frameworks in the standard framework directory on Mac OS X, located at /Library/Frameworks/.
Directories other than the standard framework directory need to be specified to the build system, and this is achieved by appending linker options to the QMAKE_LFLAGS variable, as shown in the following example:
QMAKE_LFLAGS += -F/path/to/framework/directory/
The framework itself is linked in by appending the -framework options and the name of the framework to the LIBS variable:
LIBS += -framework TheFramework
Any given library project can be configured so that the resulting library file is placed in a framework, ready for deployment. To do this, set up the project to use the lib template and add the lib_bundle option to the CONFIG variable:
TEMPLATE = lib CONFIG += lib_bundle
The data associated with the library is specified using the QMAKE_BUNDLE_DATA variable. This holds items that will be installed with a library bundle, and is often used to specify a collection of header files, as in the following example:
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
Here, the FRAMEWORK_HEADERS variable is a user-defined variable that is used to define the headers required to use a particular framework. Appending it to the QMAKE_BUNDLE_DATA variable ensures that the information about these headers are added to the collection of resources that will be installed with the library bundle. Also, the framework's name and version are specified by QMAKE_FRAMEWORK_BUNDLE_NAME and QMAKE_FRAMEWORK_VERSION variables. By default, the values used for these are obtained from the TARGET and VERSION variables.
See Deploying an Application on Mac OS X for more information about deploying applications and libraries.
Creating and Moving Xcode Projects
Developers on Mac OS X can take advantage of qmake's support for Xcode project files, as described in Qt is Mac OS X Native, by running qmake to generate an Xcode project from an existing qmake project files. For example:
qmake -spec macx-xcode project.pro
Note that, if a project is later moved on the disk, qmake must be run again to process the project file and create a new Xcode project file.
On supporting two build targets simultaneously
Implementing this is currently not feasible, because the XCode concept of Active Build Configurations is conceptually different from the qmake idea of build targets.
The XCode Active Build Configurations settings are for modifying xcode configurations, compiler flags and similar build options. Unlike Visual Studio, XCode does not allow for the selection of specific library files based on whether debug or release build configurations are selected. The qmake debug and release settings control which library files are linked to the executable.
It is currently not possible to set files in XCode configuration settings from the qmake generated xcode project file. The way the libraries are linked in the "Frameworks & Libraries" phase in the XCode build system.
Furthermore, the selected "Active Build Configuration" is stored in a .pbxuser file, which is generated by xcode on first load, not created by qmake.
Features specific to this platform include support for creating Visual Studio project files and handling manifest files when deploying Qt applications developed using Visual Studio 2005.
Creating Visual Studio Project Files
Developers using Visual Studio to write Qt applications can use the Visual Studio integration facilities provided with the Qt Commercial License and do not need to worry about how project dependencies are managed.
However, some developers may need to import an existing qmake project into Visual Studio. qmake is able to take a project file and create a Visual Studio project that contains all the necessary information required by the development environment. This is achieved by setting the qmake project template to either vcapp (for application projects) or vclib (for library projects).
This can also be set using a command line option, for example:
qmake -tp vc
It is possible to recursively generate .vcproj files in subdirectories and a .sln file in the main directory, by typing:
qmake -tp vc -r
Each time you update the project file, you need to run qmake to generate an updated Visual Studio project.
Note: If you are using the Visual Studio Add-in, you can import .pro files via the Qt->Import from .pro file menu item.
Visual Studio 2005 Manifest Files
When deploying Qt applications built using Visual Studio 2005, it is necessary to ensure that the manifest file, created when the application was linked, is handled correctly. This is handled automatically for projects that generate DLLs.
Removing manifest embedding for application executables can be done with the following assignment to the CONFIG variable:
CONFIG -= embed_manifest_exe
Also, the manifest embedding for DLLs can be removed with the following assignment to the CONFIG variable:
CONFIG -= embed_manifest_dll
This is discussed in more detail in the deployment guide for Windows.