From: Daniel Stone <daniel@fooishbar.org>
To: Tomas Frydrych <tf+lists.yocto@r-finger.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [RFC] OpenGL packaging/staging policy
Date: Tue, 23 Oct 2012 20:18:31 +1100 [thread overview]
Message-ID: <CAPj87rOZokkPT_a7kbaqmai2bWwV5xLL8oV2UNOfoxkARHfwCg@mail.gmail.com> (raw)
In-Reply-To: <50865733.40007@r-finger.com>
Hi,
On 23 October 2012 19:37, Tomas Frydrych <tf+lists.yocto@r-finger.com> wrote:
> On 23/10/12 03:06, Daniel Stone wrote:
>> You can separate GLU, which we've already done. I think you can
>> split out the core of libgbm, but not the DRI plugin. And that's
>> about it.
>
> I am well aware that GL stacks are closely tied together, and personally
> would not advise anyone to mix and match. But please reread the original
> email Ross sent explaining the Cedar Trail 'complex' situation. If Intel
> want to use mesa GL and their PVR GLES1/2 / EGL binary bits together ...
That'll break catastrophically for anyone using GL + EGL, but eh, if
they're insane enough to support it, and you're insane enough to
explicitly allow for it as a supported configuration ...
> Regardless what is done with the packaging, allowing only mesa to stage
> dev files will break things. GL headers are not interchangeable, even if
> all the implementers are well behaved (which is a big if), the
> *platform.h files are allowed to be implementation specific and so have
> to be staged by the actual platform GL stack.
Right, I do agree with you, but in the mixed-stack situation, which
headers are we building against? :)
Cheers,
Daniel
next prev parent reply other threads:[~2012-10-23 9:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 16:35 [RFC] OpenGL packaging/staging policy Burton, Ross
2012-10-22 17:19 ` Tomas Frydrych
2012-10-22 19:27 ` Burton, Ross
2012-10-22 20:25 ` Tomas Frydrych
2012-10-23 2:06 ` Daniel Stone
2012-10-23 8:37 ` Tomas Frydrych
2012-10-23 9:18 ` Daniel Stone [this message]
2012-10-23 9:49 ` Tomas Frydrych
2012-10-29 17:26 ` Burton, Ross
2012-10-29 17:26 ` [OE-core] " Burton, Ross
2012-10-29 18:27 ` Tomas Frydrych
2012-11-20 16:52 ` Burton, Ross
2012-11-20 16:52 ` [OE-core] " Burton, Ross
2012-10-22 17:32 ` [oe] " Phil Blundell
2012-10-22 17:38 ` Otavio Salvador
2012-10-22 19:26 ` Burton, Ross
2012-10-22 17:33 ` Otavio Salvador
2012-10-22 17:33 ` [OE-core] " Otavio Salvador
2012-10-22 19:25 ` Phil Blundell
2012-10-22 19:25 ` [OE-core] " Phil Blundell
2012-10-22 17:37 ` Mark Hatle
2012-10-22 19:29 ` Burton, Ross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPj87rOZokkPT_a7kbaqmai2bWwV5xLL8oV2UNOfoxkARHfwCg@mail.gmail.com \
--to=daniel@fooishbar.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=tf+lists.yocto@r-finger.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.