changes how Qt4 is found in trunk/kdelibs/

[Simon Hausmann]

On Wednesday 05 April 2006 19:11, Alexander Neundorf wrote:
> On Wednesday 05 April 2006 17:57, William A. Hoffman wrote:
> > 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.
>
> Yes, I agree. Before I joined this mailing list here, I didn't even know
> that an environment variable PKG_CONFIG_PATH exists. So I would not have
> guessed what might be going wrong.
> I actually liked the option to query qmake for information.

For KDE 4 it would make a lot of sense to use pkg-config files between the 
modules. If we would require setting PKG_CONFIG_PATH to $prefix (just like 
Gnome and X.org does, btw) then you would just have to install Qt into the 
same prefix and you're done.


Simon