Re: Qt static libraries - pkgconfig again
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 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Am Sonntag, 25. Februar 2007 schrieb Thiago Macieira:
$ tail -n 5 tools/designer/src/lib/uilib/uilib.pri
!contains(DEFINES, QT_FORMBUILDER_NO_SCRIPT) {
QT += script
HEADERS += $$PWD/formscriptrunner_p.h
SOURCES += $$PWD/formscriptrunner.cpp
}
Which, BTW, also shows that designer and UiTools can be built without
scripting support. So we cannot simply add -lQtScript to our build
dependencies if Qt 4.3 is detected.
Do you really think that KDE 4 will accept any other Qt-configuration than
full? Who's going to maintain and test those configurations? At least KDE 3
cannot be counted on building and working properly if arbitrary Qt-features
are disabled afaik.
mfg
Leo
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Leo Savernik wrote: Do you really think that KDE 4 will accept any other Qt-configuration than full? Who's going to maintain and test those configurations? At least KDE 3 cannot be counted on building and working properly if arbitrary Qt-features are disabled afaik. That's true for KDE 4, but FindQt4.cmake is used by other projects than KDE too. Treat this as a more general problem. Forget QtUiTools and QtScript. The problem is simple: we need to know every static library's dependencies to be able to use it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpHujDFh9cIC.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Dirk Mueller wrote:
On Saturday, 24. February 2007 12:42, Thiago Macieira wrote:
What happens if Trolltech decides that QtUiTools linking to QtScript
is optional?
Is it possible that this is a bug anyway? I don't see why QtUiTools
would *require* QtScript.
It's no bug. QtUiTools links to QtScript now and so does QtDesigner:
$ ldd libQtDesigner.so | grep QtScript
libQtScript.so.4
= /home/thiago/obj/troll/qt-main/lib/libQtScript.so.4 (0xb7db3000)
$ tail -n 5 tools/designer/src/lib/uilib/uilib.pri
!contains(DEFINES, QT_FORMBUILDER_NO_SCRIPT) {
QT += script
HEADERS += $$PWD/formscriptrunner_p.h
SOURCES += $$PWD/formscriptrunner.cpp
}
Which, BTW, also shows that designer and UiTools can be built without
scripting support. So we cannot simply add -lQtScript to our build
dependencies if Qt 4.3 is detected.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
pgpx8cXQG0tPB.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Am Samstag, 24. Februar 2007 schrieb Thiago Macieira: Peter Kümmel wrote: Can't we get around this problem by convincing the trolls to not make it a static lib? I doubt that. QtUiTools is a very small library whose purpose is to load designer-generated .ui files. This sounds like that it's easier to patch Qt than to introduce pkg-config on windows, or I'm wrong? Yes, it's easier to patch it. But that doesn't mean the Trolls will accept it. Thay made it specifically static for a reason. I just don't know what reason that is. And I kind of doubt that the reason is gone. What's all the fuss about that? Isn't QtUiTools located in the same directory as the shared objects such that it will be found by the -Lpath options? Wouldn't therefore a simple -lQtUiTools suffice for every link target in need of this? Or is this the solution you mean by patching Qt? mfg Leo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Holger Schröder schrieb: On Friday 23 February 2007 23:18:04 Christian Ehrlicher wrote: Holger Schröder schrieb: On Friday 23 February 2007 21:38:56 Thiago Macieira wrote: Simon Hausmann wrote: Christian is right there, also because qmake does not generate pkg-config files on Windows. 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. CMake will need it anyways for supporting static builds of other applications. well, pkg-config is available on win32, at least that is what http://pkgconfig.freedesktop.org/wiki/ says, although i haven´t tested it yet. so what about this option: for qt 4.2 we leave things as they are, and for qt 4.3 the trolls install .pc files on windows too, and we use them under linux and under windows ? pkg-config is available on win32, but it's only used in msys environment (where you have a linux-like directory layout) - the location of the pc files is not defined on windows. A path can be added with PKG_CONFIG_PATH (afaik), but imho this just makes the whole kde compilation more complex than we gain advantages from using pkg-config on win32. perhaps we should keep the future in mind. i think it would be good, if we agree on a directory layout for the installation of kde on windows under a prefix. This is already defined by the installation structure of kde, gnuwin32, dbus and other packages. If you install the sample kdelibs-mingw and all required dependencies with the kde installer you get the following directory layout under the install prefix contrib data doc etc include lib man manifest mkspecs plugins share src tools translations 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. perhaps pkg-config could help us there too. There would be a way to save pc files into a package installation dir like prefix/pkg-config so that cmake is able to detect those files. If have seen that some gnuwin32 provides .pc files, but I don't remember where they store it. The most annoying problem with pkg-config is that is uses absolute include/library path and only supports gcc on windows. It has to be extend to support multiple compilers (how to detect the currently used compiler) and include/library path depending on installation path at runtime. 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. Ralf ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Ralf Habacker wrote: Do we have the used qt version at cmake configure time or are able to detect it ? Then it looks easy to me to add one additional library at cmake configure time. That sounds like a workaround instead of a solution. What happens if Trolltech decides that QtUiTools linking to QtScript is optional? What happens for other static libraries out there, for other projects? Are we going to special-case all possibilities of static libraries, in all systems, with their dependencies? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpfVtWKrk1ll.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
On Friday 23 February 2007, Thiago Macieira wrote: What depenency is missing? QtScript. 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? -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
On Friday 23 February 2007 06:32:03 Christian Ehrlicher wrote: Thiago Macieira schrieb: Qt has one static library that we use in KDE code: QtUiTools. Whichever reason the Trolls had to make it static is besides the point: it is static. That means we must fetch its dependency info from the Qt installation into CMake. And Qt provides only one official way of doing that: via pkg-config. So, I ask again: can we start supporting discovery of Qt via pkg-config by default on all systems? If that doesn't work, we'd have a fallback to the current discovery via qmake. pkg-config on win32 is a bad idea... :( Christian is right there, also because qmake does not generate pkg-config files on Windows. I think for now we should either do what David suggests and just hardcode it for 4.3 or maybe use pkg-config on !windows and hardcode it only on Windows. Simon pgpAqNfcL41v6.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
[EMAIL PROTECTED] wrote: I guess it could. But there doesn't seem to be an easy way of doing that. maybe we should ask the trolls here - it looks quite easy to make qmake parse the .prl-files and print out QMAKE_PRL_LIBS. I think that's pointless. If we're going to parse a file, we can just as well parse the .pc file, which we are guaranteed to be standard. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpoYHLUSneTj.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Am Freitag, 23. Februar 2007 19:41 schrieb Thiago Macieira: [EMAIL PROTECTED] wrote: I guess it could. But there doesn't seem to be an easy way of doing that. maybe we should ask the trolls here - it looks quite easy to make qmake parse the .prl-files and print out QMAKE_PRL_LIBS. I think that's pointless. If we're going to parse a file, we can just as well parse the .pc file, which we are guaranteed to be standard. .. that only exists on unix. Greetings, Stephan ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Simon Hausmann wrote: Christian is right there, also because qmake does not generate pkg-config files on Windows. 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. CMake will need it anyways for supporting static builds of other applications. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpIVtNqUybyS.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
On Friday 23 February 2007 21:38:56 Thiago Macieira wrote: Simon Hausmann wrote: Christian is right there, also because qmake does not generate pkg-config files on Windows. 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. CMake will need it anyways for supporting static builds of other applications. well, pkg-config is available on win32, at least that is what http://pkgconfig.freedesktop.org/wiki/ says, although i haven´t tested it yet. so what about this option: for qt 4.2 we leave things as they are, and for qt 4.3 the trolls install .pc files on windows too, and we use them under linux and under windows ? just my 2c, Holger ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Holger Schröder schrieb: On Friday 23 February 2007 21:38:56 Thiago Macieira wrote: Simon Hausmann wrote: Christian is right there, also because qmake does not generate pkg-config files on Windows. 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. CMake will need it anyways for supporting static builds of other applications. well, pkg-config is available on win32, at least that is what http://pkgconfig.freedesktop.org/wiki/ says, although i haven´t tested it yet. so what about this option: for qt 4.2 we leave things as they are, and for qt 4.3 the trolls install .pc files on windows too, and we use them under linux and under windows ? pkg-config is available on win32, but it's only used in msys environment (where you have a linux-like directory layout) - the location of the pc files is not defined on windows. A path can be added with PKG_CONFIG_PATH (afaik), but imho this just makes the whole kde compilation more complex than we gain advantages from using pkg-config on win32. Christian signature.asc Description: OpenPGP digital signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Thiago Macieira wrote: [EMAIL PROTECTED] wrote: kdelibs does not build because QtUiTools is missing a dependency when linking kjsembed. Can't we get around this problem by convincing the trolls to not make it a static lib? I doubt that. QtUiTools is a very small library whose purpose is to load designer-generated .ui files. This sounds like that it's easier to patch Qt than to introduce pkg-config on windows, or I'm wrong? Or by parsing the .prl-files. That would not be recommended. Those files are not documented anywhere and could change format any time. Can't qmake tell us what deps we need? I guess it could. But there doesn't seem to be an easy way of doing that. What depenency is missing? QtScript. I need to compile qt4.3 on win32 to see if we really need to add this dependency - can you tell me more what's missing? The directory layout on win32 does not allow a pkg-config tool as every program has it's own subdirectory without a common place for .pkg-config - files. We've enough problems with other external libs/tools on win32 - adding another one would just rise the level for new devs once more :( We can use pkg-config for Qt only, at least. Fortunately, none of the Qt library .pc files has external dependencies, so they will parse easily by pkg-config with just one dir in $PKG_CONFIG_PATH. In any case, shouldn't Windows start having a common pkgconfig path then? ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem -- Peter Kümmel ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
On Friday 23 February 2007 23:18:04 Christian Ehrlicher wrote: Holger Schröder schrieb: On Friday 23 February 2007 21:38:56 Thiago Macieira wrote: Simon Hausmann wrote: Christian is right there, also because qmake does not generate pkg-config files on Windows. 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. CMake will need it anyways for supporting static builds of other applications. well, pkg-config is available on win32, at least that is what http://pkgconfig.freedesktop.org/wiki/ says, although i haven´t tested it yet. so what about this option: for qt 4.2 we leave things as they are, and for qt 4.3 the trolls install .pc files on windows too, and we use them under linux and under windows ? pkg-config is available on win32, but it's only used in msys environment (where you have a linux-like directory layout) - the location of the pc files is not defined on windows. A path can be added with PKG_CONFIG_PATH (afaik), but imho this just makes the whole kde compilation more complex than we gain advantages from using pkg-config on win32. perhaps we should keep the future in mind. i think it would be good, if we agree on a directory layout for the installation of kde on windows under a prefix. but the user should be able to unpack the kde package into any directory on the windows machine and have a working installation. and right now there are still some limitations in kde, which make this impossible, like the paths in kde4-config are hardcoded. perhaps pkg-config could help us there too. Christian Holger ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Peter Kümmel wrote: Can't we get around this problem by convincing the trolls to not make it a static lib? I doubt that. QtUiTools is a very small library whose purpose is to load designer-generated .ui files. This sounds like that it's easier to patch Qt than to introduce pkg-config on windows, or I'm wrong? Yes, it's easier to patch it. But that doesn't mean the Trolls will accept it. Thay made it specifically static for a reason. I just don't know what reason that is. And I kind of doubt that the reason is gone. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgptn2qk94LYl.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Thiago Macieira schrieb: Qt has one static library that we use in KDE code: QtUiTools. Whichever reason the Trolls had to make it static is besides the point: it is static. That means we must fetch its dependency info from the Qt installation into CMake. And Qt provides only one official way of doing that: via pkg-config. So, I ask again: can we start supporting discovery of Qt via pkg-config by default on all systems? If that doesn't work, we'd have a fallback to the current discovery via qmake. pkg-config on win32 is a bad idea... :( Christian signature.asc Description: OpenPGP digital signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Christian Ehrlicher wrote: pkg-config on win32 is a bad idea... :( If you want to compile KDE with Qt 4.3, you'll need it. kdelibs does not build because QtUiTools is missing a dependency when linking kjsembed. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgp946FKZMSlm.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Von: Thiago Macieira [EMAIL PROTECTED] Christian Ehrlicher wrote: pkg-config on win32 is a bad idea... :( If you want to compile KDE with Qt 4.3, you'll need it. kdelibs does not build because QtUiTools is missing a dependency when linking kjsembed. Can't we get around this problem by convincing the trolls to not make it a static lib? Or by parsing the .prl-files. Can't qmake tell us what deps we need? What depenency is missing? I need to compile qt4.3 on win32 to see if we really need to add this dependency - can you tell me more what's missing? The directory layout on win32 does not allow a pkg-config tool as every program has it's own subdirectory without a common place for .pkg-config - files. We've enough problems with other external libs/tools on win32 - adding another one would just rise the level for new devs once more :( Christian -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
[EMAIL PROTECTED] wrote: kdelibs does not build because QtUiTools is missing a dependency when linking kjsembed. Can't we get around this problem by convincing the trolls to not make it a static lib? I doubt that. QtUiTools is a very small library whose purpose is to load designer-generated .ui files. Or by parsing the .prl-files. That would not be recommended. Those files are not documented anywhere and could change format any time. Can't qmake tell us what deps we need? I guess it could. But there doesn't seem to be an easy way of doing that. What depenency is missing? QtScript. I need to compile qt4.3 on win32 to see if we really need to add this dependency - can you tell me more what's missing? The directory layout on win32 does not allow a pkg-config tool as every program has it's own subdirectory without a common place for .pkg-config - files. We've enough problems with other external libs/tools on win32 - adding another one would just rise the level for new devs once more :( We can use pkg-config for Qt only, at least. Fortunately, none of the Qt library .pc files has external dependencies, so they will parse easily by pkg-config with just one dir in $PKG_CONFIG_PATH. In any case, shouldn't Windows start having a common pkgconfig path then? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpyxna3dPC4o.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Von: Thiago Macieira [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: kdelibs does not build because QtUiTools is missing a dependency when linking kjsembed. Can't we get around this problem by convincing the trolls to not make it a static lib? I doubt that. QtUiTools is a very small library whose purpose is to load designer-generated .ui files. Or by parsing the .prl-files. That would not be recommended. Those files are not documented anywhere and could change format any time. Can't qmake tell us what deps we need? I guess it could. But there doesn't seem to be an easy way of doing that. maybe we should ask the trolls here - it looks quite easy to make qmake parse the .prl-files and print out QMAKE_PRL_LIBS. What depenency is missing? QtScript. My fault - it's to early in the morning ;) I need to compile qt4.3 on win32 to see if we really need to add this dependency - can you tell me more what's missing? The directory layout on win32 does not allow a pkg-config tool as every program has it's own subdirectory without a common place for .pkg-config - files. We've enough problems with other external libs/tools on win32 - adding another one would just rise the level for new devs once more :( We can use pkg-config for Qt only, at least. Fortunately, none of the Qt library .pc files has external dependencies, so they will parse easily by pkg-config with just one dir in $PKG_CONFIG_PATH. In any case, shouldn't Windows start having a common pkgconfig path then? A common path is hard to introduce - every user has to have access right to the common directory. Then it's maybe better to extend to PKG_CONFIG_PATH variable. But I doubt Qt 4.3 is doing that... If not, maybe cmake has to extend the pkg-config path (or parse the .pc - file directly). I have to take a look on this on weekend. Christian -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
