[OE-core] any subtle reason for using "BPN" with ALLOW_EMPTY instead of just "PN"?

Robert P. J. Day rpjday at crashcourse.ca
Fri Jun 29 17:08:10 UTC 2012


  in current poky ref manual, the explanation of ALLOW_EMPTY talks
about using it with a package name, as in:

  ALLOW_EMPTY_${PN} = "1"

which makes perfect sense, except that there is the occasional example
where something other than "PN" is used, sometimes for good reason,
sometimes not clear.

  for instance, there's this:

meta/recipes-qt/qt4/qt4.inc:ALLOW_EMPTY_${PN} = "1"
meta/recipes-qt/qt4/qt4.inc:ALLOW_EMPTY_${QT_BASE_NAME}-fonts = "1"

which makes sense (i guess) since, in this case, PN=qt4-x11-free,
while QT_BASE_NAME=qt4.  so there are obviously going to be special
cases like that.

  but here are a few that seem to use BPN unnecessarily:

meta/recipes-core/eglibc/eglibc-locale.inc:ALLOW_EMPTY_${BPN}-binaries = "1"
meta/recipes-core/eglibc/eglibc-locale.inc:ALLOW_EMPTY_${BPN}-charmaps = "1"
meta/recipes-core/eglibc/eglibc-locale.inc:ALLOW_EMPTY_${BPN}-gconvs = "1"
meta/recipes-core/eglibc/eglibc-locale.inc:ALLOW_EMPTY_${BPN}-localedatas = "1"
meta/recipes-graphics/pango/pango.inc:ALLOW_EMPTY_${BPN}-modules = "1"

it seems that, with the above packages, PN = BPN so, yes, either one
would have worked, but is there a best practice?  i would think that
using anything other than PN should be reserved for when it's
necessary, so that it's more aesthetically obvious that something
different is happening.

  thoughts?  yes, i know it makes no functional difference.  again,
i'm just trying to codify best practices.

rday

-- 

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

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




More information about the Openembedded-core mailing list