changes how Qt4 is found in trunk/kdelibs/

[William A. Hoffman]

At 11:04 AM 4/5/2006, Simon Hausmann wrote:
>On Wednesday 05 April 2006 16:49, William A. Hoffman wrote:
>> At 10:37 AM 4/5/2006, Simon Hausmann wrote:
>> >We solved it differently now. After some discussion and thinking we
>> > decided against putting it into qmake. Instead we store the path to uic
>> > and moc now in the pkgconfig files.
>> >
>> >That means with Qt 4.2 you'll be able to use pkg-config to figure out the
>> >libraries + paths for building a Qt application as well as the path to
>> >moc/uic.
>> >
>> >For example:
>> >
>> >pkg-config --variable=moc_location QtCore
>>
>> What about systems that do not have pkg-config?
>
>For those you have to assume the fallback of a in-place installation where 
>everything is inside $prefix and the binaries aren't renamed. This in 
>particular includes Windows :)

I don't think it is just windows, and also this does make it harder to
work with a non-installed qt, unless the user sets PKG_CONFIG_PATH and
some other stuff, pkg-config will not even know about the users local
qt installation.   There is no pkg-config on the mac either.  What about
SUN, HP, and other commercial unix vendors do they have pkg-config?


>Here's one of the arguments that we came up with against putting it into 
>qmake: pkg-config is the preferred way of figuring out the 
>cflags/lib/libpaths these days. Now if however qmake is used to figure out 
>another component necessary to build projects you could easily run into the 
>situation that due to pkg-config (which obeys the PKG_CONFIG_PATH environment 
>variable) you get for example /home/developer/my/private/qt/build/lib as 
>library directory but qmake is accidentially picked from /usr/bin and 
>reports /usr/bin/uic-qt4 from the path, which may come from a different Qt 
>installation. That's a recipe for problems. Hence the idea that all the 
>information should come from one place: pkg-config files.

I don't see how that can happen.  Our rule is that qmake tells all.
So the private/qt/build/bin/qmake would have to be used and it should be
able to tell where to find everything.  I am assuming that qmake itself
will not ask pkg-config anything, so I guess we could run qmake on a simple .pro file
and look at the resulting makefile.   I don't think cmake should depend on
pkg-config, I really like the idea of using qmake.  It is a single program
that knows exactly how to build the qt it is part of.  So for cmake if the
users specifies a qmake, they are done, the rest can be found from the qmake.
This will work on any platform that has qt on it.   pkg-config just does
not seem cross platform enough.  For example, it is not on our solaris,
hp, mac, or irix machines.  However, qt can be easily installed and
built on those machines.

-Bill




-Bill