FindQt4.cmake

[David Faure]

On Wednesday 01 February 2006 22:06, Tanner Lovelace wrote:
> On 2/1/06, David Faure <faure at kde.org> wrote:
> > Yeah, and I think it would be a *major* PITA to have to write #include <QtCore/QString.h>.
> > In fact I would prefer a solution that forbids it...
> 
> Let me get this straight.  You'd rather do what is arguably the "wrong way"(tm)
> just because you don't want to type a few extra keystrokes?

Who says wrong way? It's the way that works in every other Qt source code.
It's not about the typing, it's about
- consistency
- knowing what to type (do you know off hand which qt lib each class is part of?)
- automatization

> The buildsystem aside (because cmake can and does compile it as written),
> Qt4 appears to have changed many more things than just where the header
> files are.  Surely you don't think they shouldn't also be changed?  How is
> this different?

I'm not talking about the porting (it's indeed relatively easy to automate such changes),
I'm talking about the every day task of writing code. It should be made easy,
not unnecessarily difficult. And consistent with any other Qt code out there.

> > Surely there's another solution for Mac OSX, given that it works in bksys?
> 
> And it works in cmake too, at the cost of lots of complexity.  That still
> doesn't mean it shouldn't be changed to the correct usage.

I don't see what's correct about it. Grab any piece of qt-based source code
and it'll say #include <qlineedit.h> for qt3/4 or #include <QLineEdit> for qt4.
And not only KDE code, any Qt-based code.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).