[OE-core] [oe] [RFC] OpenGL packaging/staging policy

[Burton, Ross]

On 22 October 2012 18:32, Phil Blundell <philb at gnu.org> wrote:
> Different GL libraries will have different vendor extensions and Mesa's
> headers won't necessarily know about them.  If the vendor ships the
> extension bits in a custom header (rather than jamming them into a
> modified glext.h) then this could be worked around by staging the
> headers separately, but you're still left with the problem that Mesa's
> libGL.so might now be missing symbols that are required during
> linking.

This was a concern, and this is a RFC for a reason.

In my (admittedly limited) experience, it's fairly common for
applications to treat vendor's GL headers are references and
copy/paste the bits they want for this exact reason.  Imaging a game
engine that wants to use a nVidia extension *and* and ATI extension
(depending on the runtime environment) that isn't yet in the standard
GL headers - it can't be expected to compile against both GL
implementations.

If there's a clear popular example of an application that insists to
be built against a specific vendor's GL and that behaviour can't be
described as broken (and fixed with a few lines of patch), then this
is a solid counter-argument.

Ross