Re: What are _virtual providers? and other Suffixes?

[Paul Eggleton <paul.eggleton@linux.intel.com>]

Hi Brad,

On Monday 19 August 2013 22:51:04 Brad Litterell wrote:
> I searched the Yocto Mega Manual, but am still somewhat mystified by the
> suffix formatting of various variable - especially virtual ones like this:
> 
> 
> PREFERRED_PROVIDER_virtual/gettext = "gettext"
> 
> PREFERRED_PROVIDER_virtual/kernel_am335x-evm = "linux-ti-staging"
> 
> PREFERRED_PROVIDER_virtual/bootloader_am335x-evm = "u-boot-ti-staging"

These are setting PREFERRED_PROVIDER for a number of targets. "virtual/xyz" is
a convention we use where there are multiple providers for a particular
component, so a recipe that requires that component can have virtual/xyz in
its DEPENDS, each provider declares virtual/xyz in its PROVIDES, and then in
configuration the desired recipe to provide that can be selected via 
PREFERRED_PROVIDER_virtual/xyz = "...".

The second two examples have an additional override which makes them only
applicable for a specific machine (am335x-evm). If you want to know how this
mechanism works have a look at this:

http://docs.openembedded.org/bitbake/html/ch02.html#id439023

(We're in the process of updating the BitBake manual, so this old version will have to suffice.)

> Also, there seems to be some sort of prioritization going on with the
> multiple levels underscore characters in places like this:
> 
> 
> # Set the PREFERRED_PROVIDER for jpeg functionality based on the MACHINE
> 
> # architecture.  For armv7a devices libjpeg-turbo should be used to take
> 
> # advantage of the SIMD instructions.
> 
> PREFERRED_PROVIDER_jpeg = "libjpeg-turbo"
> 
> PREFERRED_PROVIDER_jpeg_armv5te = "jpeg"
> 
> 
> (all examples from the arago project in arago-prefs.inc)
> 
> Is there a succinct way of viewing these suffixes that will allow me to wrap
> my head around their various & myriad versions?

OVERRIDES is listed in order so that overrides for the later items are
preferred. If you run bitbake -e | less and search for OVERRIDES (with the /
key) you can see what the value is for the global environment; here is an
example for my current configuration:

# $OVERRIDES [3 operations]
#   set conf/bitbake.conf:670
#     "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
#   set conf/bitbake.conf:671
#     [vardepsexclude] "MACHINEOVERRIDES"
#   postdot /home/paul/poky/poky/meta/conf/distro/include/tclibc-eglibc.inc:9
#     "${LIBCOVERRIDE}"
# computed:
#   "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable${LIBCOVERRIDE}"
OVERRIDES="linux:i586:build-linux:pn-bblayers:x86:qemuall:qemux86:poky:class-target:forcevariable:libc-glibc"

Putting the values of all these variables into OVERRIDES gives us a way of
setting variable values per-machine, per-architecture etc. Based on the
above value, if I had:

SOMEVAR = "value1"
SOMEVAR_qemux86 = "anothervalue"
SOMEVAR_i586 = "yetanothervalue"

The computed value of SOMEVAR would be "anothervalue". If MACHINE were
changed to, say, "qemumips", then OVERRIDES would change and the value 
of SOMEVAR would become "value1".

> Am I right in assuming the "variable name" consists of the uppercase parse
> (regardless of number of underscores)?

That is our (fairly strict) convention in OpenEmbedded, but FWIW I don't
think bitbake itself enforces that; it's all dependent on what is in OVERRIDES
and where the _ character appears in the left hand side of the assignment
statement.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre