FreeBSD Porter's Handbook
Prev | Chapter 6 Special Considerations | Next

# 6.9 Using Qt

## 6.9.1 Ports That Require Qt

Table 6-7. Variables for Ports That Use Qt

`USE_QT_VER` | The port uses the Qt toolkit. Possible values are `3` and `4`; each specify the major version of Qt to use. Appropriate parameters are passed to `configure` script and `make`.
`QT_PREFIX` | Set to the path where Qt installed to (read-only variable).
`MOC` | Set to the path of `moc` (read-only variable). Default set according to `USE_QT_VER` value.
`QTCPPFLAGS` | Additional compiler flags passed via `CONFIGURE_ENV` for Qt toolkit. Default set according to `USE_QT_VER`.
`QTCFGLIBS` | Additional libraries for linking passed via `CONFIGURE_ENV` for Qt toolkit. Default set according to `USE_QT_VER`.
`QTNONSTANDARD` | Suppress modification of `CONFIGURE_ENV`, `CONFIGURE_ARGS`, and `MAKE_ENV`.

Table 6-8. Additional Variables for Ports That Use Qt 4.x

`QT_COMPONENTS` | Specify tool and library dependencies for Qt4. See below for details.
`UIC` | Set to the path of `uic` (read-only variable). Default set according to `USE_QT_VER` value.
`QMAKE` | Set to the path of `qmake` (read-only variable). Default set according to `USE_QT_VER` value.
`QMAKESPEC` | Set to the path of configuration file for `qmake` (read-only variable). Default set according to `USE_QT_VER` value.

When `USE_QT_VER` is set, some useful settings are passed to `configure` script:

    CONFIGURE_ARGS+=	--with-qt-includes=${QT_PREFIX}/include \
    			--with-qt-libraries=${QT_PREFIX}/lib \
    			--with-extra-libs=${LOCALBASE}/lib \
    			--with-extra-includes=${LOCALBASE}/include
    CONFIGURE_ENV+=	MOC="${MOC}" CPPFLAGS="${CPPFLAGS} ${QTCPPFLAGS}" LIBS="${QTCFGLIBS}" \
    		QTDIR="${QT_PREFIX}" KDEDIR="${KDE_PREFIX}"

If `USE_QT_VER` is set to `4`, the following settings are also deployed:

    CONFIGURE_ENV+=	UIC="${UIC}" QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}"
    MAKE_ENV+=	QMAKESPEC="${QMAKESPEC}"

## 6.9.2 Component Selection (Qt 4.x Only)

When `USE_QT_VER` is set to 4, individual Qt4 tool and library dependencies can be specified in the `QT_COMPONENTS` variable. Every component can be suffixed by either `_build` or `_run`, the suffix indicating whether the component should be depended on at buildtime or runtime, respectively. If unsuffixed, the component will be depended on at both build- and runtime. Usually, library components should be specified unsuffixed, tool components should be specified with the `_build` suffix and plugin components should be specified with the `_run` suffix. The most commonly used components are listed below (all available components are listed in `_QT_COMPONENTS_ALL` in `/usr/ports/Mk/bsd.qt.mk`):

Table 6-9. Available Qt4 Library Components

Name | Description
--- | ---
`corelib` | core library (can be omitted unless the port uses nothing but `corelib`)
`gui` | graphical user interface library
`network` | network library
`opengl` | OpenGL library
`qt3support` | Qt3 compatibility library
`qtestlib` | unit testing library
`script` | script library
`sql` | SQL library
`xml` | XML library

You can determine which libraries the application depends on, by running `ldd` on the main executable after a successful compilation.

Table 6-10. Available Qt4 Tool Components

Name | Description
--- | ---
`moc` | meta object compiler (needed for almost every Qt application at buildtime)
`qmake` | Makefile generator / build utility
`rcc` | resource compiler (need if the application comes with `*.rc` or `*.qrc` files)
`uic` | user interface compiler (needed if the application comes with `*.ui` files created by Qt Designer - in practice, every Qt application with a GUI)

Table 6-11. Available Qt4 Plugin Components

Name | Description
--- | ---
`iconengines` | SVG icon engine plugin (if the application ships SVG icons)
`imageformats` | imageformat plugins for GIF, JPEG, MNG and SVG (if the application ships image files)

Example 6-4. Selecting Qt4 Components

In this example, the ported application uses the Qt4 graphical user interface library, the Qt4 core library, all of the Qt4 code generation tools and Qt4's Makefile generator. Since the gui library implies a dependency on the core library, corelib does not need to be specified. The Qt4 code generation tools moc, uic and rcc, as well as the Makefile generator qmake are only needed at buildtime, thus they are specified with the `_build` suffix:

    USE_QT_VER=	4
    QT_COMPONENTS=	gui moc_build qmake_build rcc_build uic_build

## 6.9.3 Additional Considerations

If the application does not provide a `configure` file but a `.pro` file, you can use the following:

    HAS_CONFIGURE=	yes

    do-configure:
    	@cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \
    		${QMAKE} -unix PREFIX=${PREFIX} texmaker.pro

Note the similarity to the `qmake` line from the provided `BUILD.sh` script. Passing `CONFIGURE_ENV` ensures `qmake` will see the `QMAKESPEC` variable, without which it cannot work. `qmake` generates standard Makefiles, so it is not necessary to write our own `build` target.

Qt applications often are written to be cross-platform and often X11/Unix isn't the platform they are developed on, which in turn often leads to certain loose ends, like:

- Missing additional includepaths. Many applications come with system tray icon support, but neglect to look for includes and/or libraries in the X11 directories. You can tell `qmake` to add directories to the include and library searchpaths via the command line, for example:

      ${QMAKE} -unix PREFIX=${PREFIX} INCLUDEPATH+=${LOCALBASE}/include \
      	LIBS+=-L${LOCALBASE}/lib sillyapp.pro

- Bogus installation paths. Sometimes data such as icons or .desktop files are by default installed into directories which aren't scanned by XDG-compatible applications. `editors/texmaker` is an example for this - look at `patch-texmaker.pro` in the `files` directory of that port for a template on how to remedy this directly in the Qmake project file.

Prev | Home | Next
Using GNOME | Up | Using KDE

For questions about the FreeBSD ports system, e-mail <ports@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.