Re: Locating/Linking against Qt

[Dalibor Topic]

Brian wrote:
> I believe this to be the relevant code from [1]. I am unclear as to 
> where $PKG_CONFIG comes from. It's not an environment variable and not 
> set by configure. [2] is the AutoQt macro for Qt 1-3.

Yep, that's the bit. pkg-config comes from PKG_CHECK_MODULES, which in 
turn invokes pkg-config to read the respective .pc files.

Since Trolltech does not seem to use Automake for building Qt 4 apps, 
but GNU Classpath does, I'll walk you through the code with some 
comments on what it does and why.

> dnl Check for AWT related Qt4
>   if test "x${COMPILE_QT_PEER}" = xyes; then
>     PKG_CHECK_MODULES(QT, QtGui >= 4.0.1)

This bit uses pkg-config to check if the QtGui library exists in the 
version 4.0.1 or higher. pkg-config is a tool that reads .pc files, 
which in turn describe what CFLAGS and LDFLAGS are necessary to build 
something with some library.

GNU Classpath is using 4.0.1 since 4.0.0 had some serious linkage 
problems that prevented QX11EmbedWidget from working.

The pkg-config invocation sets some variables, with the prefix QT. So 
you'll get QT_CFLAGS and QT_LDFLAGS.

In order for pkg-config to work, it needs to be able to find the .pc 
files for Qt4. I.e. if you installed it yourself manually into 
~/something, you need to tell pkg-config about it by adding the 
installtion/lib/ path (or wherever your installation of Qt4 managed to 
stuff the .pc files into) to the PKG_CONFIG_PATH environment variable.

>     dnl Check needed because in some cases the QtGui includedir
>     dnl doesn't contain the subsystem dir.

This bit is necessary because the CFLAGS from the Qt 4.0.x .pc flags 
have a "bad" include path. The include structure in a Qt 4 installation is

address@hidden ~]$ ls -l ~/qt4/include/
total 116
drwxrwxr-x  3 topic topic 24576 Aug 20 06:40 Qt
drwxrwxr-x  2 topic topic  8192 Aug 20 06:40 Qt3Support
drwxrwxr-x  2 topic topic  4096 Aug 20 06:41 QtAssistant
drwxrwxr-x  3 topic topic  8192 Aug 20 06:39 QtCore
drwxrwxr-x  2 topic topic  4096 Aug 20 06:41 QtDesigner
drwxrwxr-x  2 topic topic 12288 Aug 20 06:40 QtGui
drwxrwxr-x  2 topic topic  4096 Aug 20 06:40 QtNetwork
drwxrwxr-x  2 topic topic  4096 Aug 20 06:40 QtOpenGL
drwxrwxr-x  2 topic topic  4096 Aug 20 06:40 QtSql
drwxrwxr-x  2 topic topic  4096 Aug 20 06:39 QtXml

where all the includes are afaict accesible via the Qt subdirectory, and 
the includes for respective modules,like QtGui are present in those 
modules as well. So both <Qt/QWidget> and <QtGui/QWidget> are ok.

The .pc files set -Iwhereveryouputqt4/include in the CFLAGS.

The problem there is that noone, not even Trolltech actually puts those 
module prefixes in their #include paths. First of all, they are 
unnecessary if you are using qmake, Trolltech's cross-platform, 
Qt-specific automake-like tool. qmake sets the -I option in CFLAGS to 
include the name of the modules your code uses, so it actually sets 
-Iwhereveryouputqt4/include/QtGui in CFLAGS in the generated Makefiles.

Since most people use qmake to create Makefiles for their Qt projects, 
they use #include <QWidget> in their code, rather than #include 
<QtGui/QWidget>. So if you don't take care to work around what I believe 
is a bug in Trolltech's .pc files, you'll either have to mess with the 
#include statements of the code of people using qmake, or improve the 
QT_CFLAGS.

The code below does the latter.

>     QT_INCLUDE_DIR=$($PKG_CONFIG --variable=includedir QtGui)

First it fetches the includedir for the QtGui library.

