poky: subtree update:c67f57c09e..c6bc20857c
Adrian Freihofer (2):
oe-publish-sdk: fix layers init via ssh
oe-publish-sdk: add --keep-orig option
Alexander Kanavin (68):
meta-selftest: correct the virgl test for 5.8 kernels
bison: upgrade 3.6.4 -> 3.7.1
util-linux: upgrade 2.35.2 -> 2.36
python3-numpy: upgrade 1.19.0 -> 1.19.1
python3-setuptools: upgrade 49.3.1 -> 49.6.0
rsync: upgrade 3.2.2 -> 3.2.3
util-linux: merge .inc into .bb
acpica: upgrade 20200528 -> 20200717
asciidoc: upgrade 9.0.1 -> 9.0.2
cryptodev: upgrade 1.10 -> 1.11
diffoscope: upgrade 153 -> 156
epiphany: upgrade 3.36.3 -> 3.36.4
font-alias: upgrade 1.0.3 -> 1.0.4
gtk+3: upgrade 3.24.21 -> 3.24.22
libcheck: upgrade 0.15.0 -> 0.15.2
libinput: upgrade 1.16.0 -> 1.16.1
libpipeline: upgrade 1.5.2 -> 1.5.3
libx11: upgrade 1.6.9 -> 1.6.11
linux-firmware: upgrade 20200619 -> 20200721
man-pages: upgrade 5.07 -> 5.08
mc: upgrade 4.8.24 -> 4.8.25
mesa: upgrade 20.1.4 -> 20.1.5
piglit: upgrade to latest revision
re2c: upgrade 2.0 -> 2.0.2
sysstat: upgrade 12.2.2 -> 12.4.0
vala: upgrade 0.48.7 -> 0.48.9
bootchart2: update 0.14.8 -> 0.14.9
harfbuzz: convert to meson, enable gobject introspection
pango: update 1.44.7 -> 1.46.0
boost: update 1.73.0 -> 1.74.0
xev: update 1.2.3 -> 1.2.4
wpebackend-fdo: update 1.6.1 -> 1.7.1
gpgme: update 1.13.1 -> 1.14.0
libpsl: update 0.21.0 -> 0.21.1.
gettext: update 0.20.2 -> 0.21
cmake: update 3.17.3 -> 3.18.1
linux-firmware: update 20200721 -> 20200817
meson: update 0.55.0 -> 0.55.1
systemd-boot: bump version to 246.2
json-glib: inherit upstream-version-is-even
packagegroup-core-device-devel: remove
oeqa/x32lib: rework to use readelf from the host
oeqa/multilib: rework to use readelf from the host
oeqa/multilib: un-skip the connman test
poky.conf: do not install packagegroup-core-device-devel into qemu images
glib-2.0: update 2.64.4 -> 2.64.5
cmake: upgrade 3.18.1 -> 3.18.2
libxcrypt: upgrade 4.4.16 -> 4.4.17
debianutils: upgrade 4.11 -> 4.11.1
enchant2: upgrade 2.2.8 -> 2.2.9
harfbuzz: upgrade 2.7.1 -> 2.7.2
libmpc: upgrade 1.1.0 -> 1.2.0
librepo: upgrade 1.12.0 -> 1.12.1
libuv: upgrade 1.38.1 -> 1.39.0
msmtp: upgrade 1.8.11 -> 1.8.12
ninja: upgrade 1.10.0 -> 1.10.1
p11-kit: upgrade 0.23.20 -> 0.23.21
pango: upgrade 1.46.0 -> 1.46.1
re2c: upgrade 2.0.2 -> 2.0.3
resolvconf: upgrade 1.82 -> 1.83
stress-ng: upgrade 0.11.18 -> 0.11.19
gnu-config: update to latest revision
nasm: update 2.15.03 -> 2.15.05
libva-utils: fix upstream version check
gnupg: update 2.2.21 -> 2.2.22
libx11: update 1.6.11 -> 1.6.12
mesa: update 20.1.5 -> 20.1.6
xserver-xorg: update 1.20.8 -> 1.20.9
Andrey Zhizhikin (1):
insane: check for missing update-alternatives inherit
Anibal Limon (1):
recipes-kernel: linux-firmware add qcom-venus-{5.2,5.4} packages
Aníbal Limón (1):
recipes-graphics/xorg-xserver: Add patch to fix segfault when probe
Armin Kuster (2):
bind: update to 9.11.22 ESV
core-image-sato: qemumips use 512 mem
Bruce Ashfield (30):
linux-yocto/5.4: update to v5.4.59
linux-yocto/5.8: update to v5.8.2
yocto-bsp: update to v5.4.56
yocto-bsp: update to v5.4.58
qemu: bump default reference kernel to v5.8
linux-yocto/5.8: fix perf and virtio_scsi warnings
linux-yocto-rt/5.8: fix lttng-modules build
linux-yocto/5.8: selftests/bpf: Prevent runqslower from racing on building bpftool
linux-yocto/5.8: disable CONFIG_NFS_DISABLE_UDP_SUPPORT
poky: set preferred version for linux-yocto to be v5.8
poky-tiny: set preferred version to 5.8
poky: add preferred version for linux-yocto-rt
linux-yocto/5.8: update to v5.8.3
linux-yocto/5.4: update to v5.4.60
kernel: config cleanups for 5.8+
linux-yocto/5.4: update to v5.4.61
linux-yocto/5.8: update to v5.8.4
linux-yocto/5.8: disable IKHEADERS in default builds
kernel-yocto: allow promotion of configuration warnings to errors
kernel-yocto: checksum all modifications to available kernel fragments directories
lttng-modules/devupstream: bump to latest 2.12 commits
linux-yocto-dev: bump to v5.9+
linux-yocto/5.8: update to v5.8.5
kernel-devsrc: account for HOSTCC and HOSTCXX
linux-yocto/config: netfilter: Enable nat for ipv4 and ipv6
linux-yocto/5.8: update to v5.8.8
linux-yocto/5.4: update to v5.4.64
linux-yocto/config: configuration warning cleanup
linux-yocto/5.8: update to v5.8.9
linux-yocto/5.4: update to v5.4.65
Changhyeok Bae (2):
iw: upgrade 5.4 -> 5.8
iputils: upgrade s20190709 -> s20200821
Chris Laplante (12):
bitbake: compat.py: remove file since it no longer actually implements anything
bitbake: COW: formatting
bitbake: COW: migrate test suite into tests/cow
cve-update-db-native: add progress handler
cve-check/cve-update-db-native: use lockfile to fix usage under multiconfig
cve-update-db-native: use context manager for cve_f
cve-check: avoid FileNotFoundError if no do_cve_check task has run
bitbake: utils: process_profilelog: use context manager
bitbake: utils: fix UnboundLocalError when _print_exception raises
cve-update-db-native: be less magical about checking whether the cve-check class is enabled
cve-update-db-native: move -journal checking into do_fetch
cve-update-db-native: remove unused variable
Christophe GUIBOUT (1):
initramfs-framework: support kernel cmdline with double quotes
Denys Dmytriyenko (2):
weston: upgrade 8.0.0 -> 9.0.0
cryptodev: bump 1 commit past 1.11 to fix 5.9-rc1+
Diego Sueiro (2):
license_image.bbclass: Create symlink to the image license manifest dir
license_image.bbclass: Fix symlink to the image license manifest dir creation
Douglas Royds (1):
tcmode-default: Drop gcc-cross-initial, gcc-crosssdk-initial references
Frazer Clews (1):
bitbake: lib: fix most undefined code picked up by pylint
Geoff Parker (1):
systemd-serialgetty: Replace sed quoting using ' with " to allow var expansion
Jacob Kroon (1):
gcc10: Don't default back to -fcommon
Jean-Francois Dagenais (1):
bitbake: siggen: clean_basepath: remove recipe full path when virtual:xyz present
Jens Rehsack (1):
lttng-modules: backport patches from 2.12.x to fix 5.4.64+ and 5.8.9+ builds
Joe Slater (1):
pseudo: fix renaming to self
Jon Mason (4):
cortex-m0plus.inc: change file permissions
tune-cortexa55.inc: clean-up ARMv8.2a uses
tune-cortexa57-cortexa53.inc: add CRC and set march
tune-cortexa*: Cleanups
Joshua Watt (8):
wic: Add 512 Byte alignment to --offset
oeqa: runtime_tests: Extra GPG debugging
oeqa: sdk: Capture stderr output
oeqa: reproducible: Fix test not producing diffs
diffoscope: upgrade 156 -> 158
bitbake: bitbake: Add parsing torture test
bitbake: cooker: Block SIGINT in worker processes
sphinx: dev-manual: Clarify that virtual providers do not apply to runtime dependencies
Kai Kang (1):
dhcpcd: 9.1.4 -> 9.2.0
Kevin Hao (1):
meta-yocto-bsp: Bump to the v5.8 kernel
Khairul Rohaizzat Jamaluddin (1):
wic/bootimg-efi: IMAGE_EFI_BOOT_FILES variable added to separate bootimg-efi and bootimg-partition
Khem Raj (24):
gcc-cross-canadian: Install gcc/g++ wrappers for musl
uninative: Upgrade to 2.9
packagegroup-core-tools-profile: Disable lttng-modules for riscv64
lttng-modules: Disable on riscv64
kexec-tools: Fix build with -fno-common on ppc
lttng-tools: Do not build for riscv64
util-linux: Allow update alternatives for additional apps
lttng-tools: lttng-ust works on riscv64
json-glib: Backport a build fix with clang
rpcbind: Use update-alternatives for rpcinfo
go: Upgrade to 1.15 major release
weston-init: Redefine weston service and add socket activation option
musl: Upgrade to latest master
libucontext: Recognise riscv32 architecture
linuxloader.bbclass: Define riscv32 ldso for musl
populate_sdk_ext: Do not assume local.conf will always exist
weston: plane_add_prop() calls break musl atomic modesetting
weston-init: Enable RDP screen share
weston-init: Do not use fbdev backend
weston-init: Select drm/fbdev backends for qemu machines
oeqa/weston: Fix tests to run with systemd
core-image-weston: Bump qemu memory to 512M
go: Update to 1.15.2 minor release
bind: Inherit update-alternatives
Mark Hatle (6):
package_tar.bbclass: Sync to the other package_* classes
kernel.bbclass: Remove do_install[prefunc] no longer needed
buildhistory.bbclass: Rework to use read_subpackage_metadata
kernel.bbclass: Move away from calling package_get_auto_pr
package.bbclass: hash equivalency and pr service
bitbake: process.py: Handle SystemExit exception to eliminate backtrace
Mark Morton (1):
sphinx: test-manual code block, link, and format update
Martin Jansa (7):
devtool: expand SRC_URI when guessing recipe update mode
image-artifact-names: introduce new bbclass and move some variables into it
kernel.bbclass: use bash variables like imageType, base_name without {}
kernel.bbclass: eliminate (initramfs_)symlink_name variables
kernel.bbclass: use camelCase notation for bash variables in do_deploy
*-initramfs: don't use .rootfs IMAGE_NAME_SUFFIX
bitbake.conf: use ${TCMODE}-${TCLIBC} directory for CACHE
Matt Madison (1):
image.bbclass: fix REPRODUCIBLE_TIMESTAMP_ROOTFS reference
Michael Gloff (2):
sysvinit rc: Use PSPLASH_FIFO_DIR for progress fifo
sysvinit: Remove ${B} assignment
Michael Tretter (1):
devtool: deploy-target: Fix size calculation for hard links
Ming Liu (2):
systemd: split systemd specific udev rules into its own package
libubootenv: inherit uboot-config
Mingli Yu (3):
qemu: always define unknown_lock_type
qemu: override DEBUG_BUILD
bison: remove the parallel build patch
Naveen Saini (1):
lib/oe/recipeutils.py: add support for BBFILES_DYNAMIC
Nicolas Dechesne (73):
linux-libc-headers: kernel headers are installed in STAGING_KERNEL_BUILDDIR
bitbake: sphinx: add initial build infrastructure
bitbake: sphinx: initial sphinx support
bitbake: sphinx: bitbake-user-manual: use builtin sphinx glossary
bitbake: sphinx: switch to readthedocs theme
bitbake: sphinx: override theme CSS
bitbake: sphinx: fixup for links
bitbake: sphinx: fix links inside notes
bitbake: sphinx: fixes all remaining warnings
bitbake: sphinx: Makefile.sphinx: add clean and publish targets
bitbake: sphinx: tweak html output a bit
bitbake: sphinx: add SPDX headers
bitbake: sphinx: index: move the boilerplate at the end of the page
bitbake: sphinx: conf: enable extlinks extension
bitbake: sphinx: add releases page
bitbake: sphinx: bitbake-user-manual: insert additional blank line after title
bitbake: sphinx: last manual round of fixes/improvements
bitbake: sphinx: update style for important, caution and warnings
bitbake: sphinx: remove leading '/'
bitbake: sphinx: theme_override: properly set font for verbatim text
bitbake: bitbake-user-manual: fix bad links
sphinx: add initial build infrastructure
sphinx: initial sphinx support
sphinx: ref-variables: use builtin sphinx glossary
sphinx: overview-manual: add figures
sphinx: switch to readthedocs theme
sphinx: Add SPDX license headers
sphinx: add CSS theme override
sphinx: bsp-guide: add figures
sphinx: add Yocto project logo
sphinx: conf: update copyright
sphinx: conf: add substitutions/global variables
sphinx: add boilerplate file
sphinx: add boilerplate to manuals
sphinx: ref-manual: add revision history table
sphinx: add a general index
sphinx: conf.py: enable sphinx.ext.autosectionlabel
sphinx: ref-manual: use builtin glossary for the Terms section
sphinx: fix internal links
sphinx: ref-manual: fix typo
sphinx: fix custom term links
sphinx: manual updates for some links
sphinx: dev-manual add figures
sphinx: kernel-dev: add figures
sphinx: profile-manual: add figures
sphinx: fix up bold text for informalexample container
sphinx: ref-manual: add figures
sphinx: sdk-manual: add figures
sphinx: test-manual: add figures
sphinx: toaster-manual: add figures
sphinx: add links for Yocto project website
sphinx: fix links when the link text should be displayed
sphinx: add links to terms in the BitBake glossary
sphinx: add links to section in the Bitbake manual
sphinx: setup extlink for docs.yoctoproject.org
sphinx: enable intersphinx extension
sphinx: insert blank below between title and toc
sphinx: fix up terms related to kernel-fitimage
sphinx: conf: a few rendering tweaks
sphinx: makefile: add publish target
sphinx: conf: include CSS/JS files, the proper way
sphinx: convert 'what I wish I'd known'
sphinx: convert 'transitioning to a custom environment'
sphinx: ref-manual: fix heading for oe-init-build-env
sphinx: brief-yoctoprojectqs: fix up all remaining rendering issues
sphinx: Makefile.sphinx improvements
sphinx: convert bsp-guide
sphinx: remove leading '/'
sphinx: update style for important, caution and warnings
sphinx: profile-manual: convert profile-manual
sphinx: theme_override: properly set font for verbatim text
sphinx: theme_override: add tying-it-together admonition
sphinx: conf: exclude adt-manual/*.rst
Oleksandr Kravchuk (1):
ell: update to 0.33
Ovidiu Panait (1):
libxml2: Fix CVE-2020-24977
Peter A. Bigot (2):
bluez5: fix builds that require ell support
timezone: include leap second data in tzdata-core
Peter Bergin (1):
systemd: avoid failing if no udev rules provided
Pierre-Jean Texier (2):
libubootenv: upgrade 0.3 -> 0.3.1
diffoscope: upgrade 158 -> 160
Quentin Schulz (16):
sphinx: brief-yoctoprojectqs: remove redundant welcome
sphinx: brief-yoctoprojectqs: fix ambiguous note for cyclone5 example
sphinx: brief-yoctoprojectqs: add missing boilerplate
sphinx: overview-manual: add link to AUH how-to section
sphinx: overview-manual: fix bitbake basic explanation
sphinx: brief-yoctoprojectqs: add note on branch consistency between layers
sphinx: what-i-wish-id-known: update "don't be fooled by doc search results"
sphinx: overview-manual: remove highlight in bold section
sphinx: replace special quotes with single and double quotes
sphinx: fix incorrect indentations
sphinx: brief-yoctoprojectqs: put other distros note after Ubuntu-specific packages
sphinx: fix a few typos or missing/too many words
sphinx: "highlight" some variables, tasks or files
sphinx: fix or add missing links and remove mention of Eclipse workflow
ref-manual: examples: hello-autotools: upgrade to 2.10
ref-manual: examples: libxpm: add relative path to .inc
Rahul Kumar (1):
systemd-serialgetty: Fix sed expression quoting
Rasmus Villemoes (1):
kernel.bbclass: run do_symlink_kernsrc before do_patch
Richard Purdie (74):
nativesdk-sdk-provides-dummy: Add /bin/sh
bitbake: fetch2/wget: Remove buffering parameter
bitbake: cooker: Ensure parse_quit thread is closed down
bitbake: cooker: Explictly shut down the sync thread
bitbake: fetch2: Drop cups.org from wget status checks
bitbake: build/msg: Cleanup verbose option handling
bitbake: cooker/cookerdata/main: Improve loglevel handling
bitbake: cookerdata: Ensure UI options are updated to the server
bitbake: cooker/cookerdata: Ensure UI event log is updated from commandline
bitbake: cooker: Defer configuration init to after UI connection
bitbake: server/process: Move the socket code to server process only
bitbake: main/server/process: Drop configuration object passing
bitbake: cooker: Ensure BB_ORIGENV is updated by changes to configuration.env
bitbake: server/process: Log extra threads at exit
bitbake: server/process: Add bitbake-server and exec() a new server process
bitbake: runqueue: Don't use sys.argv
bitbake: cooker: Ensure cooker's enviroment is updated on updateConfig
connman-gnome/matchbox-desktop: Remove file:// globbing
selftest/recipetool: Drop globbing SRC_URI test, no longer supported
local.conf.sample: Document memory resident bitbake
bitbake: fetch2: Drop globbing supprt in file:// SRC_URIs
bitbake: server/process: Use sys.executable for bitbake-server
bitbake: process: Avoid bb.utils.timeout
bitbake: utils: Drop broken timeout function
bitbake: server/process: Fix typo in code causing tracebacks
oeqa/selftest: Apply patch to fix cpio build with -fno-common
runqemu: Show an error for conflicting graphics options
lttng: Move platform logic to dedicated inc file
patchelf: upgrade 0.11 -> 0.12
build-appliance/packagegroup-core-base-utils: Replace dhcp-client/dhcp-server with dhcpcd/kea
selftest/prservice: Improve test failure message
iputils: Adapt ${PN}-tftpd package dependency to PACKAGECONFIG
bitbake: process/knotty: Improve early exception handling
bitbake: cooker/cookerdata: Use BBHandledException, not sys.exit()
bitbake: cookerdata: Fix exception raise statements
bitbake: process: Avoid printing binary strings for leftover processes
bitbake: server/process: Ensure logging is flushed
bitbake: server/process: Don't show tracebacks if the lockfile is removed
bitbake: cooker: Ensure parser replacement calls parser final_cleanup
bitbake: cooker: Assign a name to the sync thread to aid debugging
bitbake: server/process: Ensure we don't keep looping if some other server is started
bitbake: server/process: Prefix the log data with pid/time information
bitbake: server/process: Note when commands complete in logs
bitbake: cooker: Ensure parser is cleaned up
runqemu: Add a hook to allow it to renice
bitbake: cooker: Avoid parser deadlocks
bitbake: cooker: Ensure parser worker signal handlers are default
selftest/signing: Ensure build path relocation is safe
oeqa/concurrencytest: Improve builddir path manipulations
bitbake: cooker/command: Fix disconnection handling
bitbake: tinfoil: Ensure sockets don't leak even when exceptions occur
bitbake: tests/fetch: Move away from problematic freedesktop.org urls
bitbake: sphinx: Enhance the sphinx experience/nagivation with:
bitbake: sphinx: theme_override: Use bold for emphasis text
Revert "qemu: always define unknown_lock_type"
Revert "core-image-sato: qemumips use 512 mem"
sphinx: Organize top level docs
sphinx: releases.rst: Add index/links to docs for previous releases
sphinx: boilerplate.rst: Drop versions notes as we have better navigation now
sphinx: boilerplate.rst: Sphinx puts the copyright elsewhere
sphinx: history: Move revision history to its own section
sphinx: manuals: Move boilerplate after toctree
sphinx: Add support for multiple docs version
sphinx: index.rst: Fix links
sphinx: ref-system-requirements: Improve formatting of the notes sections, merging them
sphinx: ref-manual links fixes and many other cleanups to import
sphinx: dev-manual: Various URL, code block and other fixes to imported data
sphinx: sdk-manual: Various URL, code block and other fixes to imported data
sphinx: kernel-dev: Various URL, code block and other fixes to imported data
sphinx: theme_override: Use bold for emphasis text
sphinx: ref-tasks: Add populate_sdk_ext task definition
sphinx: ref-manual/migration: Split each release into its own file
sphinx: overview-manual: Various URL, code block and other fixes to imported data
build-appliance-image: Update to master head revision
Robert Yang (3):
bitbake: cooker.py: Save prioritized BBFILES to BBFILES_PRIORITIZED
bitbake: utils.py: get_file_layer(): Exit the loop when file is matched
bitbake: utils.py: get_file_layer(): Improve performance
Ross Burton (25):
package.bbclass: explode the RPROVIDES so we don't think the versions are provides
elfutils: silence a new QA warning
insane: improve gnu-hash-style warning
gdk-pixbuf: add tests PACKAGECONFIG
debianutils: change SRC_URI to use snapshot.debian.org
insane: only load real files as ELF
autoconf: consolidate SRC_URI
autoconf: consolidate DEPENDS
kea: no need to depend on kea-native
kea: don't use PACKAGECONFIG inappropriately
kea: bump to 1.7.10
help2man: rewrite recipe
local.conf.sample.extended: remove help2man reference
curl: add vendors to CVE_PRODUCT to exclude false positives
harfbuzz: update patch status
harfbuzz: fix a build race around hb-version.h
cmake: whitelist CVE-2016-10642
ncurses: remove config.cache
qemu: fix CVE-2020-14364
cve-update-db-native: remove unused import
cve-update-db-native: add more logging when fetching
cve-update-db-native: use fetch task
alsa-plugins: improve .la removal
sato-screenshot: improve .la removal
buildhistory-diff: use BUILDDIR to know where buildhistory is
Saul Wold (1):
gnupg: uprev 2.2.22 -> 2.2.23
Stacy Gaikovaia (2):
bison: uprev from 3.7.1 to 3.7.2
valgrind: fix memcheck vgtests remove fullpath-after flags
Steve Sakoman (1):
xinput-calibrator: change SRC_URI to branch with libinput support
Sumit Garg (1):
insane: fix gnu-hash-style check
TeohJayShen (1):
oeqa/runtime: add test for matchbox-terminal
Tim Orling (1):
sphinx: toaster-manual: fix vars, links, code blocks
Vijai Kumar K (2):
image_types_wic: Add ASSUME_PROVIDED to WICVARS
wic: misc: Add /bin to the list of searchpaths
Yanfei Xu (1):
kernel-yocto: only replace leading -I in include paths
Yi Zhao (1):
glib-networking: add ptest
Zhixiong Chi (1):
gnutls: CVE-2020-24659
akuster (8):
log4cplus: move meta-oe pkg to core
kea: Move from meta-networking
maintainers.inc: Add me as kea & log4plus maintainer.
dhcpcd: Move from meta-network as OE-Core needs a client
maintainers.inc: Add me as dhcpcd maintainer
dhcp: remove from core
bind: Add 9.16.x
bind: 9.11 remove
hongxu (1):
sysstat: fix installed-vs-shipped QA Issue in systemd
zangrc (4):
libcap:upgrade 2.42 -> 2.43
libcap-ng:upgrade 0.7.10 -> 0.7.11
libgpg-error:upgrade 1.38 -> 1.39
at-spi2-core:upgrade 2.36.0 -> 2.36.1
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I5542f5eea751a2641342e945725fd687cd74bebe
diff --git a/poky/documentation/sdk-manual/sdk-extensible.rst b/poky/documentation/sdk-manual/sdk-extensible.rst
new file mode 100644
index 0000000..1ad5c46
--- /dev/null
+++ b/poky/documentation/sdk-manual/sdk-extensible.rst
@@ -0,0 +1,1356 @@
+.. SPDX-License-Identifier: CC-BY-2.0-UK
+
+************************
+Using the Extensible SDK
+************************
+
+This chapter describes the extensible SDK and how to install it.
+Information covers the pieces of the SDK, how to install it, and
+presents a look at using the ``devtool`` functionality. The extensible
+SDK makes it easy to add new applications and libraries to an image,
+modify the source for an existing component, test changes on the target
+hardware, and ease integration into the rest of the
+:term:`OpenEmbedded Build System`.
+
+.. note::
+
+ For a side-by-side comparison of main features supported for an
+ extensible SDK as compared to a standard SDK, see the "
+ Introduction
+ " section.
+
+In addition to the functionality available through ``devtool``, you can
+alternatively make use of the toolchain directly, for example from
+Makefile and Autotools. See the "`Using the SDK Toolchain
+Directly <#sdk-working-projects>`__" chapter for more information.
+
+.. _sdk-extensible-sdk-intro:
+
+Why use the Extensible SDK and What is in It?
+=============================================
+
+The extensible SDK provides a cross-development toolchain and libraries
+tailored to the contents of a specific image. You would use the
+Extensible SDK if you want a toolchain experience supplemented with the
+powerful set of ``devtool`` commands tailored for the Yocto Project
+environment.
+
+The installed extensible SDK consists of several files and directories.
+Basically, it contains an SDK environment setup script, some
+configuration files, an internal build system, and the ``devtool``
+functionality.
+
+.. _sdk-installing-the-extensible-sdk:
+
+Installing the Extensible SDK
+=============================
+
+The first thing you need to do is install the SDK on your :term:`Build
+Host` by running the ``*.sh`` installation script.
+
+You can download a tarball installer, which includes the pre-built
+toolchain, the ``runqemu`` script, the internal build system,
+``devtool``, and support files from the appropriate
+:yocto_dl:`toolchain <releases/yocto/yocto-3.1.2/toolchain/>` directory within the Index of
+Releases. Toolchains are available for several 32-bit and 64-bit
+architectures with the ``x86_64`` directories, respectively. The
+toolchains the Yocto Project provides are based off the
+``core-image-sato`` and ``core-image-minimal`` images and contain
+libraries appropriate for developing against that image.
+
+The names of the tarball installer scripts are such that a string
+representing the host system appears first in the filename and then is
+immediately followed by a string representing the target architecture.
+An extensible SDK has the string "-ext" as part of the name. Following
+is the general form:
+::
+
+ poky-glibc-host_system-image_type-arch-toolchain-ext-release_version.sh
+
+ Where:
+ host_system is a string representing your development system:
+
+ i686 or x86_64.
+
+ image_type is the image for which the SDK was built:
+
+ core-image-sato or core-image-minimal
+
+ arch is a string representing the tuned target architecture:
+
+ aarch64, armv5e, core2-64, i586, mips32r2, mips64, ppc7400, or cortexa8hf-neon
+
+ release_version is a string representing the release number of the Yocto Project:
+
+ 3.1.2, 3.1.2+snapshot
+
+For example, the following SDK installer is for a 64-bit
+development host system and a i586-tuned target architecture based off
+the SDK for ``core-image-sato`` and using the current DISTRO snapshot:
+::
+
+ poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-DISTRO.sh
+
+.. note::
+
+ As an alternative to downloading an SDK, you can build the SDK
+ installer. For information on building the installer, see the "
+ Building an SDK Installer
+ " section.
+
+The SDK and toolchains are self-contained and by default are installed
+into the ``poky_sdk`` folder in your home directory. You can choose to
+install the extensible SDK in any location when you run the installer.
+However, because files need to be written under that directory during
+the normal course of operation, the location you choose for installation
+must be writable for whichever users need to use the SDK.
+
+The following command shows how to run the installer given a toolchain
+tarball for a 64-bit x86 development host system and a 64-bit x86 target
+architecture. The example assumes the SDK installer is located in
+``~/Downloads/`` and has execution rights.
+
+.. note::
+
+ If you do not have write permissions for the directory into which you
+ are installing the SDK, the installer notifies you and exits. For
+ that case, set up the proper permissions in the directory and run the
+ installer again.
+
+::
+
+ $ ./Downloads/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.5.sh
+ Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.5
+ ==========================================================================
+ Enter target directory for SDK (default: ~/poky_sdk):
+ You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed [Y/n]? Y
+ Extracting SDK..............done
+ Setting it up...
+ Extracting buildtools...
+ Preparing build system...
+ Parsing recipes: 100% |##################################################################| Time: 0:00:52
+ Initialising tasks: 100% |###############################################################| Time: 0:00:00
+ Checking sstate mirror object availability: 100% |#######################################| Time: 0:00:00
+ Loading cache: 100% |####################################################################| Time: 0:00:00
+ Initialising tasks: 100% |###############################################################| Time: 0:00:00
+ done
+ SDK has been successfully set up and is ready to be used.
+ Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
+ $ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux
+
+.. _sdk-running-the-extensible-sdk-environment-setup-script:
+
+Running the Extensible SDK Environment Setup Script
+===================================================
+
+Once you have the SDK installed, you must run the SDK environment setup
+script before you can actually use the SDK. This setup script resides in
+the directory you chose when you installed the SDK, which is either the
+default ``poky_sdk`` directory or the directory you chose during
+installation.
+
+Before running the script, be sure it is the one that matches the
+architecture for which you are developing. Environment setup scripts
+begin with the string "``environment-setup``" and include as part of
+their name the tuned target architecture. As an example, the following
+commands set the working directory to where the SDK was installed and
+then source the environment setup script. In this example, the setup
+script is for an IA-based target machine using i586 tuning:
+::
+
+ $ cd /home/scottrif/poky_sdk
+ $ source environment-setup-core2-64-poky-linux
+ SDK environment now set up; additionally you may now run devtool to perform development tasks.
+ Run devtool --help for further details.
+
+Running the setup script defines many environment variables needed in
+order to use the SDK (e.g. ``PATH``,
+:term:`CC`,
+:term:`LD`, and so forth). If you want to
+see all the environment variables the script exports, examine the
+installation file itself.
+
+Using ``devtool`` in Your SDK Workflow
+======================================
+
+The cornerstone of the extensible SDK is a command-line tool called
+``devtool``. This tool provides a number of features that help you
+build, test and package software within the extensible SDK, and
+optionally integrate it into an image built by the OpenEmbedded build
+system.
+
+.. note::
+
+ The use of
+ devtool
+ is not limited to the extensible SDK. You can use
+ devtool
+ to help you easily develop any project whose build output must be
+ part of an image built using the build system.
+
+The ``devtool`` command line is organized similarly to
+:ref:`overview-manual/overview-manual-development-environment:git` in that it has a number of
+sub-commands for each function. You can run ``devtool --help`` to see
+all the commands.
+
+.. note::
+
+ See the "
+ devtool
+ Quick Reference
+ " in the Yocto Project Reference Manual for a
+ devtool
+ quick reference.
+
+Three ``devtool`` subcommands exist that provide entry-points into
+development:
+
+- *devtool add*: Assists in adding new software to be built.
+
+- *devtool modify*: Sets up an environment to enable you to modify
+ the source of an existing component.
+
+- *devtool upgrade*: Updates an existing recipe so that you can
+ build it for an updated set of source files.
+
+As with the build system, "recipes" represent software packages within
+``devtool``. When you use ``devtool add``, a recipe is automatically
+created. When you use ``devtool modify``, the specified existing recipe
+is used in order to determine where to get the source code and how to
+patch it. In both cases, an environment is set up so that when you build
+the recipe a source tree that is under your control is used in order to
+allow you to make changes to the source as desired. By default, new
+recipes and the source go into a "workspace" directory under the SDK.
+
+The remainder of this section presents the ``devtool add``,
+``devtool modify``, and ``devtool upgrade`` workflows.
+
+.. _sdk-use-devtool-to-add-an-application:
+
+Use ``devtool add`` to Add an Application
+-----------------------------------------
+
+The ``devtool add`` command generates a new recipe based on existing
+source code. This command takes advantage of the
+:ref:`devtool-the-workspace-layer-structure`
+layer that many ``devtool`` commands use. The command is flexible enough
+to allow you to extract source code into both the workspace or a
+separate local Git repository and to use existing code that does not
+need to be extracted.
+
+Depending on your particular scenario, the arguments and options you use
+with ``devtool add`` form different combinations. The following diagram
+shows common development flows you would use with the ``devtool add``
+command:
+
+.. image:: figures/sdk-devtool-add-flow.png
+ :align: center
+
+1. *Generating the New Recipe*: The top part of the flow shows three
+ scenarios by which you could use ``devtool add`` to generate a recipe
+ based on existing source code.
+
+ In a shared development environment, it is typical for other
+ developers to be responsible for various areas of source code. As a
+ developer, you are probably interested in using that source code as
+ part of your development within the Yocto Project. All you need is
+ access to the code, a recipe, and a controlled area in which to do
+ your work.
+
+ Within the diagram, three possible scenarios feed into the
+ ``devtool add`` workflow:
+
+ - *Left*: The left scenario in the figure represents a common
+ situation where the source code does not exist locally and needs
+ to be extracted. In this situation, the source code is extracted
+ to the default workspace - you do not want the files in some
+ specific location outside of the workspace. Thus, everything you
+ need will be located in the workspace:
+ ::
+
+ $ devtool add recipe fetchuri
+
+ With this command, ``devtool`` extracts the upstream
+ source files into a local Git repository within the ``sources``
+ folder. The command then creates a recipe named recipe and a
+ corresponding append file in the workspace. If you do not provide
+ recipe, the command makes an attempt to determine the recipe name.
+
+ - *Middle*: The middle scenario in the figure also represents a
+ situation where the source code does not exist locally. In this
+ case, the code is again upstream and needs to be extracted to some
+ local area - this time outside of the default workspace.
+
+ .. note::
+
+ If required,
+ devtool
+ always creates a Git repository locally during the extraction.
+
+ Furthermore, the first positional argument srctree in this case
+ identifies where the ``devtool add`` command will locate the
+ extracted code outside of the workspace. You need to specify an
+ empty directory:
+ ::
+
+ $ devtool add recipe srctree fetchuri
+
+ In summary,
+ the source code is pulled from fetchuri and extracted into the
+ location defined by srctree as a local Git repository.
+
+ Within workspace, ``devtool`` creates a recipe named recipe along
+ with an associated append file.
+
+ - *Right*: The right scenario in the figure represents a situation
+ where the srctree has been previously prepared outside of the
+ ``devtool`` workspace.
+
+ The following command provides a new recipe name and identifies
+ the existing source tree location:
+ ::
+
+ $ devtool add recipe srctree
+
+ The command examines the source code and creates a recipe named
+ recipe for the code and places the recipe into the workspace.
+
+ Because the extracted source code already exists, ``devtool`` does
+ not try to relocate the source code into the workspace - only the
+ new recipe is placed in the workspace.
+
+ Aside from a recipe folder, the command also creates an associated
+ append folder and places an initial ``*.bbappend`` file within.
+
+2. *Edit the Recipe*: You can use ``devtool edit-recipe`` to open up the
+ editor as defined by the ``$EDITOR`` environment variable and modify
+ the file:
+ ::
+
+ $ devtool edit-recipe recipe
+
+ From within the editor, you
+ can make modifications to the recipe that take affect when you build
+ it later.
+
+3. *Build the Recipe or Rebuild the Image*: The next step you take
+ depends on what you are going to do with the new code.
+
+ If you need to eventually move the build output to the target
+ hardware, use the following ``devtool`` command:
+ :;
+
+ $ devtool build recipe
+
+ On the other hand, if you want an image to contain the recipe's
+ packages from the workspace for immediate deployment onto a device
+ (e.g. for testing purposes), you can use the ``devtool build-image``
+ command:
+ ::
+
+ $ devtool build-image image
+
+4. *Deploy the Build Output*: When you use the ``devtool build`` command
+ to build out your recipe, you probably want to see if the resulting
+ build output works as expected on the target hardware.
+
+ .. note::
+
+ This step assumes you have a previously built image that is
+ already either running in QEMU or is running on actual hardware.
+ Also, it is assumed that for deployment of the image to the
+ target, SSH is installed in the image and, if the image is running
+ on real hardware, you have network access to and from your
+ development machine.
+
+ You can deploy your build output to that target hardware by using the
+ ``devtool deploy-target`` command: $ devtool deploy-target recipe
+ target The target is a live target machine running as an SSH server.
+
+ You can, of course, also deploy the image you build to actual
+ hardware by using the ``devtool build-image`` command. However,
+ ``devtool`` does not provide a specific command that allows you to
+ deploy the image to actual hardware.
+
+5. *Finish Your Work With the Recipe*: The ``devtool finish`` command
+ creates any patches corresponding to commits in the local Git
+ repository, moves the new recipe to a more permanent layer, and then
+ resets the recipe so that the recipe is built normally rather than
+ from the workspace.
+ ::
+
+ $ devtool finish recipe layer
+
+ .. note::
+
+ Any changes you want to turn into patches must be committed to the
+ Git repository in the source tree.
+
+ As mentioned, the ``devtool finish`` command moves the final recipe
+ to its permanent layer.
+
+ As a final process of the ``devtool finish`` command, the state of
+ the standard layers and the upstream source is restored so that you
+ can build the recipe from those areas rather than the workspace.
+
+ .. note::
+
+ You can use the
+ devtool reset
+ command to put things back should you decide you do not want to
+ proceed with your work. If you do use this command, realize that
+ the source tree is preserved.
+
+.. _sdk-devtool-use-devtool-modify-to-modify-the-source-of-an-existing-component:
+
+Use ``devtool modify`` to Modify the Source of an Existing Component
+--------------------------------------------------------------------
+
+The ``devtool modify`` command prepares the way to work on existing code
+that already has a local recipe in place that is used to build the
+software. The command is flexible enough to allow you to extract code
+from an upstream source, specify the existing recipe, and keep track of
+and gather any patch files from other developers that are associated
+with the code.
+
+Depending on your particular scenario, the arguments and options you use
+with ``devtool modify`` form different combinations. The following
+diagram shows common development flows for the ``devtool modify``
+command:
+
+.. image:: figures/sdk-devtool-modify-flow.png
+ :align: center
+
+1. *Preparing to Modify the Code*: The top part of the flow shows three
+ scenarios by which you could use ``devtool modify`` to prepare to
+ work on source files. Each scenario assumes the following:
+
+ - The recipe exists locally in a layer external to the ``devtool``
+ workspace.
+
+ - The source files exist either upstream in an un-extracted state or
+ locally in a previously extracted state.
+
+ The typical situation is where another developer has created a layer
+ for use with the Yocto Project and their recipe already resides in
+ that layer. Furthermore, their source code is readily available
+ either upstream or locally.
+
+ - *Left*: The left scenario in the figure represents a common
+ situation where the source code does not exist locally and it
+ needs to be extracted from an upstream source. In this situation,
+ the source is extracted into the default ``devtool`` workspace
+ location. The recipe, in this scenario, is in its own layer
+ outside the workspace (i.e. ``meta-``\ layername).
+
+ The following command identifies the recipe and, by default,
+ extracts the source files:
+ ::
+
+ $ devtool modify recipe
+
+ Once
+ ``devtool``\ locates the recipe, ``devtool`` uses the recipe's
+ :term:`SRC_URI` statements to
+ locate the source code and any local patch files from other
+ developers.
+
+ With this scenario, no srctree argument exists. Consequently, the
+ default behavior of the ``devtool modify`` command is to extract
+ the source files pointed to by the ``SRC_URI`` statements into a
+ local Git structure. Furthermore, the location for the extracted
+ source is the default area within the ``devtool`` workspace. The
+ result is that the command sets up both the source code and an
+ append file within the workspace while the recipe remains in its
+ original location.
+
+ Additionally, if you have any non-patch local files (i.e. files
+ referred to with ``file://`` entries in ``SRC_URI`` statement
+ excluding ``*.patch/`` or ``*.diff``), these files are copied to
+ an ``oe-local-files`` folder under the newly created source tree.
+ Copying the files here gives you a convenient area from which you
+ can modify the files. Any changes or additions you make to those
+ files are incorporated into the build the next time you build the
+ software just as are other changes you might have made to the
+ source.
+
+ - *Middle*: The middle scenario in the figure represents a situation
+ where the source code also does not exist locally. In this case,
+ the code is again upstream and needs to be extracted to some local
+ area as a Git repository. The recipe, in this scenario, is again
+ local and in its own layer outside the workspace.
+
+ The following command tells ``devtool`` the recipe with which to
+ work and, in this case, identifies a local area for the extracted
+ source files that exists outside of the default ``devtool``
+ workspace:
+ ::
+
+ $ devtool modify recipe srctree
+
+ .. note::
+
+ You cannot provide a URL for
+ srctree
+ using the
+ devtool
+ command.
+
+ As with all extractions, the command uses the recipe's ``SRC_URI``
+ statements to locate the source files and any associated patch
+ files. Non-patch files are copied to an ``oe-local-files`` folder
+ under the newly created source tree.
+
+ Once the files are located, the command by default extracts them
+ into srctree.
+
+ Within workspace, ``devtool`` creates an append file for the
+ recipe. The recipe remains in its original location but the source
+ files are extracted to the location you provide with srctree.
+
+ - *Right*: The right scenario in the figure represents a situation
+ where the source tree (srctree) already exists locally as a
+ previously extracted Git structure outside of the ``devtool``
+ workspace. In this example, the recipe also exists elsewhere
+ locally in its own layer.
+
+ The following command tells ``devtool`` the recipe with which to
+ work, uses the "-n" option to indicate source does not need to be
+ extracted, and uses srctree to point to the previously extracted
+ source files:
+ ::
+
+ $ devtool modify -n recipe srctree
+
+ If an ``oe-local-files`` subdirectory happens to exist and it
+ contains non-patch files, the files are used. However, if the
+ subdirectory does not exist and you run the ``devtool finish``
+ command, any non-patch files that might exist next to the recipe
+ are removed because it appears to ``devtool`` that you have
+ deleted those files.
+
+ Once the ``devtool modify`` command finishes, it creates only an
+ append file for the recipe in the ``devtool`` workspace. The
+ recipe and the source code remain in their original locations.
+
+2. *Edit the Source*: Once you have used the ``devtool modify`` command,
+ you are free to make changes to the source files. You can use any
+ editor you like to make and save your source code modifications.
+
+3. *Build the Recipe or Rebuild the Image*: The next step you take
+ depends on what you are going to do with the new code.
+
+ If you need to eventually move the build output to the target
+ hardware, use the following ``devtool`` command:
+ ::
+
+ $ devtool build recipe
+
+ On the other hand, if you want an image to contain the recipe's
+ packages from the workspace for immediate deployment onto a device
+ (e.g. for testing purposes), you can use the ``devtool build-image``
+ command: $ devtool build-image image
+
+4. *Deploy the Build Output*: When you use the ``devtool build`` command
+ to build out your recipe, you probably want to see if the resulting
+ build output works as expected on target hardware.
+
+ .. note::
+
+ This step assumes you have a previously built image that is
+ already either running in QEMU or running on actual hardware.
+ Also, it is assumed that for deployment of the image to the
+ target, SSH is installed in the image and if the image is running
+ on real hardware that you have network access to and from your
+ development machine.
+
+ You can deploy your build output to that target hardware by using the
+ ``devtool deploy-target`` command:
+ ::
+
+ $ devtool deploy-target recipe target
+
+ The target is a live target machine running as an SSH server.
+
+ You can, of course, use other methods to deploy the image you built
+ using the ``devtool build-image`` command to actual hardware.
+ ``devtool`` does not provide a specific command to deploy the image
+ to actual hardware.
+
+5. *Finish Your Work With the Recipe*: The ``devtool finish`` command
+ creates any patches corresponding to commits in the local Git
+ repository, updates the recipe to point to them (or creates a
+ ``.bbappend`` file to do so, depending on the specified destination
+ layer), and then resets the recipe so that the recipe is built
+ normally rather than from the workspace.
+ ::
+
+ $ devtool finish recipe layer
+
+ .. note::
+
+ Any changes you want to turn into patches must be staged and
+ committed within the local Git repository before you use the
+ devtool finish
+ command.
+
+ Because there is no need to move the recipe, ``devtool finish``
+ either updates the original recipe in the original layer or the
+ command creates a ``.bbappend`` file in a different layer as provided
+ by layer. Any work you did in the ``oe-local-files`` directory is
+ preserved in the original files next to the recipe during the
+ ``devtool finish`` command.
+
+ As a final process of the ``devtool finish`` command, the state of
+ the standard layers and the upstream source is restored so that you
+ can build the recipe from those areas rather than from the workspace.
+
+ .. note::
+
+ You can use the
+ devtool reset
+ command to put things back should you decide you do not want to
+ proceed with your work. If you do use this command, realize that
+ the source tree is preserved.
+
+.. _sdk-devtool-use-devtool-upgrade-to-create-a-version-of-the-recipe-that-supports-a-newer-version-of-the-software:
+
+Use ``devtool upgrade`` to Create a Version of the Recipe that Supports a Newer Version of the Software
+-------------------------------------------------------------------------------------------------------
+
+The ``devtool upgrade`` command upgrades an existing recipe to that of a
+more up-to-date version found upstream. Throughout the life of software,
+recipes continually undergo version upgrades by their upstream
+publishers. You can use the ``devtool upgrade`` workflow to make sure
+your recipes you are using for builds are up-to-date with their upstream
+counterparts.
+
+.. note::
+
+ Several methods exist by which you can upgrade recipes -
+ devtool upgrade
+ happens to be one. You can read about all the methods by which you
+ can upgrade recipes in the "
+ Upgrading Recipes
+ " section of the Yocto Project Development Tasks Manual.
+
+The ``devtool upgrade`` command is flexible enough to allow you to
+specify source code revision and versioning schemes, extract code into
+or out of the ``devtool``
+:ref:`devtool-the-workspace-layer-structure`,
+and work with any source file forms that the
+:ref:`fetchers <bitbake:bb-fetchers>` support.
+
+The following diagram shows the common development flow used with the
+``devtool upgrade`` command:
+
+.. image:: figures/sdk-devtool-upgrade-flow.png
+ :align: center
+
+1. *Initiate the Upgrade*: The top part of the flow shows the typical
+ scenario by which you use the ``devtool upgrade`` command. The
+ following conditions exist:
+
+ - The recipe exists in a local layer external to the ``devtool``
+ workspace.
+
+ - The source files for the new release exist in the same location
+ pointed to by :term:`SRC_URI`
+ in the recipe (e.g. a tarball with the new version number in the
+ name, or as a different revision in the upstream Git repository).
+
+ A common situation is where third-party software has undergone a
+ revision so that it has been upgraded. The recipe you have access to
+ is likely in your own layer. Thus, you need to upgrade the recipe to
+ use the newer version of the software:
+ ::
+
+ $ devtool upgrade -V version recipe
+
+ By default, the ``devtool upgrade`` command extracts source
+ code into the ``sources`` directory in the
+ :ref:`devtool-the-workspace-layer-structure`.
+ If you want the code extracted to any other location, you need to
+ provide the srctree positional argument with the command as follows:
+ $ devtool upgrade -V version recipe srctree
+
+ .. note::
+
+ In this example, the "-V" option specifies the new version. If you
+ don't use "-V", the command upgrades the recipe to the latest
+ version.
+
+ If the source files pointed to by the ``SRC_URI`` statement in the
+ recipe are in a Git repository, you must provide the "-S" option and
+ specify a revision for the software.
+
+ Once ``devtool`` locates the recipe, it uses the ``SRC_URI`` variable
+ to locate the source code and any local patch files from other
+ developers. The result is that the command sets up the source code,
+ the new version of the recipe, and an append file all within the
+ workspace.
+
+ Additionally, if you have any non-patch local files (i.e. files
+ referred to with ``file://`` entries in ``SRC_URI`` statement
+ excluding ``*.patch/`` or ``*.diff``), these files are copied to an
+ ``oe-local-files`` folder under the newly created source tree.
+ Copying the files here gives you a convenient area from which you can
+ modify the files. Any changes or additions you make to those files
+ are incorporated into the build the next time you build the software
+ just as are other changes you might have made to the source.
+
+2. *Resolve any Conflicts created by the Upgrade*: Conflicts could exist
+ due to the software being upgraded to a new version. Conflicts occur
+ if your recipe specifies some patch files in ``SRC_URI`` that
+ conflict with changes made in the new version of the software. For
+ such cases, you need to resolve the conflicts by editing the source
+ and following the normal ``git rebase`` conflict resolution process.
+
+ Before moving onto the next step, be sure to resolve any such
+ conflicts created through use of a newer or different version of the
+ software.
+
+3. *Build the Recipe or Rebuild the Image*: The next step you take
+ depends on what you are going to do with the new code.
+
+ If you need to eventually move the build output to the target
+ hardware, use the following ``devtool`` command:
+ ::
+
+ $ devtool build recipe
+
+ On the other hand, if you want an image to contain the recipe's
+ packages from the workspace for immediate deployment onto a device
+ (e.g. for testing purposes), you can use the ``devtool build-image``
+ command:
+ ::
+
+ $ devtool build-image image
+
+4. *Deploy the Build Output*: When you use the ``devtool build`` command
+ or ``bitbake`` to build your recipe, you probably want to see if the
+ resulting build output works as expected on target hardware.
+
+ .. note::
+
+ This step assumes you have a previously built image that is
+ already either running in QEMU or running on actual hardware.
+ Also, it is assumed that for deployment of the image to the
+ target, SSH is installed in the image and if the image is running
+ on real hardware that you have network access to and from your
+ development machine.
+
+ You can deploy your build output to that target hardware by using the
+ ``devtool deploy-target`` command: $ devtool deploy-target recipe
+ target The target is a live target machine running as an SSH server.
+
+ You can, of course, also deploy the image you build using the
+ ``devtool build-image`` command to actual hardware. However,
+ ``devtool`` does not provide a specific command that allows you to do
+ this.
+
+5. *Finish Your Work With the Recipe*: The ``devtool finish`` command
+ creates any patches corresponding to commits in the local Git
+ repository, moves the new recipe to a more permanent layer, and then
+ resets the recipe so that the recipe is built normally rather than
+ from the workspace.
+
+ Any work you did in the ``oe-local-files`` directory is preserved in
+ the original files next to the recipe during the ``devtool finish``
+ command.
+
+ If you specify a destination layer that is the same as the original
+ source, then the old version of the recipe and associated files are
+ removed prior to adding the new version.
+ ::
+
+ $ devtool finish recipe layer
+
+ .. note::
+
+ Any changes you want to turn into patches must be committed to the
+ Git repository in the source tree.
+
+ As a final process of the ``devtool finish`` command, the state of
+ the standard layers and the upstream source is restored so that you
+ can build the recipe from those areas rather than the workspace.
+
+ .. note::
+
+ You can use the
+ devtool reset
+ command to put things back should you decide you do not want to
+ proceed with your work. If you do use this command, realize that
+ the source tree is preserved.
+
+.. _sdk-a-closer-look-at-devtool-add:
+
+A Closer Look at ``devtool add``
+================================
+
+The ``devtool add`` command automatically creates a recipe based on the
+source tree you provide with the command. Currently, the command has
+support for the following:
+
+- Autotools (``autoconf`` and ``automake``)
+
+- CMake
+
+- Scons
+
+- ``qmake``
+
+- Plain ``Makefile``
+
+- Out-of-tree kernel module
+
+- Binary package (i.e. "-b" option)
+
+- Node.js module
+
+- Python modules that use ``setuptools`` or ``distutils``
+
+Apart from binary packages, the determination of how a source tree
+should be treated is automatic based on the files present within that
+source tree. For example, if a ``CMakeLists.txt`` file is found, then
+the source tree is assumed to be using CMake and is treated accordingly.
+
+.. note::
+
+ In most cases, you need to edit the automatically generated recipe in
+ order to make it build properly. Typically, you would go through
+ several edit and build cycles until the recipe successfully builds.
+ Once the recipe builds, you could use possible further iterations to
+ test the recipe on the target device.
+
+The remainder of this section covers specifics regarding how parts of
+the recipe are generated.
+
+.. _sdk-name-and-version:
+
+Name and Version
+----------------
+
+If you do not specify a name and version on the command line,
+``devtool add`` uses various metadata within the source tree in an
+attempt to determine the name and version of the software being built.
+Based on what the tool determines, ``devtool`` sets the name of the
+created recipe file accordingly.
+
+If ``devtool`` cannot determine the name and version, the command prints
+an error. For such cases, you must re-run the command and provide the
+name and version, just the name, or just the version as part of the
+command line.
+
+Sometimes the name or version determined from the source tree might be
+incorrect. For such a case, you must reset the recipe:
+::
+
+ $ devtool reset -n recipename
+
+After running the ``devtool reset`` command, you need to
+run ``devtool add`` again and provide the name or the version.
+
+.. _sdk-dependency-detection-and-mapping:
+
+Dependency Detection and Mapping
+--------------------------------
+
+The ``devtool add`` command attempts to detect build-time dependencies
+and map them to other recipes in the system. During this mapping, the
+command fills in the names of those recipes as part of the
+:term:`DEPENDS` variable within the
+recipe. If a dependency cannot be mapped, ``devtool`` places a comment
+in the recipe indicating such. The inability to map a dependency can
+result from naming not being recognized or because the dependency simply
+is not available. For cases where the dependency is not available, you
+must use the ``devtool add`` command to add an additional recipe that
+satisfies the dependency. Once you add that recipe, you need to update
+the ``DEPENDS`` variable in the original recipe to include the new
+recipe.
+
+If you need to add runtime dependencies, you can do so by adding the
+following to your recipe:
+::
+
+ RDEPENDS_${PN} += "dependency1 dependency2 ..."
+
+.. note::
+
+ The
+ devtool add
+ command often cannot distinguish between mandatory and optional
+ dependencies. Consequently, some of the detected dependencies might
+ in fact be optional. When in doubt, consult the documentation or the
+ configure script for the software the recipe is building for further
+ details. In some cases, you might find you can substitute the
+ dependency with an option that disables the associated functionality
+ passed to the configure script.
+
+.. _sdk-license-detection:
+
+License Detection
+-----------------
+
+The ``devtool add`` command attempts to determine if the software you
+are adding is able to be distributed under a common, open-source
+license. If so, the command sets the
+:term:`LICENSE` value accordingly.
+You should double-check the value added by the command against the
+documentation or source files for the software you are building and, if
+necessary, update that ``LICENSE`` value.
+
+The ``devtool add`` command also sets the
+:term:`LIC_FILES_CHKSUM`
+value to point to all files that appear to be license-related. Realize
+that license statements often appear in comments at the top of source
+files or within the documentation. In such cases, the command does not
+recognize those license statements. Consequently, you might need to
+amend the ``LIC_FILES_CHKSUM`` variable to point to one or more of those
+comments if present. Setting ``LIC_FILES_CHKSUM`` is particularly
+important for third-party software. The mechanism attempts to ensure
+correct licensing should you upgrade the recipe to a newer upstream
+version in future. Any change in licensing is detected and you receive
+an error prompting you to check the license text again.
+
+If the ``devtool add`` command cannot determine licensing information,
+``devtool`` sets the ``LICENSE`` value to "CLOSED" and leaves the
+``LIC_FILES_CHKSUM`` value unset. This behavior allows you to continue
+with development even though the settings are unlikely to be correct in
+all cases. You should check the documentation or source files for the
+software you are building to determine the actual license.
+
+.. _sdk-adding-makefile-only-software:
+
+Adding Makefile-Only Software
+-----------------------------
+
+The use of Make by itself is very common in both proprietary and
+open-source software. Unfortunately, Makefiles are often not written
+with cross-compilation in mind. Thus, ``devtool add`` often cannot do
+very much to ensure that these Makefiles build correctly. It is very
+common, for example, to explicitly call ``gcc`` instead of using the
+:term:`CC` variable. Usually, in a
+cross-compilation environment, ``gcc`` is the compiler for the build
+host and the cross-compiler is named something similar to
+``arm-poky-linux-gnueabi-gcc`` and might require arguments (e.g. to
+point to the associated sysroot for the target machine).
+
+When writing a recipe for Makefile-only software, keep the following in
+mind:
+
+- You probably need to patch the Makefile to use variables instead of
+ hardcoding tools within the toolchain such as ``gcc`` and ``g++``.
+
+- The environment in which Make runs is set up with various standard
+ variables for compilation (e.g. ``CC``, ``CXX``, and so forth) in a
+ similar manner to the environment set up by the SDK's environment
+ setup script. One easy way to see these variables is to run the
+ ``devtool build`` command on the recipe and then look in
+ ``oe-logs/run.do_compile``. Towards the top of this file, a list of
+ environment variables exists that are being set. You can take
+ advantage of these variables within the Makefile.
+
+- If the Makefile sets a default for a variable using "=", that default
+ overrides the value set in the environment, which is usually not
+ desirable. For this case, you can either patch the Makefile so it
+ sets the default using the "?=" operator, or you can alternatively
+ force the value on the ``make`` command line. To force the value on
+ the command line, add the variable setting to
+ :term:`EXTRA_OEMAKE` or
+ :term:`PACKAGECONFIG_CONFARGS`
+ within the recipe. Here is an example using ``EXTRA_OEMAKE``:
+ ::
+
+ EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'"
+
+ In the above example,
+ single quotes are used around the variable settings as the values are
+ likely to contain spaces because required default options are passed
+ to the compiler.
+
+- Hardcoding paths inside Makefiles is often problematic in a
+ cross-compilation environment. This is particularly true because
+ those hardcoded paths often point to locations on the build host and
+ thus will either be read-only or will introduce contamination into
+ the cross-compilation because they are specific to the build host
+ rather than the target. Patching the Makefile to use prefix variables
+ or other path variables is usually the way to handle this situation.
+
+- Sometimes a Makefile runs target-specific commands such as
+ ``ldconfig``. For such cases, you might be able to apply patches that
+ remove these commands from the Makefile.
+
+.. _sdk-adding-native-tools:
+
+Adding Native Tools
+-------------------
+
+Often, you need to build additional tools that run on the :term:`Build
+Host` as opposed to
+the target. You should indicate this requirement by using one of the
+following methods when you run ``devtool add``:
+
+- Specify the name of the recipe such that it ends with "-native".
+ Specifying the name like this produces a recipe that only builds for
+ the build host.
+
+- Specify the "DASHDASHalso-native" option with the ``devtool add``
+ command. Specifying this option creates a recipe file that still
+ builds for the target but also creates a variant with a "-native"
+ suffix that builds for the build host.
+
+.. note::
+
+ If you need to add a tool that is shipped as part of a source tree
+ that builds code for the target, you can typically accomplish this by
+ building the native and target parts separately rather than within
+ the same compilation process. Realize though that with the
+ "DASHDASHalso-native" option, you can add the tool using just one
+ recipe file.
+
+.. _sdk-adding-node-js-modules:
+
+Adding Node.js Modules
+----------------------
+
+You can use the ``devtool add`` command two different ways to add
+Node.js modules: 1) Through ``npm`` and, 2) from a repository or local
+source.
+
+Use the following form to add Node.js modules through ``npm``:
+::
+
+ $ devtool add "npm://registry.npmjs.org;name=forever;version=0.15.1"
+
+The name and
+version parameters are mandatory. Lockdown and shrinkwrap files are
+generated and pointed to by the recipe in order to freeze the version
+that is fetched for the dependencies according to the first time. This
+also saves checksums that are verified on future fetches. Together,
+these behaviors ensure the reproducibility and integrity of the build.
+
+.. note::
+
+ - You must use quotes around the URL. The ``devtool add`` does not
+ require the quotes, but the shell considers ";" as a splitter
+ between multiple commands. Thus, without the quotes,
+ ``devtool add`` does not receive the other parts, which results in
+ several "command not found" errors.
+
+ - In order to support adding Node.js modules, a ``nodejs`` recipe
+ must be part of your SDK.
+
+As mentioned earlier, you can also add Node.js modules directly from a
+repository or local source tree. To add modules this way, use
+``devtool add`` in the following form:
+::
+
+ $ devtool add https://github.com/diversario/node-ssdp
+
+In this example, ``devtool``
+fetches the specified Git repository, detects the code as Node.js code,
+fetches dependencies using ``npm``, and sets
+:term:`SRC_URI` accordingly.
+
+.. _sdk-working-with-recipes:
+
+Working With Recipes
+====================
+
+When building a recipe using the ``devtool build`` command, the typical
+build progresses as follows:
+
+1. Fetch the source
+
+2. Unpack the source
+
+3. Configure the source
+
+4. Compile the source
+
+5. Install the build output
+
+6. Package the installed output
+
+For recipes in the workspace, fetching and unpacking is disabled as the
+source tree has already been prepared and is persistent. Each of these
+build steps is defined as a function (task), usually with a "do\_" prefix
+(e.g. :ref:`ref-tasks-fetch`,
+:ref:`ref-tasks-unpack`, and so
+forth). These functions are typically shell scripts but can instead be
+written in Python.
+
+If you look at the contents of a recipe, you will see that the recipe
+does not include complete instructions for building the software.
+Instead, common functionality is encapsulated in classes inherited with
+the ``inherit`` directive. This technique leaves the recipe to describe
+just the things that are specific to the software being built. A
+:ref:`base <ref-classes-base>` class exists that
+is implicitly inherited by all recipes and provides the functionality
+that most recipes typically need.
+
+The remainder of this section presents information useful when working
+with recipes.
+
+.. _sdk-finding-logs-and-work-files:
+
+Finding Logs and Work Files
+---------------------------
+
+After the first run of the ``devtool build`` command, recipes that were
+previously created using the ``devtool add`` command or whose sources
+were modified using the ``devtool modify`` command contain symbolic
+links created within the source tree:
+
+- ``oe-logs``: This link points to the directory in which log files and
+ run scripts for each build step are created.
+
+- ``oe-workdir``: This link points to the temporary work area for the
+ recipe. The following locations under ``oe-workdir`` are particularly
+ useful:
+
+ - ``image/``: Contains all of the files installed during the
+ :ref:`ref-tasks-install` stage.
+ Within a recipe, this directory is referred to by the expression
+ ``${``\ :term:`D`\ ``}``.
+
+ - ``sysroot-destdir/``: Contains a subset of files installed within
+ ``do_install`` that have been put into the shared sysroot. For
+ more information, see the "`Sharing Files Between
+ Recipes <#sdk-sharing-files-between-recipes>`__" section.
+
+ - ``packages-split/``: Contains subdirectories for each package
+ produced by the recipe. For more information, see the
+ "`Packaging <#sdk-packaging>`__" section.
+
+You can use these links to get more information on what is happening at
+each build step.
+
+.. _sdk-setting-configure-arguments:
+
+Setting Configure Arguments
+---------------------------
+
+If the software your recipe is building uses GNU autoconf, then a fixed
+set of arguments is passed to it to enable cross-compilation plus any
+extras specified by
+:term:`EXTRA_OECONF` or
+:term:`PACKAGECONFIG_CONFARGS`
+set within the recipe. If you wish to pass additional options, add them
+to ``EXTRA_OECONF`` or ``PACKAGECONFIG_CONFARGS``. Other supported build
+tools have similar variables (e.g.
+:term:`EXTRA_OECMAKE` for
+CMake, :term:`EXTRA_OESCONS`
+for Scons, and so forth). If you need to pass anything on the ``make``
+command line, you can use ``EXTRA_OEMAKE`` or the
+:term:`PACKAGECONFIG_CONFARGS`
+variables to do so.
+
+You can use the ``devtool configure-help`` command to help you set the
+arguments listed in the previous paragraph. The command determines the
+exact options being passed, and shows them to you along with any custom
+arguments specified through ``EXTRA_OECONF`` or
+``PACKAGECONFIG_CONFARGS``. If applicable, the command also shows you
+the output of the configure script's "DASHDASHhelp" option as a
+reference.
+
+.. _sdk-sharing-files-between-recipes:
+
+Sharing Files Between Recipes
+-----------------------------
+
+Recipes often need to use files provided by other recipes on the
+:term:`Build Host`. For example,
+an application linking to a common library needs access to the library
+itself and its associated headers. The way this access is accomplished
+within the extensible SDK is through the sysroot. One sysroot exists per
+"machine" for which the SDK is being built. In practical terms, this
+means a sysroot exists for the target machine, and a sysroot exists for
+the build host.
+
+Recipes should never write files directly into the sysroot. Instead,
+files should be installed into standard locations during the
+:ref:`ref-tasks-install` task within
+the ``${``\ :term:`D`\ ``}`` directory. A
+subset of these files automatically goes into the sysroot. The reason
+for this limitation is that almost all files that go into the sysroot
+are cataloged in manifests in order to ensure they can be removed later
+when a recipe is modified or removed. Thus, the sysroot is able to
+remain free from stale files.
+
+.. _sdk-packaging:
+
+Packaging
+---------
+
+Packaging is not always particularly relevant within the extensible SDK.
+However, if you examine how build output gets into the final image on
+the target device, it is important to understand packaging because the
+contents of the image are expressed in terms of packages and not
+recipes.
+
+During the :ref:`ref-tasks-package`
+task, files installed during the
+:ref:`ref-tasks-install` task are
+split into one main package, which is almost always named the same as
+the recipe, and into several other packages. This separation exists
+because not all of those installed files are useful in every image. For
+example, you probably do not need any of the documentation installed in
+a production image. Consequently, for each recipe the documentation
+files are separated into a ``-doc`` package. Recipes that package
+software containing optional modules or plugins might undergo additional
+package splitting as well.
+
+After building a recipe, you can see where files have gone by looking in
+the ``oe-workdir/packages-split`` directory, which contains a
+subdirectory for each package. Apart from some advanced cases, the
+:term:`PACKAGES` and
+:term:`FILES` variables controls
+splitting. The ``PACKAGES`` variable lists all of the packages to be
+produced, while the ``FILES`` variable specifies which files to include
+in each package by using an override to specify the package. For
+example, ``FILES_${PN}`` specifies the files to go into the main package
+(i.e. the main package has the same name as the recipe and
+``${``\ :term:`PN`\ ``}`` evaluates to the
+recipe name). The order of the ``PACKAGES`` value is significant. For
+each installed file, the first package whose ``FILES`` value matches the
+file is the package into which the file goes. Defaults exist for both
+the ``PACKAGES`` and ``FILES`` variables. Consequently, you might find
+you do not even need to set these variables in your recipe unless the
+software the recipe is building installs files into non-standard
+locations.
+
+.. _sdk-restoring-the-target-device-to-its-original-state:
+
+Restoring the Target Device to its Original State
+=================================================
+
+If you use the ``devtool deploy-target`` command to write a recipe's
+build output to the target, and you are working on an existing component
+of the system, then you might find yourself in a situation where you
+need to restore the original files that existed prior to running the
+``devtool deploy-target`` command. Because the ``devtool deploy-target``
+command backs up any files it overwrites, you can use the
+``devtool undeploy-target`` command to restore those files and remove
+any other files the recipe deployed. Consider the following example:
+::
+
+ $ devtool undeploy-target lighttpd root@192.168.7.2
+
+If you have deployed
+multiple applications, you can remove them all using the "-a" option
+thus restoring the target device to its original state:
+::
+
+ $ devtool undeploy-target -a root@192.168.7.2
+
+Information about files deployed to
+the target as well as any backed up files are stored on the target
+itself. This storage, of course, requires some additional space on the
+target machine.
+
+.. note::
+
+ The
+ devtool deploy-target
+ and
+ devtool undeploy-target
+ commands do not currently interact with any package management system
+ on the target device (e.g. RPM or OPKG). Consequently, you should not
+ intermingle
+ devtool deploy-target
+ and package manager operations on the target device. Doing so could
+ result in a conflicting set of files.
+
+.. _sdk-installing-additional-items-into-the-extensible-sdk:
+
+Installing Additional Items Into the Extensible SDK
+===================================================
+
+Out of the box the extensible SDK typically only comes with a small
+number of tools and libraries. A minimal SDK starts mostly empty and is
+populated on-demand. Sometimes you must explicitly install extra items
+into the SDK. If you need these extra items, you can first search for
+the items using the ``devtool search`` command. For example, suppose you
+need to link to libGL but you are not sure which recipe provides libGL.
+You can use the following command to find out:
+::
+
+ $ devtool search libGL mesa
+
+A free implementation of the OpenGL API Once you know the recipe
+(i.e. ``mesa`` in this example), you can install it:
+::
+
+ $ devtool sdk-install mesa
+
+By default, the ``devtool sdk-install`` command assumes
+the item is available in pre-built form from your SDK provider. If the
+item is not available and it is acceptable to build the item from
+source, you can add the "-s" option as follows:
+::
+
+ $ devtool sdk-install -s mesa
+
+It is important to remember that building the item from source
+takes significantly longer than installing the pre-built artifact. Also,
+if no recipe exists for the item you want to add to the SDK, you must
+instead add the item using the ``devtool add`` command.
+
+.. _sdk-applying-updates-to-an-installed-extensible-sdk:
+
+Applying Updates to an Installed Extensible SDK
+===============================================
+
+If you are working with an installed extensible SDK that gets
+occasionally updated (e.g. a third-party SDK), then you will need to
+manually "pull down" the updates into the installed SDK.
+
+To update your installed SDK, use ``devtool`` as follows:
+::
+
+ $ devtool sdk-update
+
+The previous command assumes your SDK provider has set the
+default update URL for you through the
+:term:`SDK_UPDATE_URL`
+variable as described in the "`Providing Updates to the Extensible SDK
+After
+Installation <#sdk-providing-updates-to-the-extensible-sdk-after-installation>`__"
+section. If the SDK provider has not set that default URL, you need to
+specify it yourself in the command as follows: $ devtool sdk-update
+path_to_update_directory
+
+.. note::
+
+ The URL needs to point specifically to a published SDK and not to an
+ SDK installer that you would download and install.
+
+.. _sdk-creating-a-derivative-sdk-with-additional-components:
+
+Creating a Derivative SDK With Additional Components
+====================================================
+
+You might need to produce an SDK that contains your own custom
+libraries. A good example would be if you were a vendor with customers
+that use your SDK to build their own platform-specific software and
+those customers need an SDK that has custom libraries. In such a case,
+you can produce a derivative SDK based on the currently installed SDK
+fairly easily by following these steps:
+
+1. If necessary, install an extensible SDK that you want to use as a
+ base for your derivative SDK.
+
+2. Source the environment script for the SDK.
+
+3. Add the extra libraries or other components you want by using the
+ ``devtool add`` command.
+
+4. Run the ``devtool build-sdk`` command.
+
+The previous steps take the recipes added to the workspace and construct
+a new SDK installer that contains those recipes and the resulting binary
+artifacts. The recipes go into their own separate layer in the
+constructed derivative SDK, which leaves the workspace clean and ready
+for users to add their own recipes.