<div dir="ltr">O conclusion on this topic would be great. There are a lot of people waiting for a fix on this topic.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 5, 2013 at 10:58 PM, Tomas Frydrych <span dir="ltr"><<a href="mailto:tf+lists.yocto@r-finger.com" target="_blank">tf+lists.yocto@r-finger.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ross,<br>
<div class="im"><br>
On 03/02/13 23:35, Ross Burton wrote:<br>
> On Sunday, 3 February 2013 at 21:33, Marcin Juszkiewicz wrote:<br>
>> As they are different architectures you can try this:<br>
>><br>
>> DISTRO_FEATURES_wm8950 = "here copy your default DISTRO_FEATURES<br>
>> but skip opengl"<br>
>><br>
>> Replace wm8950 with MACHINE name. Ugly solution but should work.<br>
> That means that Qt won't be built with GLES support.<br>
><br>
> The best approach is to probe the hardware/libraries at runtime and<br>
> adapt - i.e. if only GLES libraries are available use those, but a<br>
> lot of software doesn't support that or simple probing isn't<br>
> sufficient (Intel Pine Trail supports both but GL is best, Cedar<br>
> Trail supports both but GL is terrible).<br>
<br>
</div>Run-time probing is not a solution at all, because (a) we are not<br>
talking about how to write portable GL applications, but primarily how<br>
to package software already written by other people, and (b) with the<br>
current OE set up run-time probing cannot work anyway (and does not,<br>
e.g. cogl), because with two 'GL' providers there is no guarantee that<br>
the optimal one (i.e., not the mesa software GL rasterizer), gets used.<br>
<br>
The above scenario where someone wants to maintain a distro with<br>
multiple target architectures is the normal thing to ask for with OE.<br>
The fact that current OE cannot support it cleanly, and it has to be<br>
worked around on distro level (whether by bbappends that make the GL<br>
components machine-specific as they should be, or hacks like<br>
DISTRO_FEATURES_my-random-machine), demonstrates that we are not doing<br>
it right at the moment.<br>
<div class="im"><br>
<br>
> It's not as simple as it appears and causes a rather large number of<br>
> packages to become machine-specific.<br>
<br>
</div>From actual experience I think this is well overstated; I dare you to<br>
support this by real numbers :-)<br>
<br>
Tomas<br>
<br>
--<br>
<a href="http://sleepfive.com" target="_blank">http://sleepfive.com</a><br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core" target="_blank">http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div style="text-align:center"></div><div style="text-align:center"><div align="left" style="font-family:'Times New Roman';font-size:medium">
<b style="color:rgb(51,51,51);font-family:Arial;font-size:small;text-align:center">Andrei Gherzan</b><font face="Arial" color="#333333" size="-1"><br></font><font face="Arial" color="#333333" size="-1">m: +40.744.478.414 | f: +40.31.816.28.12</font><br>
</div></div></div>
</div>