From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Burton, Ross" <ross.burton@intel.com>
Cc: Koen Kooi <koen@dominion.thruhere.net>,
OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [yocto] opengl / libgl / libgles
Date: Thu, 06 Sep 2012 16:55:56 +0100 [thread overview]
Message-ID: <1346946956.7493.13.camel@ted> (raw)
In-Reply-To: <CAJTo0La9-QHoWJB2v82C2tiM2XFwgHzsP1zda+Duqe_3uTwByw@mail.gmail.com>
On Thu, 2012-09-06 at 14:51 +0100, Burton, Ross wrote:
> On 6 September 2012 14:25, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > It's not automatic, but you can do something like this:
> >
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=23b02134
> >
> > That recipe ships multiple copies of the libraries to account for different silicon revisions (the shader compiler will offload different things to the CPU), but we don't want the shlibs code to pickup the copies. So for mesa you can do:
> >
> > PRIVATE_LIBS_${PN}-dri = "libGL.so"
> > RPROVIDES_${PN}-dri = $magic_python_function(PACKAGE_CONFIG, sometthing, something, libgl)
> >
> > And in the recipes that link to a GL lib you do:
> >
> > RDEPENDS_${PN} = "libGL"
>
> Ah, interesting. I'm not entirely keen on the manual dependencies but
> that's certainly a step in the right direction.
>
> If automatic replacement dependencies were added to bitbake, how would
> you implement them? In Debian, libgl1-mesa installs a
> libgl1-mesa-glx.shlibs file with this contents:
>
> libGL 1 libgl1-mesa-glx | libgl1
>
> "when linking to libGL.so, use the dependency 'libgl1-mesa-glx |
> libg1". All packages which contain libgl.so.1 have Provides: libgl1,
> so they are interchangable.
>
> Some way of expressing that in the bitbake recipe would be great.
Note that this needs to be expressed at the core level, not recipe level
since it needs to be injected into several places and we don't want to
teach each one this. At best each would have to inherit
opengllib.bbclass.
We might just want to add a table of these and have package.bbclass add
dependencies using the table?
Yes, its suboptimal and not pretty but it would probably be very
effective.
Cheers,
Richard
next prev parent reply other threads:[~2012-09-06 16:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAK18fxEb3gjEEwhvN-du3eJvgUVCbjXU2Ag4kicFFDt6xra6og@mail.gmail.com>
2012-09-06 13:04 ` [yocto] opengl / libgl / libgles Burton, Ross
2012-09-06 13:25 ` 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 [this message]
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=1346946956.7493.13.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=koen@dominion.thruhere.net \
--cc=openembedded-core@lists.openembedded.org \
--cc=ross.burton@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox