Re: What are _virtual providers? and other Suffixes?

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

On Tuesday 20 August 2013 23:16:56 Brad Litterell wrote:
> Thanks for taking the time to explain, very enlightening.  I think I
> understood it, please allow me to play back my understanding:
> 
> 1.  _virtual is part of the variable name, and is not a special type of
> override. 

Actually, virtual/kernel is an override as well. The way a few variables, 
including PREFERRED_PROVIDER, are used is that OVERRIDES is set to include the 
item being dealt with when the variable is read, thus specifically with 
PREFERRED_PROVIDER you always override it with the name of the target you wish 
to select the provider for.

> 2.  PREFERRED_PROVIDER_virtual/kernel_am335x-evm breaks into:
> "PREFERRED_PROVIDER_virtual/kernel" with an override condition of 
> "am335x-evm"

Outside of the part of the code where it's actually read, yes. Within that 
code the override "virtual/kernel" will be applied when it's looking to see 
what the provider for "virtual/kernel" should be, and thus it will get the 
appropriate value for the PREFERRED_PROVIDER variable. So technically the 
variable is just PREFERRED_PROVIDER.

> 3. So for the jpeg case:
> >> PREFERRED_PROVIDER_jpeg = "libjpeg-turbo"
> >> 
> >> PREFERRED_PROVIDER_jpeg_armv5te = "jpeg"
> 
> Could this have also been _virtual/jpeg?  It's just that some components use
> the _virtual convention and others don't?

The prefix is virtual/ not _virtual, and as I mentioned earlier virtual/ is 
just a convention (although there are a few isolated parts of the code that 
specifically look for the virtual/ prefix). The mechanism will work in the same 
way here; recipes that need jpeg decoding have "jpeg" in DEPENDS and providing 
libjpeg-turbo has jpeg in its PROVIDES, which it does, we can select between 
two different recipes providing that - jpeg and libjpeg-turbo (where the latter 
is provided at all of course, i.e. when you have the meta-oe layer in your 
configuration). 

I don't think there's any special reason we don't have virtual/jpeg rather 
than jpeg here other than that having multiple jpeg decoding libraries is a 
relatively new situation compared to others such as virtual/kernel, and there 
are already a bunch of recipes out there referring to "jpeg" in their DEPENDS. 
(One wonders why there is a need for multiple jpeg decoding libraries in the 
first place, but that's a different can of worms...)
 
Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre