From: Saul Wold <sgw@linux.intel.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>,
OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: curious about why bitbake.conf setting of FILES_${PN}-bin
Date: Tue, 15 Jul 2014 08:23:41 -0700 [thread overview]
Message-ID: <53C5477D.3030501@linux.intel.com> (raw)
In-Reply-To: <alpine.LFD.2.11.1407150923000.13777@localhost>
On 07/15/2014 06:24 AM, Robert P. J. Day wrote:
>
> currently doing a writeup on file distribution among a recipe's
> generated packages, and noticed the following. here's a snippet from
> OE's bitbake.conf:
>
>
> PACKAGE_BEFORE_PN ?= ""
> PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
> PACKAGES_DYNAMIC = "^${PN}-locale-.*"
> FILES = ""
>
> FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
> ${sysconfdir} ${sharedstatedir} ${localstatedir} \
> ${base_bindir}/* ${base_sbindir}/* \
> ${base_libdir}/*${SOLIBS} \
> ${base_prefix}/lib/udev/rules.d ${prefix}/lib/udev/rules.d \
> ${datadir}/${BPN} ${libdir}/${BPN}/* \
> ${datadir}/pixmaps ${datadir}/applications \
> ${datadir}/idl ${datadir}/omf ${datadir}/sounds \
> ${libdir}/bonobo/servers"
>
>
> first, to make sure i understand the above correctly, the setting of
> FILES_${PN} defines the (default) entire possible set of generated
> files that will be used to populate the packages created by a single
> recipe, correct?
>
This is correct
> also, since packages are populated in order, left to right, we'll
> see file definitions like:
>
> FILES_${PN}-dbg = ...
> FILES_${PN}-staticdev = ...
> FILES_${PN}-dev = ...
>
> where, once a file is placed in a package, even if that name occurs
> again in a later package, it will be skipped. (anyone remember which
> manual this is mentioned in?)
>
I just did a basic search and could not find any reference and I know
that PACKAGES/FILES is "greedy" meaning once a file is consumed by a
FILES entry it's not available again. Should probably be added to the
PACKAGES and / or FILES.
> however, i also see this:
>
> FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
>
> and i thought, that's weird, that particular package isn't mentioned
> anywhere in bitbake.conf, why is it being defined if it isn't used?
> ah, then i see this in lib_package.bbclass:
>
> PACKAGE_BEFORE_PN = "${PN}-bin"
>
> which clearly defines a library being packaged, but also allowing
> binary executables to be broken out separately, which is fine, but
> it's confusing why the setting of FILES_${PN}-bin is done in
> bitbake.conf, when its only application is (currently) for library
> packaging.
>
> wouldn't it make more sense to move that line so that
> lib_package.bbclass contained:
>
> FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
> PACKAGE_BEFORE_PN = "${PN}-bin"
>
> that would make lib_package.bbclass more self-contained, and stop
> bitbake.conf from setting a variable that most recipes don't care
> about. thoughts?
>
Blame me for that patch! Looking back at the commit message from about
2 years ago I think this got mid-way through a change, with the plan to
actually remove lib_package completely since all it contained was the
setting of PACKAGE_BEFORE_PN, therefore having FILES${PN}-bin. Not sure
why we did not end up completing that.
So another option is to remove the inherits and replace it with
PACKAGE_BEFORE_PNs, Which would finish off the orignal plan!
> rday
>
> p.s. this kind of goes back to the image vs core-image discussion,
> where one wonders why base classes are doing things that require
> inheriting classes to finish off for them. or something like that.
>
next prev parent reply other threads:[~2014-07-15 15:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-15 13:24 curious about why bitbake.conf setting of FILES_${PN}-bin Robert P. J. Day
2014-07-15 15:23 ` Saul Wold [this message]
2014-07-15 15:49 ` Robert P. J. Day
2014-07-15 15:51 ` Burton, Ross
2014-07-15 15:56 ` Saul Wold
2014-07-15 16:18 ` Robert P. J. Day
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=53C5477D.3030501@linux.intel.com \
--to=sgw@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=rpjday@crashcourse.ca \
/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.