[OE-core] [RFC] OpenGL packaging/staging policy
Tomas Frydrych
tf+lists.yocto at r-finger.com
Mon Oct 29 18:27:44 UTC 2012
On 29/10/12 17:26, Burton, Ross wrote:
> Rule 1. Unambiguous package naming
>
> I won't repeat this, everyone agreed this was sane. I've a patch for
> mesa that I'll submit shortly.
>
> Rule 2. No whitelisting for GL driver conflicts
>
> The target GL shall be staged, and situations which result in multiple
> GLs being installed should handle this case and resolve it.
>
> For atom-pc this means building Mesa. For Beagle this means staging
> the Beagle binary drivers. For Tegra as I've discovered this is
> "interesting" as they don't appear to provide any headers in their
> Tegra For Linux tarball...
>
> For Cedar Trail and EMGD, the easiest solution is a dedicated Mesa
> building just GL. As Mesa's DRI driver API isn't stable this is
> practically required anyway: the ABI of the libGL we build and the
> libGL that the binary driver was built against need to match. This
> mesa-just-gl (mesa-solo?) can be in meta-intel unless other machines
> turn out to have a similar (crazy) requirement.
>
> Rule 3. No dependencies on specific GL implementations
>
> Useful so that GL implementations are swappable on systems where that
> can happen, but not essential if there isn't a single blessed GL for
> sysroot. We'll do this later.
>
> Some things that will also happen whilst I do this:
> 1) mesa-dri renamed to mesa. Let's get this done nice and early!
> 2) mesa stops architecture-overriding enabling of EGL and GLES, so all
> architectures that build Mesa get GL/EGL/GLESv1/GLESv2. If you don't
> want this don't build Mesa, and the namespaced packaging means there
> won't be conflicts.
>
> Any more comments?
FWIW, I am happy with this proposal :)
Tomas
More information about the Openembedded-core
mailing list