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

[Nicolas Dechesne]

On Mon, Sep 9, 2013 at 3:17 PM, Burton, Ross <ross.burton at intel.com> 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.
>

well, if opengl means gl or gles, then doing something like this should be
considered wrong (bug):

> ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
> '--disable-video-opengl', d)} \

since here it's clear that opengl means gl, not gles. it clearly breaks on
machine where opengl means gles and no gl support is available (here i am
considering pulling mesa as a bug, since we probably don't want it on
embedded devices).


>
> > 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.


well, i am not quite convinced that GL/GLX vs GLes/EGL really is machine
specific. It might have been the case before, but more and more i think
this is becoming a 'distro' (or stack, or product?) preference. things like
Qt5 or wayland now enforce the need for gles, so to me this is no longer
machine dependent. Without GLES on your machine you can't run them anymore.



>  We may need some
> machine-level hints as to the GL feature set available for recipes
> that don't probe at runtime.


yes, i agree. we need to know what machines can do GL, GLX, EGL, GLES, and
what distro 'need/expect' and combine the 2 sets (and use mesa as fallback
when needed, or even we should be able to prohibit mesa too). we could get
such thing using opengl and opengles flags in DISTRO_ and
MACHINES_FEATURES.. but it's not quite nice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130909/e5fe0197/attachment-0002.html>