All of lore.kernel.org
 help / color / mirror / Atom feed
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.
>


  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.