[yocto] under what circumstances is BBCLASSEXTEND = "native" required in a recipe?
Robert P. J. Day
rpjday at crashcourse.ca
Sat Aug 11 10:03:08 PDT 2012
[aside: i just tried to post to oe-core list but it bounced, and
since this involves the yocto QS guide, i figured i'd use the yocto
list as plan B.]
kind of a followup from my earlier (oe-core) post but i'm a bit
puzzled as to the *necessity* of a recipe including the line:
BBCLASSEXTEND = "native"
my original understanding (which could be wildly inaccurate) was that
this line meant that that recipe had support for being built natively;
as in, it was required on the build host. so far, so good?
but in the yocto quick start guide:
http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html
you read about "The Packages", which allegedly represents the packages
the developer is *required* to have on his development host, based on
the developer *installing* those packages, which is what leads to my
confusion.
for example, the QS guide claims that "chrpath" is required, and
that one is expected to install that command using whatever
distro-specific command is necessary. that command is listed in
in meta/classes/sanity.bbclass in SANITY_REQUIRED_UTILITIES, so that
seems reasonable.
however, the "chrpath" command is not listed in bitbake as part of
ASSUME_PROVIDED, and its recipe includes the line
BBCLASSEXTEND = "native"
that's what's confusing -- if the QS guide demands that the user
install "chrpath" manually, what is the subsequent value of its recipe
dictating that it be natively buildable?
clarification, please?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
More information about the yocto
mailing list