Qt static libraries - pkgconfig again

Alexander Neundorf neundorf at kde.org
Tue Feb 27 22:20:19 CET 2007


Hi,

answering several mails in one:

David wrote:
> For this one special case, can't we start linking to -lQtUiTools -lQtScript
> when we switch to 4.3, rather than complicate the setup on all platforms and
> especially on windows?

Yes, I think so too.

Ralf wrote:
> Holger wrote:
> > but the user should be able to unpack the kde package into any 
> > directory on the windows machine and have a working installation. 
>
> agreed 
>
> > and right now there are still some limitations in kde, which make this
> > impossible, like the paths in kde4-config are hardcoded.
>   
> Which has to be changed for windows as already done with dbus.  The
> dbus-daemon detects the installation base using the executable path.

So, would changing kde4-config so that the subdirs are determined from its own 
installation directory be acceptable on UNIX ?

Beside that, the directories are not very-hard-coded, they are put there 
during configure (cmake) time. So we could also do something special there.

Thiago wrote:
> May I suggest then that we together standardise on a dependency file for 
> static libraries (and platforms where such a thing is necessary)? More or 
> less like the libtool .la file.

For CMake it could look like this:

SET(QtUiTools_LIB_DEPENDS "/usr/lib/qt4/lib/libQtCore.so;/usr/lib/qt4/lib/libQtScript.so;")
...
etc. just like our KDELibsDependencies.cmake file, which is then simply 
included by cmake when building all later mdoules after kdelibs.

Ralf wrote:
> Sometime ago I have written an initial version of a pkg-config for
> windbus.
> http://windbus.svn.sourceforge.net/viewvc/windbus/trunk/pkg-config/
> Maybe this could be used as a starting point for a better implementation.

I don't think trying to push pkg-config on Windows is a good idea, I mean, 
something which will be used outside KDE too.

Thiago wrote:
> That's true for KDE 4, but FindQt4.cmake is used by other projects than 
> KDE too.

I'd like that to be true.
I'd prefer if we could stay in sync with the FindQt4.cmake from cmake cvs. 
Currently we are not. 
The cmake version for instance parses the mkspecs/qconfig.prl file to find out 
some more about Qt. It supports all Qt4 version from 4.0 to current, while in 
our version some things (I think the debug lib name change) has been "cleaned 
up" with Qt 4.2.
I try to keep the rest in sync as much as possible.
In theory it would be nice if we could simply use the FindQt4.cmake coming 
with cmake, but actually I don't see this happening, just have a look at this 
very discussion. Endless arguing about using pkg-config (which doesn't exist 
on all platforms where CMake and Qt4 have to work) or not.
So maybe we'll just have to live with our own version of FindQt4.cmake (until 
KDE5 comes out ;-)

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net


More information about the Kde-buildsystem mailing list