All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: curious about why bitbake.conf setting of FILES_${PN}-bin
Date: Tue, 15 Jul 2014 09:24:15 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.11.1407150923000.13777@localhost> (raw)


  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?

  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?)

  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?

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.

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================




             reply	other threads:[~2014-07-15 13:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-15 13:24 Robert P. J. Day [this message]
2014-07-15 15:23 ` curious about why bitbake.conf setting of FILES_${PN}-bin Saul Wold
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=alpine.LFD.2.11.1407150923000.13777@localhost \
    --to=rpjday@crashcourse.ca \
    --cc=openembedded-core@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 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.