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

Burton, Ross ross.burton at intel.com
Mon Sep 9 13:17:57 UTC 2013


On 9 September 2013 13:40, Nicolas Dechesne <nicolas.dechesne at linaro.org> wrote:
> how about gl vs gles?

The problem of any patch that touches the opengl distro feature is
that it causes this discussion, because the semantics of it are rather
vague to say the least!

> i have been trying to understand over the last couple of days whether or not
> 'opengl' in DISTRO_FEATURES means OpenGL and OpenGLES. I don't think it's
> clearly indicated anywhere.

My personal opinion is it means "enable support for the OpenGL
collection of APIs, include OpenGL, GLES and/or EGL".  Last year there
was a patch series from the early Wayland enabling that added machine
features for each form of GL, but that wasn't finished or merged (not
entirely required).

> in libsdl recipe, we have this:
>
> DEPENDS = "${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '',
> d)} \
>            ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
> '', d)} \
>
> and in EXTRA_OECONF we add this:
> ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
> '--disable-video-opengl', d)} \
>
> which tends to make me think that 'opengl' means 'OpenGL', not OpenGLES. I
> am building for ARM platforms with GLes support, but no GL support. I
> initially had 'opengl' in DISTRO_FEATURES, but we ended with mesa being
> pulled in because of libsdl, which was wrong. So we now removed 'opengl'
> from our DISTRO_FEATURES list. (note we have our own EGL/GLes library for
> GPU, so we don't want mesa at all).

OpenGL-wrangling aside, that's a pretty good example of where
PACKAGECONFIG should be used so your configuration can easily tweak
SDL without changing distro features.

> In weston recipe, we have this:
> ${@base_contains('DISTRO_FEATURES', 'opengles2', 'gles', '', d)}
>
> so, that seems to imply that opengles2 is now a 'new' DISTRO_FEATURES, but
> it's only used once (looking at oe-core and meta-oe).

Not sure what I was thinking there, potentially a bad search and
replace.  As you say its the only instance of that feature.  Patch
incoming to fix that.

I'm happy for DISTRO_FEATURES to be vague and just mean the GL
collection instead of specific implementations, because OpenGL/GLX vs
GLESv2/EGL etc is a machine-specific feature and encoding that into
DISTRO_FEATURES would mean changing the distro features when the
machine changes, which is obviously wrong.  We may need some
machine-level hints as to the GL feature set available for recipes
that don't probe at runtime.

Ross



More information about the Openembedded-core mailing list