Re: OpenGL as a DISTRO_FEATURE

[Tomas Frydrych <tf+lists.yocto@r-finger.com>]

Hi Ross,

On 03/02/13 23:35, Ross Burton wrote:
> On Sunday, 3 February 2013 at 21:33, Marcin Juszkiewicz wrote:
>> As they are different architectures you can try this:
>> 
>> DISTRO_FEATURES_wm8950 = "here copy your default DISTRO_FEATURES 
>> but skip opengl"
>> 
>> Replace wm8950 with MACHINE name. Ugly solution but should work.
> That means that Qt won't be built with GLES support.
> 
> The best approach is to probe the hardware/libraries at runtime and 
> adapt - i.e. if only GLES libraries are available use those, but a 
> lot of software doesn't support that or simple probing isn't 
> sufficient (Intel Pine Trail supports both but GL is best, Cedar 
> Trail supports both but GL is terrible).

Run-time probing is not a solution at all, because (a) we are not
talking about how to write portable GL applications, but primarily how
to package software already written by other people, and (b) with the
current OE set up run-time probing cannot work anyway (and does not,
e.g. cogl), because with two 'GL' providers there is no guarantee that
the optimal one (i.e., not the mesa software GL rasterizer), gets used.

The above scenario where someone wants to maintain a distro with
multiple target architectures is the normal thing to ask for with OE.
The fact that current OE cannot support it cleanly, and it has to be
worked around on distro level (whether by bbappends that make the GL
components machine-specific as they should be, or hacks like
DISTRO_FEATURES_my-random-machine), demonstrates that we are not doing
it right at the moment.


> It's not as simple as it appears and causes a rather large number of 
> packages to become machine-specific.

From actual experience I think this is well overstated; I dare you to
support this by real numbers :-)

Tomas

--
http://sleepfive.com