Yes, you've got it, when using override specific versions of variables, that's exactly right.
-- Chris Larson On Jan 16, 2010, at 8:47 AM, "Robert P. J. Day" <[email protected]> wrote: > On Sat, 16 Jan 2010, Christopher Larson wrote: > >> The most specific overrides the least specific. Machine wins over >> target arch, local wins over all. In the code, the overrides are >> collapsed in the order of the overrides variable, left to right, so >> the last will win. >> >> -- Chris Larson >> >> On Jan 16, 2010, at 6:01 AM, "Robert P. J. Day" <[email protected] >> > wrote: >> >>> >>> from the manual: >>> >>> OVERRIDES is a “:” separated variable containing each item you w >>> ant to >>> satisfy conditions. So, if you have a variable which is >>> conditional on >>> “arm”, and “arm” is in OVERRIDES, then the “arm” >>> specific version of >>> the variable is used rather than the non-conditional version. >>> Example: >>> >>> OVERRIDES = "architecture:os:machine" >>> TEST = "defaultvalue" >>> TEST_os = "osspecificvalue" >>> TEST_condnotinoverrides = "othercondvalue" >>> >>> In this example, TEST would be osspecificvalue, due to the >>> condition “os” being in OVERRIDES. >>> >>> and what *would* happen if that second conditional variable was >>> also in OVERRIDES? would it override the first one? that should >>> be clarified here. > > ah, so the order of *assignments* isn't important, it's the order of > the variables within the OVERRIDES string? so, using the above > example, if i had: > > TEST = "default" > TEST_machine = "machine" > TEST_os = "os" > > the final value of TEST would be "machine" since it appears in the > OVERRIDES string furthest to the right, is that it? even though "os" > was assigned last. > > rday > -- > > === > ===================================================================== > Robert P. J. Day Waterloo, Ontario, > CANADA > > Linux Consulting, Training and Kernel Pedantry. > > Web page: http://crashcourse.ca > Twitter: http://twitter.com/rpjday > === > ===================================================================== _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
