From: Tomas Frydrych <tf+lists.yocto@r-finger.com>
To: yocto@yoctoproject.org
Subject: Re: opengl / libgl / libgles
Date: Thu, 06 Sep 2012 11:19:14 +0100 [thread overview]
Message-ID: <504878A2.2090507@r-finger.com> (raw)
In-Reply-To: <CAK18fxEb3gjEEwhvN-du3eJvgUVCbjXU2Ag4kicFFDt6xra6og@mail.gmail.com>
On 06/09/12 11:00, Andrei Gherzan wrote:
> Hello,
>
> In DISTRO_FEATURES we have opengl. That is pretty vague and generally we
> don't want to have mesa on machines where there is no libgl but only gles +
> egl. For example if we want to compile something that adds a DEPENDS based
> on DISTRO_FEATURE opengl, this dependency will be added even if there is no
> libgl implemented for that specific machine.
>
> First idea would be that opengl (gl / gles) are machine related. On the
> other hand opengl can be a DISTRO_FEATURE as we have a software
> implementation - mesa.
>
> How would you guys see a solution for this? The idea that came into my mind
> was to map opengl to libgl or libgles. Or to both if there is the case.
I think we need both machine and distro features matching the options
here: opengl, gles1, gles2. The machine conf sets the MACHINE_FEATURE
appropriately, the distro conf then sets the distro features based on
intersection of distro policy and what is available on the machine.
Recipes like the xserver use DISTRO_FEATURE to determine how to
configure the package.
Tomas
next prev parent reply other threads:[~2012-09-06 10:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-06 10:00 opengl / libgl / libgles Andrei Gherzan
2012-09-06 10:19 ` Tomas Frydrych [this message]
2012-09-06 13:04 ` [yocto] " Burton, Ross
2012-09-06 13:04 ` Burton, Ross
2012-09-06 13:25 ` [yocto] " Koen Kooi
2012-09-06 13:51 ` Burton, Ross
2012-09-06 14:37 ` Tomas Frydrych
2012-09-06 14:50 ` Koen Kooi
2012-09-06 16:10 ` Tomas Frydrych
2012-09-06 16:36 ` Koen Kooi
2012-09-06 14:50 ` Burton, Ross
2012-09-06 15:55 ` Richard Purdie
2012-09-19 11:14 ` Andrei Gherzan
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=504878A2.2090507@r-finger.com \
--to=tf+lists.yocto@r-finger.com \
--cc=yocto@yoctoproject.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 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.