Adding a New Machine
- Adding a new machine to the Yocto Project is a straight forward
+ Adding a new machine to the Yocto Project is a straightforward
process.
This section describes how to add machines that are similar
to those that the Yocto Project already supports.
@@ -3034,7 +3034,8 @@
The most important variables you must set in your machine
- configuration file are as follows:
+ configuration file or include from a lower-level configuration
+ file are as follows:
TARGET_ARCH
(e.g. "arm")
@@ -3192,41 +3193,47 @@
variables in the
meta/conf/bitbake.conf configuration file define how files installed
by the do_install task are packaged.
- By default, the PACKAGES variable contains
- ${PN}-staticdev, which includes all static library files.
+ By default, the PACKAGES variable includes
+ ${PN}-staticdev, which represents all static library files.
Some previously released versions of the Yocto Project
defined the static library files through
${PN}-dev.
- Following, is part of the BitBake configuration file.
- You can see where the static library files are defined:
+ Following is part of the BitBake configuration file, where
+ you can see how the static library files are defined:
- PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-locale"
- PACKAGES_DYNAMIC = "${PN}-locale-*"
+ PACKAGE_BEFORE_PN ?= ""
+ PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
+ PACKAGES_DYNAMIC = "^${PN}-locale-.*"
FILES = ""
FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
${sysconfdir} ${sharedstatedir} ${localstatedir} \
${base_bindir}/* ${base_sbindir}/* \
${base_libdir}/*${SOLIBS} \
+ ${base_prefix}/lib/udev/rules.d ${prefix}/lib/udev/rules.d \
${datadir}/${BPN} ${libdir}/${BPN}/* \
${datadir}/pixmaps ${datadir}/applications \
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
${libdir}/bonobo/servers"
+ FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
+
FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
${datadir}/gnome/help"
SECTION_${PN}-doc = "doc"
- FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
+ FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
+ FILES_${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
- ${datadir}/aclocal ${base_libdir}/*.o"
+ ${datadir}/aclocal ${base_libdir}/*.o \
+ ${libdir}/${BPN}/*.la ${base_libdir}/*.la"
SECTION_${PN}-dev = "devel"
ALLOW_EMPTY_${PN}-dev = "1"
RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
- FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a"
+ FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"
SECTION_${PN}-staticdev = "devel"
RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
@@ -3256,7 +3263,7 @@
While the Multilib feature is most commonly used for 32 and 64-bit differences,
the approach the build system uses facilitates different target optimizations.
You could compile some binaries to use one set of libraries and other binaries
- to use other different sets of libraries.
+ to use a different set of libraries.
The libraries could differ in architecture, compiler options, or other
optimizations.
@@ -3315,8 +3322,9 @@
RDEPENDS,
RPROVIDES,
RRECOMMENDS,
- PACKAGES,
- and PACKAGES_DYNAMIC are automatically extended by the system.
+ PACKAGES, and
+ PACKAGES_DYNAMIC
+ are automatically extended by the system.
If you are extending any manual code in the recipe, you can use the
${MLPREFIX} variable to ensure those names are extended
correctly.
@@ -3360,7 +3368,7 @@
You can also build Multilib packages specifically with a command like this:
- $ bitbake lib32-connman
+ $ bitbake lib32-connman
@@ -3434,7 +3442,7 @@
- The process is straight forward as long as the libraries use
+ The process is straightforward as long as the libraries use
proper versioning.
With properly versioned libraries, all you need to do to
individually specify the libraries is create separate,
@@ -3488,7 +3496,7 @@
from existing OpenEmbedded build artifacts.
Image generation is driven by partitioning commands contained
in an Openembedded kickstart file (.wks)
- specified either directly on the command-line or as one of a
+ specified either directly on the command line or as one of a
selection of canned .wks files as shown
with the wic list images command in the
"Using an Existing Kickstart File"
@@ -3545,7 +3553,7 @@
standalone utility that initially provides
easier-to-use and more flexible replacements for a
couple bits of existing functionality in OE Core's
- directdisk.bbclass and
+ boot-directdisk.bbclass and
mkefidisk.sh scripts.
The difference between
wic and those examples is
@@ -3650,7 +3658,7 @@
$ wic list <image> help
- Where <image> is either
+ where <image> is either
directdisk or
mkefidisk.
@@ -3698,7 +3706,7 @@
Where:
image_name.wks
- An an OpenEmbedded kickstart file. You can provide
+ An OpenEmbedded kickstart file. You can provide
your own custom file or use a file from a set of
existing files as described by further options.
@@ -3730,7 +3738,7 @@
The path to the native sysroot containing the tools to use
to build the image.
- -p, ‐‐skip-build-check
+ -s, ‐‐skip-build-check
Skips the build check.
-D, ‐‐debug
@@ -3805,13 +3813,13 @@
# long-description: Creates a partitioned EFI disk image that the user
# can directly dd to boot media.
- part /boot ‐‐source bootimg-efi ‐‐ondisk sda ‐‐active
+ part /boot --source bootimg-efi --ondisk sda --label msdos --active --align 1024
- part / ‐‐source rootfs ‐‐ondisk sda ‐‐fstype=ext3 ‐‐label platform
+ part / --source rootfs --ondisk sda --fstype=ext3 --label platform --align 1024
- part swap ‐‐ondisk sda ‐‐size 44 ‐‐label swap1 ‐‐fstype=swap
+ part swap --ondisk sda --size 44 --label swap1 --fstype=swap
- bootloader ‐‐timeout=10 ‐‐append="rootwait console=ttyPCH0,115200"
+ bootloader --timeout=10 --append="rootwait rootfstype=ext3 console=ttyPCH0,115200 console=tty0 vmalloc=256MB snd-hda-intel.enable_msi=0"