http://www.openembedded.info/wiki/Bitbake_recipes

一个不错的oe Blog

Unable to open conf/bitbake.conf

出现这个信息的原因是由于忘记设bitbake的环境标量

#export BBPATH=${OEDIR}/build/:${OEDIR}/org.openembedded.dev/

#=====================================================================
一些有用的变量
EXTRA_OEMAKE = "LDFLAGS=-L${STAGING_LIBDIR}"
The paramters are passed to make during an oe_runmake call:
oe_runmake() {
    ${MAKE} ${EXTRA_OEMAKE} "$@" || die "oe_runmake failed"
}
#=====================================================================
扩展configure参数
EXTRA_OECONF
For packages which are autotools based (and therefore using the autotools inherit)
additional option can be passed to the configure script be specifying them in this variable.
The following example from the wget recipe shows that the options to enable IPv6 support and
to disable SSL support are being passed as additional parameters to configure:
EXTRA_OECONF = "--enable-ipv6 --without-ssl"
#=====================================================================
显示信息
oenote   Display some informational messages to the user.
oewarn   Display a warning to the user.
oefatal Display an error message to the user and abort the action.
oedebug Display a debugging message to the user but only if they have requested debugging output.
#=====================================================================
oe_runconfig ENDIANESS变量
do_configure() {
    # endianness fun.. inspired by openssl.inc
    . ${CONFIG_SITE}
    if test "x$ac_cv_c_bigendian" = "xyes"; then
        ENDIANESS=" --with-endianness=big"
    elif test "x$ac_cv_c_littleendian" = "xyes"; then
        ENDIANESS=" --with-endianness=little"
    else
       oefatal do_configure cannot determine endianess
    fi
    oe_runconf $ENDIANESS
}
#=====================================================================
mirrors
export GNU_MIRROR = "http://www.planetmirror.com/pub/gnu"
export DEBIAN_MIRROR = "http://mirror.optusnet.com.au/debian/pool"
export SOURCEFORGE_MIRROR = "http://optusnet.dl.sourceforge.net/sourceforge"

#=====================================================================
Conditional patches
It is sometimes desirable to only include patches for a specific architecture and/or
to include different files based on the architecture. This can be done via the SRC_URI_append
method by postfixing it was the architecture.
In this example, from glibc, the patch creates a glibc configuration file which should only be
created for the sh4 architecture, so the source is appended to the list of source files via:
#=====================================================================
# Build fails on sh4 unless no-z-defs is defined
SRC_URI_append_sh4 = " "  
SRC_URI_append_架构名字
SRC_URI_append_architecture
#=====================================================================
#=====================================================================
D = "${WORKDIR}/image"
S = "${WORKDIR}/${P}"
WORKDIR = "${TMPDIR}/work/${PF}"

#=====================================================================
STAGING_DIR       STAGING_DIR     = "${TMPDIR}/staging"
STAGING_BINDIR    STAGING_BINDIR = "${STAGING_DIR}/${BUILD_SYS}/bin"
STAGING_LIBDIR    STAGING_LIBDIR = "${STAGING_DIR}/${HOST_SYS}/lib"
STAGING_INCDIR    STAGING_INCDIR = "${STAGING_DIR}/${HOST_SYS}/include"
STAGING_DATADIR   STAGING_DATADIR = "${STAGING_DIR}/${HOST_SYS}/share"  
PKG_CONFIG_PATH   PKG_CONFIG_PATH = "${STAGING_DATADIR}/pkgconfig"
#=====================================================================
do_stage() {
    install -m 0644 zlib.h ${STAGING_INCDIR}/zlib.h
    install -m 0644 zconf.h ${STAGING_INCDIR}/zconf.h
    oe_libinstall -a -so libz ${STAGING_LIBDIR}
}
#=====================================================================
Unpacked source code directory: S
SRC_URI="http://www.example.com/software/widgets-${PN}.tar.gz"
S = "${WORKDIR}/widgets"
#=====================================================================
PARALLEL_MAKE = "-j 3"
#=====================================================================
PACKAGES              List the names of each of the packages which are to be generated.
FILES_<name>          List of the files that are to be included in the package named name.
ALLOW_EMPTY_<name>    Determines if the package will still be generated even
                      if no files are to be included in the package. By default packages which have
                       no files are not created and no error is raised.
PKG_<name>            Specifies the name of the generated package.
#=====================================================================

Structure

The structure of the various directories is described in Bitbake_usage.

A quick overview is provided here:

${WORKDIR} == oetmp/work/<packagename>-<version>-<release>${WORKDIR}/image : ${D} - the destination directory. You should install into here
/install : Packages are created in here.
/< srcdir> : ${S} - the source directory. Unpackaged source directory. Default is <packagename>-<version>
/temp : ${T} - the temp directory. Log's and scripts.


#=====================================================================Metadata

As you may have seen in the usage information, or in the information about .bb files, the BBFILES variable is how the bitbake tool locates its files. This variable is a space seperated list of files that are available, and supports wildcards.

Example 4.4. Setting BBFILES

BBFILES = "/path/to/bbfiles/*.bb"

With regard to dependencies, it expects the .bb to define a DEPENDS variable, which contains a space seperated list of “package names”, which themselves are the PN variable. The PN variable is, in general, by default, set to a component of the .bb filename.

Example 4.5. Depending on another .bb

a.bb:

PN = "package-a"
DEPENDS += "package-b"

b.bb:

PN = "package-b"

Example 4.6. Using PROVIDES

This example shows the usage of the PROVIDES variable, which allows a given .bb to specify what functionality it provides.

package1.bb:

PROVIDES += "virtual/package"

package2.bb:

DEPENDS += "virtual/package"

package3.bb:

PROVIDES += "virtual/package"

As you can see, here there are two different .bb's that provide the same functionality (virtual/package). Clearly, there needs to be a way for the person running bitbake to control which of those providers gets used. There is, indeed, such a way.

The following would go into a .conf file, to select package1:

PREFERRED_PROVIDER_virtual/package = "package1"
#=====================================================================
build/conf/local.conf 文件中 MACHINE = "db1200" 代表指定配置
/org.openembedded.dev/conf/machine/db1200.conf ==>>
同样对应disto
require conf/machine/include/qemu.inc -->代表include qemu.inc的意思
注意: setup-env 中的 OEDIR=xxxx 后面别加 / ，因为引用 ${OEDIR}/xxx 会变成//了
#=====================================================================
出处自Bitbake recipesmirrorsexport GNU_MIRROR = " http://www.planetmirror.com/pub/gnu"
export DEBIAN_MIRROR = " http://mirror.optusnet.com.au/debian/pool"
export SOURCEFORGE_MIRROR = " http://optusnet.dl.sourceforge.net/sourceforge"
#=====================================================================