On Fri, Jun 4, 2010 at 12:12 AM, Robert P. J. Day <[email protected]>wrote:
> 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.
>
Well, *modifications* to overrides aren't being done often. There are
thousands of cases of uses of those overrides to specify conditionally
defined variables, of course. The default simply happens to cover all the
common conditions we care about.
> 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.
>
The only cases where it makes sense to modify OVERRIDES in OE today, in my
opinion, is the case like the above nslu2. The machine is nslu2le or
nslu2be, for endianness, but they wanted a common override, so they wouldn't
have to specify two conditional versions of every conditional variable
definition. In order for it to behave sanely, it needs to show up as less
specific than nslu2le and nslu2be, so those can override the common version,
so it needs to be injected in the overrides at that particular point.
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 ...
>
Cool, I'm sure we'd all appreciate (and do) your comments and any
improvements you'd like to make to it.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
_______________________________________________
Bitbake-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bitbake-dev
