[yocto] What are _virtual providers? and other Suffixes?

[Brad Litterell]

Hi Paul,

Thanks - that makes it clearer.  But now I have one other question to ask:

if  virtual/xyz is added to overrides when the item is dealt with, then in that case P_P_virtual/xyz_am335 has two overrides hanging off of the base variable PREFERRED_PROVIDER.

You also said earlier that the latest override applies, so is there some rule for multiple conditionals on a variable?

E.g. What happens in a case like the following?

OVERRIDES="foo1:bar2:car3"

VARIABLE_foo1_bar2 = "both"
VARIABLE_car3 = "last one"

what does VARIABLE wind up?  The first is "more specific" in that it matches two values in overrides, whereas car is last, but less specific.

Thanks & sorry if I'm missing something simple.

Brad



On Aug 20, 2013, at 4:33 PM, Paul Eggleton <paul.eggleton at linux.intel.com>
 wrote:

> 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