On Thu, 3 Jun 2010, Chris Larson wrote:
... snip ...
> OVERRIDES exists to facilitate conditional variable definition - I
> think is a slightly more sane way to describe it. We do it this way
> rather than via a more traditional if block because this is rather
> more declarative.
... snip ...
> OVERRIDES are processed *in order*, in such a way that the first
> overrides the last. I realize the manual likely doesn't mention it,
> but it's incredibly important. If that machine had appended, then
> their values would be "least specific" -- that is, anything sooner
> in the overrides list would override in the case when multiple
> override specific variables exist. If they'd prepended, it would
> have overridden everything else.
... snip ...
once i took a closer look, yes, it makes perfect sense, but let me
make absolutely sure i'm not misinterpreting.
in any .conf file, you can define the valid set of override
conditions, they typically (well, kind of *necessarily* to make any
sense) go from most specific to least specific, and they will apply to
*all* variables referenced. in a recipe, i might simply refer to
variable ${VAR}, completely oblivious that it's actually being
conditionally overridden by something set much earlier in the
processing somewhere in a distant file. but that should make no
difference to me -- i just use ${VAR} and let the bitbake processing
take care of the rest.
knowing that, i did a grep, figuring i'd find all sorts of funky and
novel OVERRIDES processing, but this is all i found in the entire OE
tree dev branch:
conf/bitbake.conf:OVERRIDES =
"local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
conf/machine/nslu2be.conf:OVERRIDES =
"local:${MACHINE}:nslu2:ixp4xx:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
conf/machine/nslu2le.conf:OVERRIDES =
"local:${MACHINE}:nslu2:ixp4xx:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
conf/machine/kixrp435.conf:OVERRIDES =
"local:${MACHINE}:nslu2:ixp4xx:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
conf/machine/fsg3be.conf:OVERRIDES =
"local:${MACHINE}:ixp4xxbe:ixp4xx:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
conf/distro/micro.conf:OVERRIDES =
"local:${MACHINE}:${MACHINE_CLASS}:${DISTRO}:${TARGET_OS}:\
conf/distro/shr.conf:OVERRIDES =
"local:${MACHINE}:${MACHINE_CLASS}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
conf/distro/minimal.conf:OVERRIDES =
"local:${MACHINE}:${MACHINE_CLASS}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
conf/distro/openmoko.conf:OVERRIDES =
"local:${MACHINE}:openmoko:angstrom:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
what i think is interesting about the above:
first, not that much overriding being done, a lot less than i
expected.
second, for consistency, wouldn't it make more sense to not hardcode
values like, say, "nslu2" or "ixp4xx" if there's a standard OE
variable that represents it?
finally, i'm assuming that the entry in bitbake.conf is the default
setting, and that that value is overridden (no pun intended) by any
further conf file, is that correct? and if that's the case, it would
be redundant to have any other .conf file set that variable to exactly
the same value as what's in bitbake.conf. i just ask since i wonder
if any of those OVERRIDES setting in any of the conf/machine/*.conf
files actually represent the same value as in bitbake.conf, meaning
they're superfluous.
ah, well, no big deal, at least i understand it now. onward to more
pedantry. but that section on OVERRIDES could definitely be made
clearer. i have an idea ...
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
