changes how Qt4 is found in trunk/kdelibs/

[Simon Hausmann]

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.   There is no pkg-config on the mac either.  What about
> SUN, HP, and other commercial unix vendors do they have pkg-config?

Yes, most of them also ship Gnome and Gnome requires pkg-config. (Remember, 
they actually invented/wrote it by generalizing their foo-config scripts)

> >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.

The qmake maintainer, too, suggested the approach of using a .pro file as 
little script, slightly smarter than my idea to grep in the resulting 
Makefile:

debug_and_release {
   message("Config:Debug")
   message("Config:Release")
} CONFIG(debug, debug|release)
   message("Config:Debug")
} else {
   message("Config:Release")
}
message("MOC = $$QMAKE_MOC")
message("RCC = $$QMAKE_RCC")

That way you can query a bit more information.

Simon