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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core