[kde-freebsd] [Request For Commit] Qt 4.5 Build Fixes (with Qt33 installed)

[David Johnson]

On Sunday 12 April 2009 11:57:20 pm David Naylor wrote:
> devel/qt4-corelib:
>  - Remove port revision
>  - Remove hack to hard-code the features of qconfig.h.  The hack now
> appears to do more damage that good.  Attached is the qconfig.h generated
> by configure (as apposed to the files/qconfig.h.in that has been removed).
> - P.S. Please add USE_ICONV when the fix is committed

I committed a fix for corelib yesterday (in the qt-4.5 branch). It does 
essentially the same as yours.

> The fixes for build with qt33 are a result from -I{LOCALBASE} being
> included way to early.  How it gets there I do not know.  It appears to be
> included after the specific .pro file has been read and before some extra
> .prf files are read (such as mkspecs/features/unix/hide_symbols.prf).  Any
> idea as to the root cause?

The only place I ran across problems was with QtGui. The core problem is with 
the new QGTKStyle. I was able to fix this in a non-port build by changing 
src/gui/Makefile. Alternatively, once could patch src/gui/styles/styles.pri to 
totally disable QGTKStyle. (And make it a separate port).

I'm still working in this area. It seems from your list that other ports 
besides qt5-gui are having this problem. Have you identified their differences 
from 4.4.3 that cause this?

> Currently qt4 (in area51) only supports installing the ports into the same
> prefix as qmake4.  This is since the install prefix is hard coded into
> qmake4.  I have found only one way to override this hard-code, that is to
> recompile qmake4.  configure does this by default so I intend to restore
> this behaviour (when installing into a different PREFIX as to that by the
> system qmake).  This however will result in quite some growth in the
> Makefiles so I propose to refractor the common code between the Makefiles
> (such as the do-not-extract stuff).  This would hopefully simplify
> maintenance.

How big of a problem is this? Are there use cases where different PREFIXes 
would be desirable? Couldn't these use cases take advantage of a qmake.conf 
file instead?

p.s. My time is limited this week and next, but if I find some I'll look over 
your other patches closer. Some of them look good at first glance.

-- 
David Johnson