On Thu, Jun 3, 2010 at 1:57 AM, Robert P. J. Day <[email protected]>wrote:
>
> given that i have some spare time on my hands, i'm going to bite the
> bullet and try to go thru all the bitbake/OE docs and finally
> understand it, and that's going to start with perusing the bitbake
> manual and making notes about what seems confusing. i don't want to
> take up time on the developer's ML for just doc-related stuff so if
> there's a better place to post this, that works for me.
>
> as an example, from the perspective of someone who's written tons of
> docs over the years, early in the manual, the section describing
> OVERRIDES isn't really informative:
>
>
> "OVERRIDES is a ":" seperated variable containing each item you want
> 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:
>
This is worded quite badly. I honestly don't know what I was thinking :)
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.
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."
>
> well, ok, except it's not clear from the above whether "os" is
> something the user would type *verbatim*. in cases like the above, it
> would be incredibly useful to show a real example from an OE file
> somewhere. for example:
>
> conf/distro/shr.conf:OVERRIDES =
>
> "local:${MACHINE}:${MACHINE_CLASS}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
>
> suddenly, the reader understands that OVERRIDES will represent all
> kinds of information about the specific build being done. but there's
> still something confusing about this.
>
> for example, here's another example:
>
> conf/machine/kixrp435.conf:OVERRIDES =
>
> "local:${MACHINE}:nslu2:ixp4xx:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
>
> i'm curious -- wouldn't that second example also have been able to
> use the more generic "${MACHINE}" or "${MACHINE_CLASS}" variables?
> wouldn't it make sense to keep all rules as generic as possible?
> and, further, maybe i haven't read far enough ahead yet, but is there
> *any* reason to not start OVERRIDES off with what would appear to be a
> pre-requisite set of OVERRIDES including MACHINE, DISTRO, TARGET_OS,
> etc? those fundamental variable would seem to apply to all possible
> builds, so that i would expect to see only the occasional use of
> *appending* some special cases to OVERRIDES.
>
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.
To put it another way, all of our configuration metadata is designed to be
layered based on specificity of the information. It's reflected both by the
order of includes/requires in bitbake.conf (we load more specific later, and
lesser sooner, so the former overrides the latter, in the general case) and
the order of items in OVERRIDES. The intent is that more specific
information is always preferred. If we know that this should be set to some
value for a specific machine, then you definitely want to use that, rather
than, say, a value for the target architecture.
"local" is the most specific, just as "local.conf" is intended to be the
same way. So you can confidently set FOO_local = "bar" in your local.conf,
and you know that no matter what overrides exist, anywhere, FOO *will* be
bar.
I think it helps to view it conceptually as layering, and I think the
documentation should reflect that, as that was the original design intent,
and I think it makes more sense than trying to grasp the bits and pieces.
To return to the append / prepend vs variable redefinition thing, this is
the same dilemma that comes up with things like FILESPATH and FILESPATHPKG
-- the common case likely isn't to prepend or append, but to insert at a
specific point, and our format doesn't give us a mechanism to implement that
directly. We could, of course, shift the bits in the middle that are most
likely to need manipulation into a separate variable.
Does that help to clarify?
--
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
