[oe] qt4x11 vs. uicmoc4-native vs. qmake2-native
Geoffrey Wossum
geoffrey at pager.net
Thu Jul 3 14:17:45 UTC 2008
Hi all,
I've been doing some work with some Qt4 based applications, and I must say
that I'm confused by the relationship between OE's qt4x11, uicmoc4-native,
and qmake2-native packages.
As far as I can tell, this is what each package provides:
qt4x11 - headers and libraries for target system
uicmoc4-native - All Qt tools except qmake for host system
qmake2-native - qmake and mkspecs for host system
My main question is why can't uicmoc4-native and qmake2-native be combined
into a single package? Let me share my pain.
I need Qt 4.4 because I'm using Phonon. So I make a new Bitbake recipe for
qt4x11-4.4.0. uicmoc4-native is still from 4.3.3. Oh, noes! uic from 4.3.3
doesn't generate code that works with QT_NO_ACCESSIBILITY, but that was fixed
in 4.4.0. So I make a uicmoc4-native recipe and patches for 4.4.0. Now I'm
building a package that uses CMake (phonon-vlc-mplayer) and Qt. CMake uses
qmake (NOOOOO!) to figure out how to build Qt based applications.
phonon-vlc-mplayer's build system punts because the qmake it finds from
qmake2-native is for 4.3.3, and it wants at least 4.4.0. So now I'm creating
a qmake2-native recipe and patches that builds qmake from 4.4.0, and it feels
like deja vu all over again.
But it gets even worse. uicmoc4-native gets its version number from the
version of Qt used to build it. But qmake2-native gets it's version number
from the qmake version, which is independent of the Qt version. Both Qt
4.3.3 and 4.4.0 include qmake 2.10a. However, qmake also remembers the
version of Qt used to build it, which is what makes CMake unhappy. So the
qmake version of 2.10a really isn't the whole story.
I understand that Qt's build system doesn't really handle building host tools
and target libraries in one shot, so at least two recipes are almost
certainly necessary. However, is there any good reason why uicmoc4-native
and qmake2-native couldn't be combined into a single package?
TIA,
---
Geoffrey
More information about the Openembedded-devel
mailing list