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
