[OE-core] [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Martin Jansa]

Even if there is separate DISTRO_FEATURE for gles, we still have problem
that the same distribution can support MACHINEs with different support for
*gl*.

You still cannot build the same TUNE_PKGARCH qtbase package where once it's
used for MACHINE where you have only mesa as *gl* provider and for
different MACHINE which has binary blob for gles2. DISTRO_FEATUREs can
contain only common denominator for features available in all supported
MACHINEs. Splitting it to 2 separate features doesn't help with this.

And if we cannot build TUNE_PKGARCH qtbase we would need to make also
qtwebkit MACHINE_ARCH and I really don't like it, because of webkit build
time :/.


On Wed, Oct 23, 2013 at 11:25 AM, Nicolas Dechesne <
nicolas.dechesne at linaro.org> wrote:

> On Wed, Oct 23, 2013 at 11:00 AM, Burton, Ross <ross.burton at intel.com>
> wrote:
> > On 23 October 2013 09:53, Nicolas Dechesne <nicolas.dechesne at linaro.org>
> wrote:
> >> i am still not convinced that we should treat GL and GLES with a
> >> single 'DISTRO_FEATURE' since they aren't 'equivalent' features. I
> >> understand we need a mechanism to say if the platforms has 'graphics'
> >> support, and for some recipes 'graphics' is enough, but especially for
> >> libsdl this isn't enough since on GLES platforms we don't want
> >> --enable-video-opengl to be enabled since that is a GL feature, not
> >> GLES.
> >
> > I don't think anyone thinks that the current opengl feature is
> > sufficient but there hasn't been a good enough alternative just yet.
> > Are you proposing that the "opengl" distro feature is re-purposed as
> > "OpenGL", and we add "opengles" for "OpenGLES".  Does this need to be
> > GLES-version-specific, what about EGL, and what about machines which
> > can support multiple drivers/GPU hardware?
>
> well, that's more or less what I had said in that thread earlier. e.g.
> make opengl vs opengles 2 distinct "DISTRO_FEATURE". at least what's
> sure now, is that currently it is broken, libsdl is the only instance
> we have noticed the problem, there could be more, not sure.
>
> i agree that we could easily extend the number of combos... but we
> could start 'small' and add new 'feature' whenever needed. the problem
> is probably even more subtle... right now opengl is a DISTRO_FEATURE
> to say globally if the 'distro/stack' we build has some sort of
> graphics.. if we start getting into EGL, GLX, and GL/GLES versions
> then we start going into machine features.
>
> a quick grep (in the layers i use) reveals that the situation isn't
> really too good ;-)
>
> -- meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:
> PACKAGECONFIG
> ??= "${@base_contains('DISTRO_FEATURES', 'opengl', 'opengl',
> 'openglesv2', d)}"
> -- meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:
>    ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-gl',
> '--enable-gles', d)} \
>
> here, we use opengl distro feature to switch between GL and GLES
>
> -- meta-qt5/recipes-qt/qt5/qtbase.inc:PACKAGECONFIG_GL ?=
> "${@base_contains('DISTRO_FEATURES', 'opengl', 'gl', '', d)}"
>
> here, opengl is used to enable GL , nothing about GLES. in our layer,
> we have added a .bbapend with this to get Qt to work:
>
> # By default, qtbase.inc PACKAGECONFIG_GL is either "gl" (if
> DISTRO_FEATURES
> # includes "opengl") or empty (if it doesn't). Over-ride and force to
> "gles2".
> PACKAGECONFIG_GL = "gles2"
>
> -- openembedded-core/meta/conf/machine/include/ia32-base.inc:
>  ${@base_contains('DISTRO_FEATURES', 'opengl',
> 'xserver-xorg-extension-glx', '', d)} \
>
> here, used to enable GLX
>
> -- openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb:
>        ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
> '', d)} \
> -- openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb:
>             ${@base_contains('DISTRO_FEATURES', 'opengl',
> '--enable-video-opengl', '--disable-video-opengl', d)} \
>
> here to enable GL features, incompatible with GLES.
>
> -- openembedded-core/meta/recipes-graphics/wayland/weston_1.1.0.bb:
>                ${@base_contains('DISTRO_FEATURES', 'opengles2',
> 'gles', '', d)} \
>
> here, we have an instance of opengles2, which we discussed already.
> that's the only place where we have that, and you agreed it was a bug.
>
> --
> openembedded-core/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb:
> PACKAGECONFIG
> ??= "sna udev ${@base_contains('DISTRO_FEATURES', 'opengl', 'dri', '',
> d)}"
> --
> openembedded-core/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc:PACKAGECONFIG
> ??= "udev ${@base_contains('DISTRO_FEATURES', 'opengl', 'dri dri2
> glx', '', d)}"
>
> to enable GLX/DRI
>
> -- openembedded-core/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb:DEPENDS
> += " ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
> '', d)}"
>
> another instance, like libsdl which would break on GLES only platform.
>
> -- openembedded-core/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb:
>            ${@base_contains('DISTRO_FEATURES', 'opengl',
> '--enable-webgl', '--disable-webgl', d)} \
>
> here to enable WebGL
>
> So i think given these examples, it's difficult to 'define' what
> opengl DISTRO_FEATURE means. it is used for many different things, so
> maybe this isn't the 'right level of abstraction'. what do you think?
>
>
> ps: sorry, i have the feeling that gmail is going to mess up very
> badly with the formatting of this email...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20131023/02e3cdd8/attachment-0002.html>