>     EXTRA_QT_INCLUDE_DIR="$QT_INCLUDE_DIR/Qt"

Then it appends "/Qt" to the includedir. That's the directory in a Qt4 
installation where all the include files are present, so that one should 
make all Qt4 headers available to the compiler in a shorthand notation.

>     AC_CHECK_FILE([$QT_INCLUDE_DIR/QWidget],

If the includedir in the pc file is OK, configure should be able to find 
QWidget in it, and don't need to append an extra include dir ending with 
"/Qt" to it.

>                   AC_MSG_NOTICE([No extra QT_INCLUDE_DIR needed]),
>
>
>                   AC_CHECK_FILE([$EXTRA_QT_INCLUDE_DIR/QWidget],

Otherwise, the code checks if appending /Qt to the includedir leads to 
the QWidget include file. If that works, the extra include dir is added 
to the original QT_CFLAGS.

>                         QT_CFLAGS="$QT_CFLAGS -I$EXTRA_QT_INCLUDE_DIR",
>                         AC_MSG_WARN([QWidget not found])))

If none works, something strange has happened. Strange things may happen 
in the future when distributions start shipping qt4, for example, and 
may have to try to figure out ways to make it coexist with 
qt1/2/3/embedded versions that they are shipping as well. Distributions 
ocassionally do non-obvious things. In that case, the code prints a 
warning that it couldn't find the QWidget include file.

>     AC_MSG_NOTICE([Set QT_CFLAGS... $QT_CFLAGS])

It also makes sure to tell that the QT_FLAGS have been set to something 
useful.

>     AC_CHECK_PROG(MOC, [moc], [moc])

This bit checks for moc, a Qt-specific tool, which converts the Qt-C++ 
dialect's SIGNAL and SLOT shorthand macros into more standard C++ 
support files. It creates installation-specific .moc files.

Here, one more word of warning: some distributions ship the Qt4 moc 
under a different name, to make it coexist on the $PATH with the earlier 
versions. I've seen that Debian's unstable Qt4 package uses moc-qt4, 
too. You'll want to make sure that the plain "moc" from qt4 is on the 
$PATH before such renamed versions.

Moc from Qt3 will most likely *not* work with Qt4.

For how to use moc, see the Makefile.am cited below.

If you don't want to use automake for your Qt4 build fun, see 
Trolltech's Qt4 installation tarballs forn example projects, where 
internally, qmake is invoked to deal with the whole thing.

If you want to use qmake, check for qmake, of course. ;)

>     AC_SUBST(QT_CFLAGS)
>     AC_SUBST(QT_LIBS)

These bits take cure that the QT_* flags that the configure script has 
put so much work in by now, are actually made available to the Makefiles. ;)

>   fi

And that's it. For how it is being used in practice, see 
http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/classpath/classpath/native/jni/qt-peer/Makefile.am?rev=1.4&content-type=text/vnd.viewcvs-markup

It has worked fine for me (& Kaffe) on GNU/Linux and for others on OS X.
So you can marvel in the lovely Qt based AWT peers of GNU Classpath on 
those platforms, for all I know. I have not yet had the time to play 
with the Windows version.

> [2] http://cvs.sourceforge.net/viewcvs.py/*checkout*/autoqt/autoqt/gwqt.m4

I am also using the autoqt macros in Kaffe for the other set of Qt peers 
 (Qt2/3/Embedded), and that's what they are really nice for. Since Qt4 
comes with pkg-config support, though, and you probably really want to 
use Qt4 (the APIs are partially different from earlier versions, so your 
source will not build on them), then just going with the solution I 
explained above is simpler, than trying to update the autoqt macros for 
Qt4.

Note that contrary to earlier versions of Qt, with which autoqt deals 
just fine, as you can see in the Kaffe CVS head's m4 dir, Qt4 has split 
the core libraries into different modules, and changed a few other 
things about the default installation (header organisation, for example).

That might require a bit of work to make it all work fine if you decide 
to improve autoqt. I have not tried it myself, as the Qt peers in GNU 
Classpath only work with Qt4.

cheers,
dalibor topic