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:
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.
and, finally, what's with that initial value of "local" in the
string? that's not explained at all in the manual.
in any event, with what little i've read so far, it would seem that
some sections could be less verbose (all that variable assignment
stuff could be way shorter), but sections like OVERRIDES deserve
*more* coverage. and using live examples ripped from actual OE files
would be tremendously useful.
i will now go back to reading.
rday
p.s. i know that i've submitted a few patches to the manual and
they've been accepted, but what's online is still old content:
http://bitbake.berlios.de/manual/
would it be a hassle to upload the latest version of the manual there?
--
========================================================================
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
