On Sun, Jun 22, 2014 at 6:20 AM, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> as i said, it took me a few minutes to figure out what the > conditional metadata example above was trying to demonstrate, but as > soon as i saw a real example in the codebase, it was perfectly clear. > to this end, i'm creating wiki pages that show stuff like that > exactly, like this one for conditional overrides: > It's not directly related, but here's some background if it helps anyone at all. Conceptually, when we designed overrides, it was created to let us implement layering of metadata (note: not layers as in yocto layers, but conceptual layers), to let us always let more specific information be used in preference to less specific information. Machine information will be used in preference to Architecture which is used in preference to the default. This lets us ensure that we're always using the most accurate information available about the configuration in question. I've always thought that thinking of it this way helps one see the purpose behind the mechanism (and you can see that the order of the includes/requires in bitbake.conf essentially implements the same ordering where possible, to provide the same capability based on load order of the config files). I'm not sure if any of our docs talk about it this way, and I'm not sure if it helps anyone else wrap their heads around it, but I'm throwing it out there since I've found that some folks seem to find it a useful way of looking at it. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
