From: Saul Wold <sgw@linux.intel.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] evince: who is responsible to pack all within usr/lib/evince/3/backends to ${PN}?
Date: Fri, 27 Jan 2012 07:22:10 -0800 [thread overview]
Message-ID: <4F22C122.9030206@linux.intel.com> (raw)
In-Reply-To: <CALbNGRTqHJYvSzbman=ZPQ4D=Cyu8oX0F4JdTA7hrH4oMW_wbA@mail.gmail.com>
On 01/27/2012 04:48 AM, Andreas Müller wrote:
> On Fri, Jan 27, 2012 at 9:43 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Fri, Jan 27, 2012 at 2:28 AM, Saul Wold<sgw@linux.intel.com> wrote:
>>> On 01/26/2012 05:16 PM, Andreas Müller wrote:
>>>>
>>>> I checked: the complete contents of /usr/lib/evince/3/backends go to
>>>> evince package and I would like to move *.a to ${PN}-staticdev and
>>>> *.la to ${PN}-dev but I don't understand: who is responsible for
>>>> adding all this to ${PN}?
>>>>
>>> bitbake.conf defines where most files should go, but when you get files in
>>> sub-directories, such as /usr/lib/evince/..., then the recipe needs to do a
>>> little more work. If you look at the evince_2.32.0.bb, there already is a
>>> FILES_${PN}-staticdev that adds some extensions, you need to add this set of
>>> backends to that list, probably same with the .la to the -dev package.
>>>
>> Why I asked this: Maybe there is a chance to fix this more globally
>> instead of one by one in each recipe. But therefore I need to know
>> where the path is packed.
>>
> I looked around for this a bit: As Saul pointed out, in bitbake.conf we have
> FILES_${PN} = ... ${libdir}/${BPN}/* ...
>
> This
> * drags in all below this directory ( e.g *.la / *.a )
> * Forces me to rewrite FILES_${PN} in evince ( e.g just adding
> ${libdir}/${BPN}/*/backends/*.a to FILES_${PN}-staticdev fixes nothing
> ). This is something I would like to avoid.
>
> Suggestions?
>
> I guess others but evince are also affected.
>
Actually the ordering of PACKAGES matters here and since bitbake.conf
lists the ${PN}-dev and ${PN}-staticdev package before ${PN}, you can
append the ${libdir}/${BPN}/3/backends/*.a to FILES_${PN}-staticdev and
it will pull those first before doing the FILES_${PN}. does that make
sense? You don't have to re-write FILES_${PN}.
Sau!
> Andreas
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
next prev parent reply other threads:[~2012-01-27 15:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CALbNGRS-WsE45UakTV5VE2T5bAxb1C2iWgPeN+Ys+OTx-i48Rw@mail.gmail.com>
[not found] ` <4F21FDA2.5070803@linux.intel.com>
[not found] ` <CALbNGRQ0+FDE7QisckBOCXBUspQiumZFLjPJYgRf87a1mqtHaw@mail.gmail.com>
2012-01-27 12:48 ` [oe] evince: who is responsible to pack all within usr/lib/evince/3/backends to ${PN}? Andreas Müller
2012-01-27 15:22 ` Saul Wold [this message]
2012-01-27 23:16 ` Andreas Müller
2012-01-27 23:29 ` Andreas Müller
2012-01-28 15:03 ` Paul Eggleton
2012-01-28 22:46 ` Andreas Müller
2012-01-29 0:08 ` Andreas Müller
2012-01-30 23:45 ` Saul Wold
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=4F22C122.9030206@linux.intel.com \
--to=sgw@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=openembedded-devel@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