qt4-x11-free dependence on gtk+

qt4-x11-free dependence on gtk+

[Peter A. Bigot]

Since "bitbake qt4-x11-free" failed for me until I did "bitbake gtk+", 
qt4-x11-free needs some sort of dependency on gtk+ to avoid the failure 
below.  I'm guessing it's something like the following added to 
qt4-x11-free.inc:

PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'gtk', '', 
d)}"
PACKAGECONFIG[gtk] = "-gtkstyle,-no-gtkstyle,gtk+"

but since it takes about an hour to build qt4-x11-free on my system I'm 
hoping somebody can tell me whether that's the right approach.

Peter

arm-poky-linux-gnueabi-g++  -march=armv7-a -mthumb-interwork 
-mfloat-abi=softfp -mfpu=neon 
--sysroot=/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo -c -O2 -pipe 
-g -feliminate-unused-debug-types -fpermissive 
-fvisibility-inlines-hidden 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/freetype2 -pthread 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/glib-2.0 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/lib/glib-2.0/include 
-pthread 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/gtk-2.0 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/lib/gtk-2.0/include 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/pango-1.0 -I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/cairo 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/pixman-1 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/libpng16 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/gdk-pixbuf-2.0 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/libpng16 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/pango-1.0 -I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/harfbuzz 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/pango-1.0 -I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/freetype2 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/atk-1.0 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/glib-2.0 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/lib/glib-2.0/include 
-O2 -O2 -fvisibility=hidden -fvisibility-inlines-hidden 
-fvisibility=hidden -fvisibility=hidden -fvisibility-inlines-hidden 
-Wall -W -Wall -W -Wall -W -D_REENTRANT 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/freetype2 -fPIC 
-fPIC -fPIC -DQT_SHARED -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE 
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT 
-DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_NO_OPENTYPE 
-DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP 
-DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_S60 
-DQ_INTERNAL_QAPP_SRC -DQT_HAVE_NEON -DQT_NO_DEBUG -DQT_CORE_LIB 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. 
-I../../include/QtCore -I../../include -I../../include/QtGui 
-I.rcc/release-shared -I../3rdparty/xorg -Iimage 
-I../3rdparty/harfbuzz/src -Idialogs 
-I/prj/oe/omap/build-gumstix-dev/tmp/sysroots/overo/usr/include/freetype2 -I.moc/release-shared 
-I.uic/release-shared -o .obj/release-shared/qx11embed_x11.o 
kernel/qx11embed_x11.cpp
In file included from ../../include/QtGui/private/qgtkstyle_p.h:1:0,
                  from kernel/qguiplatformplugin.cpp:63:
../../include/QtGui/private/../../../src/gui/styles/qgtkstyle_p.h:69:21: 
fatal error: gtk/gtk.h: No such file or directory
  #include <gtk/gtk.h>
                      ^
compilation terminated.
make[1]: *** [.obj/release-shared/qguiplatformplugin.o] Error 1

Re: qt4-x11-free dependence on gtk+

[Paul Eggleton]

Hi Peter,

On Tuesday 27 August 2013 13:59:24 Peter A. Bigot wrote:
> Since "bitbake qt4-x11-free" failed for me until I did "bitbake gtk+",
> qt4-x11-free needs some sort of dependency on gtk+ to avoid the failure
> below.  I'm guessing it's something like the following added to
> qt4-x11-free.inc:
> 
> PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'gtk', '',
> d)}"
> PACKAGECONFIG[gtk] = "-gtkstyle,-no-gtkstyle,gtk+"
> 
> but since it takes about an hour to build qt4-x11-free on my system I'm
> hoping somebody can tell me whether that's the right approach.

This seems reasonable to me. I can't actually reproduce the failure, but I can 
see how the dependency comes in and it does look to be on by default.

Looking at bitbake -g output (for master at least) it seems like gtk+3 will 
always be built by default when building qt4-x11-free because pulseaudio 
depends upon it, so that explains how this problem doesn't often come up. Of 
course if gtk+3 is rebuilding when qt4-x11-free is in do_compile, or you've 
disabled pulseaudio, then this issue will occur so we do need to do something 
such as the above. I think the PACKAGECONFIG option for this should be called 
"gtkstyle" rather than just "gtk" to give a better idea of what it's enabling 
though. Would you please send an actual patch to add this?

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: qt4-x11-free dependence on gtk+

[Peter A. Bigot]

On 08/30/2013 08:37 AM, Paul Eggleton wrote:
> Hi Peter,
>
> On Tuesday 27 August 2013 13:59:24 Peter A. Bigot wrote:
>> Since "bitbake qt4-x11-free" failed for me until I did "bitbake gtk+",
>> qt4-x11-free needs some sort of dependency on gtk+ to avoid the failure
>> below.  I'm guessing it's something like the following added to
>> qt4-x11-free.inc:
>>
>> PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'gtk', '',
>> d)}"
>> PACKAGECONFIG[gtk] = "-gtkstyle,-no-gtkstyle,gtk+"
>>
>> but since it takes about an hour to build qt4-x11-free on my system I'm
>> hoping somebody can tell me whether that's the right approach.
> This seems reasonable to me. I can't actually reproduce the failure, but I can
> see how the dependency comes in and it does look to be on by default.

What actually happens is qt4 assumes -gtkstyle, but disables it if gtk+ 
(not gtk+3) can't be located in sysroots by invoking pkgconfig.

qt4-x11-free already depends on x11 so looking for x11 in 
DISTRO_FEATURES will always succeed.

Further, PACKAGECONFIG doesn't work because the recipe uses qmake and I 
can't see where changes to EXTRA_OECONF are ever applied.

So unless there's a way to do something like PACKAGECONFIG that isn't 
PACKAGECONFIG, the options I see are either add -gtkstyle to 
QT_X11_FLAGS and gtk+ to DEPENDS, or leave DEPENDS alone and add 
-no-gtkstyle to QT_X11_FLAGS. I don't knowingly use qt4 so don't know 
whether the GTK theme is important, but I'm inclined to the former path 
(unconditionally enable gtk+).

Any better way to solve this?

Peter

> Looking at bitbake -g output (for master at least) it seems like gtk+3 will
> always be built by default when building qt4-x11-free because pulseaudio
> depends upon it, so that explains how this problem doesn't often come up. Of
> course if gtk+3 is rebuilding when qt4-x11-free is in do_compile, or you've
> disabled pulseaudio, then this issue will occur so we do need to do something
> such as the above. I think the PACKAGECONFIG option for this should be called
> "gtkstyle" rather than just "gtk" to give a better idea of what it's enabling
> though. Would you please send an actual patch to add this?
>
> Thanks,
> Paul
>

Re: qt4-x11-free dependence on gtk+

[Paul Eggleton]

Hi Peter,
 
On Saturday 31 August 2013 03:40:13 Peter A. Bigot wrote:
> On 08/30/2013 08:37 AM, Paul Eggleton wrote:
> > On Tuesday 27 August 2013 13:59:24 Peter A. Bigot wrote:
> >> Since "bitbake qt4-x11-free" failed for me until I did "bitbake gtk+",
> >> qt4-x11-free needs some sort of dependency on gtk+ to avoid the failure
> >> below.  I'm guessing it's something like the following added to
> >> qt4-x11-free.inc:
> >> 
> >> PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'gtk', '',
> >> d)}"
> >> PACKAGECONFIG[gtk] = "-gtkstyle,-no-gtkstyle,gtk+"
> >> 
> >> but since it takes about an hour to build qt4-x11-free on my system I'm
> >> hoping somebody can tell me whether that's the right approach.
> > 
> > This seems reasonable to me. I can't actually reproduce the failure, but I
> > can see how the dependency comes in and it does look to be on by default.
>
> What actually happens is qt4 assumes -gtkstyle, but disables it if gtk+
> (not gtk+3) can't be located in sysroots by invoking pkgconfig.
> 
> qt4-x11-free already depends on x11 so looking for x11 in
> DISTRO_FEATURES will always succeed.

Right, that check alone wouldn't solve anything.
 
> Further, PACKAGECONFIG doesn't work because the recipe uses qmake and I
> can't see where changes to EXTRA_OECONF are ever applied.

