From: Tomas Frydrych <tf+lists.yocto@r-finger.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [RFC] OpenGL packaging/staging policy
Date: Mon, 22 Oct 2012 18:19:06 +0100 [thread overview]
Message-ID: <5085800A.4060600@r-finger.com> (raw)
In-Reply-To: <CAJTo0LboPRF7Oxnwh8QS6b6ReS-1-P+=r04L54QRptPnHfV5oQ@mail.gmail.com>
Hi Ross,
On 22/10/12 17:35, Burton, Ross wrote:
> Rule 3. Only Mesa stages, nothing else
I think it is a big mistake to special case mesa as anything other than
*a* GL provider. GL stacks provide their own headers, these headers
might not be identical to the mesa headers, and people writing GL
software for the particular target have every right to expect to be
using the headers provided with their GL stack -- sooner or later this
rule will have to be broken because of customer software not buildable
under Yocto. (Whether the headers should be identical is neither here
nor there; Yocto needs to work in the real world, and you well know that
in the real world this is not the case.)
I know some folk don't like to hear this, but whether you like it or
not, GL libs are tied to specific HW, i.e., are machine-specific. Our
current difficulties stem directly from trying to pretend this is not
the case, or that mesa is somehow more than just *a* GL provider. IMHO
the correct thing to do here is:
a) Make the mesa packages machine specific so we can control compatible
machines and preferred providers to match the HW realities,
b) Split the ginormous mesa recipe, so that it is, for example, possible
to stage mesa gl without mesa egl, so that we can accommodate HW that
wants to use bits of mesa.
Tomas
next prev parent reply other threads:[~2012-10-22 17:32 UTC|newest]
Thread overview: 18+ 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 [this message]
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
2012-10-23 9:49 ` Tomas Frydrych
2012-10-29 17:26 ` Burton, Ross
2012-10-29 18:27 ` Tomas Frydrych
2012-11-20 16:52 ` 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 19:25 ` 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=5085800A.4060600@r-finger.com \
--to=tf+lists.yocto@r-finger.com \
--cc=openembedded-core@lists.openembedded.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox