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.eggle...@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 _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