Indeed, I had missed that - that's because we haven't yet used PACKAGECONFIG 
in conjunction with Qt (mainly because a lot of the Qt configure options 
effectively have more than two states which PACKAGECONFIG can't handle) and Qt 
doesn't use autotools so it doesn't already use EXTRA_OECONF.

> So unless there's a way to do something like PACKAGECONFIG that isn't
> PACKAGECONFIG, the options I see are either add -gtkstyle to
> QT_X11_FLAGS and gtk+ to DEPENDS, or leave DEPENDS alone and add
> -no-gtkstyle to QT_X11_FLAGS. I don't knowingly use qt4 so don't know
> whether the GTK theme is important, but I'm inclined to the former path
> (unconditionally enable gtk+).
> 
> Any better way to solve this?

We could add ${EXTRA_OECONF} to the configure command line and then the 
previously suggested PACKAGECONFIG will work. I'm tempted to suggest this 
should be off by default as well since most users of Qt in our environment will 
neither want nor expect it to depend on GTK+; having QGtkStyle enabled is (I 
would think) peripheral to most embedded use cases.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: qt4-x11-free dependence on gtk+

[Peter A. Bigot]

On 09/04/2013 05:56 AM, Paul Eggleton wrote:
> Hi Peter,
>   
> On Saturday 31 August 2013 03:40:13 Peter A. Bigot wrote:
>> On 08/30/2013 08:37 AM, Paul Eggleton wrote:
>>> On Tuesday 27 August 2013 13:59:24 Peter A. Bigot wrote:
>>>> Since "bitbake qt4-x11-free" failed for me until I did "bitbake gtk+",
>>>> qt4-x11-free needs some sort of dependency on gtk+ to avoid the failure
>>>> below.  I'm guessing it's something like the following added to
>>>> qt4-x11-free.inc:
>>>>
>>>> PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'gtk', '',
>>>> d)}"
>>>> PACKAGECONFIG[gtk] = "-gtkstyle,-no-gtkstyle,gtk+"
>>>>
>>>> but since it takes about an hour to build qt4-x11-free on my system I'm
>>>> hoping somebody can tell me whether that's the right approach.
>>> This seems reasonable to me. I can't actually reproduce the failure, but I
>>> can see how the dependency comes in and it does look to be on by default.
>> What actually happens is qt4 assumes -gtkstyle, but disables it if gtk+
>> (not gtk+3) can't be located in sysroots by invoking pkgconfig.
>>
>> qt4-x11-free already depends on x11 so looking for x11 in
>> DISTRO_FEATURES will always succeed.
> Right, that check alone wouldn't solve anything.
>   
>> Further, PACKAGECONFIG doesn't work because the recipe uses qmake and I
>> can't see where changes to EXTRA_OECONF are ever applied.
> Indeed, I had missed that - that's because we haven't yet used PACKAGECONFIG
> in conjunction with Qt (mainly because a lot of the Qt configure options
> effectively have more than two states which PACKAGECONFIG can't handle) and Qt
> doesn't use autotools so it doesn't already use EXTRA_OECONF.
>
>> So unless there's a way to do something like PACKAGECONFIG that isn't
>> PACKAGECONFIG, the options I see are either add -gtkstyle to
>> QT_X11_FLAGS and gtk+ to DEPENDS, or leave DEPENDS alone and add
>> -no-gtkstyle to QT_X11_FLAGS. I don't knowingly use qt4 so don't know
>> whether the GTK theme is important, but I'm inclined to the former path
>> (unconditionally enable gtk+).
>>
>> Any better way to solve this?
> We could add ${EXTRA_OECONF} to the configure command line and then the
> previously suggested PACKAGECONFIG will work. I'm tempted to suggest this
> should be off by default as well since most users of Qt in our environment will
> neither want nor expect it to depend on GTK+; having QGtkStyle enabled is (I
> would think) peripheral to most embedded use cases.

I actually tried that and the build blew up; I think some sort of 
machine-specific options got inherited and placed where they weren't 
expected (Qt's configure is not autoconf configure), but didn't bother 
looking closely.

Any solution other than forcing either -gtkstyle or -no-gtkstyle is more 
intrusive than I want to take on, especially for a recipe I don't 
personally rely on and at this stage of the development cycle.  Since I 
can't tell what the right choice is and turning it off may break the 
observed existing behavior in many cases, I've opened bug 5116 for 
somebody more qualified to handle.

Peter

>
> Cheers,
> Paul
>