diff options
| author |   takeshi_hoshina <takeshi_hoshina@mail.toyota.co.jp> | 2020-11-02 11:07:33 +0900 |
|---|---|---|
| committer | takeshi_hoshina <takeshi_hoshina@mail.toyota.co.jp> | 2020-11-02 11:07:33 +0900 |
| commit | 1c7d6584a7811b7785ae5c1e378f14b5ba0971cf (patch) | |
| tree | cd70a267a5ef105ba32f200aa088e281fbd85747 /external/poky/documentation | |
| parent | 4204309872da5cb401cbb2729d9e2d4869a87f42 (diff) | |
basesystem-jjsandbox/ToshikazuOhiwa/master-jj
recipes
Diffstat (limited to 'external/poky/documentation')
61 files changed, 3548 insertions, 4892 deletions
diff --git a/external/poky/documentation/Makefile b/external/poky/documentation/Makefile index 0566a0f3..15644bf9 100644 --- a/external/poky/documentation/Makefile +++ b/external/poky/documentation/Makefile @@ -4,24 +4,17 @@ # in any manuals must be .PNG files and live in the individual book's figures # directory as well as in the figures directory for the mega-manual. # -# Some manuals are available as linked help through the Eclipse development -# system. These manuals also include an "eclipse" sub-directory as part of -# the make process. -# # Note that the figures for the Yocto Project Development Tasks Manual # differ depending on the BRANCH being built. # # The Makefile has these targets: # all: If you leave off the target then "all" is implied. -# You will generate HTML, eclipse help (if applicable), -# and a tarball of files. +# You will generate HTML and a tarball of files. # # pdf: generates a PDF version of a manual. Not valid for the # Quick Start or the mega-manual (single, large HTML file # comprised of all Yocto Project manuals). # html: generates an HTML version of a manual. -# eclipse: generates an HTML version of a manual that can be used as -# eclipse help (including necessary metadata files). # tarball: creates a tarball for the doc files. # validate: validates # publish: pushes generated files to the Yocto Project website @@ -53,13 +46,13 @@ # make DOC=dev-manual BRANCH=edison # make DOC=mega-manual BRANCH=denzil # -# The first example generates the HTML and Eclipse help versions of the BSP Guide. +# The first example generates the HTML version of the BSP Guide. # The second example generates the HTML version only of the Quick Start. Note # that the Quick Start only has an HTML version available. So, the # 'make DOC=brief-yoctoprojectqs' command would be equivalent. The third example # generates just the PDF version of the Yocto Project Reference Manual. -# The fourth example generates the HTML 'edison' version and (if available) -# the Eclipse help version of the YP Development Tasks Manual. The last example +# The fourth example generates the HTML 'edison' version of the YP Development +# Tasks Manual. The last example # generates the HTML version of the mega-manual and uses the 'denzil' # branch when choosing figures for the tarball of figures. Any example that does # not use the BRANCH argument builds the current version of the manual set. @@ -67,7 +60,7 @@ # The publish target pushes the generated manuals to the Yocto Project # website. Unless you are a developer on the YP team, you will not succeed in # pushing manuals to this server. All files needed for the manual's HTML form are -# pushed as well as applicable Eclipse versions. +# pushed. # # Examples: # @@ -95,10 +88,10 @@ XSLTOPTS = --stringparam html.stylesheet brief-yoctoprojectqs-style.css \ --stringparam section.autolabel 0 \ --stringparam section.label.includes.component.label 0 \ --xinclude -ALLPREQ = html eclipse tarball +ALLPREQ = html tarball TARFILES = brief-yoctoprojectqs-style.css brief-yoctoprojectqs.html figures/bypqs-title.png \ figures/yocto-project-transp.png -MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse +MANUALS = $(DOC)/$(DOC).html FIGURES = figures STYLESHEET = $(DOC)/*.css @@ -106,7 +99,7 @@ endif ifeq ($(DOC),overview-manual) XSLTOPTS = --xinclude -ALLPREQ = html eclipse tarball +ALLPREQ = html tarball TARFILES = overview-manual-style.css overview-manual.html figures/overview-manual-title.png \ figures/git-workflow.png figures/source-repos.png figures/index-downloads.png \ figures/yp-download.png figures/YP-flow-diagram.png figures/key-dev-elements.png \ @@ -115,9 +108,8 @@ TARFILES = overview-manual-style.css overview-manual.html figures/overview-manua figures/package-feeds.png figures/patching.png figures/source-fetching.png \ figures/configuration-compile-autoreconf.png figures/analysis-for-package-splitting.png \ figures/image-generation.png figures/sdk-generation.png figures/images.png \ - figures/sdk.png \ - eclipse -MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse + figures/sdk.png +MANUALS = $(DOC)/$(DOC).html FIGURES = figures STYLESHEET = $(DOC)/*.css @@ -125,11 +117,10 @@ endif ifeq ($(DOC),bsp-guide) XSLTOPTS = --xinclude -ALLPREQ = html eclipse tarball +ALLPREQ = html tarball TARFILES = bsp-style.css bsp-guide.html figures/bsp-title.png \ - figures/bsp-dev-flow.png \ - eclipse -MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse + figures/bsp-dev-flow.png +MANUALS = $(DOC)/$(DOC).html FIGURES = figures STYLESHEET = $(DOC)/*.css @@ -137,7 +128,7 @@ endif ifeq ($(DOC),dev-manual) XSLTOPTS = --xinclude -ALLPREQ = html eclipse tarball +ALLPREQ = html tarball # # Note that the tarfile might produce the "Cannot stat: No such file or # directory" error message for .PNG files that are not present when building @@ -170,11 +161,10 @@ TARFILES = dev-style.css dev-manual.html \ TARFILES = dev-style.css dev-manual.html figures/buildhistory-web.png \ figures/dev-title.png figures/buildhistory.png \ figures/recipe-workflow.png figures/bitbake-build-flow.png \ - figures/multiconfig_files.png \ - eclipse + figures/multiconfig_files.png figures/cute-files-npm-example.png endif -MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse +MANUALS = $(DOC)/$(DOC).html FIGURES = figures STYLESHEET = $(DOC)/*.css @@ -235,7 +225,7 @@ TARFILES = mega-manual.html mega-style.css \ figures/profile-title.png figures/kernelshark-all.png \ figures/kernelshark-choose-events.png \ figures/kernelshark-i915-display.png \ - figures/kernelshark-output-display.png figures/lttngmain0.png \ + figures/kernelshark-output-display.png \ figures/oprofileui-busybox.png figures/oprofileui-copy-to-user.png \ figures/oprofileui-downloading.png figures/oprofileui-processes.png \ figures/perf-probe-do_fork-profile.png \ @@ -272,9 +262,10 @@ TARFILES = mega-manual.html mega-style.css \ figures/compatible-layers.png figures/import-layer.png figures/new-project.png \ figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \ figures/sdk-devtool-add-flow.png figures/sdk-installed-extensible-sdk-directory.png \ - figures/sdk-devtool-modify-flow.png figures/sdk-eclipse-dev-flow.png \ + figures/sdk-devtool-modify-flow.png \ figures/sdk-devtool-upgrade-flow.png figures/bitbake-build-flow.png figures/bypqs-title.png \ - figures/overview-manual-title.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png + figures/overview-manual-title.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png \ + figures/bb_multiconfig_files.png figures/bitbake-title.png figures/cute-files-npm-example.png endif MANUALS = $(DOC)/$(DOC).html @@ -285,37 +276,35 @@ endif ifeq ($(DOC),ref-manual) XSLTOPTS = --xinclude -ALLPREQ = html eclipse tarball +ALLPREQ = html tarball TARFILES = ref-manual.html ref-style.css figures/poky-title.png \ - figures/build-workspace-directory.png \ - eclipse -MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse + figures/build-workspace-directory.png +MANUALS = $(DOC)/$(DOC).html FIGURES = figures STYLESHEET = $(DOC)/*.css endif ifeq ($(DOC),sdk-manual) XSLTOPTS = --xinclude -ALLPREQ = html eclipse tarball +ALLPREQ = html tarball TARFILES = sdk-manual.html sdk-style.css figures/sdk-title.png \ figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \ figures/sdk-installed-extensible-sdk-directory.png figures/sdk-devtool-add-flow.png \ - figures/sdk-devtool-modify-flow.png figures/sdk-eclipse-dev-flow.png \ - figures/sdk-devtool-upgrade-flow.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png \ - eclipse -MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse + figures/sdk-devtool-modify-flow.png \ + figures/sdk-devtool-upgrade-flow.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png +MANUALS = $(DOC)/$(DOC).html FIGURES = figures STYLESHEET = $(DOC)/*.css endif ifeq ($(DOC),profile-manual) XSLTOPTS = --xinclude -ALLPREQ = html eclipse tarball +ALLPREQ = html tarball TARFILES = profile-manual.html profile-manual-style.css \ figures/profile-title.png figures/kernelshark-all.png \ figures/kernelshark-choose-events.png \ figures/kernelshark-i915-display.png \ - figures/kernelshark-output-display.png figures/lttngmain0.png \ + figures/kernelshark-output-display.png \ figures/oprofileui-busybox.png figures/oprofileui-copy-to-user.png \ figures/oprofileui-downloading.png figures/oprofileui-processes.png \ figures/perf-probe-do_fork-profile.png \ @@ -336,21 +325,19 @@ TARFILES = profile-manual.html profile-manual-style.css \ figures/pychart-linux-yocto-rpm.png \ figures/pychart-linux-yocto-rpm-nostrip.png \ figures/sched-wakeup-profile.png figures/sysprof-callers.png \ - figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png \ - eclipse -MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse + figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png +MANUALS = $(DOC)/$(DOC).html FIGURES = figures STYLESHEET = $(DOC)/*.css endif ifeq ($(DOC),kernel-dev) XSLTOPTS = --xinclude -ALLPREQ = html eclipse tarball +ALLPREQ = html tarball TARFILES = kernel-dev.html kernel-dev-style.css \ figures/kernel-dev-title.png figures/kernel-overview-2-generic.png \ - figures/kernel-architecture-overview.png figures/kernel-dev-flow.png \ - eclipse -MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse + figures/kernel-architecture-overview.png figures/kernel-dev-flow.png +MANUALS = $(DOC)/$(DOC).html FIGURES = figures STYLESHEET = $(DOC)/*.css endif @@ -416,50 +403,6 @@ else endif -eclipse: BASE_DIR = html/$(DOC)/ - -eclipse: eclipse-generate eclipse-resolve-links - -.PHONY : eclipse-generate eclipse-resolve-links - -eclipse-generate: -ifeq ($(filter $(DOC), overview-manual sdk-manual bsp-guide dev-manual kernel-dev profile-manual ref-manual brief-yoctoprojectqs),) - @echo " " - @echo "ERROR: You can only create eclipse documentation" - @echo " of the following documentation parts:" - @echo " - overview-manual" - @echo " - sdk-manual" - @echo " - bsp-guide" - @echo " - dev-manual" - @echo " - kernel-dev" - @echo " - profile-manual" - @echo " - ref-manual" - @echo " - brief-yoctoprojectqs" - @echo " " -else - @echo " " - @echo "******** Building eclipse help of "$(DOC) - @echo " " - cd $(DOC) && \ - xsltproc $(XSLTOPTS) \ - --stringparam base.dir '$(BASE_DIR)' \ - -o eclipse/$(DOC).html \ - $(DOC)-eclipse-customization.xsl $(DOC).xml && \ - mv eclipse/toc.xml eclipse/$(DOC)-toc.xml && \ - cp -rf $(FIGURES) eclipse/$(BASE_DIR) && \ - cd ..; - - $(call modify-eclipse) -endif - -eclipse-resolve-links: - @echo " " - @echo "******** Using eclipse-help.sed to process external links" - @echo " " - $(foreach FILE, \ - $(wildcard $(DOC)/eclipse/html/$(DOC)/*.html), \ - $(shell sed -i -f tools/eclipse-help.sed $(FILE))) - tarball: html @echo " " @echo "******** Creating Tarball of document files" @@ -476,8 +419,8 @@ publish: echo " "; \ echo "******** Publishing "$(DOC)".html"; \ echo " "; \ - scp -r $(MANUALS) $(STYLESHEET) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \ - cd $(DOC); scp -r $(FIGURES) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \ + scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \ + cd $(DOC); scp -r $(FIGURES) www.yoctoproject.org:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \ else \ echo " "; \ echo $(DOC)".html missing. Generate the file first then try again."; \ diff --git a/external/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs-eclipse-customization.xsl b/external/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs-eclipse-customization.xsl deleted file mode 100644 index fbb3b578..00000000 --- a/external/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs-eclipse-customization.xsl +++ /dev/null @@ -1,35 +0,0 @@ -<?xml version='1.0'?> -<xsl:stylesheet - xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - xmlns="http://www.w3.org/1999/xhtml" - xmlns:fo="http://www.w3.org/1999/XSL/Format" - version="1.0"> - - <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - -<!-- - - <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - - <xsl:import - href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" /> - ---> - - <xsl:import href="brief-yoctoprojectqs-titlepage.xsl"/> - - <xsl:param name="chunker.output.indent" select="'yes'"/> - <xsl:param name="chunk.quietly" select="1"/> - <xsl:param name="use.id.as.filename" select="1"/> - <xsl:param name="ulink.target" select="'_self'" /> - <xsl:param name="base.dir" select="'html/brief-yoctoprojectqs/'"/> - <xsl:param name="chunk.section.depth" select="0"/> - <xsl:param name="html.stylesheet" select="'../book.css'"/> - <xsl:param name="eclipse.manifest" select="0"/> - <xsl:param name="create.plugin.xml" select="0"/> - <xsl:param name="suppress.navigation" select="1"/> - <xsl:param name="generate.index" select="0"/> - <xsl:param name="generate.toc" select="'article nop'"></xsl:param> - <xsl:param name="html.stylesheet" select="'style.css'" /> -</xsl:stylesheet> - diff --git a/external/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml b/external/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml index f261deed..3c83afd4 100644 --- a/external/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml +++ b/external/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml @@ -55,10 +55,18 @@ information. </para></listitem> <listitem><para> - You cannot use a build host that is using the - <ulink url='https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux'>Windows Subsystem for Linux</ulink> - (WSL). - The Yocto Project is not compatible with WSL. + You may use Windows Subsystem For Linux v2 to set up a build + host using Windows 10. + <note> + The Yocto Project is not compatible with WSLv1, it is + compatible but not officially supported nor validated + with WSLv2, if you still decide to use WSL please upgrade + to WSLv2. + </note> + See the + <ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-wsl'>Setting Up to Use Windows Subsystem For Linux</ulink>" + section in the Yocto Project Development Tasks Manual for more + information. </para></listitem> </itemizedlist> </note> @@ -99,17 +107,20 @@ Git 1.8.3.1 or greater </para></listitem> <listitem><para> - tar 1.27 or greater + tar 1.28 or greater </para></listitem> <listitem><para> - Python 3.4.0 or greater. - </para></listitem> + Python 3.5.0 or greater. + </para></listitem> + <listitem><para> + gcc 5.0 or greater. + </para></listitem> </itemizedlist> If your build host does not meet any of these three listed version requirements, you can take steps to prepare the system so that you can still use the Yocto Project. See the - "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</ulink>" + "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</ulink>" section in the Yocto Project Reference Manual for information. </para></listitem> </itemizedlist> @@ -131,7 +142,7 @@ section in the Yocto Project Reference Manual. </note> <literallayout class='monospaced'> - $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; libsdl1.2-dev xterm + $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; </literallayout> </para> </section> @@ -148,11 +159,11 @@ <literallayout class='monospaced'> $ git clone git://git.yoctoproject.org/poky Cloning into 'poky'... - remote: Counting objects: 445141, done. - remote: Compressing objects: 100% (105214/105214), done. - remote: Total 445141 (delta 333098), reused 444745 (delta 332720) - Receiving objects: 100% (445141/445141), 156.60 MiB | 5.13 MiB/s, done. - Resolving deltas: 100% (333098/333098), done. + remote: Counting objects: 432160, done. + remote: Compressing objects: 100% (102056/102056), done. + remote: Total 432160 (delta 323116), reused 432037 (delta 323000) + Receiving objects: 100% (432160/432160), 153.81 MiB | 8.54 MiB/s, done. + Resolving deltas: 100% (323116/323116), done. Checking connectivity... done. </literallayout> Move to the <filename>poky</filename> directory and take a look @@ -172,11 +183,9 @@ yocto-2.5 yocto-2.5.1 yocto-2.5.2 - yocto-2.5.3 yocto-2.6 yocto-2.6.1 yocto-2.6.2 - yocto-2.6.3 yocto-2.7 yocto_1.5_M5.rc8 </literallayout> @@ -268,7 +277,7 @@ meta-toolchain meta-ide-support - You can also run generated qemu images with a command like 'runqemu qemux86' + You can also run generated qemu images with a command like 'runqemu qemux86-64' </literallayout> Among other things, the script creates the <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>, @@ -334,7 +343,7 @@ QEMU, which is a Quick EMUlator that ships with the Yocto Project: <literallayout class='monospaced'> - $ runqemu qemux86 + $ runqemu qemux86-64 </literallayout> If you want to learn more about running QEMU, see the "<ulink url="&YOCTO_DOCS_DEV_URL;#dev-manual-qemu">Using the Quick EMUlator (QEMU)</ulink>" @@ -392,15 +401,16 @@ You can put the copy in the top level of the copy of the Poky repository created earlier: <literallayout class='monospaced'> + $ cd ~/poky $ git clone https://github.com/kraj/meta-altera.git Cloning into 'meta-altera'... - remote: Enumerating objects: 219, done. - remote: Counting objects: 100% (219/219), done. - remote: Compressing objects: 100% (116/116), done. - remote: Total 1463 (delta 111), reused 172 (delta 79), pack-reused 1244 - Receiving objects: 100% (1463/1463), 211.60 KiB | 0 bytes/s, done. - Resolving deltas: 100% (706/706), done. - Checking connectivity... done. </literallayout> + remote: Counting objects: 25170, done. + remote: Compressing objects: 100% (350/350), done. + remote: Total 25170 (delta 645), reused 719 (delta 538), pack-reused 24219 + Receiving objects: 100% (25170/25170), 41.02 MiB | 1.64 MiB/s, done. + Resolving deltas: 100% (13385/13385), done. + Checking connectivity... done. + </literallayout> The hardware layer now exists with other layers inside the Poky reference repository on your build host as <filename>meta-altera</filename> and contains all the @@ -438,6 +448,8 @@ $ cd ~/poky/build $ bitbake-layers add-layer ../meta-altera NOTE: Starting bitbake server... + Parsing recipes: 100% |##################################################################| Time: 0:00:32 + Parsing of 918 .bb files complete (0 cached, 918 parsed). 1401 targets, 123 skipped, 0 masked, 0 errors. </literallayout> You can find more information on adding layers in the "<ulink url='&YOCTO_DOCS_DEV_URL;#adding-a-layer-using-the-bitbake-layers-script'>Adding a Layer Using the <filename>bitbake-layers</filename> Script</ulink>" diff --git a/external/poky/documentation/bsp-guide/bsp-guide-eclipse-customization.xsl b/external/poky/documentation/bsp-guide/bsp-guide-eclipse-customization.xsl deleted file mode 100644 index 35346eff..00000000 --- a/external/poky/documentation/bsp-guide/bsp-guide-eclipse-customization.xsl +++ /dev/null @@ -1,35 +0,0 @@ -<?xml version='1.0'?> -<xsl:stylesheet - xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - xmlns="http://www.w3.org/1999/xhtml" - xmlns:fo="http://www.w3.org/1999/XSL/Format" - version="1.0"> - - <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - -<!-- - - <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - - <xsl:import - href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" /> - ---> - - <xsl:param name="chunker.output.indent" select="'yes'"/> - <xsl:param name="chunk.quietly" select="1"/> - <xsl:param name="chunk.first.sections" select="1"/> - <xsl:param name="chunk.section.depth" select="10"/> - <xsl:param name="use.id.as.filename" select="1"/> - <xsl:param name="ulink.target" select="'_self'" /> - <xsl:param name="base.dir" select="'html/bsp-guide/'"/> - <xsl:param name="html.stylesheet" select="'../book.css'"/> - <xsl:param name="eclipse.manifest" select="0"/> - <xsl:param name="create.plugin.xml" select="0"/> - <xsl:param name="suppress.navigation" select="1"/> - <xsl:param name="generate.index" select="0"/> - <xsl:param name="chapter.autolabel" select="1" /> - <xsl:param name="appendix.autolabel" select="1" /> - <xsl:param name="section.autolabel" select="1" /> - <xsl:param name="section.label.includes.component.label" select="1" /> -</xsl:stylesheet> diff --git a/external/poky/documentation/bsp-guide/bsp-guide.xml b/external/poky/documentation/bsp-guide/bsp-guide.xml index b7a5ba67..76f40f81 100644..100755 --- a/external/poky/documentation/bsp-guide/bsp-guide.xml +++ b/external/poky/documentation/bsp-guide/bsp-guide.xml @@ -22,33 +22,27 @@ <authorgroup> <author> - <firstname>Scott</firstname> <surname>Rifenbark</surname> <affiliation> - <orgname>Scotty's Documentation Services, INC</orgname> + <orgname>&ORGNAME;</orgname> </affiliation> - <email>srifenbark@gmail.com</email> + <email>&ORGEMAIL;</email> </author> </authorgroup> <revhistory> <revision> <revnumber>0.9</revnumber> - <date>24 November 2010</date> - <revremark>The initial document draft released with the Yocto Project 0.9 Release.</revremark> + <date>November 2010</date> + <revremark>The initial document released with the Yocto Project 0.9 Release.</revremark> </revision> <revision> <revnumber>1.0</revnumber> - <date>6 April 2011</date> + <date>April 2011</date> <revremark>Released with the Yocto Project 1.0 Release.</revremark> </revision> <revision> - <revnumber>1.0.1</revnumber> - <date>23 May 2011</date> - <revremark>Released with the Yocto Project 1.0.1 Release.</revremark> - </revision> - <revision> <revnumber>1.1</revnumber> - <date>6 October 2011</date> + <date>October 2011</date> <revremark>Released with the Yocto Project 1.1 Release.</revremark> </revision> <revision> @@ -72,11 +66,6 @@ <revremark>Released with the Yocto Project 1.5 Release.</revremark> </revision> <revision> - <revnumber>1.5.1</revnumber> - <date>January 2014</date> - <revremark>Released with the Yocto Project 1.5.1 Release.</revremark> - </revision> - <revision> <revnumber>1.6</revnumber> <date>April 2014</date> <revremark>Released with the Yocto Project 1.6 Release.</revremark> @@ -127,24 +116,29 @@ <revremark>Released with the Yocto Project 2.6 Release.</revremark> </revision> <revision> - <revnumber>2.6.1</revnumber> - <date>February 2019</date> - <revremark>Released with the Yocto Project 2.6.1 Release.</revremark> + <revnumber>2.7</revnumber> + <date>May 2019</date> + <revremark>Released with the Yocto Project 2.7 Release.</revremark> </revision> <revision> - <revnumber>2.6.2</revnumber> - <date>April 2019</date> - <revremark>Released with the Yocto Project 2.6.2 Release.</revremark> + <revnumber>3.0</revnumber> + <date>October 2019</date> + <revremark>Released with the Yocto Project 3.0 Release.</revremark> </revision> <revision> - <revnumber>2.6.3</revnumber> - <date>August 2019</date> - <revremark>Released with the Yocto Project 2.6.3 Release.</revremark> + <revnumber>3.1</revnumber> + <date>April 2020</date> + <revremark>Released with the Yocto Project 3.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.4</revnumber> - <date>November 2019</date> - <revremark>Released with the Yocto Project 2.6.4 Release.</revremark> + <revnumber>3.1.1</revnumber> + <date>June 2020</date> + <revremark>Released with the Yocto Project 3.1.1 Release.</revremark> + </revision> + <revision> + <revnumber>3.1.2</revnumber> + <date>&REL_MONTH_YEAR;</date> + <revremark>Released with the Yocto Project 3.1.2 Release.</revremark> </revision> </revhistory> @@ -167,7 +161,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -184,18 +178,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. </para></listitem> - <listitem><para> + <listitem> + <para> To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - <filename>yocto@yoctoproject.com</filename> or log into - the freenode <filename>#yocto</filename> channel. - </para></listitem> + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + <filename>docs@lists.yoctoproject.org</filename> or + log into the freenode <filename>#yocto</filename> channel. + </para> + </listitem> </itemizedlist> </note> </legalnotice> diff --git a/external/poky/documentation/bsp-guide/bsp.xml b/external/poky/documentation/bsp-guide/bsp.xml index a1d91031..96c0455f 100644 --- a/external/poky/documentation/bsp-guide/bsp.xml +++ b/external/poky/documentation/bsp-guide/bsp.xml @@ -19,7 +19,7 @@ </para> <para> - This guide presents information about BSP Layers, defines a structure for components + This guide presents information about BSP layers, defines a structure for components so that BSPs follow a commonly understood layout, discusses how to customize a recipe for a BSP, addresses BSP licensing, and provides information that shows you how to create a @@ -34,7 +34,7 @@ <para> A BSP consists of a file structure inside a base directory. Collectively, you can think of the base directory, its file structure, - and the contents as a BSP Layer. + and the contents as a <firstterm>BSP layer</firstterm>. Although not a strict requirement, BSP layers in the Yocto Project use the following well-established naming convention: <literallayout class='monospaced'> @@ -69,9 +69,9 @@ Each repository is a BSP layer supported by the Yocto Project (e.g. <filename>meta-raspberrypi</filename> and <filename>meta-intel</filename>). - Each of these layers is a repository unto itself and clicking on a - layer reveals information that includes two links from which you can choose - to set up a clone of the layer's repository on your local host system. + Each of these layers is a repository unto itself and clicking on + the layer name displays two URLs from which you can + clone the layer's repository to your local system. Here is an example that clones the Raspberry Pi BSP layer: <literallayout class='monospaced'> $ git clone git://git.yoctoproject.org/meta-raspberrypi @@ -83,12 +83,13 @@ <filename>meta-yocto-bsp</filename> layer is part of the shipped <filename>poky</filename> repository. The <filename>meta-yocto-bsp</filename> layer maintains several - BSPs such as the Beaglebone, EdgeRouter, and generic versions of + "reference" BSPs including the ARM-based Beaglebone, MIPS-based + EdgeRouter, and generic versions of both 32-bit and 64-bit IA machines. </para> <para> - For information on the BSP development workflow, see the + For information on typical BSP development workflow, see the "<link linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</link>" section. For more information on how to set up a local copy of source files @@ -98,12 +99,12 @@ </para> <para> - The layer's base directory + The BSP layer's base directory (<filename>meta-<replaceable>bsp_root_name</replaceable></filename>) - is the root directory of the BSP Layer. + is the root directory of that Layer. This directory is what you add to the <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink> - variable in the <filename>conf/bblayers.conf</filename> file found in the + variable in the <filename>conf/bblayers.conf</filename> file found in your <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>, which is established after you run the OpenEmbedded build environment setup script (i.e. @@ -148,16 +149,25 @@ Some layers function as a layer to hold other BSP layers. These layers are knows as "<ulink url='&YOCTO_DOCS_REF_URL;#term-container-layer'>container layers</ulink>". - An example of this type of layer is the - <filename>meta-intel</filename> layer. - This layer contains BSP layers for the Intel-core2-32 - <trademark class='registered'>Intel</trademark> Common Core - (Intel-core2-32) and the Intel-corei7-64 - <trademark class='registered'>Intel</trademark> Common Core - (Intel-corei7-64). - the <filename>meta-intel</filename> layer also contains - the <filename>common/</filename> directory, which contains - common content across those layers. + An example of this type of layer is OpenEmbedded's + <ulink url='https://github.com/openembedded/meta-openembedded'><filename>meta-openembedded</filename></ulink> + layer. + The <filename>meta-openembedded</filename> layer contains + many <filename>meta-*</filename> layers. + In cases like this, you need to include the names of the actual + layers you want to work with, such as: + <literallayout class='monospaced'> + BBLAYERS ?= " \ + /usr/local/src/yocto/meta \ + /usr/local/src/yocto/meta-poky \ + /usr/local/src/yocto/meta-yocto-bsp \ + /usr/local/src/yocto/meta-mylayer \ + .../meta-openembedded/meta-oe \ + .../meta-openembedded/meta-perl \ + .../meta-openembedded/meta-networking \ + " + </literallayout> + and so on. </para> <para> @@ -243,11 +253,11 @@ <literallayout class='monospaced'> $ git clone git://git.yoctoproject.org/meta-intel.git Cloning into 'meta-intel'... - remote: Counting objects: 17179, done. - remote: Compressing objects: 100% (5307/5307), done. - remote: Total 17179 (delta 10209), reused 17139 (delta 10169) - Receiving objects: 100% (17179/17179), 4.76 MiB | 4.39 MiB/s, done. - Resolving deltas: 100% (10209/10209), done. + remote: Counting objects: 15585, done. + remote: Compressing objects: 100% (5056/5056), done. + remote: Total 15585 (delta 9123), reused 15329 (delta 8867) + Receiving objects: 100% (15585/15585), 4.51 MiB | 3.19 MiB/s, done. + Resolving deltas: 100% (9123/9123), done. Checking connectivity... done. </literallayout> </para></listitem> @@ -289,12 +299,13 @@ <literallayout class='monospaced'> $ git clone git://git.yoctoproject.org/meta-raspberrypi Cloning into 'meta-raspberrypi'... - remote: Counting objects: 6205, done. - remote: Compressing objects: 100% (2700/2700), done. - remote: Total 6205 (delta 3342), reused 5916 (delta 3146) - Receiving objects: 100% (6205/6205), 1.43 MiB | 0 bytes/s, done. - Resolving deltas: 100% (3342/3342), done. - Checking connectivity... done. </literallayout> + remote: Counting objects: 4743, done. + remote: Compressing objects: 100% (2185/2185), done. + remote: Total 4743 (delta 2447), reused 4496 (delta 2258) + Receiving objects: 100% (4743/4743), 1.18 MiB | 0 bytes/s, done. + Resolving deltas: 100% (2447/2447), done. + Checking connectivity... done. + </literallayout> </para></listitem> <listitem><para> <emphasis>Initialize the Build Environment:</emphasis> @@ -355,25 +366,24 @@ layer combined with a build system and other tools. Realize that it is important to maintain the distinction that the BSP layer, a build system, and tools are - separate components that could to be combined in + separate components that could be combined in certain end products. </para> <para> - Before looking at the common form for the file structure - inside a BSP Layer, you should be aware that some + Before looking at the recommended form for the directory structure + inside a BSP layer, you should be aware that some requirements do exist in order for a BSP layer to - be considered compliant with the Yocto Project. + be considered <firstterm>compliant</firstterm> with the Yocto Project. For that list of requirements, see the "<link linkend='released-bsp-requirements'>Released BSP Requirements</link>" section. </para> <para> - Below is the common form for the file structure - inside a BSP Layer. + Below is the typical directory structure for a BSP layer. While this basic form represents the standard, - realize that the actual file structures for specific + realize that the actual layout for individual BSPs could differ. <literallayout class='monospaced'> meta-<replaceable>bsp_root_name</replaceable>/ @@ -391,15 +401,164 @@ </para> <para> - You can examine the Raspberry Pi BSP + Below is an example of the Raspberry Pi BSP layer that is available from the - <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink> by - following this link: - <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/?h=&DISTRO_NAME_NO_CAP;'></ulink>. - Following the link puts you in the Source Repositories and the - Raspberry Pi BSP layer for the "&DISTRO_NAME_NO_CAP;" release. - You can use the interface to explore the configuration, docs, and - recipe files. + <ulink url='&YOCTO_GIT_URL;'>Source Respositories</ulink>: + <literallayout class='monospaced'> + meta-raspberrypi/COPYING.MIT + meta-raspberrypi/README.md + meta-raspberrypi/classes + meta-raspberrypi/classes/sdcard_image-rpi.bbclass + meta-raspberrypi/conf/ + meta-raspberrypi/conf/layer.conf + meta-raspberrypi/conf/machine/ + meta-raspberrypi/conf/machine/raspberrypi-cm.conf + meta-raspberrypi/conf/machine/raspberrypi-cm3.conf + meta-raspberrypi/conf/machine/raspberrypi.conf + meta-raspberrypi/conf/machine/raspberrypi0-wifi.conf + meta-raspberrypi/conf/machine/raspberrypi0.conf + meta-raspberrypi/conf/machine/raspberrypi2.conf + meta-raspberrypi/conf/machine/raspberrypi3-64.conf + meta-raspberrypi/conf/machine/raspberrypi3.conf + meta-raspberrypi/conf/machine/include + meta-raspberrypi/conf/machine/include/rpi-base.inc + meta-raspberrypi/conf/machine/include/rpi-default-providers.inc + meta-raspberrypi/conf/machine/include/rpi-default-settings.inc + meta-raspberrypi/conf/machine/include/rpi-default-versions.inc + meta-raspberrypi/conf/machine/include/tune-arm1176jzf-s.inc + meta-raspberrypi/docs + meta-raspberrypi/docs/Makefile + meta-raspberrypi/docs/conf.py + meta-raspberrypi/docs/contributing.md + meta-raspberrypi/docs/extra-apps.md + meta-raspberrypi/docs/extra-build-config.md + meta-raspberrypi/docs/index.rst + meta-raspberrypi/docs/layer-contents.md + meta-raspberrypi/docs/readme.md + meta-raspberrypi/files + meta-raspberrypi/files/custom-licenses + meta-raspberrypi/files/custom-licenses/Broadcom + meta-raspberrypi/recipes-bsp + meta-raspberrypi/recipes-bsp/bootfiles + meta-raspberrypi/recipes-bsp/bootfiles/bcm2835-bootfiles.bb + meta-raspberrypi/recipes-bsp/bootfiles/rpi-config_git.bb + meta-raspberrypi/recipes-bsp/common + meta-raspberrypi/recipes-bsp/common/firmware.inc + meta-raspberrypi/recipes-bsp/formfactor + meta-raspberrypi/recipes-bsp/formfactor/formfactor + meta-raspberrypi/recipes-bsp/formfactor/formfactor/raspberrypi + meta-raspberrypi/recipes-bsp/formfactor/formfactor/raspberrypi/machconfig + meta-raspberrypi/recipes-bsp/formfactor/formfactor_0.0.bbappend + meta-raspberrypi/recipes-bsp/rpi-u-boot-src + meta-raspberrypi/recipes-bsp/rpi-u-boot-src/files + meta-raspberrypi/recipes-bsp/rpi-u-boot-src/files/boot.cmd.in + meta-raspberrypi/recipes-bsp/rpi-u-boot-src/rpi-u-boot-scr.bb + meta-raspberrypi/recipes-bsp/u-boot + meta-raspberrypi/recipes-bsp/u-boot/u-boot + meta-raspberrypi/recipes-bsp/u-boot/u-boot/*.patch + meta-raspberrypi/recipes-bsp/u-boot/u-boot_%.bbappend + meta-raspberrypi/recipes-connectivity + meta-raspberrypi/recipes-connectivity/bluez5 + meta-raspberrypi/recipes-connectivity/bluez5/bluez5 + meta-raspberrypi/recipes-connectivity/bluez5/bluez5/*.patch + meta-raspberrypi/recipes-connectivity/bluez5/bluez5/BCM43430A1.hcd + meta-raspberrypi/recipes-connectivity/bluez5/bluez5brcm43438.service + meta-raspberrypi/recipes-connectivity/bluez5/bluez5_%.bbappend + meta-raspberrypi/recipes-core + meta-raspberrypi/recipes-core/images + meta-raspberrypi/recipes-core/images/rpi-basic-image.bb + meta-raspberrypi/recipes-core/images/rpi-hwup-image.bb + meta-raspberrypi/recipes-core/images/rpi-test-image.bb + meta-raspberrypi/recipes-core/packagegroups + meta-raspberrypi/recipes-core/packagegroups/packagegroup-rpi-test.bb + meta-raspberrypi/recipes-core/psplash + meta-raspberrypi/recipes-core/psplash/files + meta-raspberrypi/recipes-core/psplash/files/psplash-raspberrypi-img.h + meta-raspberrypi/recipes-core/psplash/psplash_git.bbappend + meta-raspberrypi/recipes-core/udev + meta-raspberrypi/recipes-core/udev/udev-rules-rpi + meta-raspberrypi/recipes-core/udev/udev-rules-rpi/99-com.rules + meta-raspberrypi/recipes-core/udev/udev-rules-rpi.bb + meta-raspberrypi/recipes-devtools + meta-raspberrypi/recipes-devtools/bcm2835 + meta-raspberrypi/recipes-devtools/bcm2835/bcm2835_1.52.bb + meta-raspberrypi/recipes-devtools/pi-blaster + meta-raspberrypi/recipes-devtools/pi-blaster/files + meta-raspberrypi/recipes-devtools/pi-blaster/files/*.patch + meta-raspberrypi/recipes-devtools/pi-blaster/pi-blaster_git.bb + meta-raspberrypi/recipes-devtools/python + meta-raspberrypi/recipes-devtools/python/python-rtimu + meta-raspberrypi/recipes-devtools/python/python-rtimu/*.patch + meta-raspberrypi/recipes-devtools/python/python-rtimu_git.bb + meta-raspberrypi/recipes-devtools/python/python-sense-hat_2.2.0.bb + meta-raspberrypi/recipes-devtools/python/rpi-gpio + meta-raspberrypi/recipes-devtools/python/rpi-gpio/*.patch + meta-raspberrypi/recipes-devtools/python/rpi-gpio_0.6.3.bb + meta-raspberrypi/recipes-devtools/python/rpio + meta-raspberrypi/recipes-devtools/python/rpio/*.patch + meta-raspberrypi/recipes-devtools/python/rpio_0.10.0.bb + meta-raspberrypi/recipes-devtools/wiringPi + meta-raspberrypi/recipes-devtools/wiringPi/files + meta-raspberrypi/recipes-devtools/wiringPi/files/*.patch + meta-raspberrypi/recipes-devtools/wiringPi/wiringpi_git.bb + meta-raspberrypi/recipes-graphics + meta-raspberrypi/recipes-graphics/eglinfo + meta-raspberrypi/recipes-graphics/eglinfo/eglinfo-fb_%.bbappend + meta-raspberrypi/recipes-graphics/eglinfo/eglinfo-x11_%.bbappend + meta-raspberrypi/recipes-graphics/mesa + meta-raspberrypi/recipes-graphics/mesa/mesa-gl_%.bbappend + meta-raspberrypi/recipes-graphics/mesa/mesa_%.bbappend + meta-raspberrypi/recipes-graphics/userland + meta-raspberrypi/recipes-graphics/userland/userland + meta-raspberrypi/recipes-graphics/userland/userland/*.patch + meta-raspberrypi/recipes-graphics/userland/userland_git.bb + meta-raspberrypi/recipes-graphics/vc-graphics + meta-raspberrypi/recipes-graphics/vc-graphics/files + meta-raspberrypi/recipes-graphics/vc-graphics/files/egl.pc + meta-raspberrypi/recipes-graphics/vc-graphics/files/vchiq.sh + meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics-hardfp.bb + meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics.bb + meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics.inc + meta-raspberrypi/recipes-graphics/wayland + meta-raspberrypi/recipes-graphics/wayland/weston_%.bbappend + meta-raspberrypi/recipes-graphics/xorg-xserver + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/98-pitft.conf + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/99-calibration.conf + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend + meta-raspberrypi/recipes-kernel + meta-raspberrypi/recipes-kernel/linux-firmware + meta-raspberrypi/recipes-kernel/linux-firmware/files + meta-raspberrypi/recipes-kernel/linux-firmware/files/brcmfmac43430-sdio.bin + meta-raspberrypi/recipes-kernel/linux-firmware/files/brcfmac43430-sdio.txt + meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware_%.bbappend + meta-raspberrypi/recipes-kernel/linux + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-dev.bb + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi.inc + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.14.bb + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb + meta-raspberrypi/recipes-multimedia + meta-raspberrypi/recipes-multimedia/gstreamer + meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx + meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx/*.patch + meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx_%.bbappend + meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend + meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.12 + meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.12/*.patch + meta-raspberrypi/recipes-multimedia/omxplayer + meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer + meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer/*.patch + meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer_git.bb + meta-raspberrypi/recipes-multimedia/x264 + meta-raspberrypi/recipes-multimedia/x264/x264_git.bbappend + meta-raspberrypi/wic + meta-raspberrypi/wic/sdimage-raspberrypi.wks + </literallayout> </para> <para> @@ -422,7 +581,7 @@ for the BSP. The type or types of files here can vary depending on the licensing requirements. - For example, in the Raspberry Pi BSP all licensing + For example, in the Raspberry Pi BSP, all licensing requirements are handled with the <filename>COPYING.MIT</filename> file. </para> @@ -657,7 +816,7 @@ <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>. For example, many <filename>tune-*</filename> files (e.g. <filename>tune-arm1136jf-s.inc</filename>, - <filename>tun-1586-nlp.inc</filename>, and so forth) + <filename>tune-1586-nlp.inc</filename>, and so forth) reside in the <filename>poky/meta/conf/machine/include</filename> directory. @@ -689,14 +848,14 @@ This optional directory contains miscellaneous recipe files for the BSP. Most notably would be the formfactor files. - For example, in the Raspberry Pi BSP there is the - <filename>formfactor_%.bbappend</filename> file, + For example, in the Raspberry Pi BSP, there is the + <filename>formfactor_0.0.bbappend</filename> file, which is an append file used to augment the recipe that starts the build. Furthermore, there are machine-specific settings used during the build that are defined by the <filename>machconfig</filename> file further down in - the directory (i.e. <filename>formfactor/rpi/</filename>). + the directory. Here is the <filename>machconfig</filename> file for the Raspberry Pi BSP: <literallayout class='monospaced'> @@ -716,8 +875,7 @@ formfactor recipe <filename>meta/recipes-bsp/formfactor/formfactor_0.0.bb</filename>, which is found in the - <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink> - (i.e. <filename>poky</filename>). + <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>. </para></note> </section> @@ -757,7 +915,7 @@ The <filename>*.bb</filename> files would be a developer-supplied kernel recipe. This area of the BSP hierarchy can contain both these - types of files, although in practice, it is likely that + types of files although, in practice, it is likely that you would have one or the other. </para> @@ -832,7 +990,7 @@ <title>Developing a Board Support Package (BSP)</title> <para> - This section contains the high-level procedure you can + This section describes the high-level procedure you can follow to create a BSP. Although not required for BSP creation, the <filename>meta-intel</filename> repository, which @@ -931,10 +1089,6 @@ (<filename>beaglebone-yocto</filename>) </para></listitem> <listitem><para> - Freescale MPC8315E-RDB - (<filename>mpc8315e-rdb</filename>) - </para></listitem> - <listitem><para> Ubiquiti Networks EdgeRouter Lite (<filename>edgerouter</filename>) </para></listitem> @@ -1158,7 +1312,7 @@ (<filename>openembedded-core</filename>) or the Source Directory (<filename>poky</filename>). In other words, make sure you place related - files in appropriately related + files in appropriately-related <filename>recipes-*</filename> subdirectories specific to the recipe's function, or within a subdirectory containing a set of closely-related @@ -1175,7 +1329,7 @@ directory. This license covers the BSP Metadata as a whole. You must specify which license to use since no - default license exists when one not specified. + default license exists when one is not specified. See the <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-raspberrypi/tree/COPYING.MIT'><filename>COPYING.MIT</filename></ulink> file for the Raspberry Pi BSP in the @@ -1198,12 +1352,10 @@ file should contain the following: <itemizedlist> <listitem><para> - A brief description about the hardware the BSP - targets. + A brief description of the target hardware. </para></listitem> <listitem><para> - A list of all the dependencies - on which a BSP layer depends. + A list of all the dependencies of the BSP. These dependencies are typically a list of required layers needed to build the BSP. @@ -1466,7 +1618,7 @@ <title>BSP Licensing Considerations</title> <para> - In some cases, a BSP contains separately licensed + In some cases, a BSP contains separately-licensed Intellectual Property (IP) for a component or components. For these cases, you are required to accept the terms of a commercial or other type of license that requires @@ -1479,7 +1631,7 @@ </para> <para> - You could find that some separately licensed components + You could find that some separately-licensed components that are essential for normal operation of the system might not have an unencumbered (or free) substitute. Without these essential components, the system would be @@ -1487,7 +1639,7 @@ Then again, you might find that other licensed components that are simply 'good-to-have' or purely elective do have an unencumbered, free replacement component that you can - use rather than agreeing to the separately licensed + use rather than agreeing to the separately-licensed component. Even for components essential to the system, you might find an unencumbered component that is not identical but @@ -1600,7 +1752,7 @@ <para> The <filename>bitbake-layers create-layer</filename> script automates creating a BSP layer. - What makes a layer a "BSP layer", is the presence of a machine + What makes a layer a "BSP layer" is the presence of at least one machine configuration file. Additionally, a BSP layer usually has a kernel recipe or an append file that leverages off an existing kernel recipe. @@ -1668,9 +1820,8 @@ The remainder of this section provides a description of the Yocto Project reference BSP for Beaglebone, which resides in the - <ulink url='&YOCTO_DOCS_REF_URL;#term-container-layer'>Container Layer</ulink> - (i.e. - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto-bsp'><filename>meta-yocto-bsp</filename></ulink>). + <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto-bsp'><filename>meta-yocto-bsp</filename></ulink> + layer. </para> <section id='bsp-layer-configuration-example'> @@ -1725,15 +1876,18 @@ </para> <para> - Machine configuration files exist in the + One or more machine configuration files exist in the <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename> directory of the layer: <literallayout class='monospaced'> - <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename><replaceable>machine</replaceable><filename>.conf</filename> + <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename><replaceable>machine1</replaceable><filename>.conf</filename> + <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename><replaceable>machine2</replaceable><filename>.conf</filename> + <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename><replaceable>machine3</replaceable><filename>.conf</filename> + ... more ... </literallayout> For example, the machine configuration file for the <ulink url='http://beagleboard.org/bone'>BeagleBone and BeagleBone Black development boards</ulink> - is located in the container layer + is located in the layer <filename>poky/meta-yocto-bsp/conf/machine</filename> and is named <filename>beaglebone-yocto.conf</filename>: <literallayout class='monospaced'> @@ -1759,10 +1913,11 @@ IMAGE_INSTALL_append = " kernel-devicetree kernel-image-zimage" do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot" - SERIAL_CONSOLES = "115200;ttyO0" + SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0" + SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}" PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" - PREFERRED_VERSION_linux-yocto ?= "4.12%" + PREFERRED_VERSION_linux-yocto ?= "5.0%" KERNEL_IMAGETYPE = "zImage" KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb" @@ -1770,17 +1925,17 @@ SPL_BINARY = "MLO" UBOOT_SUFFIX = "img" - UBOOT_MACHINE = "am335x_boneblack_config" + UBOOT_MACHINE = "am335x_evm_defconfig" UBOOT_ENTRYPOINT = "0x80008000" UBOOT_LOADADDRESS = "0x80008000" MACHINE_FEATURES = "usbgadget usbhost vfat alsa" - IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} MLO" + IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} MLO zImage am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb" </literallayout> The variables used to configure the machine define - machine-specific properties. - For example, machine-dependent packages, machine + machine-specific properties; + for example, machine-dependent packages, machine tunings, the type of kernel to build, and U-Boot configurations. </para> @@ -1791,7 +1946,7 @@ machine configuration file for the BeagleBone development boards. Realize that much more can be defined as part of - a machines configuration file. + a machine's configuration file. In general, you can learn about related variables that this example does not have by locating the variables in the @@ -1805,7 +1960,7 @@ In this case, the recipe that provides "virtual/xserver" is "xserver-xorg", which exists in - <filename>poky/meta/recipes-graphics/xserver-xorg</filename>. + <filename>poky/meta/recipes-graphics/xorg-xserver</filename>. </para></listitem> <listitem><para> <ulink url='&YOCTO_DOCS_REF_URL;#var-XSERVER'><filename>XSERVER</filename></ulink>: @@ -1918,7 +2073,7 @@ <listitem><para> <ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_VERSION'><filename>PREFERRED_VERSION_linux-yocto</filename></ulink>: Defines the version of the recipe used - to build the kernel, which is "4.12" in this + to build the kernel, which is "5.0" in this case. </para></listitem> <listitem><para> @@ -1929,8 +2084,8 @@ </para></listitem> <listitem><para> <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_DEVICETREE'><filename>KERNEL_DEVICETREE</filename></ulink>: - The name of the generated Linux kernel device - tree (i.e. the <filename>.dtb</filename>) file. + The names of the generated Linux kernel device + trees (i.e. the <filename>*.dtb</filename>) files. All the device trees for the various BeagleBone devices are included. <!-- @@ -2004,8 +2159,6 @@ when preparing the image using the Wic tool with the <filename>bootimg-partition</filename> source plugin. - In this case, the "u-boot.${UBOOT_SUFFIX}" and - "MLO" files are installed. </para></listitem> </itemizedlist> </para> @@ -2020,55 +2173,49 @@ machine configuration: <literallayout class='monospaced'> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" - PREFERRED_VERSION_linux-yocto ?= "4.12%" + PREFERRED_VERSION_linux-yocto ?= "5.0%" </literallayout> The <filename>meta-yocto-bsp/recipes-kernel/linux</filename> directory in the layer contains metadata used to build the kernel. - In this case, a kernel append file is used to - override an established kernel recipe, which is + In this case, a kernel append file (i.e. + <filename>linux-yocto_5.0.bbappend</filename>) is used to + override an established kernel recipe (i.e. + <filename>linux-yocto_5.0.bb</filename>), which is located in - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux'></ulink> - and named - <filename>linux-yocto_4.12.bb</filename>. + <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux'></ulink>. </para> <para> Following is the contents of the append file: <literallayout class='monospaced'> - KBRANCH_genericx86 = "standard/base" - KBRANCH_genericx86-64 = "standard/base" + KBRANCH_genericx86 = "v5.0/standard/base" + KBRANCH_genericx86-64 = "v5.0/standard/base" + KBRANCH_edgerouter = "v5.0/standard/edgerouter" + KBRANCH_beaglebone-yocto = "v5.0/standard/beaglebone" KMACHINE_genericx86 ?= "common-pc" KMACHINE_genericx86-64 ?= "common-pc-64" - KBRANCH_edgerouter = "standard/edgerouter" - KBRANCH_beaglebone-yocto = "standard/beaglebone" - KMACHINE_beaglebone-yocto = "beaglebone" - KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb" - - SRCREV_machine_genericx86 ?= "1c4ad569af3e23a77994235435040e322908687f" - SRCREV_machine_genericx86-64 ?= "1c4ad569af3e23a77994235435040e322908687f" - SRCREV_machine_edgerouter ?= "257f843ea367744620f1d92910afd2f454e31483" - SRCREV_machine_beaglebone-yocto ?= "257f843ea367744620f1d92910afd2f454e31483" - SRCREV_machine_mpc8315e-rdb ?= "014560874f9eb2a86138c9cc35046ff1720485e1" + KMACHINE_beaglebone-yocto ?= "beaglebone" + SRCREV_machine_genericx86 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d" + SRCREV_machine_genericx86-64 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d" + SRCREV_machine_edgerouter ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d" + SRCREV_machine_beaglebone-yocto ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d" COMPATIBLE_MACHINE_genericx86 = "genericx86" COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64" COMPATIBLE_MACHINE_edgerouter = "edgerouter" COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto" - COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb" - LINUX_VERSION_genericx86 = "4.12.20" - LINUX_VERSION_genericx86-64 = "4.12.20" - LINUX_VERSION_edgerouter = "4.12.19" - LINUX_VERSION_beaglebone-yocto = "4.12.19" - LINUX_VERSION_mpc8315e-rdb = "4.12.19" + LINUX_VERSION_genericx86 = "5.0.3" + LINUX_VERSION_genericx86-64 = "5.0.3" + LINUX_VERSION_edgerouter = "5.0.3" + LINUX_VERSION_beaglebone-yocto = "5.0.3" </literallayout> This particular append file works for all the machines that are part of the - <filename>meta-yocto-bsp</filename> container - layer. + <filename>meta-yocto-bsp</filename> layer. The relevant statements are appended with the "beaglebone-yocto" string. The OpenEmbedded build system uses these @@ -2091,15 +2238,6 @@ <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>: Identifies the revision of the source code used to build the image. -<!-- - You find out about that point in the kernel source tree by - doing the following command: - - git log ‐‐decorate 257f843ea367744620f1d92910afd2f454e31483 - - Returns information about the commit, which is usually - that it is a merge point for a stable kernel release. ---> </para></listitem> <listitem><para> <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>: diff --git a/external/poky/documentation/dev-manual/dev-manual-common-tasks.xml b/external/poky/documentation/dev-manual/dev-manual-common-tasks.xml index c75e718d..e9ce182a 100644 --- a/external/poky/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/external/poky/documentation/dev-manual/dev-manual-common-tasks.xml @@ -184,6 +184,10 @@ variable. </para></listitem> <listitem><para> + <ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></ulink>: + Lists all layers on which this layer depends (if any). + </para></listitem> + <listitem><para> <ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERSERIES_COMPAT'><filename>LAYERSERIES_COMPAT</filename></ulink>: Lists the <ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Yocto Project</ulink> @@ -315,12 +319,26 @@ DEPENDS_append_one = " foo" DEPENDS_prepend_one = "foo " </literallayout> - As an actual example, here's a line from the recipe - for gnutls, which adds dependencies on - "argp-standalone" when building with the musl C - library: + As an actual example, here's a snippet from the + generic kernel include file + <filename>linux-yocto.inc</filename>, + wherein the kernel compile and link options are + adjusted in the case of a subset of the supported + architectures: <literallayout class='monospaced'> - DEPENDS_append_libc-musl = " argp-standalone" + DEPENDS_append_aarch64 = " libgcc" + KERNEL_CC_append_aarch64 = " ${TOOLCHAIN_OPTIONS}" + KERNEL_LD_append_aarch64 = " ${TOOLCHAIN_OPTIONS}" + + DEPENDS_append_nios2 = " libgcc" + KERNEL_CC_append_nios2 = " ${TOOLCHAIN_OPTIONS}" + KERNEL_LD_append_nios2 = " ${TOOLCHAIN_OPTIONS}" + + DEPENDS_append_arc = " libgcc" + KERNEL_CC_append_arc = " ${TOOLCHAIN_OPTIONS}" + KERNEL_LD_append_arc = " ${TOOLCHAIN_OPTIONS}" + + KERNEL_FEATURES_append_qemuall=" features/debug/printk.scc" </literallayout> <note> Avoiding "+=" and "=+" and using @@ -580,11 +598,19 @@ <filename>bitbake -e</filename>). </para></listitem> <listitem><para> + <filename>common.test_world</filename>: + Verifies that <filename>bitbake world</filename> works. + </para></listitem> + <listitem><para> <filename>common.test_signatures</filename>: Tests to be sure that BSP and DISTRO layers do not come with recipes that change signatures. </para></listitem> <listitem><para> + <filename>common.test_layerseries_compat</filename>: + Verifies layer compatibility is set properly. + </para></listitem> + <listitem><para> <filename>bsp.test_bsp_defines_machines</filename>: Tests if a BSP layer has machine configurations. </para></listitem> @@ -594,11 +620,22 @@ machine when the layer is added. </para></listitem> <listitem><para> + <filename>bsp.test_machine_world</filename>: + Verifies that <filename>bitbake world</filename> + works regardless of which machine is selected. + </para></listitem> + <listitem><para> + <filename>bsp.test_machine_signatures</filename>: + Verifies that building for a particular machine + affects only the signature of tasks specific to that + machine. + </para></listitem> + <listitem><para> <filename>distro.test_distro_defines_distros</filename>: Tests if a DISTRO layer has distro configurations. </para></listitem> <listitem><para> - <filename>distro.test_distro_no_set_distro</filename>: + <filename>distro.test_distro_no_set_distros</filename>: Tests to ensure a DISTRO layer does not set the distribution when the layer is added. </para></listitem> @@ -1397,7 +1434,7 @@ package specified in the <filename>PACKAGES</filename> statement. <note> - The <filename>inherit packages</filename> should be + The <filename>inherit packagegroup</filename> line should be located near the top of the recipe, certainly before the <filename>PACKAGES</filename> statement. </note> @@ -1417,28 +1454,32 @@ <para> Here is a short, fabricated example showing the same basic - pieces: + pieces for a hypothetical packagegroup defined in + <filename>packagegroup-custom.bb</filename>, where the + variable <filename>PN</filename> is the standard way to + abbreviate the reference to the full packagegroup name + <filename>packagegroup-custom</filename>: <literallayout class='monospaced'> DESCRIPTION = "My Custom Package Groups" inherit packagegroup PACKAGES = "\ - packagegroup-custom-apps \ - packagegroup-custom-tools \ + ${PN}-apps \ + ${PN}-tools \ " - RDEPENDS_packagegroup-custom-apps = "\ + RDEPENDS_${PN}-apps = "\ dropbear \ portmap \ psplash" - RDEPENDS_packagegroup-custom-tools = "\ + RDEPENDS_${PN}-tools = "\ oprofile \ oprofileui-server \ lttng-tools" - RRECOMMENDS_packagegroup-custom-tools = "\ + RRECOMMENDS_${PN}-tools = "\ kernel-module-oprofile" </literallayout> </para> @@ -1883,7 +1924,8 @@ <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink> task uses the prefix of each entry in the <filename>SRC_URI</filename> variable value to determine which - fetcher to use to get your source files. + <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetcher</ulink> + to use to get your source files. It is the <filename>SRC_URI</filename> variable that triggers the fetcher. The @@ -1899,9 +1941,9 @@ <para> The <filename>SRC_URI</filename> variable in your recipe must define each unique location for your source files. - It is good practice to not hard-code pathnames in an URL used + It is good practice to not hard-code version numbers in a URL used in <filename>SRC_URI</filename>. - Rather than hard-code these paths, use + Rather than hard-code these values, use <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink><filename>}</filename>, which causes the fetch process to use the version specified in the recipe filename. @@ -1912,13 +1954,13 @@ <para> Here is a simple example from the - <filename>meta/recipes-devtools/cdrtools/cdrtools-native_3.01a20.bb</filename> + <filename>meta/recipes-devtools/strace/strace_5.5.bb</filename> recipe where the source comes from a single tarball. Notice the use of the <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink> variable: <literallayout class='monospaced'> - SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2" + SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \ </literallayout> </para> @@ -1977,16 +2019,17 @@ For these cases, you provide a name for each URL as part of the <filename>SRC_URI</filename> and then reference that name in the subsequent checksum statements. - Here is an example: + Here is an example combining lines from the files + <filename>git.inc</filename> and + <filename>git_2.24.1.bb</filename>: <literallayout class='monospaced'> - SRC_URI = "${DEBIAN_MIRROR}/main/a/apmd/apmd_3.2.2.orig.tar.gz;name=tarball \ - ${DEBIAN_MIRROR}/main/a/apmd/apmd_${PV}.diff.gz;name=patch" + SRC_URI = "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \ + ${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages" - SRC_URI[tarball.md5sum] = "b1e6309e8331e0f4e6efd311c2d97fa8" - SRC_URI[tarball.sha256sum] = "7f7d9f60b7766b852881d40b8ff91d8e39fccb0d1d913102a5c75a2dbb52332d" - - SRC_URI[patch.md5sum] = "57e1b689264ea80f78353519eece0c92" - SRC_URI[patch.sha256sum] = "7905ff96be93d725544d0040e425c42f9c05580db3c272f11cff75b9aa89d430" + SRC_URI[tarball.md5sum] = "166bde96adbbc11c8843d4f8f4f9811b" + SRC_URI[tarball.sha256sum] = "ad5334956301c86841eb1e5b1bb20884a6bad89a10a6762c958220c7cf64da02" + SRC_URI[manpages.md5sum] = "31c2272a8979022497ba3d4202df145d" + SRC_URI[manpages.sha256sum] = "9a7ae3a093bea39770eb96ca3e5b40bff7af0b9f6123f089d7821d0e5b8e1230" </literallayout> </para> @@ -2348,7 +2391,7 @@ Most software provides some means of setting build-time configuration options before compilation. Typically, setting these options is accomplished by running a - configure script with some options, or by modifying a build + configure script with options, or by modifying a build configuration file. <note> As of Yocto Project Release 1.7, some of the core recipes @@ -2388,6 +2431,7 @@ software is built using Autotools. If this is the case, you just need to worry about modifying the configuration.</para> + <para>When using Autotools, your recipe needs to inherit the <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-autotools'><filename>autotools</filename></ulink> @@ -2400,13 +2444,15 @@ or <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS'><filename>PACKAGECONFIG_CONFARGS</filename></ulink> to pass any needed configure options that are specific - to the recipe.</para></listitem> + to the recipe. + </para></listitem> <listitem><para><emphasis>CMake:</emphasis> If your source files have a <filename>CMakeLists.txt</filename> file, then your software is built using CMake. If this is the case, you just need to worry about modifying the configuration.</para> + <para>When you use CMake, your recipe needs to inherit the <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-cmake'><filename>cmake</filename></ulink> @@ -2416,7 +2462,16 @@ You can make some adjustments by setting <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OECMAKE'><filename>EXTRA_OECMAKE</filename></ulink> to pass any needed configure options that are specific - to the recipe.</para></listitem> + to the recipe. + <note> + If you need to install one or more custom CMake + toolchain files that are supplied by the + application you are building, install the files to + <filename>${D}${datadir}/cmake/</filename> Modules + during + <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>. + </note> + </para></listitem> <listitem><para><emphasis>Other:</emphasis> If your source files do not have a <filename>configure.ac</filename> or @@ -2779,6 +2834,14 @@ <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKEINST'><filename>PARALLEL_MAKEINST</filename></ulink> for additional information. </para></listitem> + <listitem><para> + If you need to install one or more custom CMake + toolchain files that are supplied by the + application you are building, install the files to + <filename>${D}${datadir}/cmake/</filename> Modules + during + <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>. + </para></listitem> </itemizedlist> </note> </section> @@ -3221,8 +3284,6 @@ The script defined in the post-installation function is called when the root filesystem is created. If the script succeeds, the package is marked as installed. - If the script fails, the package is marked as unpacked and - the script is executed when the image boots again. <note> Any RPM post-installation script that runs on the target should return a 0 exit code. @@ -3241,7 +3302,7 @@ mark post installs to defer to the target. You can use <filename>pkg_postinst_ontarget()</filename> or call - <filename>postinst-intercepts defer_to_first_boot</filename> + <filename>postinst_intercept delay_to_first_boot</filename> from <filename>pkg_postinst()</filename>. Any failure of a <filename>pkg_postinst()</filename> script (including exit 1) triggers an error during the @@ -4196,11 +4257,27 @@ built by layer recipes. It is recommended to keep recipes up-to-date with upstream version releases. + </para> + + <para> + While several methods exist that allow you upgrade a recipe, + you might consider checking on the upgrade status of a recipe + first. + You can do so using the + <filename>devtool check-upgrade-status</filename> command. + See the + "<ulink url='&YOCTO_DOCS_REF_URL;#devtool-checking-on-the-upgrade-status-of-a-recipe'>Checking on the Upgrade Status of a Recipe</ulink>" + section in the Yocto Project Reference Manual for more information. + </para> + + <para> + The remainder of this section describes three ways you can + upgrade a recipe. You can use the Automated Upgrade Helper (AUH) to set up automatic version upgrades. Alternatively, you can use <filename>devtool upgrade</filename> to set up semi-automatic version upgrades. - Finally, you can even manually upgrade a recipe by editing the + Finally, you can manually upgrade a recipe by editing the recipe itself. </para> @@ -4319,12 +4396,6 @@ Make these following configurations: <itemizedlist> <listitem><para> - Enable "distrodata" as follows: - <literallayout class='monospaced'> - INHERIT =+ "distrodata" - </literallayout> - </para></listitem> - <listitem><para> If you want to enable <ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality'>Build History</ulink>, which is optional, you need the following @@ -5116,15 +5187,15 @@ So, commands such as the following are useful when exploring the data store and running functions: <literallayout class='monospaced'> - pydevshell> d.getVar("STAGING_DIR", True) + pydevshell> d.getVar("STAGING_DIR") '/media/build1/poky/build/tmp/sysroots' - pydevshell> d.getVar("STAGING_DIR", False) + pydevshell> d.getVar("STAGING_DIR") '${TMPDIR}/sysroots' pydevshell> d.setVar("FOO", "bar") - pydevshell> d.getVar("FOO", True) + pydevshell> d.getVar("FOO") 'bar' pydevshell> d.delVar("FOO") - pydevshell> d.getVar("FOO", True) + pydevshell> d.getVar("FOO") pydevshell> bb.build.exec_func("do_unpack", d) pydevshell> </literallayout> @@ -5409,26 +5480,39 @@ <literallayout class='monospaced'> BBMULTICONFIG = "x86 arm" </literallayout> + <note> + A "default" configuration already exists by + definition. + This configuration is named: "" (i.e. empty + string) and is defined by the variables coming + from your <filename>local.conf</filename> file. + Consequently, the previous example actually + adds two additional configurations to your + build: "arm" and "x86" along with "". + </note> </para></listitem> <listitem><para> <emphasis>Launch BitBake</emphasis>: Use the following BitBake command form to launch the multiple configuration build: <literallayout class='monospaced'> - $ bitbake [multiconfig:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable> [[[multiconfig:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable>] ... ] + $ bitbake [mc:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable> [[[mc:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable>] ... ] </literallayout> For the example in this section, the following command applies: <literallayout class='monospaced'> - $ bitbake multiconfig:x86:core-image-minimal multiconfig:arm:core-image-sato + $ bitbake mc:x86:core-image-minimal mc:arm:core-image-sato mc::core-image-base </literallayout> The previous BitBake command builds a <filename>core-image-minimal</filename> image that is configured through the - <filename>x86.conf</filename> configuration file - and builds a <filename>core-image-sato</filename> + <filename>x86.conf</filename> configuration file, + a <filename>core-image-sato</filename> image that is configured through the - <filename>arm.conf</filename> configuration file. + <filename>arm.conf</filename> configuration file + and a <filename>core-image-base</filename> that is + configured through your + <filename>local.conf</filename> configuration file. </para></listitem> </itemizedlist> <note> @@ -5468,7 +5552,7 @@ build, you must declare the dependencies in the recipe using the following statement form: <literallayout class='monospaced'> - <replaceable>task_or_package</replaceable>[mcdepends] = "multiconfig:<replaceable>from_multiconfig</replaceable>:<replaceable>to_multiconfig</replaceable>:<replaceable>recipe_name</replaceable>:<replaceable>task_on_which_to_depend</replaceable>" + <replaceable>task_or_package</replaceable>[mcdepends] = "mc:<replaceable>from_multiconfig</replaceable>:<replaceable>to_multiconfig</replaceable>:<replaceable>recipe_name</replaceable>:<replaceable>task_on_which_to_depend</replaceable>" </literallayout> To better show how to use this statement, consider the example scenario from the first paragraph of this section. @@ -5476,7 +5560,7 @@ that builds the <filename>core-image-sato</filename> image: <literallayout class='monospaced'> - do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_rootfs" + do_image[mcdepends] = "mc:x86:arm:core-image-minimal:do_rootfs" </literallayout> In this example, the <replaceable>from_multiconfig</replaceable> is "x86". @@ -5491,7 +5575,7 @@ Once you set up this dependency, you can build the "x86" multiconfig using a BitBake command as follows: <literallayout class='monospaced'> - $ bitbake multiconfig:x86:core-image-sato + $ bitbake mc:x86:core-image-sato </literallayout> This command executes all the tasks needed to create the <filename>core-image-sato</filename> image for the @@ -5507,7 +5591,7 @@ Consider this change to the statement in the <filename>core-image-sato</filename> recipe: <literallayout class='monospaced'> - do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_image" + do_image[mcdepends] = "mc:x86:arm:core-image-minimal:do_image" </literallayout> In this case, BitBake must create the <filename>core-image-minimal</filename> image for the @@ -6323,9 +6407,180 @@ </literallayout> </para> </section> - </section> + <section id="replicating-a-build-offline"> + <title>Replicating a Build Offline</title> + <para> + It can be useful to take a "snapshot" of upstream sources + used in a build and then use that "snapshot" later to + replicate the build offline. + To do so, you need to first prepare and populate your downloads + directory your "snapshot" of files. + Once your downloads directory is ready, you can use it at + any time and from any machine to replicate your build. + </para> + + <para> + Follow these steps to populate your Downloads directory: + <orderedlist> + <listitem><para> + <emphasis>Create a Clean Downloads Directory:</emphasis> + Start with an empty downloads directory + (<ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink>). + You start with an empty downloads directory by either + removing the files in the existing directory or by + setting + <filename>DL_DIR</filename> to point to either an + empty location or one that does not yet exist. + </para></listitem> + <listitem><para> + <emphasis>Generate Tarballs of the Source Git Repositories:</emphasis> + Edit your <filename>local.conf</filename> configuration + file as follows: + <literallayout class='monospaced'> + DL_DIR = "/home/<replaceable>your-download-dir</replaceable>/" + BB_GENERATE_MIRROR_TARBALLS = "1" + </literallayout> + During the fetch process in the next step, BitBake + gathers the source files and creates tarballs in + the directory pointed to by <filename>DL_DIR</filename>. + See the + <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></ulink> + variable for more information. + </para></listitem> + <listitem><para> + <emphasis>Populate Your Downloads Directory Without Building:</emphasis> + Use BitBake to fetch your sources but inhibit the + build: + <literallayout class='monospaced'> + $ bitbake <replaceable>target</replaceable> --runonly=fetch + </literallayout> + The downloads directory (i.e. + <filename>${DL_DIR}</filename>) now has a "snapshot" of + the source files in the form of tarballs, which can + be used for the build. + </para></listitem> + <listitem><para> + <emphasis>Optionally Remove Any Git or other SCM Subdirectories From the Downloads Directory:</emphasis> + If you want, you can clean up your downloads directory + by removing any Git or other Source Control Management + (SCM) subdirectories such as + <filename>${DL_DIR}/git2/*</filename>. + The tarballs already contain these subdirectories. + </para></listitem> + </orderedlist> + </para> + + <para> + Once your downloads directory has everything it needs regarding + source files, you can create your "own-mirror" and build + your target. + Understand that you can use the files to build the target + offline from any machine and at any time. + </para> + + <para> + Follow these steps to build your target using the files in the + downloads directory: + <orderedlist> + <listitem><para> + <emphasis>Using Local Files Only:</emphasis> + Inside your <filename>local.conf</filename> file, add + the + <ulink url='&YOCTO_DOCS_REF_URL;#var-SOURCE_MIRROR_URL'><filename>SOURCE_MIRROR_URL</filename></ulink> + variable, + inherit the <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-own-mirrors'><filename>own-mirrors</filename></ulink> + class, and use the + <ulink url='&YOCTO_DOCS_BB_URL;#var-bb-BB_NO_NETWORK'><filename>BB_NO_NETWORK</filename></ulink> + variable to your <filename>local.conf</filename>. + <literallayout class='monospaced'> + SOURCE_MIRROR_URL ?= "file:///home/<replaceable>your-download-dir</replaceable>/" + INHERIT += "own-mirrors" + BB_NO_NETWORK = "1" + </literallayout> + The <filename>SOURCE_MIRROR_URL</filename> and + <filename>own-mirror</filename> class set up the system + to use the downloads directory as your "own mirror". + Using the <filename>BB_NO_NETWORK</filename> + variable makes sure that BitBake's fetching process + in step 3 stays local, which means files from + your "own-mirror" are used. + </para></listitem> + <listitem><para> + <emphasis>Start With a Clean Build:</emphasis> + You can start with a clean build by removing the + <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink><filename>}</filename> + directory or using a new + <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>. + </para></listitem> + <listitem><para> + <emphasis>Build Your Target:</emphasis> + Use BitBake to build your target: + <literallayout class='monospaced'> + $ bitbake <replaceable>target</replaceable> + </literallayout> + The build completes using the known local "snapshot" of + source files from your mirror. + The resulting tarballs for your "snapshot" of source + files are in the downloads directory. + <note> + <para>The offline build does not work if recipes + attempt to find the latest version of software + by setting + <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink> + to + <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-AUTOREV'><filename>AUTOREV</filename></ulink><filename>}</filename>: + <literallayout class='monospaced'> + SRCREV = "${AUTOREV}" + </literallayout> + When a recipe sets + <filename>SRCREV</filename> to + <filename>${AUTOREV}</filename>, the build system + accesses the network in an attempt to determine the + latest version of software from the SCM. + Typically, recipes that use + <filename>AUTOREV</filename> are custom or + modified recipes. + Recipes that reside in public repositories + usually do not use <filename>AUTOREV</filename>. + </para> + + <para>If you do have recipes that use + <filename>AUTOREV</filename>, you can take steps to + still use the recipes in an offline build. + Do the following: + <orderedlist> + <listitem><para> + Use a configuration generated by + enabling + <link linkend='maintaining-build-output-quality'>build history</link>. + </para></listitem> + <listitem><para> + Use the + <filename>buildhistory-collect-srcrevs</filename> + command to collect the stored + <filename>SRCREV</filename> values from + the build's history. + For more information on collecting these + values, see the + "<link linkend='build-history-package-information'>Build History Package Information</link>" + section. + </para></listitem> + <listitem><para> + Once you have the correct source + revisions, you can modify those recipes + to to set <filename>SRCREV</filename> + to specific versions of the software. + </para></listitem> + </orderedlist> + </para> + </note> + </para></listitem> + </orderedlist> + </para> + </section> + </section> <section id='speeding-up-a-build'> <title>Speeding Up a Build</title> @@ -6892,8 +7147,8 @@ <literallayout class='monospaced'> MACHINE = "qemux86-64" DEFAULTTUNE = "x86-64-x32" - baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) \ - or 'INVALID'), True) or 'lib'}" + baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE') \ + or 'INVALID')) or 'lib'}" </literallayout> Once you have set up your configuration file, use BitBake to build an image that supports the x32 psABI. @@ -6947,7 +7202,8 @@ This problem is solved with the OpenEmbedded build system by running the code through QEMU, which allows precisely that. Unfortunately, QEMU does not always work perfectly as mentioned - in the xxx section. + in the + "<link linkend='known-issues'>Known Issues</link>" section. </para> <section id='enabling-the-generation-of-introspection-data'> @@ -7216,17 +7472,17 @@ it is based on is by definition incomplete. The purpose of the command is to allow the generation of customized images, and as such, was designed to be - completely extensible through a plug-in interface. + completely extensible through a plugin interface. See the - "<link linkend='wic-using-the-wic-plug-ins-interface'>Using the Wic Plug-Ins Interface</link>" - section for information on these plug-ins. + "<link linkend='wic-using-the-wic-plugin-interface'>Using the Wic PlugIn Interface</link>" + section for information on these plugins. </para> <para> This section provides some background information on Wic, describes what you need to have in place to run the tool, provides instruction on how to use - the Wic utility, provides information on using the Wic plug-ins + the Wic utility, provides information on using the Wic plugins interface, and provides several examples that show how to use Wic. </para> @@ -7393,7 +7649,6 @@ available Wic images as follows: <literallayout class='monospaced'> $ wic list images - mpc8315e-rdb Create SD card image for MPC8315E-RDB genericx86 Create an EFI disk image for genericx86* beaglebone-yocto Create SD card image for Beaglebone edgerouter Create SD card image for Edgerouter @@ -7581,7 +7836,6 @@ files: <literallayout class='monospaced'> $ wic list images - mpc8315e-rdb Create SD card image for MPC8315E-RDB genericx86 Create an EFI disk image for genericx86* beaglebone-yocto Create SD card image for Beaglebone edgerouter Create SD card image for Edgerouter @@ -7621,28 +7875,28 @@ </para> </section> - <section id='wic-using-the-wic-plug-ins-interface'> - <title>Using the Wic Plug-Ins Interface</title> + <section id='wic-using-the-wic-plugin-interface'> + <title>Using the Wic Plugin Interface</title> <para> You can extend and specialize Wic functionality by using - Wic plug-ins. - This section explains the Wic plug-in interface. + Wic plugins. + This section explains the Wic plugin interface. <note> - Wic plug-ins consist of "source" and "imager" plug-ins. - Imager plug-ins are beyond the scope of this section. + Wic plugins consist of "source" and "imager" plugins. + Imager plugins are beyond the scope of this section. </note> </para> <para> - Source plug-ins provide a mechanism to customize partition + Source plugins provide a mechanism to customize partition content during the Wic image generation process. - You can use source plug-ins to map values that you specify + You can use source plugins to map values that you specify using <filename>--source</filename> commands in kickstart - files (i.e. <filename>*.wks</filename>) to a plug-in + files (i.e. <filename>*.wks</filename>) to a plugin implementation used to populate a given partition. <note> - If you use plug-ins that have build-time dependencies + If you use plugins that have build-time dependencies (e.g. native tools, bootloaders, and so forth) when building a Wic image, you need to specify those dependencies using the @@ -7652,43 +7906,43 @@ </para> <para> - Source plug-ins are subclasses defined in plug-in files. - As shipped, the Yocto Project provides several plug-in + Source plugins are subclasses defined in plugin files. + As shipped, the Yocto Project provides several plugin files. - You can see the source plug-in files that ship with the + You can see the source plugin files that ship with the Yocto Project <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/scripts/lib/wic/plugins/source'>here</ulink>. - Each of these plug-in files contains source plug-ins that + Each of these plugin files contains source plugins that are designed to populate a specific Wic image partition. </para> <para> - Source plug-ins are subclasses of the + Source plugins are subclasses of the <filename>SourcePlugin</filename> class, which is defined in the <filename>poky/scripts/lib/wic/pluginbase.py</filename> file. For example, the <filename>BootimgEFIPlugin</filename> - source plug-in found in the + source plugin found in the <filename>bootimg-efi.py</filename> file is a subclass of the <filename>SourcePlugin</filename> class, which is found in the <filename>pluginbase.py</filename> file. </para> <para> - You can also implement source plug-ins in a layer outside + You can also implement source plugins in a layer outside of the Source Repositories (external layer). - To do so, be sure that your plug-in files are located in + To do so, be sure that your plugin files are located in a directory whose path is <filename>scripts/lib/wic/plugins/source/</filename> within your external layer. - When the plug-in files are located there, the source - plug-ins they contain are made available to Wic. + When the plugin files are located there, the source + plugins they contain are made available to Wic. </para> <para> When the Wic implementation needs to invoke a - partition-specific implementation, it looks for the plug-in + partition-specific implementation, it looks for the plugin with the same name as the <filename>--source</filename> parameter used in the kickstart file given to that partition. @@ -7698,13 +7952,13 @@ part /boot --source bootimg-pcbios --ondisk sda --label boot --active --align 1024 </literallayout> The methods defined as class members of the matching - source plug-in (i.e. <filename>bootimg-pcbios</filename>) - in the <filename>bootimg-pcbios.py</filename> plug-in file + source plugin (i.e. <filename>bootimg-pcbios</filename>) + in the <filename>bootimg-pcbios.py</filename> plugin file are used. </para> <para> - To be more concrete, here is the corresponding plug-in + To be more concrete, here is the corresponding plugin definition from the <filename>bootimg-pcbios.py</filename> file for the previous command along with an example method called by the Wic implementation when it needs to @@ -7736,19 +7990,19 @@ . . </literallayout> - If a subclass (plug-in) itself does not implement a + If a subclass (plugin) itself does not implement a particular function, Wic locates and uses the default version in the superclass. - It is for this reason that all source plug-ins are derived + It is for this reason that all source plugins are derived from the <filename>SourcePlugin</filename> class. </para> <para> The <filename>SourcePlugin</filename> class defined in the <filename>pluginbase.py</filename> file defines - a set of methods that source plug-ins can implement or + a set of methods that source plugins can implement or override. - Any plug-ins (subclass of + Any plugins (subclass of <filename>SourcePlugin</filename>) that do not implement a particular method inherit the implementation of the method from the <filename>SourcePlugin</filename> class. @@ -7809,11 +8063,11 @@ </para> <para> - You can extend the source plug-in mechanism. - To add more hooks, create more source plug-in methods + You can extend the source plugin mechanism. + To add more hooks, create more source plugin methods within <filename>SourcePlugin</filename> and the corresponding derived subclasses. - The code that calls the plug-in methods uses the + The code that calls the plugin methods uses the <filename>plugin.get_source_plugin_methods()</filename> function to find the method or methods needed by the call. Retrieval of those methods is accomplished by filling up @@ -8792,11 +9046,17 @@ <link linkend='handling-optional-module-packaging'>Handling optional module packaging</link> </para></listitem> <listitem><para> - <link linkend='using-runtime-package-management'>Using Runtime Package Management</link> + <link linkend='using-runtime-package-management'>Using runtime package management</link> + </para></listitem> + <listitem><para> + <link linkend='generating-and-using-signed-packages'>Generating and using signed packages</link> </para></listitem> <listitem><para> <link linkend='testing-packages-with-ptest'>Setting up and running package test (ptest)</link> </para></listitem> + <listitem><para> + <link linkend='creating-node-package-manager-npm-packages'>Creating node package manager (NPM) packages</link> + </para></listitem> </itemizedlist> </para> @@ -9233,7 +9493,7 @@ <para> Many pieces of software split functionality into optional - modules (or plug-ins) and the plug-ins that are built + modules (or plugins) and the plugins that are built might depend on configuration options. To avoid having to duplicate the logic that determines what modules are available in your recipe or to avoid having @@ -10225,6 +10485,282 @@ </para> </section> </section> + + <section id='creating-node-package-manager-npm-packages'> + <title>Creating Node Package Manager (NPM) Packages</title> + + <para> + <ulink url='https://en.wikipedia.org/wiki/Npm_(software)'>NPM</ulink> + is a package manager for the JavaScript programming + language. + The Yocto Project supports the NPM + <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetcher</ulink>. + You can use this fetcher in combination with + <ulink url='&YOCTO_DOCS_REF_URL;#ref-devtool-reference'><filename>devtool</filename></ulink> + to create recipes that produce NPM packages. + </para> + + <para> + Two workflows exist that allow you to create NPM packages + using <filename>devtool</filename>: the NPM registry modules + method and the NPM project code method. + <note> + While it is possible to create NPM recipes manually, + using <filename>devtool</filename> is far simpler. + </note> + Additionally, some requirements and caveats exist. + </para> + + <section id='npm-package-creation-requirements'> + <title>Requirements and Caveats</title> + + <para> + You need to be aware of the following before using + <filename>devtool</filename> to create NPM packages: + <itemizedlist> + <listitem><para> + Of the two methods that you can use + <filename>devtool</filename> to create NPM + packages, the registry approach is slightly + simpler. + However, you might consider the project + approach because you do not have to publish + your module in the NPM registry + (<ulink url='https://docs.npmjs.com/misc/registry'><filename>npm-registry</filename></ulink>), + which is NPM's public registry. + </para></listitem> + <listitem><para> + Be familiar with + <ulink url='&YOCTO_DOCS_REF_URL;#ref-devtool-reference'><filename>devtool</filename></ulink>. + </para></listitem> + <listitem><para> + The NPM host tools need the native + <filename>nodejs-npm</filename> package, which + is part of the OpenEmbedded environment. + You need to get the package by cloning the + <ulink url='https://github.com/openembedded/meta-openembedded'></ulink> + repository out of GitHub. + Be sure to add the path to your local copy to + your <filename>bblayers.conf</filename> file. + </para></listitem> + <listitem><para> + <filename>devtool</filename> cannot detect + native libraries in module dependencies. + Consequently, you must manually add packages + to your recipe. + </para></listitem> + <listitem><para> + While deploying NPM packages, + <filename>devtool</filename> cannot determine + which dependent packages are missing on the + target (e.g. the node runtime + <filename>nodejs</filename>). + Consequently, you need to find out what + files are missing and be sure they are on the + target. + </para></listitem> + <listitem><para> + Although you might not need NPM to run your + node package, it is useful to have NPM on your + target. + The NPM package name is + <filename>nodejs-npm</filename>. + </para></listitem> + </itemizedlist> + </para> + </section> + + <section id='npm-using-the-registry-modules-method'> + <title>Using the Registry Modules Method</title> + + <para> + This section presents an example that uses the + <filename>cute-files</filename> module, which is a + file browser web application. + <note> + You must know the <filename>cute-files</filename> + module version. + </note> + </para> + + <para> + The first thing you need to do is use + <filename>devtool</filename> and the NPM fetcher to + create the recipe: + <literallayout class='monospaced'> + $ devtool add "npm://registry.npmjs.org;package=cute-files;version=1.0.2" + </literallayout> + The <filename>devtool add</filename> command runs + <filename>recipetool create</filename> and uses the + same fetch URI to download each dependency and capture + license details where possible. + The result is a generated recipe. + </para> + + <para> + The recipe file is fairly simple and contains every + license that <filename>recipetool</filename> finds + and includes the licenses in the recipe's + <ulink url='&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></ulink> + variables. + You need to examine the variables and look for those + with "unknown" in the + <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink> + field. + You need to track down the license information for + "unknown" modules and manually add the information to the + recipe. + </para> + + <para> + <filename>recipetool</filename> creates a "shrinkwrap" file + for your recipe. + Shrinkwrap files capture the version of all dependent + modules. + Many packages do not provide shrinkwrap files. + <filename>recipetool</filename> create a shrinkwrap + file as it runs. + <note> + A package is created for each sub-module. + This policy is the only practical way to have the + licenses for all of the dependencies represented + in the license manifest of the image. + </note> + </para> + + <para> + The <filename>devtool edit-recipe</filename> command + lets you take a look at the recipe: + <literallayout class='monospaced'> + $ devtool edit-recipe cute-files + SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network." + LICENSE = "MIT & ISC & Unknown" + LIC_FILES_CHKSUM = "file://LICENSE;md5=71d98c0a1db42956787b1909c74a86ca \ + file://node_modules/toidentifier/LICENSE;md5=1a261071a044d02eb6f2bb47f51a3502 \ + file://node_modules/debug/LICENSE;md5=ddd815a475e7338b0be7a14d8ee35a99 \ + ... + + SRC_URI = " \ + npm://registry.npmjs.org/;package=cute-files;version=${PV} \ + npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \ + " + + S = "${WORKDIR}/npm" + + inherit npm + + LICENSE_${PN} = "MIT" + LICENSE_${PN}-accepts = "MIT" + LICENSE_${PN}-array-flatten = "MIT" + ... + LICENSE_${PN}-vary = "MIT" + </literallayout> + Three key points exist in the previous example: + <itemizedlist> + <listitem><para> + <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> + uses the NPM scheme so that the NPM fetcher + is used. + </para></listitem> + <listitem><para> + <filename>recipetool</filename> collects all + the license information. + If a sub-module's license is unavailable, + the sub-module's name appears in the comments. + </para></listitem> + <listitem><para> + The <filename>inherit npm</filename> statement + causes the + <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-npm'><filename>npm</filename></ulink> + class to package up all the modules. + </para></listitem> + </itemizedlist> + </para> + + <para> + You can run the following command to build the + <filename>cute-files</filename> package: + <literallayout class='monospaced'> + $ devtool build cute-files + </literallayout> + Remember that <filename>nodejs</filename> must be + installed on the target before your package. + </para> + + <para> + Assuming 192.168.7.2 for the target's IP address, use + the following command to deploy your package: + <literallayout class='monospaced'> + $ devtool deploy-target -s cute-files root@192.168.7.2 + </literallayout> + Once the package is installed on the target, you can + test the application: + <note> + Because of a know issue, you cannot simply run + <filename>cute-files</filename> as you would if you + had run <filename>npm install</filename>. + </note> + <literallayout class='monospaced'> + $ cd /usr/lib/node_modules/cute-files + $ node cute-files.js + </literallayout> + On a browser, go to + <filename>http://192.168.7.2:3000</filename> and you + see the following: + <imagedata fileref="figures/cute-files-npm-example.png" align="center" width="6in" depth="4in" /> + </para> + + <para> + You can find the recipe in + <filename>workspace/recipes/cute-files</filename>. + You can use the recipe in any layer you choose. + </para> + </section> + + <section id='npm-using-the-npm-projects-method'> + <title>Using the NPM Projects Code Method</title> + + <para> + Although it is useful to package modules already in the + NPM registry, adding <filename>node.js</filename> projects + under development is a more common developer use case. + </para> + + <para> + This section covers the NPM projects code method, which is + very similar to the "registry" approach described in the + previous section. + In the NPM projects method, you provide + <filename>devtool</filename> with an URL that points to the + source files. + </para> + + <para> + Replicating the same example, (i.e. + <filename>cute-files</filename>) use the following command: + <literallayout class='monospaced'> + $ devtool add https://github.com/martinaglv/cute-files.git + </literallayout> + The recipe this command generates is very similar to the + recipe created in the previous section. + However, the <filename>SRC_URI</filename> looks like the + following: + <literallayout class='monospaced'> + SRC_URI = " \ + git://github.com/martinaglv/cute-files.git;protocol=https \ + npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \ + " + </literallayout> + In this example, the main module is taken from the Git + repository and dependents are taken from the NPM registry. + Other than those differences, the recipe is basically the + same between the two methods. + You can build and deploy the package exactly as described + in the previous section that uses the registry modules + method. + </para> + </section> + </section> </section> <section id='efficiently-fetching-source-files-during-a-build'> @@ -10314,7 +10850,7 @@ Use the following BitBake command form to fetch all the necessary sources without starting the build: <literallayout class='monospaced'> - $ bitbake -c <replaceable>target</replaceable> runall="fetch" + $ bitbake <replaceable>target</replaceable> --runall=fetch </literallayout> This variation of the BitBake command guarantees that you have all the sources for that BitBake target should you @@ -10337,6 +10873,38 @@ </para> <para> + Within the system, SysVinit treats system components as services. + These services are maintained as shell scripts stored in the + <filename>/etc/init.d/</filename> directory. + Services organize into different run levels. + This organization is maintained by putting links to the services + in the <filename>/etc/rcN.d/</filename> directories, where + <replaceable>N/</replaceable> is one of the following options: + "S", "0", "1", "2", "3", "4", "5", or "6". + <note> + Each runlevel has a dependency on the previous runlevel. + This dependency allows the services to work properly. + </note> + </para> + + <para> + In comparison, systemd treats components as units. + Using units is a broader concept as compared to using a service. + A unit includes several different types of entities. + Service is one of the types of entities. + The runlevel concept in SysVinit corresponds to the concept of a + target in systemd, where target is also a type of supported unit. + </para> + + <para> + In a SysVinit-based system, services load sequentially (i.e. one + by one) during and parallelization is not supported. + With systemd, services start in parallel. + Needless to say, the method can have an impact on system startup + performance. + </para> + + <para> If you want to use SysVinit, you do not have to do anything. But, if you want to use systemd, you must @@ -10347,7 +10915,7 @@ <title>Using systemd Exclusively</title> <para> - Set the these variables in your distribution configuration + Set these variables in your distribution configuration file as follows: <literallayout class='monospaced'> DISTRO_FEATURES_append = " systemd" @@ -10615,18 +11183,18 @@ <para> To create the read-only root filesystem, simply add the - "read-only-rootfs" feature to your image. - Using either of the following statements in your - image recipe or from within the - <filename>local.conf</filename> file found in the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink> - causes the build system to create a read-only root filesystem: + "read-only-rootfs" feature to your image, normally in one of two ways. + The first way is to add the "read-only-rootfs" image feature + in the image's recipe file via the + <filename>IMAGE_FEATURES</filename> variable: <literallayout class='monospaced'> - IMAGE_FEATURES = "read-only-rootfs" + IMAGE_FEATURES += "read-only-rootfs" </literallayout> - or + As an alternative, you can add the same feature from within your + build directory's <filename>local.conf</filename> file with the + associated <filename>EXTRA_IMAGE_FEATURES</filename> variable, as in: <literallayout class='monospaced'> - EXTRA_IMAGE_FEATURES += "read-only-rootfs" + EXTRA_IMAGE_FEATURES = "read-only-rootfs" </literallayout> </para> @@ -11489,15 +12057,15 @@ In order to run tests on hardware, you need to set <filename>TEST_TARGET</filename> to an appropriate value. For QEMU, you do not have to change anything, the default - value is "QemuTarget". + value is "qemu". For running tests on hardware, the following options exist: <itemizedlist> - <listitem><para><emphasis>"SimpleRemoteTarget":</emphasis> - Choose "SimpleRemoteTarget" if you are going to + <listitem><para><emphasis>"simpleremote":</emphasis> + Choose "simpleremote" if you are going to run tests on a target system that is already running the image to be tested and is available on the network. - You can use "SimpleRemoteTarget" in conjunction + You can use "simpleremote" in conjunction with either real hardware or an image running within a separately started QEMU or any other virtual machine manager. @@ -11672,7 +12240,7 @@ <title>Power Control</title> <para> - For most hardware targets other than SimpleRemoteTarget, + For most hardware targets other than "simpleremote", you can control power: <itemizedlist> <listitem><para> @@ -12069,7 +12637,7 @@ <listitem><para><emphasis><filename>target</filename>:</emphasis> The target controller object used to deploy and start an image on a particular target - (e.g. QemuTarget, SimpleRemote, and + (e.g. Qemu, SimpleRemote, and SystemdbootTarget). Tests usually use the following: <itemizedlist> @@ -12318,14 +12886,6 @@ </itemizedlist> </para> - <para> - For debugging information within the popular - <trademark class='trade'>Eclipse</trademark> IDE, see the - "<ulink url='&YOCTO_DOCS_SDK_URL;#adt-eclipse'>Working within Eclipse</ulink>" - section in the Yocto Project Application Development and the - Extensible Software Development Kit (eSDK) manual. - </para> - <section id='dev-debugging-viewing-logs-from-failed-tasks'> <title>Viewing Logs from Failed Tasks</title> @@ -12363,6 +12923,16 @@ <title>Viewing Variable Values</title> <para> + Sometimes you need to know the value of a variable as a + result of BitBake's parsing step. + This could be because some unexpected behavior occurred + in your project. + Perhaps an attempt to + <ulink url='&YOCTO_DOCS_BB_URL;#modifying-existing-variables'>modify a variable</ulink> + did not work out as expected. + </para> + + <para> BitBake's <filename>-e</filename> option is used to display variable values after parsing. The following command displays the variable values after the @@ -14888,12 +15458,12 @@ </para> <para> - Specifying audio and video plug-ins as part of the + Specifying audio and video plugins as part of the <filename>COMMERCIAL_AUDIO_PLUGINS</filename> and <filename>COMMERCIAL_VIDEO_PLUGINS</filename> statements (along with the enabling <filename>LICENSE_FLAGS_WHITELIST</filename>) includes the - plug-ins or components into built images, thus adding + plugins or components into built images, thus adding support for media formats or components. </para> </section> diff --git a/external/poky/documentation/dev-manual/dev-manual-eclipse-customization.xsl b/external/poky/documentation/dev-manual/dev-manual-eclipse-customization.xsl deleted file mode 100644 index 6d7b5fbb..00000000 --- a/external/poky/documentation/dev-manual/dev-manual-eclipse-customization.xsl +++ /dev/null @@ -1,35 +0,0 @@ -<?xml version='1.0'?> -<xsl:stylesheet - xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - xmlns="http://www.w3.org/1999/xhtml" - xmlns:fo="http://www.w3.org/1999/XSL/Format" - version="1.0"> - - <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - -<!-- - - <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - - <xsl:import - href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" /> - ---> - - <xsl:param name="chunker.output.indent" select="'yes'"/> - <xsl:param name="chunk.quietly" select="1"/> - <xsl:param name="chunk.first.sections" select="1"/> - <xsl:param name="chunk.section.depth" select="10"/> - <xsl:param name="use.id.as.filename" select="1"/> - <xsl:param name="ulink.target" select="'_self'" /> - <xsl:param name="base.dir" select="'html/dev-manual/'"/> - <xsl:param name="html.stylesheet" select="'../book.css'"/> - <xsl:param name="eclipse.manifest" select="0"/> - <xsl:param name="create.plugin.xml" select="0"/> - <xsl:param name="suppress.navigation" select="1"/> - <xsl:param name="generate.index" select="0"/> - <xsl:param name="chapter.autolabel" select="1" /> - <xsl:param name="appendix.autolabel" select="1" /> - <xsl:param name="section.autolabel" select="1" /> - <xsl:param name="section.label.includes.component.label" select="1" /> -</xsl:stylesheet> diff --git a/external/poky/documentation/dev-manual/dev-manual-qemu.xml b/external/poky/documentation/dev-manual/dev-manual-qemu.xml index 4e7b5de4..5ccc0dfe 100644 --- a/external/poky/documentation/dev-manual/dev-manual-qemu.xml +++ b/external/poky/documentation/dev-manual/dev-manual-qemu.xml @@ -151,13 +151,13 @@ <itemizedlist> <listitem><para> This example starts QEMU with - <replaceable>MACHINE</replaceable> set to "qemux86". + <replaceable>MACHINE</replaceable> set to "qemux86-64". Assuming a standard <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>, <filename>runqemu</filename> automatically finds the - <filename>bzImage-qemux86.bin</filename> image file and + <filename>bzImage-qemux86-64.bin</filename> image file and the - <filename>core-image-minimal-qemux86-20140707074611.rootfs.ext3</filename> + <filename>core-image-minimal-qemux86-64-20200218002850.rootfs.ext4</filename> (assuming the current build created a <filename>core-image-minimal</filename> image). <note> @@ -166,7 +166,7 @@ timestamp. </note> <literallayout class='monospaced'> - $ runqemu qemux86 + $ runqemu qemux86-64 </literallayout> </para></listitem> <listitem><para> @@ -175,7 +175,7 @@ This command, however, specifically provides the image and root filesystem type. <literallayout class='monospaced'> - $ runqemu qemux86 core-image-minimal ext3 + $ runqemu qemux86-64 core-image-minimal ext4 </literallayout> </para></listitem> <listitem><para> @@ -188,7 +188,7 @@ be installed (see the previous description for the <filename>audio</filename> option for more information). <literallayout class='monospaced'> - $ runqemu qemux86 ramfs audio + $ runqemu qemux86-64 ramfs audio </literallayout> </para></listitem> <listitem><para> @@ -200,7 +200,7 @@ <replaceable>KERNEL</replaceable>, or <replaceable>VM</replaceable> option. <literallayout class='monospaced'> - $ runqemu ext3 + $ runqemu ext4 </literallayout> </para></listitem> <listitem><para> @@ -209,9 +209,9 @@ From the <filename>.wic.vmdk</filename>, <filename>runqemu</filename> determines the QEMU architecture (<replaceable>MACHINE</replaceable>) to be - "qemux86" and the root filesystem type to be "vmdk". + "qemux86-64" and the root filesystem type to be "vmdk". <literallayout class='monospaced'> - $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86.wic.vmdk + $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86-64.wic.vmdk </literallayout> </para></listitem> </itemizedlist> @@ -296,7 +296,7 @@ extracts it to a directory named <filename>test-nfs</filename>: <literallayout class='monospaced'> - runqemu-extract-sdk ./tmp/deploy/images/qemux86/core-image-sato-qemux86.tar.bz2 test-nfs + runqemu-extract-sdk ./tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64.tar.bz2 test-nfs </literallayout> </para></listitem> <listitem><para> @@ -310,7 +310,7 @@ Here is an example using the <filename>qemux86</filename> image: <literallayout class='monospaced'> - runqemu qemux86 ./test-nfs + runqemu qemux86-64 ./test-nfs </literallayout> </para></listitem> </orderedlist> @@ -590,6 +590,9 @@ <filename>nographic</filename>: Disables the video console, which sets the console to "ttys0". + This option is useful when you have logged into a server + and you do not want to disable forwarding from the + X Window System (X11) to your workstation or laptop. </para></listitem> <listitem><para> <filename>serial</filename>: diff --git a/external/poky/documentation/dev-manual/dev-manual-start.xml b/external/poky/documentation/dev-manual/dev-manual-start.xml index d37c0303..8cb5631f 100644 --- a/external/poky/documentation/dev-manual/dev-manual-start.xml +++ b/external/poky/documentation/dev-manual/dev-manual-start.xml @@ -7,7 +7,7 @@ <title>Setting Up to Use the Yocto Project</title> <para> - This chapter provides procedures related to getting set up to use the + This chapter provides guidance on how to prepare to use the Yocto Project. You can learn about creating a team environment that develops using the Yocto Project, how to set up a @@ -23,11 +23,10 @@ It might not be immediately clear how you can use the Yocto Project in a team development environment, or how to scale it for a large team of developers. - One of the strengths of the Yocto Project is that it is extremely - flexible. - Thus, you can adapt it to many different use cases and scenarios. - However, this flexibility could cause difficulties if you are trying - to create a working setup that scales across a large team. + You can adapt the Yocto Project to many different use cases and + scenarios; + however, this flexibility could cause difficulties if you are trying + to create a working setup that scales effectively. </para> <para> @@ -36,17 +35,17 @@ that can help you get the results you want. The procedure is high-level and presents some of the project's most successful experiences, practices, solutions, and available - technologies that have proved to work well in the past. - Keep in mind, the procedure here is a starting point. + technologies that have proved to work well in the past; + however, keep in mind, the procedure here is simply a starting point. You can build off these steps and customize the procedure to fit any particular working environment and set of practices. <orderedlist> <listitem><para> <emphasis>Determine Who is Going to be Developing:</emphasis> - You need to understand who is going to be doing anything - related to the Yocto Project and what their roles would be. + You first need to understand who is going to be doing anything + related to the Yocto Project and determine their roles. Making this determination is essential to completing - steps two and three, which are to get your equipment together + subsequent steps, which are to get your equipment together and set up your development environment's hardware topology. </para> @@ -65,8 +64,8 @@ <listitem><para> <emphasis>Build Engineer:</emphasis> This type of developer manages Autobuilders and - releases. - Not all environments need a Build Engineer. + releases. Depending on the specifics of the environment, + not all situations might need a Build Engineer. </para></listitem> <listitem><para> <emphasis>Test Engineer:</emphasis> @@ -89,6 +88,11 @@ You can help ensure efficiency by having any machines used for testing or that run Autobuilders be as high performance as possible. + <note> + Given sufficient processing power, you might also consider + building Yocto Project development containers to be run + under Docker, which is described later. + </note> </para></listitem> <listitem><para> <emphasis>Understand the Hardware Topology of the Environment:</emphasis> @@ -115,10 +119,10 @@ and any software you are developing under the control of an SCM system that is compatible with the OpenEmbedded build system is advisable. - Of the SCMs BitBake supports, the Yocto Project team strongly + Of all of the SCMs supported by BitBake, the Yocto Project team strongly recommends using <ulink url='&YOCTO_DOCS_OM_URL;#git'>Git</ulink>. - Git is a distributed system that is easy to backup, + Git is a distributed system that is easy to back up, allows you to work remotely, and then connects back to the infrastructure. <note> @@ -176,14 +180,6 @@ isolated applications. </para></listitem> <listitem><para> - When possible, use the Yocto Project plug-in for the - <trademark class='trade'>Eclipse</trademark> IDE - and SDK development practices. - For more information, see the - <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink> - manual. - </para></listitem> - <listitem><para> Keep your cross-development toolchains updated. You can do this through provisioning either as new toolchain downloads or as updates through a package @@ -311,7 +307,7 @@ <para>As with any development environment, it is important to document the policy used as well as any main project guidelines so they are understood by everyone. - It is also a good idea to have well structured + It is also a good idea to have well-structured commit messages, which are usually a part of a project's guidelines. Good commit messages are essential when looking back in time and @@ -403,16 +399,18 @@ This section provides procedures to set up a system to be used as your <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink> for development using the Yocto Project. - Your build host can be a native Linux machine (recommended) or it can + Your build host can be a native Linux machine (recommended), it can be a machine (Linux, Mac, or Windows) that uses - <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/crops/about/'>CROPS</ulink>, + <ulink url='https://github.com/crops/poky-container'>CROPS</ulink>, which leverages - <ulink url='https://www.docker.com/'>Docker Containers</ulink>. + <ulink url='https://www.docker.com/'>Docker Containers</ulink> or it can + be a Windows machine capable of running Windows Subsystem For Linux v2 (WSL). <note> - You cannot use a build host that is using the - <ulink url='https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux'>Windows Subsystem for Linux</ulink> - (WSL). - The Yocto Project is not compatible with WSL. + The Yocto Project is not compatible with + <ulink url='https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux'>Windows Subsystem for Linux v1</ulink>. + It is compatible but not officially supported nor validated with WSLv2. + If you still decide to use WSL please upgrade to + <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-install'>WSLv2</ulink>. </note> </para> @@ -421,8 +419,7 @@ further steps are necessary depending on what you want to accomplish. See the following references for information on how to prepare for - Board Support Package (BSP) development, kernel development, and - development using the <trademark class='trade'>Eclipse</trademark> IDE: + Board Support Package (BSP) development and kernel development: <itemizedlist> <listitem><para> <emphasis>BSP Development:</emphasis> @@ -437,13 +434,6 @@ "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#preparing-the-build-host-to-work-on-the-kernel'>Preparing the Build Host to Work on the Kernel</ulink>" section in the Yocto Project Linux Kernel Development Manual. </para></listitem> - <listitem><para> - <emphasis>Eclipse Development:</emphasis> - See the - "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-eclipse-project'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></ulink>" - Chapter in the Yocto Project Application Development and the - Extensible Software Development Kit (eSDK) manual. - </para></listitem> </itemizedlist> </para> @@ -459,7 +449,7 @@ You should have a reasonably current Linux-based host system. You will have the best results with a recent release of - Fedora, openSUSE, Debian, Ubuntu, or CentOS as these + Fedora, openSUSE, Debian, Ubuntu, RHEL or CentOS as these releases are frequently tested against the Yocto Project and officially supported. For a list of the distributions under validation and their @@ -477,23 +467,26 @@ <emphasis>Meet Minimal Version Requirements:</emphasis> The OpenEmbedded build system should be able to run on any modern distribution that has the following versions for - Git, tar, and Python. + Git, tar, Python and gcc. <itemizedlist> <listitem><para> Git 1.8.3.1 or greater </para></listitem> <listitem><para> - tar 1.27 or greater + tar 1.28 or greater </para></listitem> <listitem><para> - Python 3.4.0 or greater. - </para></listitem> + Python 3.5.0 or greater. + </para></listitem> + <listitem><para> + gcc 5.0 or greater. + </para></listitem> </itemizedlist> If your build host does not meet any of these three listed version requirements, you can take steps to prepare the system so that you can still use the Yocto Project. See the - "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</ulink>" + "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</ulink>" section in the Yocto Project Reference Manual for information. </para></listitem> @@ -534,7 +527,7 @@ <para> With - <ulink url='https://github.com/crops/crops/blob/master/README.md'>CROPS</ulink>, + <ulink url='https://github.com/crops/poky-container'>CROPS</ulink>, which leverages <ulink url='https://www.docker.com/'>Docker Containers</ulink>, you can create a Yocto Project development environment that @@ -671,15 +664,147 @@ section in the Toaster User Manual. </para> </section> + + <section id='setting-up-to-use-wsl'> + <title>Setting Up to Use Windows Subsystem For Linux (WSLv2)</title> + + <para> + With <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-about'> + Windows Subsystem for Linux (WSLv2)</ulink>, you can create a + Yocto Project development environment that allows you to build + on Windows. You can set up a Linux distribution inside Windows + in which you can develop using the Yocto Project. + </para> + + <para> + Follow these general steps to prepare a Windows machine using WSLv2 + as your Yocto Project build host: + <orderedlist> + <listitem><para> + <emphasis>Make sure your Windows 10 machine is capable of running WSLv2:</emphasis> + + WSLv2 is only available for Windows 10 builds > 18917. To + check which build version you are running, you may open a + command prompt on Windows and execute the command "ver". + <literallayout class='monospaced'> + C:\Users\myuser> ver + + Microsoft Windows [Version 10.0.19041.153] + </literallayout> + If your build is capable of running WSLv2 you may continue, + for more information on this subject or instructions on how + to upgrade to WSLv2 visit <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-install'>Windows 10 WSLv2</ulink> + </para></listitem> + <listitem><para> + <emphasis>Install the Linux distribution of your choice inside Windows 10:</emphasis> + Once you know your version of Windows 10 supports WSLv2, + you can install the distribution of your choice from the + Microsoft Store. + Open the Microsoft Store and search for Linux. While there + are several Linux distributions available, the assumption + is that your pick will be one of the distributions supported + by the Yocto Project as stated on the instructions for + using a native Linux host. + After making your selection, simply click "Get" to download + and install the distribution. + </para></listitem> + <listitem><para> + <emphasis>Check your Linux distribution is using WSLv2:</emphasis> + Open a Windows PowerShell and run: + <literallayout class='monospaced'> + C:\WINDOWS\system32> wsl -l -v + NAME STATE VERSION + *Ubuntu Running 2 + </literallayout> + Note the version column which says the WSL version being used by + your distribution, on compatible systems, this can be changed back + at any point in time. + </para></listitem> + <listitem><para> + <emphasis>Optionally Orient Yourself on WSL:</emphasis> + If you are unfamiliar with WSL, you can learn more here - + <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-about'></ulink>. + </para></listitem> + <listitem><para> + <emphasis>Launch your WSL Distibution:</emphasis> + From the Windows start menu simply launch your WSL distribution + just like any other application. + </para></listitem> + <listitem><para> + <emphasis>Optimize your WSLv2 storage often:</emphasis> + Due to the way storage is handled on WSLv2, the storage + space used by the undelying Linux distribution is not + reflected immedately, and since bitbake heavily uses + storage, after several builds, you may be unaware you + are running out of space. WSLv2 uses a VHDX file for + storage, this issue can be easily avoided by manually + optimizing this file often, this can be done in the + following way: + <orderedlist> + <listitem><para> + <emphasis>Find the location of your VHDX file:</emphasis> + First you need to find the distro app package directory, + to achieve this open a Windows Powershell as Administrator + and run: + <literallayout class='monospaced'> + C:\WINDOWS\system32> Get-AppxPackage -Name "*Ubuntu*" | Select PackageFamilyName + PackageFamilyName + ----------------- + CanonicalGroupLimited.UbuntuonWindows_79abcdefgh + </literallayout> + You should now replace the <replaceable>PackageFamilyName</replaceable> + and your <replaceable>user</replaceable> on the following + path to find your VHDX file: <filename>C:\Users\user\AppData\Local\Packages\PackageFamilyName\LocalState\</filename> + For example: + <literallayout class='monospaced'> + ls C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ + Mode LastWriteTime Length Name + -a---- 3/14/2020 9:52 PM 57418973184 ext4.vhdx + </literallayout> + Your VHDX file path is: <filename>C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx</filename> + </para></listitem> + <listitem><para><emphasis>Optimize your VHDX file:</emphasis> + Open a Windows Powershell as Administrator to optimize + your VHDX file, shutting down WSL first: + <literallayout class='monospaced'> + C:\WINDOWS\system32> wsl --shutdown + C:\WINDOWS\system32> optimize-vhd -Path C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx -Mode full + </literallayout> + A progress bar should be shown while optimizing the VHDX file, + and storage should now be reflected correctly on the Windows + Explorer. + </para></listitem> + </orderedlist> + </para></listitem> + </orderedlist> + <note> + The current implementation of WSLv2 does not have out-of-the-box + access to external devices such as those connected through a + USB port, but it automatically mounts your <filename>C:</filename> + drive on <filename>/mnt/c/</filename> (and others), which + you can use to share deploy artifacts to be later flashed on + hardware through Windows, but your build directory should not + reside inside this mountpoint. + </note> + Once you have WSLv2 set up, everything is in place to + develop just as if you were running on a native Linux machine. + If you are going to use the Extensible SDK container, see the + "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extensible'>Using the Extensible SDK</ulink>" + Chapter in the Yocto Project Application Development and the + Extensible Software Development Kit (eSDK) manual. + If you are going to use the Toaster container, see the + "<ulink url='&YOCTO_DOCS_TOAST_URL;#toaster-manual-setup-and-use'>Setting Up and Using Toaster</ulink>" + section in the Toaster User Manual. + </para> + </section> </section> <section id='locating-yocto-project-source-files'> <title>Locating Yocto Project Source Files</title> <para> - This section shows you how to locate and access the - source files that ship with the Yocto Project. - You establish and use these local files to work on projects. + This section shows you how to locate, fetch and configure the source + files you'll need to work with the Yocto Project. <note><title>Notes</title> <itemizedlist> <listitem><para> @@ -767,7 +892,7 @@ <ulink url='&YOCTO_DL_URL;/releases'></ulink> to access the Index of Releases. The list represents released components (e.g. - <filename>eclipse-plugin</filename>, + <filename>bitbake</filename>, <filename>sato</filename>, and so on). <note> The <filename>yocto</filename> directory contains the @@ -864,8 +989,7 @@ Yocto Project maintains an area for nightly builds that contains tarball releases at <ulink url='&YOCTO_AB_NIGHTLY_URL;'/>. These builds include Yocto Project releases ("poky"), - toolchains, Yocto Project plugins for Eclipse, and builds for - supported machines. + toolchains, and builds for supported machines. </para> <para> @@ -951,11 +1075,11 @@ <literallayout class='monospaced'> $ git clone git://git.yoctoproject.org/poky Cloning into 'poky'... - remote: Counting objects: 416542, done. - remote: Compressing objects: 100% (98611/98611), done. - remote: Total 416542 (delta 311104), reused 416377 (delta 310939) - Receiving objects: 100% (416542/416542), 150.39 MiB | 15.77 MiB/s, done. - Resolving deltas: 100% (311104/311104), done. + remote: Counting objects: 432160, done. + remote: Compressing objects: 100% (102056/102056), done. + remote: Total 432160 (delta 323116), reused 432037 (delta 323000) + Receiving objects: 100% (432160/432160), 153.81 MiB | 8.54 MiB/s, done. + Resolving deltas: 100% (323116/323116), done. Checking connectivity... done. </literallayout> Unless you specify a specific development branch or @@ -1037,18 +1161,18 @@ . . . - remotes/origin/master-next - remotes/origin/master-next2 - remotes/origin/morty - remotes/origin/pinky - remotes/origin/purple - remotes/origin/pyro - remotes/origin/rocko + remotes/origin/thud + remotes/origin/thud-next + remotes/origin/warrior + remotes/origin/warrior-next + remotes/origin/zeus + remotes/origin/zeus-next + ... and so on ... </literallayout> </para></listitem> <listitem><para> - <emphasis>Checkout the Branch:</emphasis> - Checkout the development branch in which you want to work. + <emphasis>Check out the Branch:</emphasis> + Check out the development branch in which you want to work. For example, to access the files for the Yocto Project &DISTRO; Release (&DISTRO_NAME;), use the following command: <literallayout class='monospaced'> @@ -1125,13 +1249,16 @@ yocto-2.5 yocto-2.5.1 yocto-2.5.2 + yocto-2.5.3 yocto-2.6 yocto-2.6.1 + yocto-2.6.2 + yocto-2.7 yocto_1.5_M5.rc8 </literallayout> </para></listitem> <listitem><para> - <emphasis>Checkout the Branch:</emphasis> + <emphasis>Check out the Branch:</emphasis> <literallayout class='monospaced'> $ git checkout tags/&DISTRO_REL_TAG; -b my_yocto_&DISTRO; Switched to a new branch 'my_yocto_&DISTRO;' diff --git a/external/poky/documentation/dev-manual/dev-manual.xml b/external/poky/documentation/dev-manual/dev-manual.xml index 3ec921f6..381c7e3c 100644..100755 --- a/external/poky/documentation/dev-manual/dev-manual.xml +++ b/external/poky/documentation/dev-manual/dev-manual.xml @@ -22,18 +22,17 @@ <authorgroup> <author> - <firstname>Scott</firstname> <surname>Rifenbark</surname> <affiliation> - <orgname>Scotty's Documentation Services, INC</orgname> + <orgname>&ORGNAME;</orgname> </affiliation> - <email>srifenbark@gmail.com</email> + <email>&ORGEMAIL;</email> </author> </authorgroup> <revhistory> <revision> <revnumber>1.1</revnumber> - <date>6 October 2011</date> + <date>October 2011</date> <revremark>The initial document released with the Yocto Project 1.1 Release.</revremark> </revision> <revision> @@ -57,11 +56,6 @@ <revremark>Released with the Yocto Project 1.5 Release.</revremark> </revision> <revision> - <revnumber>1.5.1</revnumber> - <date>January 2014</date> - <revremark>Released with the Yocto Project 1.5.1 Release.</revremark> - </revision> - <revision> <revnumber>1.6</revnumber> <date>April 2014</date> <revremark>Released with the Yocto Project 1.6 Release.</revremark> @@ -112,24 +106,29 @@ <revremark>Released with the Yocto Project 2.6 Release.</revremark> </revision> <revision> - <revnumber>2.6.1</revnumber> - <date>February 2019</date> - <revremark>Released with the Yocto Project 2.6.1 Release.</revremark> + <revnumber>2.7</revnumber> + <date>May 2019</date> + <revremark>Released with the Yocto Project 2.7 Release.</revremark> + </revision> + <revision> + <revnumber>3.0</revnumber> + <date>October 2019</date> + <revremark>Released with the Yocto Project 3.0 Release.</revremark> </revision> <revision> - <revnumber>2.6.2</revnumber> - <date>April 2019</date> - <revremark>Released with the Yocto Project 2.6.2 Release.</revremark> + <revnumber>3.1</revnumber> + <date>April 2020</date> + <revremark>Released with the Yocto Project 3.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.3</revnumber> - <date>August 2019</date> - <revremark>Released with the Yocto Project 2.6.3 Release.</revremark> + <revnumber>3.1.1</revnumber> + <date>June 2020</date> + <revremark>Released with the Yocto Project 3.1.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.4</revnumber> - <date>November 2019</date> - <revremark>Released with the Yocto Project 2.6.4 Release.</revremark> + <revnumber>3.1.2</revnumber> + <date>&REL_MONTH_YEAR;</date> + <revremark>Released with the Yocto Project 3.1.2 Release.</revremark> </revision> </revhistory> @@ -154,7 +153,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -171,18 +170,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. </para></listitem> - <listitem><para> + <listitem> + <para> To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - <filename>yocto@yoctoproject.com</filename> or log into - the freenode <filename>#yocto</filename> channel. - </para></listitem> + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + <filename>docs@lists.yoctoproject.org</filename> or + log into the freenode <filename>#yocto</filename> channel. + </para> + </listitem> </itemizedlist> </note> </legalnotice> diff --git a/external/poky/documentation/dev-manual/figures/cute-files-npm-example.png b/external/poky/documentation/dev-manual/figures/cute-files-npm-example.png Binary files differnew file mode 100644 index 00000000..1ebe74f5 --- /dev/null +++ b/external/poky/documentation/dev-manual/figures/cute-files-npm-example.png diff --git a/external/poky/documentation/kernel-dev/kernel-dev-common.xml b/external/poky/documentation/kernel-dev/kernel-dev-common.xml index 90528761..c1c2d6d7 100644 --- a/external/poky/documentation/kernel-dev/kernel-dev-common.xml +++ b/external/poky/documentation/kernel-dev/kernel-dev-common.xml @@ -89,8 +89,8 @@ <emphasis>Prepare Your <filename>local.conf</filename> File:</emphasis> By default, the <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> - variable is set to "qemux86", which is fine if you are - building for the QEMU emulator in 32-bit mode. + variable is set to "qemux86-64", which is fine if you are + building for the QEMU emulator in 64-bit mode. However, if you are not, you need to set the <filename>MACHINE</filename> variable appropriately in your <filename>conf/local.conf</filename> file found in @@ -104,10 +104,12 @@ <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</filename></ulink> variable to include kernel modules.</para> - <para>This example uses the default "qemux86" for the - <filename>MACHINE</filename> variable but needs to - add the "kernel-modules": + <para>In this example we wish to build for qemux86 so + we must set the <filename>MACHINE</filename> variable + to "qemux86" and also add the "kernel-modules". As described + we do this by appending to <filename>conf/local.conf</filename>: <literallayout class='monospaced'> + MACHINE = "qemux86" MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules" </literallayout> </para></listitem> @@ -185,7 +187,7 @@ Poky (Yocto Project Reference Distro) Extensible SDK installer version &DISTRO; ============================================================================ Enter target directory for SDK (default: ~/poky_sdk): - You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y + You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed [Y/n]? Y Extracting SDK......................................done Setting it up... Extracting buildtools... @@ -314,8 +316,8 @@ File:</emphasis> By default, the <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> - variable is set to "qemux86", which is fine if you are - building for the QEMU emulator in 32-bit mode. + variable is set to "qemux86-64", which is fine if you are + building for the QEMU emulator in 64-bit mode. However, if you are not, you need to set the <filename>MACHINE</filename> variable appropriately in your <filename>conf/local.conf</filename> file found @@ -329,10 +331,12 @@ <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</filename></ulink> variable to include kernel modules.</para> - <para>This example uses the default "qemux86" for the - <filename>MACHINE</filename> variable but needs to - add the "kernel-modules": + <para>In this example we wish to build for qemux86 so + we must set the <filename>MACHINE</filename> variable + to "qemux86" and also add the "kernel-modules". As described + we do this by appending to <filename>conf/local.conf</filename>: <literallayout class='monospaced'> + MACHINE = "qemux86" MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules" </literallayout> </para></listitem> @@ -549,9 +553,9 @@ <literallayout class='monospaced'> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" - SRC_URI_append += "file://<replaceable>patch-file-one</replaceable>" - SRC_URI_append += "file://<replaceable>patch-file-two</replaceable>" - SRC_URI_append += "file://<replaceable>patch-file-three</replaceable>" + SRC_URI_append = " file://<replaceable>patch-file-one</replaceable>" + SRC_URI_append = " file://<replaceable>patch-file-two</replaceable>" + SRC_URI_append = " file://<replaceable>patch-file-three</replaceable>" </literallayout> The <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink> @@ -655,26 +659,22 @@ KMACHINE_genericx86-64 ?= "common-pc-64" KBRANCH_edgerouter = "standard/edgerouter" KBRANCH_beaglebone = "standard/beaglebone" - KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb" SRCREV_machine_genericx86 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19" SRCREV_machine_genericx86-64 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19" SRCREV_machine_edgerouter ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d" SRCREV_machine_beaglebone ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d" - SRCREV_machine_mpc8315e-rdb ?= "2d1d010240846d7bff15d1fcc0cb6eb8a22fc78a" COMPATIBLE_MACHINE_genericx86 = "genericx86" COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64" COMPATIBLE_MACHINE_edgerouter = "edgerouter" COMPATIBLE_MACHINE_beaglebone = "beaglebone" - COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb" LINUX_VERSION_genericx86 = "4.12.7" LINUX_VERSION_genericx86-64 = "4.12.7" LINUX_VERSION_edgerouter = "4.12.10" LINUX_VERSION_beaglebone = "4.12.10" - LINUX_VERSION_mpc8315e-rdb = "4.12.10" </literallayout> This append file contains statements used to support several BSPs that ship with the Yocto Project. @@ -948,12 +948,14 @@ <literallayout class='monospaced'> KBUILD_DEFCONFIG_<replaceable>KMACHINE</replaceable> ?= <replaceable>defconfig_file</replaceable> </literallayout> - Here is an example that appends the - <filename>KBUILD_DEFCONFIG</filename> variable with - "common-pc" and provides the path to the "in-tree" - <filename>defconfig</filename> file: + Here is an example that assigns the + <filename>KBUILD_DEFCONFIG</filename> variable based on + "raspberrypi2" and provides the path to the "in-tree" + <filename>defconfig</filename> file + to be used for a Raspberry Pi 2, + which is based on the Broadcom 2708/2709 chipset: <literallayout class='monospaced'> - KBUILD_DEFCONFIG_common-pc ?= "/home/scottrif/configfiles/my_defconfig_file" + KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig" </literallayout> </para> @@ -1479,15 +1481,33 @@ <para> To use the <filename>menuconfig</filename> tool in the Yocto - Project development environment, you must launch it using - BitBake. - Thus, the environment must be set up using the - <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink> - script found in the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>. - You must also be sure of the state of your build's - configuration in the - <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>. + Project development environment, you must do the following: + <itemizedlist> + <listitem><para> + Because you launch <filename>menuconfig</filename> + using BitBake, you must be sure to set up your + environment by running the + <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink> + script found in the + <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>. + </para></listitem> + <listitem><para> + You must be sure of the state of your build's + configuration in the + <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>. + </para></listitem> + <listitem><para> + Your build host must have the following two packages + installed: + <literallayout class='monospaced'> + libncurses5-dev + libtinfo-dev + </literallayout> + </para></listitem> + </itemizedlist> + </para> + + <para> The following commands initialize the BitBake environment, run the <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-kernel_configme'><filename>do_kernel_configme</filename></ulink> diff --git a/external/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml b/external/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml index 6d675a6d..62c68527 100644 --- a/external/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml +++ b/external/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml @@ -543,7 +543,6 @@ yocto-kernel-cache/features/kgdb/hardware.cfg yocto-kernel-cache/ktypes/base/hardware.cfg yocto-kernel-cache/bsp/mti-malta32/hardware.cfg - yocto-kernel-cache/bsp/fsl-mpc8315e-rdb/hardware.cfg yocto-kernel-cache/bsp/qemu-ppc32/hardware.cfg yocto-kernel-cache/bsp/qemuarma9/hardware.cfg yocto-kernel-cache/bsp/mti-malta64/hardware.cfg diff --git a/external/poky/documentation/kernel-dev/kernel-dev-eclipse-customization.xsl b/external/poky/documentation/kernel-dev/kernel-dev-eclipse-customization.xsl deleted file mode 100644 index 3c56a5a9..00000000 --- a/external/poky/documentation/kernel-dev/kernel-dev-eclipse-customization.xsl +++ /dev/null @@ -1,35 +0,0 @@ -<?xml version='1.0'?> -<xsl:stylesheet - xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - xmlns="http://www.w3.org/1999/xhtml" - xmlns:fo="http://www.w3.org/1999/XSL/Format" - version="1.0"> - - <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - -<!-- - - <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - - <xsl:import - href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" /> - ---> - - <xsl:param name="chunker.output.indent" select="'yes'"/> - <xsl:param name="chunk.quietly" select="1"/> - <xsl:param name="chunk.first.sections" select="1"/> - <xsl:param name="chunk.section.depth" select="10"/> - <xsl:param name="use.id.as.filename" select="1"/> - <xsl:param name="ulink.target" select="'_self'" /> - <xsl:param name="base.dir" select="'html/kernel-dev/'"/> - <xsl:param name="html.stylesheet" select="'../book.css'"/> - <xsl:param name="eclipse.manifest" select="0"/> - <xsl:param name="create.plugin.xml" select="0"/> - <xsl:param name="suppress.navigation" select="1"/> - <xsl:param name="generate.index" select="0"/> - <xsl:param name="chapter.autolabel" select="1" /> - <xsl:param name="appendix.autolabel">A</xsl:param> - <xsl:param name="section.autolabel" select="1" /> - <xsl:param name="section.label.includes.component.label" select="1" /> -</xsl:stylesheet> diff --git a/external/poky/documentation/kernel-dev/kernel-dev.xml b/external/poky/documentation/kernel-dev/kernel-dev.xml index 6f3e5895..be613fe4 100644..100755 --- a/external/poky/documentation/kernel-dev/kernel-dev.xml +++ b/external/poky/documentation/kernel-dev/kernel-dev.xml @@ -22,11 +22,10 @@ <authorgroup> <author> - <firstname>Scott</firstname> <surname>Rifenbark</surname> <affiliation> - <orgname>Scotty's Documentation Services, INC</orgname> + <orgname>&ORGNAME;</orgname> </affiliation> - <email>srifenbark@gmail.com</email> + <email>&ORGEMAIL;</email> </author> </authorgroup> @@ -34,7 +33,7 @@ <revision> <revnumber>1.4</revnumber> <date>April 2013</date> - <revremark>Released with the Yocto Project 1.4 Release.</revremark> + <revremark>The initial document released with the Yocto Project 1.4 Release.</revremark> </revision> <revision> <revnumber>1.5</revnumber> @@ -42,11 +41,6 @@ <revremark>Released with the Yocto Project 1.5 Release.</revremark> </revision> <revision> - <revnumber>1.5.1</revnumber> - <date>January 2014</date> - <revremark>Released with the Yocto Project 1.5.1 Release.</revremark> - </revision> - <revision> <revnumber>1.6</revnumber> <date>April 2014</date> <revremark>Released with the Yocto Project 1.6 Release.</revremark> @@ -97,24 +91,29 @@ <revremark>Released with the Yocto Project 2.6 Release.</revremark> </revision> <revision> - <revnumber>2.6.1</revnumber> - <date>February 2019</date> - <revremark>Released with the Yocto Project 2.6.1 Release.</revremark> + <revnumber>2.7</revnumber> + <date>May 2019</date> + <revremark>Released with the Yocto Project 2.7 Release.</revremark> + </revision> + <revision> + <revnumber>3.0</revnumber> + <date>October 2019</date> + <revremark>Released with the Yocto Project 3.0 Release.</revremark> </revision> <revision> - <revnumber>2.6.2</revnumber> - <date>April 2019</date> - <revremark>Released with the Yocto Project 2.6.2 Release.</revremark> + <revnumber>3.1</revnumber> + <date>April 2020</date> + <revremark>Released with the Yocto Project 3.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.3</revnumber> - <date>August 2019</date> - <revremark>Released with the Yocto Project 2.6.3 Release.</revremark> + <revnumber>3.1.1</revnumber> + <date>June 2020</date> + <revremark>Released with the Yocto Project 3.1.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.4</revnumber> - <date>November 2019</date> - <revremark>Released with the Yocto Project 2.6.4 Release.</revremark> + <revnumber>3.1.2</revnumber> + <date>&REL_MONTH_YEAR;</date> + <revremark>Released with the Yocto Project 3.1.2 Release.</revremark> </revision> </revhistory> @@ -137,7 +136,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -154,18 +153,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. </para></listitem> - <listitem><para> + <listitem> + <para> To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - <filename>yocto@yoctoproject.com</filename> or log into - the freenode <filename>#yocto</filename> channel. - </para></listitem> + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + <filename>docs@lists.yoctoproject.org</filename> or + log into the freenode <filename>#yocto</filename> channel. + </para> + </listitem> </itemizedlist> </note> </legalnotice> diff --git a/external/poky/documentation/mega-manual/figures/bb_multiconfig_files.png b/external/poky/documentation/mega-manual/figures/bb_multiconfig_files.png Binary files differnew file mode 100644 index 00000000..041f0640 --- /dev/null +++ b/external/poky/documentation/mega-manual/figures/bb_multiconfig_files.png diff --git a/external/poky/documentation/mega-manual/figures/bitbake-title.png b/external/poky/documentation/mega-manual/figures/bitbake-title.png Binary files differnew file mode 100644 index 00000000..cb290154 --- /dev/null +++ b/external/poky/documentation/mega-manual/figures/bitbake-title.png diff --git a/external/poky/documentation/mega-manual/figures/cute-files-npm-example.png b/external/poky/documentation/mega-manual/figures/cute-files-npm-example.png Binary files differnew file mode 100644 index 00000000..1ebe74f5 --- /dev/null +++ b/external/poky/documentation/mega-manual/figures/cute-files-npm-example.png diff --git a/external/poky/documentation/mega-manual/figures/index-downloads.png b/external/poky/documentation/mega-manual/figures/index-downloads.png Binary files differindex 96303b87..d8d4475c 100644..100755 --- a/external/poky/documentation/mega-manual/figures/index-downloads.png +++ b/external/poky/documentation/mega-manual/figures/index-downloads.png diff --git a/external/poky/documentation/mega-manual/figures/lttngmain0.png b/external/poky/documentation/mega-manual/figures/lttngmain0.png Binary files differdeleted file mode 100644 index 5f60113c..00000000 --- a/external/poky/documentation/mega-manual/figures/lttngmain0.png +++ /dev/null diff --git a/external/poky/documentation/mega-manual/figures/sdk-eclipse-dev-flow.png b/external/poky/documentation/mega-manual/figures/sdk-eclipse-dev-flow.png Binary files differdeleted file mode 100644 index 9f986e0d..00000000 --- a/external/poky/documentation/mega-manual/figures/sdk-eclipse-dev-flow.png +++ /dev/null diff --git a/external/poky/documentation/mega-manual/mega-manual.xml b/external/poky/documentation/mega-manual/mega-manual.xml index 300246c9..69111a9c 100644..100755 --- a/external/poky/documentation/mega-manual/mega-manual.xml +++ b/external/poky/documentation/mega-manual/mega-manual.xml @@ -12,9 +12,11 @@ <abstract> The Yocto Project Mega-Manual is a concatenation of the published - Yocto Project HTML manuals for the given release. - The manual exists to help users efficiently search for strings - across the entire Yocto Project documentation set. + Yocto Project HTML manuals along with the corresponding BitBake + User Manual for the given release. + The Mega-Manual exists to help users efficiently search for strings + across the entire Yocto Project documentation set inclusive of + the BitBake User Manual. </abstract> <mediaobject> @@ -31,11 +33,10 @@ <authorgroup> <author> - <firstname>Scott</firstname> <surname>Rifenbark</surname> <affiliation> - <orgname>Scotty's Documentation Services, INC</orgname> + <orgname>&ORGNAME;</orgname> </affiliation> - <email>srifenbark@gmail.com</email> + <email>&ORGEMAIL;</email> </author> </authorgroup> @@ -43,7 +44,7 @@ <revision> <revnumber>1.8</revnumber> <date>April 2015</date> - <revremark>Released with the Yocto Project 1.8 Release.</revremark> + <revremark>The initial document released with the Yocto Project 1.8 Release.</revremark> </revision> <revision> <revnumber>2.0</revnumber> @@ -81,24 +82,29 @@ <revremark>Released with the Yocto Project 2.6 Release.</revremark> </revision> <revision> - <revnumber>2.6.1</revnumber> - <date>February 2019</date> - <revremark>Released with the Yocto Project 2.6.1 Release.</revremark> + <revnumber>2.7</revnumber> + <date>May 2019</date> + <revremark>Released with the Yocto Project 2.7 Release.</revremark> </revision> <revision> - <revnumber>2.6.2</revnumber> - <date>April 2019</date> - <revremark>Released with the Yocto Project 2.6.2 Release.</revremark> + <revnumber>3.0</revnumber> + <date>October 2019</date> + <revremark>Released with the Yocto Project 3.0 Release.</revremark> </revision> <revision> - <revnumber>2.6.3</revnumber> - <date>August 2019</date> - <revremark>Released with the Yocto Project 2.6.3 Release.</revremark> + <revnumber>3.1</revnumber> + <date>April 2020</date> + <revremark>Released with the Yocto Project 3.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.4</revnumber> - <date>November 2019</date> - <revremark>Released with the Yocto Project 2.6.4 Release.</revremark> + <revnumber>3.1.1</revnumber> + <date>June 2020</date> + <revremark>Released with the Yocto Project 3.1.1 Release.</revremark> + </revision> + <revision> + <revnumber>3.1.2</revnumber> + <date>&REL_MONTH_YEAR;</date> + <revremark>Released with the Yocto Project 3.1.2 Release.</revremark> </revision> </revhistory> @@ -121,7 +127,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -138,18 +144,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. </para></listitem> - <listitem><para> + <listitem> + <para> To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - <filename>yocto@yoctoproject.com</filename> or log into - the freenode <filename>#yocto</filename> channel. - </para></listitem> + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + <filename>docs@lists.yoctoproject.org</filename> or + log into the freenode <filename>#yocto</filename> channel. + </para> + </listitem> </itemizedlist> </note> @@ -214,15 +222,11 @@ <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-working-projects.xml"/> <xi:include - xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-eclipse-project.xml"/> - <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-appendix-obtain.xml"/> <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-appendix-customizing.xml"/> <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-appendix-customizing-standard.xml"/> - <xi:include - xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-appendix-neon.xml"/> <!-- Includes bsp-guide title image and then bsp-guide chapters --> @@ -337,6 +341,30 @@ <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../toaster-manual/toaster-manual-reference.xml"/> +<!-- Includes bitbake-user-manual title image and then bitbake-user-manual chapters --> + + <para> + <imagedata fileref="figures/bitbake-title.png" width="100%" align="left" scalefit="1" /> + </para> + + <xi:include + xmlns:xi="http://www.w3.org/2003/XInclude" href="../../bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml"/> + + <xi:include + xmlns:xi="http://www.w3.org/2003/XInclude" href="../../bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml"/> + + <xi:include + xmlns:xi="http://www.w3.org/2003/XInclude" href="../../bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml"/> + + <xi:include + xmlns:xi="http://www.w3.org/2003/XInclude" href="../../bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml"/> + + <xi:include + xmlns:xi="http://www.w3.org/2003/XInclude" href="../../bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml"/> + + <xi:include + xmlns:xi="http://www.w3.org/2003/XInclude" href="../../bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml"/> + </book> <!-- diff --git a/external/poky/documentation/overview-manual/figures/index-downloads.png b/external/poky/documentation/overview-manual/figures/index-downloads.png Binary files differindex 96303b87..d8d4475c 100644..100755 --- a/external/poky/documentation/overview-manual/figures/index-downloads.png +++ b/external/poky/documentation/overview-manual/figures/index-downloads.png diff --git a/external/poky/documentation/overview-manual/overview-manual-concepts.xml b/external/poky/documentation/overview-manual/overview-manual-concepts.xml index 064c235a..f085dd71 100644 --- a/external/poky/documentation/overview-manual/overview-manual-concepts.xml +++ b/external/poky/documentation/overview-manual/overview-manual-concepts.xml @@ -82,7 +82,7 @@ <para> This section briefly introduces BitBake. If you want more information on BitBake, see the - <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>. + <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>. </para> <para> @@ -924,9 +924,12 @@ <title>Source Control Managers (Optional)</title> <para> - Another place the build system can get source files from is - through an SCM such as Git or Subversion. - In this case, a repository is cloned or checked out. + Another place from which the build system can get source + files is with + <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetchers</ulink> + employing various Source Control Managers (SCMs) such as + Git or Subversion. + In such cases, a repository is cloned or checked out. The <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink> task inside BitBake uses @@ -940,7 +943,7 @@ <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink> directory, see the <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></ulink> - variable. + variable in the Yocto Project Reference Manual. </note> </para> @@ -1091,7 +1094,7 @@ <note> Separate documentation exists for the BitBake tool. See the - <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink> + <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink> for reference material on BitBake. </note> </para> diff --git a/external/poky/documentation/overview-manual/overview-manual-development-environment.xml b/external/poky/documentation/overview-manual/overview-manual-development-environment.xml index bba93cce..36ebf8a3 100644 --- a/external/poky/documentation/overview-manual/overview-manual-development-environment.xml +++ b/external/poky/documentation/overview-manual/overview-manual-development-environment.xml @@ -87,7 +87,7 @@ as its operating system as your development host. When you have a Mac or Windows-based system, you can set it up as the development host by using - <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/crops/about/'>CROPS</ulink>, + <ulink url='https://github.com/crops/poky-container'>CROPS</ulink>, which leverages <ulink url='https://www.docker.com/'>Docker Containers</ulink>. Once you take the steps to set up a CROPS machine, you effectively @@ -166,22 +166,6 @@ section in the Yocto Project Linux Kernel Development Manual. </para></listitem> <listitem><para> - <emphasis>Using the <trademark class='trade'>Eclipse</trademark> IDE:</emphasis> - One of two Yocto Project development methods that involves an - interface that effectively puts the Yocto Project into the - background is the popular Eclipse IDE. - This method of development is advantageous if you are already - familiar with working within Eclipse. - Development is supported through a plugin that you install - onto your development host.</para> - - <para>For steps that show you how to set up your development - host to use the Eclipse Yocto Project plugin, see the - "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-eclipse-project'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></ulink>" - Chapter in the Yocto Project Application Development and the - Extensible Software Development Kit (eSDK) manual. - </para></listitem> - <listitem><para> <emphasis>Using Toaster:</emphasis> The other Yocto Project development method that involves an interface that effectively puts the Yocto Project into the @@ -276,11 +260,10 @@ <emphasis> <ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink> </emphasis> - This is an index of releases such as - the <trademark class='trade'>Eclipse</trademark> - Yocto Plug-in, miscellaneous support, Poky, Pseudo, installers - for cross-development toolchains, and all released versions of - Yocto Project in the form of images or tarballs. + This is an index of releases such as Poky, Pseudo, installers + for cross-development toolchains, miscellaneous support + and all released versions of Yocto Project in the form of + images or tarballs. Downloading and extracting these files does not produce a local copy of the Git repository but rather a snapshot of a particular release or image.</para> diff --git a/external/poky/documentation/overview-manual/overview-manual-eclipse-customization.xsl b/external/poky/documentation/overview-manual/overview-manual-eclipse-customization.xsl deleted file mode 100644 index aaf99ea1..00000000 --- a/external/poky/documentation/overview-manual/overview-manual-eclipse-customization.xsl +++ /dev/null @@ -1,35 +0,0 @@ -<?xml version='1.0'?> -<xsl:stylesheet - xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - xmlns="http://www.w3.org/1999/xhtml" - xmlns:fo="http://www.w3.org/1999/XSL/Format" - version="1.0"> - - <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - -<!-- - - <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - - <xsl:import - href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" /> - ---> - - <xsl:param name="chunker.output.indent" select="'yes'"/> - <xsl:param name="chunk.quietly" select="1"/> - <xsl:param name="chunk.first.sections" select="1"/> - <xsl:param name="chunk.section.depth" select="10"/> - <xsl:param name="use.id.as.filename" select="1"/> - <xsl:param name="ulink.target" select="'_self'" /> - <xsl:param name="base.dir" select="'html/overview-manual/'"/> - <xsl:param name="html.stylesheet" select="'../book.css'"/> - <xsl:param name="eclipse.manifest" select="0"/> - <xsl:param name="create.plugin.xml" select="0"/> - <xsl:param name="suppress.navigation" select="1"/> - <xsl:param name="generate.index" select="0"/> - <xsl:param name="chapter.autolabel" select="1" /> - <xsl:param name="appendix.autolabel" select="1" /> - <xsl:param name="section.autolabel" select="1" /> - <xsl:param name="section.label.includes.component.label" select="1" /> -</xsl:stylesheet> diff --git a/external/poky/documentation/overview-manual/overview-manual-yp-intro.xml b/external/poky/documentation/overview-manual/overview-manual-yp-intro.xml index 254f191c..1b60a303 100644 --- a/external/poky/documentation/overview-manual/overview-manual-yp-intro.xml +++ b/external/poky/documentation/overview-manual/overview-manual-yp-intro.xml @@ -225,9 +225,9 @@ For information that helps you transition from trying out the Yocto Project to using it for your project, see the - "<ulink url='&YOCTO_HOME_URL;/docs/what-i-wish-id-known/'>What I wish I'd Known</ulink>" + "<ulink url='&YOCTO_DOCS_URL;/what-i-wish-id-known/'>What I wish I'd Known</ulink>" and - "<ulink url='&YOCTO_HOME_URL;/docs/transitioning-to-a-custom-environment/'>Transitioning to a Custom Environment for Systems Development</ulink>" + "<ulink url='&YOCTO_DOCS_URL;/transitioning-to-a-custom-environment/'>Transitioning to a Custom Environment for Systems Development</ulink>" documents on the Yocto Project website. </para></listitem> <listitem><para> @@ -437,7 +437,7 @@ <itemizedlist> <listitem><para id='gs-crops-overview'> <emphasis>CROPS:</emphasis> - <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/crops/about/'>CROPS</ulink> + <ulink url='https://github.com/crops/poky-container/'>CROPS</ulink> is an open source, cross-platform development framework that leverages <ulink url='https://www.docker.com/'>Docker Containers</ulink>. @@ -502,35 +502,6 @@ Manual. </para></listitem> <listitem><para> - <emphasis><trademark class='trade'>Eclipse</trademark> IDE Plug-in:</emphasis> - This plug-in enables you to use the popular Eclipse - Integrated Development Environment (IDE), which allows - for development using the Yocto Project all within the - Eclipse IDE. - You can work within Eclipse to cross-compile, deploy, - and execute your output into a QEMU emulation session - as well as onto actual target hardware.</para> - - <para>The environment also supports performance - enhancing tools that allow you to perform remote - profiling, tracing, collection of power data, - collection of latency data, and collection of - performance data.</para> - - <para>Once you enable the plug-in, standard Eclipse - functions automatically use the cross-toolchain - and target system libraries. - You can build applications using any of these - libraries.</para> - - <para>For more information on the Eclipse plug-in, - see the - "<ulink url='&YOCTO_DOCS_SDK_URL;#adt-eclipse'>Working Within Eclipse</ulink>" - section in the Yocto Project Application Development - and the Extensible Software Development Kit (eSDK) - manual. - </para></listitem> - <listitem><para> <emphasis>Toaster:</emphasis> Toaster is a web interface to the Yocto Project OpenEmbedded build system. @@ -912,7 +883,7 @@ <listitem><para> <emphasis>CROss PlatformS (CROPS):</emphasis> Typically, you use - <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/crops/about/'>CROPS</ulink>, + <ulink url='https://github.com/crops/poky-container/'>CROPS</ulink>, which leverages <ulink url='https://www.docker.com/'>Docker Containers</ulink>, to set up a Build Host that is not running Linux (e.g. @@ -937,6 +908,24 @@ section in the Yocto Project Development Tasks Manual. </para></listitem> <listitem><para> + <emphasis>Windows Subsystem For Linux (WSLv2):</emphasis> + You may use Windows Subsystem For Linux v2 to set up a build + host using Windows 10. + <note> + The Yocto Project is not compatible with WSLv1, it is + compatible but not officially supported nor validated + with WSLv2, if you still decide to use WSL please upgrade + to WSLv2. + </note> + The Windows Subsystem For Linux allows Windows 10 to run a real + Linux kernel inside of a lightweight utility virtual + machine (VM) using virtualization technology.</para> + <para>For information on how to set up a Build Host with + WSLv2, see the + "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-wsl'>Setting Up to Use Windows Subsystem For Linux</ulink>" + section in the Yocto Project Development Tasks Manual. + </para></listitem> + <listitem><para> <emphasis>Toaster:</emphasis> Regardless of what your Build Host is running, you can use Toaster to develop software using the Yocto Project. @@ -953,20 +942,6 @@ see the <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>. </para></listitem> - <listitem><para> - <emphasis><trademark class='trade'>Eclipse</trademark> IDE:</emphasis> - If your Build Host supports and runs the popular - Eclipse IDE, you can install the Yocto Project Eclipse - plug-in and use the Yocto Project to develop software. - The plug-in integrates the Yocto Project functionality - into Eclipse development practices.</para> - - <para>For information about how to install and use the - Yocto Project Eclipse plug-in, see the - "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-eclipse-project'>Developing Applications Using Eclipse</ulink>" - chapter in the Yocto Project Application Development and - the Extensible Software Development Kit (eSDK) Manual. - </para></listitem> </itemizedlist> </para> </section> diff --git a/external/poky/documentation/overview-manual/overview-manual.xml b/external/poky/documentation/overview-manual/overview-manual.xml index e79867ec..771eca07 100644..100755 --- a/external/poky/documentation/overview-manual/overview-manual.xml +++ b/external/poky/documentation/overview-manual/overview-manual.xml @@ -22,11 +22,10 @@ <authorgroup> <author> - <firstname>Scott</firstname> <surname>Rifenbark</surname> <affiliation> - <orgname>Scotty's Documentation Services, INC</orgname> + <orgname>&ORGNAME;</orgname> </affiliation> - <email>srifenbark@gmail.com</email> + <email>&ORGEMAIL;</email> </author> </authorgroup> @@ -42,24 +41,29 @@ <revremark>Released with the Yocto Project 2.6 Release.</revremark> </revision> <revision> - <revnumber>2.6.1</revnumber> - <date>February 2019</date> - <revremark>Released with the Yocto Project 2.6.1 Release.</revremark> + <revnumber>2.7</revnumber> + <date>May 2019</date> + <revremark>Released with the Yocto Project 2.7 Release.</revremark> </revision> <revision> - <revnumber>2.6.2</revnumber> - <date>April 2019</date> - <revremark>Released with the Yocto Project 2.6.2 Release.</revremark> + <revnumber>3.0</revnumber> + <date>October 2019</date> + <revremark>Released with the Yocto Project 3.0 Release.</revremark> </revision> <revision> - <revnumber>2.6.3</revnumber> - <date>August 2019</date> - <revremark>Released with the Yocto Project 2.6.3 Release.</revremark> + <revnumber>3.1</revnumber> + <date>April 2020</date> + <revremark>Released with the Yocto Project 3.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.4</revnumber> - <date>November 2019</date> - <revremark>Released with the Yocto Project 2.6.4 Release.</revremark> + <revnumber>3.1.1</revnumber> + <date>June 2020</date> + <revremark>Released with the Yocto Project 3.1.1 Release.</revremark> + </revision> + <revision> + <revnumber>3.1.2</revnumber> + <date>&REL_MONTH_YEAR;</date> + <revremark>Released with the Yocto Project 3.1.2 Release.</revremark> </revision> </revhistory> @@ -84,7 +88,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -101,18 +105,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. </para></listitem> - <listitem><para> + <listitem> + <para> To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - <filename>yocto@yoctoproject.com</filename> or log into - the freenode <filename>#yocto</filename> channel. - </para></listitem> + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + <filename>docs@lists.yoctoproject.org</filename> or + log into the freenode <filename>#yocto</filename> channel. + </para> + </listitem> </itemizedlist> </note> </legalnotice> diff --git a/external/poky/documentation/poky.ent b/external/poky/documentation/poky.ent index 34f8c114..1d0aef5f 100644..100755 --- a/external/poky/documentation/poky.ent +++ b/external/poky/documentation/poky.ent @@ -1,19 +1,21 @@ -<!ENTITY DISTRO "2.6.4"> -<!ENTITY DISTRO_COMPRESSED "264"> -<!ENTITY DISTRO_NAME_NO_CAP "thud"> -<!ENTITY DISTRO_NAME "Thud"> -<!ENTITY DISTRO_NAME_NO_CAP_MINUS_ONE "sumo"> -<!ENTITY DISTRO_NAME_MINUS_ONE "Sumo"> -<!ENTITY YOCTO_DOC_VERSION "2.6.4"> -<!ENTITY YOCTO_DOC_VERSION_MINUS_ONE "2.5.4"> -<!ENTITY DISTRO_REL_TAG "yocto-2.6.4"> -<!ENTITY METAINTELVERSION "10.1"> -<!ENTITY REL_MONTH_YEAR "November 2019"> +<!ENTITY DISTRO "3.1.2"> +<!ENTITY DISTRO_COMPRESSED "312"> +<!ENTITY DISTRO_NAME_NO_CAP "dunfell"> +<!ENTITY DISTRO_NAME "Dunfell"> +<!ENTITY DISTRO_NAME_NO_CAP_MINUS_ONE "zeus"> +<!ENTITY DISTRO_NAME_MINUS_ONE "Zeus"> +<!ENTITY YOCTO_DOC_VERSION "3.1.2"> +<!ENTITY YOCTO_DOC_VERSION_MINUS_ONE "3.0.2"> +<!ENTITY DISTRO_REL_TAG "yocto-3.1.2"> +<!ENTITY METAINTELVERSION "12.0"> +<!ENTITY REL_MONTH_YEAR "July 2020"> <!ENTITY META_INTEL_REL_TAG "&METAINTELVERSION;-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;"> -<!ENTITY POKYVERSION "20.0.4"> -<!ENTITY POKYVERSION_COMPRESSED "2004"> +<!ENTITY POKYVERSION "23.0.2"> +<!ENTITY POKYVERSION_COMPRESSED "2302"> <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;"> -<!ENTITY COPYRIGHT_YEAR "2010-2019"> +<!ENTITY COPYRIGHT_YEAR "2010-2020"> +<!ENTITY ORGNAME "The Yocto Project"> +<!ENTITY ORGEMAIL "docs@lists.yoctoproject.org"> <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org"> <!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org"> <!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org"> @@ -27,15 +29,6 @@ <!ENTITY OE_DOCS_URL "http://docs.openembedded.org"> <!ENTITY OH_HOME_URL "http://o-hand.com"> <!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/"> -<!ENTITY ECLIPSE_MAIN_URL "http://www.eclipse.org/downloads"> -<!ENTITY ECLIPSE_DL_URL "http://download.eclipse.org"> -<!ENTITY ECLIPSE_DL_PLUGIN_URL "&YOCTO_DL_URL;/releases/eclipse-plugin/&DISTRO;"> -<!ENTITY ECLIPSE_UPDATES_URL "&ECLIPSE_DL_URL;/tm/updates/3.3"> -<!ENTITY ECLIPSE_INDIGO_URL "&ECLIPSE_DL_URL;/releases/indigo"> -<!ENTITY ECLIPSE_JUNO_URL "&ECLIPSE_DL_URL;/releases/juno"> -<!ENTITY ECLIPSE_LUNA_URL "&ECLIPSE_DL_URL;/releases/luna"> -<!ENTITY ECLIPSE_KEPLER_URL "&ECLIPSE_DL_URL;/releases/kepler"> -<!ENTITY ECLIPSE_INDIGO_CDT_URL "&ECLIPSE_DL_URL;/tools/cdt/releases/indigo"> <!ENTITY YOCTO_DOCS_URL "&YOCTO_HOME_URL;/docs"> <!ENTITY YOCTO_SOURCES_URL "&YOCTO_HOME_URL;/sources/"> <!ENTITY YOCTO_AB_PORT_URL "https://autobuilder.yocto.io/"> @@ -43,7 +36,6 @@ <!ENTITY YOCTO_POKY_URL "&YOCTO_DL_URL;/releases/poky/"> <!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;"> <!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/"> -<!ENTITY YOCTO_ECLIPSE_DL_URL "&YOCTO_RELEASE_DL_URL;/eclipse-plugin/"> <!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt-installer"> <!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2"> <!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines"> @@ -68,18 +60,30 @@ <!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env"> <!ENTITY OE_INIT_FILE "oe-init-build-env"> <!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo gcc-multilib \ - build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \ - xz-utils debianutils iputils-ping"> + build-essential chrpath socat cpio python3 python3-pip python3-pexpect \ + xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \ + pylint3 xterm"> <!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python3 unzip perl patch \ diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \ ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \ - python3-pexpect findutils which file cpio python python3-pip xz"> + python3-pexpect findutils which file cpio python python3-pip xz python3-GitPython \ + python3-jinja2 SDL-devel xterm rpcgen"> <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \ diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \ - python3-pexpect xz which"> -<!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "-y epel-release + python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel xterm rpcgen + $ sudo pip3 install GitPython"> +<!ENTITY CENTOS7_HOST_PACKAGES_ESSENTIAL "-y epel-release $ sudo yum makecache - $ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \ + $ sudo yum install gawk make wget tar bzip2 gzip python3 unzip perl patch \ diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat \ - perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python34-pip xz \ - which"> + perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python36-pip xz \ + which SDL-devel xterm + $ sudo pip3 install GitPython jinja2"> +<!ENTITY CENTOS8_HOST_PACKAGES_ESSENTIAL "-y epel-release + $ sudo dnf config-manager --set-enabled PowerTools + $ sudo dnf makecache + $ sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch \ + diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath ccache \ + socat perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python3-pip \ + python3-GitPython python3-jinja2 python3-pexpect xz which SDL-devel xterm \ + rpcgen"> diff --git a/external/poky/documentation/profile-manual/figures/lttngmain0.png b/external/poky/documentation/profile-manual/figures/lttngmain0.png Binary files differdeleted file mode 100644 index 5f60113c..00000000 --- a/external/poky/documentation/profile-manual/figures/lttngmain0.png +++ /dev/null diff --git a/external/poky/documentation/profile-manual/profile-manual-eclipse-customization.xsl b/external/poky/documentation/profile-manual/profile-manual-eclipse-customization.xsl deleted file mode 100644 index a898281f..00000000 --- a/external/poky/documentation/profile-manual/profile-manual-eclipse-customization.xsl +++ /dev/null @@ -1,35 +0,0 @@ -<?xml version='1.0'?> -<xsl:stylesheet - xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - xmlns="http://www.w3.org/1999/xhtml" - xmlns:fo="http://www.w3.org/1999/XSL/Format" - version="1.0"> - - <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - -<!-- - - <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - - <xsl:import - href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" /> - ---> - - <xsl:param name="chunker.output.indent" select="'yes'"/> - <xsl:param name="chunk.quietly" select="1"/> - <xsl:param name="chunk.first.sections" select="1"/> - <xsl:param name="chunk.section.depth" select="10"/> - <xsl:param name="use.id.as.filename" select="1"/> - <xsl:param name="ulink.target" select="'_self'" /> - <xsl:param name="base.dir" select="'html/profile-manual/'"/> - <xsl:param name="html.stylesheet" select="'../book.css'"/> - <xsl:param name="eclipse.manifest" select="0"/> - <xsl:param name="create.plugin.xml" select="0"/> - <xsl:param name="suppress.navigation" select="1"/> - <xsl:param name="generate.index" select="0"/> - <xsl:param name="chapter.autolabel" select="1" /> - <xsl:param name="appendix.autolabel">A</xsl:param> - <xsl:param name="section.autolabel" select="1" /> - <xsl:param name="section.label.includes.component.label" select="1" /> -</xsl:stylesheet> diff --git a/external/poky/documentation/profile-manual/profile-manual-usage.xml b/external/poky/documentation/profile-manual/profile-manual-usage.xml index a1b56515..9a4273a0 100644 --- a/external/poky/documentation/profile-manual/profile-manual-usage.xml +++ b/external/poky/documentation/profile-manual/profile-manual-usage.xml @@ -2182,7 +2182,7 @@ meta-toolchain meta-ide-support - You can also run generated qemu images with a command like 'runqemu qemux86' + You can also run generated qemu images with a command like 'runqemu qemux86-64' </literallayout> Once you've done that, you can cd to whatever directory @@ -2350,22 +2350,8 @@ <para> For this section, we'll assume you've already performed the basic setup outlined in the General Setup section. - </para> - - <para> LTTng is run on the target system by ssh'ing to it. - However, if you want to see the traces graphically, - install Eclipse as described in section - "<link linkend='manually-copying-a-trace-to-the-host-and-viewing-it-in-eclipse'>Manually copying a trace to the host and viewing it in Eclipse (i.e. using Eclipse without network support)</link>" - and follow the directions to manually copy traces to the host and - view them in Eclipse (i.e. using Eclipse without network support). </para> - - <note> - Be sure to download and install/run the 'SR1' or later Juno release - of eclipse e.g.: - <ulink url='http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/juno/SR1/eclipse-cpp-juno-SR1-linux-gtk-x86_64.tar.gz'>http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/juno/SR1/eclipse-cpp-juno-SR1-linux-gtk-x86_64.tar.gz</ulink> - </note> </section> <section id='collecting-and-viewing-traces'> @@ -2564,163 +2550,6 @@ </para> </section> - <section id='manually-copying-a-trace-to-the-host-and-viewing-it-in-eclipse'> - <title>Manually copying a trace to the host and viewing it in Eclipse (i.e. using Eclipse without network support)</title> - - <para> - If you already have an LTTng trace on a remote target and - would like to view it in Eclipse on the host, you can easily - copy it from the target to the host and import it into - Eclipse to view it using the LTTng Eclipse plug-in already - bundled in the Eclipse (Juno SR1 or greater). - </para> - - <para> - Using the trace we created in the previous section, archive - it and copy it to your host system: - <literallayout class='monospaced'> - root@crownbay:~/lttng-traces# tar zcvf auto-20121015-232120.tar.gz auto-20121015-232120 - auto-20121015-232120/ - auto-20121015-232120/kernel/ - auto-20121015-232120/kernel/metadata - auto-20121015-232120/kernel/channel0_1 - auto-20121015-232120/kernel/channel0_0 - - $ scp root@192.168.1.47:lttng-traces/auto-20121015-232120.tar.gz . - root@192.168.1.47's password: - auto-20121015-232120.tar.gz 100% 1566KB 1.5MB/s 00:01 - </literallayout> - Unarchive it on the host: - <literallayout class='monospaced'> - $ gunzip -c auto-20121015-232120.tar.gz | tar xvf - - auto-20121015-232120/ - auto-20121015-232120/kernel/ - auto-20121015-232120/kernel/metadata - auto-20121015-232120/kernel/channel0_1 - auto-20121015-232120/kernel/channel0_0 - </literallayout> - We can now import the trace into Eclipse and view it: - <orderedlist> - <listitem><para>First, start eclipse and open the - 'LTTng Kernel' perspective by selecting the following - menu item: - <literallayout class='monospaced'> - Window | Open Perspective | Other... - </literallayout></para></listitem> - <listitem><para>In the dialog box that opens, select - 'LTTng Kernel' from the list.</para></listitem> - <listitem><para>Back at the main menu, select the - following menu item: - <literallayout class='monospaced'> - File | New | Project... - </literallayout></para></listitem> - <listitem><para>In the dialog box that opens, select - the 'Tracing | Tracing Project' wizard and press - 'Next>'.</para></listitem> - <listitem><para>Give the project a name and press - 'Finish'.</para></listitem> - <listitem><para>In the 'Project Explorer' pane under - the project you created, right click on the - 'Traces' item.</para></listitem> - <listitem><para>Select 'Import..." and in the dialog - that's displayed:</para></listitem> - <listitem><para>Browse the filesystem and find the - select the 'kernel' directory containing the trace - you copied from the target - e.g. auto-20121015-232120/kernel</para></listitem> - <listitem><para>'Checkmark' the directory in the tree - that's displayed for the trace</para></listitem> - <listitem><para>Below that, select 'Common Trace Format: - Kernel Trace' for the 'Trace Type'</para></listitem> - <listitem><para>Press 'Finish' to close the dialog - </para></listitem> - <listitem><para>Back in the 'Project Explorer' pane, - double-click on the 'kernel' item for the - trace you just imported under 'Traces' - </para></listitem> - </orderedlist> - You should now see your trace data displayed graphically - in several different views in Eclipse: - </para> - - <para> - <imagedata fileref="figures/lttngmain0.png" width="6in" depth="6in" align="center" scalefit="1" /> - </para> - - <para> - You can access extensive help information on how to use - the LTTng plug-in to search and analyze captured traces via - the Eclipse help system: - <literallayout class='monospaced'> - Help | Help Contents | LTTng Plug-in User Guide - </literallayout> - </para> - </section> - - <section id='collecting-and-viewing-a-trace-in-eclipse'> - <title>Collecting and viewing a trace in Eclipse</title> - - <note> - This section on collecting traces remotely doesn't currently - work because of Eclipse 'RSE' connectivity problems. Manually - tracing on the target, copying the trace files to the host, - and viewing the trace in Eclipse on the host as outlined in - previous steps does work however - please use the manual - steps outlined above to view traces in Eclipse. - </note> - - <para> - In order to trace a remote target, you also need to add - a 'tracing' group on the target and connect as a user - who's part of that group e.g: - <literallayout class='monospaced'> - # adduser tomz - # groupadd -r tracing - # usermod -a -G tracing tomz - </literallayout> - <orderedlist> - <listitem><para>First, start eclipse and open the - 'LTTng Kernel' perspective by selecting the following - menu item: - <literallayout class='monospaced'> - Window | Open Perspective | Other... - </literallayout></para></listitem> - <listitem><para>In the dialog box that opens, select - 'LTTng Kernel' from the list.</para></listitem> - <listitem><para>Back at the main menu, select the - following menu item: - <literallayout class='monospaced'> - File | New | Project... - </literallayout></para></listitem> - <listitem><para>In the dialog box that opens, select - the 'Tracing | Tracing Project' wizard and - press 'Next>'.</para></listitem> - <listitem><para>Give the project a name and press - 'Finish'. That should result in an entry in the - 'Project' subwindow.</para></listitem> - <listitem><para>In the 'Control' subwindow just below - it, press 'New Connection'.</para></listitem> - <listitem><para>Add a new connection, giving it the - hostname or IP address of the target system. - </para></listitem> - <listitem><para>Provide the username and password - of a qualified user (a member of the 'tracing' group) - or root account on the target system. - </para></listitem> - <listitem><para>Provide appropriate answers to whatever - else is asked for e.g. 'secure storage password' - can be anything you want. - If you get an 'RSE Error' it may be due to proxies. - It may be possible to get around the problem by - changing the following setting: - <literallayout class='monospaced'> - Window | Preferences | Network Connections - </literallayout> - Switch 'Active Provider' to 'Direct' - </para></listitem> - </orderedlist> - </para> - </section> </section> <section id='lltng-documentation'> @@ -2742,15 +2571,6 @@ You can find a "Getting Started" link on this site that takes you to an LTTng Quick Start. </para> - - <para> - Finally, you can access extensive help information on how to use - the LTTng plug-in to search and analyze captured traces via the - Eclipse help system: - <literallayout class='monospaced'> - Help | Help Contents | LTTng Plug-in User Guide - </literallayout> - </para> </section> </section> diff --git a/external/poky/documentation/profile-manual/profile-manual.xml b/external/poky/documentation/profile-manual/profile-manual.xml index 02d989ff..3527850d 100644..100755 --- a/external/poky/documentation/profile-manual/profile-manual.xml +++ b/external/poky/documentation/profile-manual/profile-manual.xml @@ -22,11 +22,10 @@ <authorgroup> <author> - <firstname>Scott</firstname> <surname>Rifenbark</surname> <affiliation> - <orgname>Scotty's Documentation Services, INC</orgname> + <orgname>&ORGNAME;</orgname> </affiliation> - <email>srifenbark@gmail.com</email> + <email>&ORGEMAIL;</email> </author> </authorgroup> @@ -34,7 +33,7 @@ <revision> <revnumber>1.4</revnumber> <date>April 2013</date> - <revremark>Released with the Yocto Project 1.4 Release.</revremark> + <revremark>The initial document released with the Yocto Project 1.4 Release.</revremark> </revision> <revision> <revnumber>1.5</revnumber> @@ -42,11 +41,6 @@ <revremark>Released with the Yocto Project 1.5 Release.</revremark> </revision> <revision> - <revnumber>1.5.1</revnumber> - <date>January 2014</date> - <revremark>Released with the Yocto Project 1.5.1 Release.</revremark> - </revision> - <revision> <revnumber>1.6</revnumber> <date>April 2014</date> <revremark>Released with the Yocto Project 1.6 Release.</revremark> @@ -97,24 +91,29 @@ <revremark>Released with the Yocto Project 2.6 Release.</revremark> </revision> <revision> - <revnumber>2.6.1</revnumber> - <date>February 2019</date> - <revremark>Released with the Yocto Project 2.6.1 Release.</revremark> + <revnumber>2.7</revnumber> + <date>May 2019</date> + <revremark>Released with the Yocto Project 2.7 Release.</revremark> + </revision> + <revision> + <revnumber>3.0</revnumber> + <date>October 2019</date> + <revremark>Released with the Yocto Project 3.0 Release.</revremark> </revision> <revision> - <revnumber>2.6.2</revnumber> - <date>April 2019</date> - <revremark>Released with the Yocto Project 2.6.2 Release.</revremark> + <revnumber>3.1</revnumber> + <date>April 2020</date> + <revremark>Released with the Yocto Project 3.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.3</revnumber> - <date>August 2019</date> - <revremark>Released with the Yocto Project 2.6.3 Release.</revremark> + <revnumber>3.1.1</revnumber> + <date>June 2020</date> + <revremark>Released with the Yocto Project 3.1.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.4</revnumber> - <date>November 2019</date> - <revremark>Released with the Yocto Project 2.6.4 Release.</revremark> + <revnumber>3.1.2</revnumber> + <date>&REL_MONTH_YEAR;</date> + <revremark>Released with the Yocto Project 3.1.2 Release.</revremark> </revision> </revhistory> @@ -139,7 +138,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -156,18 +155,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. </para></listitem> - <listitem><para> + <listitem> + <para> To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - <filename>yocto@yoctoproject.com</filename> or log into - the freenode <filename>#yocto</filename> channel. - </para></listitem> + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + <filename>docs@lists.yoctoproject.org</filename> or + log into the freenode <filename>#yocto</filename> channel. + </para> + </listitem> </itemizedlist> </note> </legalnotice> diff --git a/external/poky/documentation/ref-manual/faq.xml b/external/poky/documentation/ref-manual/faq.xml index 49ff8626..d94cb32a 100644 --- a/external/poky/documentation/ref-manual/faq.xml +++ b/external/poky/documentation/ref-manual/faq.xml @@ -33,7 +33,7 @@ <para id='faq-not-meeting-requirements'> My development system does not meet the required Git, tar, and Python versions. - In particular, I do not have Python 3.4.0 or greater. + In particular, I do not have Python 3.5.0 or greater. Can I still use the Yocto Project? </para> </question> @@ -43,7 +43,7 @@ system a couple different ways (i.e. building a tarball or downloading a tarball). See the - "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>" + "<link linkend='required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</link>" section for steps on how to update your build tools. </para> </answer> diff --git a/external/poky/documentation/ref-manual/migration.xml b/external/poky/documentation/ref-manual/migration.xml index c648d8d4..affc8b90 100644 --- a/external/poky/documentation/ref-manual/migration.xml +++ b/external/poky/documentation/ref-manual/migration.xml @@ -680,7 +680,7 @@ <para> For more information on this requirement, see the - "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>" + "<link linkend='required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</link>" section. </para> </section> @@ -875,8 +875,7 @@ not work. This change is intended to catch those kinds of situations. Valid <filename>IMAGE_FEATURES</filename> are drawn from - <link linkend='var-PACKAGE_GROUP'><filename>PACKAGE_GROUP</filename></link> - definitions, + <filename>PACKAGE_GROUP</filename> definitions, <link linkend='var-COMPLEMENTARY_GLOB'><filename>COMPLEMENTARY_GLOB</filename></link> and a new "validitems" varflag on <filename>IMAGE_FEATURES</filename>. @@ -1404,8 +1403,7 @@ <para> The - <link linkend='var-PACKAGE_GROUP'><filename>PACKAGE_GROUP</filename></link> - variable has been renamed to + <filename>PACKAGE_GROUP</filename> variable has been renamed to <link linkend='var-FEATURE_PACKAGES'><filename>FEATURE_PACKAGES</filename></link> to more accurately reflect its purpose. You can still use <filename>PACKAGE_GROUP</filename> but @@ -1754,7 +1752,7 @@ Git that meets this requirement, you can use the <filename>buildtools-tarball</filename> that does. See the - "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>" + "<link linkend='required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</link>" section for more information. </para> </section> @@ -2103,15 +2101,14 @@ </para> <para> - Additionally, a - <link linkend='ref-classes-bluetooth'><filename>bluetooth</filename></link> - class has been added to make selection of the appropriate bluetooth - support within a recipe a little easier. + Additionally, a <filename>bluetooth</filename> class has been added + to make selection of the appropriate bluetooth support within a + recipe a little easier. If you wish to make use of this class in a recipe, add something such as the following: <literallayout class='monospaced'> inherit bluetooth - PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)} + PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}" PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4" PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5" </literallayout> @@ -2566,9 +2563,7 @@ <link linkend='oe-core'>OE-Core</link>. The change includes <filename>package_regex.inc</filename> and <filename>distro_alias.inc</filename>, which are typically enabled - when using the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class. + when using the <filename>distrodata</filename> class. Additionally, the contents of <filename>upstream_tracking.inc</filename> has now been split out to the relevant recipes. @@ -3218,7 +3213,7 @@ recent version, you can install the buildtools, which will provide it. See the - "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>" + "<link linkend='required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</link>" section for more information on the buildtools tarball. </para></listitem> <listitem><para> @@ -3627,7 +3622,7 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. image types, this part of the kernel image base name as been removed leaving only the following: <literallayout class='monospaced'> - KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME} + KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" </literallayout> If you have recipes or classes that use <filename>KERNEL_IMAGE_BASE_NAME</filename> directly, you might @@ -4506,8 +4501,8 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>. </para></listitem> <listitem><para> <emphasis>fsimage Plug-in Removed:</emphasis> - The Wic fsimage plug-in has been removed as it duplicates - functionality of the rawcopy plug-in. + The Wic fsimage plugin has been removed as it duplicates + functionality of the rawcopy plugin. </para></listitem> </itemizedlist> </para> @@ -4742,7 +4737,7 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>. <para> This section provides information about packaging changes that have - ocurred: + occurred: <itemizedlist> <listitem><para> <emphasis><filename>python3</filename> Changes:</emphasis> @@ -5604,7 +5599,7 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>. creation time, use <filename>pkg_postinst_ontarget()</filename> or call - <filename>postinst-intercepts defer_to_first_boot</filename> + <filename>postinst_intercept delay_to_first_boot</filename> from <filename>pkg_postinst()</filename>. Any failure of a <filename>pkg_postinst()</filename> script (including <filename>exit 1</filename>) @@ -6195,7 +6190,7 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>. If you want to explicitly defer a postinstall to first boot on the target rather than at rootfs creation time, use <filename>pkg_postinst_ontarget()</filename> or call - <filename>postinst-intercepts defer_to_first_boot</filename> from + <filename>postinst_intercept delay_to_first_boot</filename> from <filename>pkg_postinst()</filename>. Any failure of a <filename>pkg_postinst()</filename> script (including exit 1) triggers an error during the @@ -6325,6 +6320,980 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>. </para> </section> </section> + +<section id='moving-to-the-yocto-project-2.7-release'> + <title>Moving to the Yocto Project 2.7 Release</title> + + <para> + This section provides migration information for moving to the + Yocto Project 2.7 Release from the prior release. + </para> + + <section id='migration-2.7-bitbake-changes'> + <title>BitBake Changes</title> + + <para> + The following changes have been made to BitBake: + <itemizedlist> + <listitem><para> + BitBake now checks anonymous Python functions and pure + Python functions (e.g. <filename>def funcname:</filename>) + in the metadata for tab indentation. + If found, BitBake produces a warning. + </para></listitem> + <listitem><para> + Bitbake now checks + <link linkend='var-BBFILE_COLLECTIONS'><filename>BBFILE_COLLECTIONS</filename></link> + for duplicate entries and triggers an error if any are + found. + </para></listitem> + </itemizedlist> + </para> + </section> + + <section id='migration-2.7-eclipse-support-dropped'> + <title><trademark class='trade'>Eclipse</trademark> Support Removed</title> + + <para> + Support for the Eclipse IDE has been removed. + Support continues for those releases prior to 2.7 that did include + support. + The 2.7 release does not include the Eclipse Yocto plugin. + </para> + </section> + + <section id='migration-2.7-qemu-native-splits-system-and-user-mode-parts'> + <title><filename>qemu-native</filename> Splits the System and User-Mode Parts</title> + + <para> + The system and user-mode parts of <filename>qemu-native</filename> + are now split. + <filename>qemu-native</filename> provides the user-mode components + and <filename>qemu-system-native</filename> provides the system + components. + If you have recipes that depend on QEMU's system emulation + functionality at build time, they should now depend upon + <filename>qemu-system-native</filename> instead of + <filename>qemu-native</filename>. + </para> + </section> + + <section id='migration-2.7-upstream-tracking.inc-removed'> + <title>The <filename>upstream-tracking.inc</filename> File Has Been Removed</title> + + <para> + The previously deprecated <filename>upstream-tracking.inc</filename> + file is now removed. + Any <filename>UPSTREAM_TRACKING*</filename> variables are now set + in the corresponding recipes instead. + </para> + + <para> + Remove any references you have to the + <filename>upstream-tracking.inc</filename> file in your + configuration. + </para> + </section> + + <section id='migration-2.7-distro-features-libc-removed'> + <title>The <filename>DISTRO_FEATURES_LIBC</filename> Variable Has Been Removed</title> + + <para> + The <filename>DISTRO_FEATURES_LIBC</filename> variable is no + longer used. + The ability to configure glibc using kconfig has been removed + for quite some time making the <filename>libc-*</filename> features + set no longer effective. + </para> + + <para> + Remove any references you have to + <filename>DISTRO_FEATURES_LIBC</filename> in your own layers. + </para> + </section> + + <section id='migration-2.7-license-values'> + <title>License Value Corrections</title> + + <para> + The following corrections have been made to the + <link linkend='var-LICENSE'><filename>LICENSE</filename></link> + values set by recipes: + <literallayout class='monospaced'> + <emphasis>socat</emphasis>: Corrected <filename>LICENSE</filename> to be "GPLv2" rather than + "GPLv2+". + + <emphasis>libgfortran</emphasis>: Set license to "GPL-3.0-with-GCC-exception". + + <emphasis>elfutils</emphasis>: Removed "Elfutils-Exception" and set to "GPLv2" for shared + libraries + </literallayout> + </para> + </section> + + <section id='migration-2.7-packaging-changes'> + <title>Packaging Changes</title> + + <para> + This section provides information about packaging changes. + <itemizedlist> + <listitem><para> + <filename>bind</filename>: The + <filename>nsupdate</filename> binary has been moved to + the <filename>bind-utils</filename> package. + </para></listitem> + <listitem><para> + Debug split: The default debug split has been changed to + create separate source packages (i.e. + <replaceable>package_name</replaceable><filename>-dbg</filename> + and + <replaceable>package_name</replaceable><filename>-src</filename>). + If you are currently using <filename>dbg-pkgs</filename> + in + <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link> + to bring in debug symbols and you still need the sources, + you must now also add <filename>src-pkgs</filename> to + <filename>IMAGE_FEATURES</filename>. + Source packages remain in the target portion of the SDK + by default, unless you have set your own value for + <link linkend='var-SDKIMAGE_FEATURES'><filename>SDKIMAGE_FEATURES</filename></link> + that does not include <filename>src-pkgs</filename>. + </para></listitem> + <listitem><para> + Mount all using <filename>util-linux</filename>: + <filename>/etc/default/mountall</filename> has + moved into the -mount sub-package. + </para></listitem> + <listitem><para> + Splitting binaries using <filename>util-linux</filename>: + <filename>util-linux</filename> now splits each binary into + its own package for fine-grained control. + The main <filename>util-linux</filename> package pulls in + the individual binary packages using the + <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> + and + <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> + variables. + As a result, existing images should not see any changes + assuming + <link linkend='var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></link> + is not set. + </para></listitem> + <listitem><para> + <filename>netbase/base-files</filename>: + <filename>/etc/hosts</filename> has moved from + <filename>netbase</filename> to + <filename>base-files</filename>. + </para></listitem> + <listitem><para> + <filename>tzdata</filename>: The main package has been + converted to an empty meta package that pulls in all + <filename>tzdata</filename> packages by default. + </para></listitem> + <listitem><para> + <filename>lrzsz</filename>: This package has been removed + from <filename>packagegroup-self-hosted</filename> and + <filename>packagegroup-core-tools-testapps</filename>. + The X/Y/ZModem support is less likely to be needed on + modern systems. + If you are relying on these packagegroups to include the + <filename>lrzsz</filename> package in your image, you + now need to explicitly add the package. + </para></listitem> + </itemizedlist> + </para> + </section> + + <section id='migration-2.7-removed-recipes'> + <title>Removed Recipes</title> + + <para> + The following recipes have been removed: + <literallayout class='monospaced'> + <emphasis>gcc</emphasis>: Drop version 7.3 recipes. Version 8.3 now remains. + + <emphasis>linux-yocto</emphasis>: Drop versions 4.14 and 4.18 recipes. Versions 4.19 and 5.0 remain. + + <emphasis>go</emphasis>: Drop version 1.9 recipes. Versions 1.11 and 1.12 remain. + + <emphasis>xvideo-tests</emphasis>: Became obsolete. + + <emphasis>libart-lgpl</emphasis>: Became obsolete. + + <emphasis>gtk-icon-utils-native</emphasis>: These tools are now provided by gtk+3-native + + <emphasis>gcc-cross-initial</emphasis>: No longer needed. gcc-cross/gcc-crosssdk is now used instead. + + <emphasis>gcc-crosssdk-initial</emphasis>: No longer needed. gcc-cross/gcc-crosssdk is now used instead. + + <emphasis>glibc-initial</emphasis>: Removed because the benefits of having it for site_config are + currently outweighed by the cost of building the recipe. + </literallayout> + </para> + </section> + + <section id='migration-2.7-removed-classes'> + <title>Removed Classes</title> + + <para> + The following classes have been removed: + <literallayout class='monospaced'> + <emphasis>distutils-tools</emphasis>: This class was never used. + + <emphasis>bugzilla.bbclass</emphasis>: Became obsolete. + + <emphasis>distrodata</emphasis>: This functionally has been replaced by a more modern + tinfoil-based implementation. + </literallayout> + </para> + </section> + + <section id='migration-2.7-miscellaneous-changes'> + <title>Miscellaneous Changes</title> + + <para> + The following miscellaneous changes occurred: + <itemizedlist> + <listitem><para> + The <filename>distro</filename> subdirectory of the Poky + repository has been removed from the top-level + <filename>scripts</filename> directory. + </para></listitem> + <listitem><para> + Perl now builds for the target using + <ulink url='http://arsv.github.io/perl-cross/'><filename>perl-cross</filename></ulink> + for better maintainability and improved build performance. + This change should not present any problems unless you have + heavily customized your Perl recipe. + </para></listitem> + <listitem><para> + <filename>arm-tunes</filename>: Removed the "-march" + option if mcpu is already added. + </para></listitem> + <listitem><para> + <filename>update-alternatives</filename>: Convert file + renames to + <link linkend='var-PACKAGE_PREPROCESS_FUNCS'><filename>PACKAGE_PREPROCESS_FUNCS</filename></link> + </para></listitem> + <listitem><para> + <filename>base/pixbufcache</filename>: Obsolete + <filename>sstatecompletions</filename> code has been + removed. + </para></listitem> + <listitem><para> + <link linkend='ref-classes-native'><filename>native</filename></link> + class: + <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> + handling has been enabled. + </para></listitem> + <listitem><para> + <filename>inetutils</filename>: This recipe has rsh + disabled. + </para></listitem> + </itemizedlist> + </para> + </section> +</section> + +<section id='moving-to-the-yocto-project-3.0-release'> + <title>Moving to the Yocto Project 3.0 Release</title> + + <para> + This section provides migration information for moving to the + Yocto Project 3.0 Release from the prior release. + </para> + + <section id='migration-3.0-init-system-selection'> + <title>Init System Selection</title> + + <para> + Changing the init system manager previously required setting a + number of different variables. + You can now change the manager by setting the + <filename>INIT_MANAGER</filename> variable and the corresponding + include files + (i.e. <filename>conf/distro/include/init-manager-*.conf</filename>). + Include files are provided for four values: "none", "sysvinit", + "systemd", and "mdev-busybox". + The default value, "none", for <filename>INIT_MANAGER</filename> + should allow your current settings to continue working. + However, it is advisable to explicitly set + <filename>INIT_MANAGER</filename>. + </para> + </section> + + <section id='migration-3.0-lsb-support-removed'> + <title>LSB Support Removed</title> + + <para> + Linux Standard Base (LSB) as a standard is not current, and + is not well suited for embedded applications. + Support can be continued in a separate layer if needed. + However, presently LSB support has been removed from the core. + </para> + + <para> + As a result of this change, the <filename>poky-lsb</filename> + derivative distribution configuration that was also used for + testing alternative configurations has been replaced with a + <filename>poky-altcfg</filename> distribution that has LSB + parts removed. + </para> + </section> + + <section id='migration-3.0-removed-recipes'> + <title>Removed Recipes</title> + + <para> + The following recipes have been removed. + <itemizedlist> + <listitem><para> + <filename>core-image-lsb-dev</filename>: Part of removed + LSB support. + </para></listitem> + <listitem><para> + <filename>core-image-lsb</filename>: Part of removed + LSB support. + </para></listitem> + <listitem><para> + <filename>core-image-lsb-sdk</filename>: Part of removed + LSB support. + </para></listitem> + <listitem><para> + <filename>cve-check-tool</filename>: Functionally replaced + by the <filename>cve-update-db</filename> recipe and + <filename>cve-check</filename> class. + </para></listitem> + <listitem><para> + <filename>eglinfo</filename>: No longer maintained. + <filename>eglinfo</filename> from + <filename>mesa-demos</filename> is an adequate and + maintained alternative. + </para></listitem> + <listitem><para> + <filename>gcc-8.3</filename>: Version 8.3 removed. + Replaced by 9.2. + </para></listitem> + <listitem><para> + <filename>gnome-themes-standard</filename>: Only needed + by gtk+ 2.x, which has been removed. + </para></listitem> + <listitem><para> + <filename>gtk+</filename>: GTK+ 2 is obsolete and has been + replaced by gtk+3. + </para></listitem> + <listitem><para> + <filename>irda-utils</filename>: Has become obsolete. + IrDA support has been removed from the Linux kernel in + version 4.17 and later. + </para></listitem> + <listitem><para> + <filename>libnewt-python</filename>: + <filename>libnewt</filename> Python support merged into + main <filename>libnewt</filename> recipe. + </para></listitem> + <listitem><para> + <filename>libsdl</filename>: Replaced by newer + <filename>libsdl2</filename>. + </para></listitem> + <listitem><para> + <filename>libx11-diet</filename>: Became obsolete. + </para></listitem> + <listitem><para> + <filename>libxx86dga</filename>: Removed obsolete client + library. + </para></listitem> + <listitem><para> + <filename>libxx86misc</filename>: Removed. Library is + redundant. + </para></listitem> + <listitem><para> + <filename>linux-yocto</filename>: Version 5.0 removed, + which is now redundant (5.2 / 4.19 present). + </para></listitem> + <listitem><para> + <filename>lsbinitscripts</filename>: Part of removed LSB + support. + </para></listitem> + <listitem><para> + <filename>lsb</filename>: Part of removed LSB support. + </para></listitem> + <listitem><para> + <filename>lsbtest</filename>: Part of removed LSB support. + </para></listitem> + <listitem><para> + <filename>openssl10</filename>: Replaced by newer + <filename>openssl</filename> version 1.1. + </para></listitem> + <listitem><para> + <filename>packagegroup-core-lsb</filename>: Part of removed + LSB support. + </para></listitem> + <listitem><para> + <filename>python-nose</filename>: Removed the Python 2.x + version of the recipe. + </para></listitem> + <listitem><para> + <filename>python-numpy</filename>: Removed the Python 2.x + version of the recipe. + </para></listitem> + <listitem><para> + <filename>python-scons</filename>: Removed the Python 2.x + version of the recipe. + </para></listitem> + <listitem><para> + <filename>source-highlight</filename>: No longer needed. + </para></listitem> + <listitem><para> + <filename>stress</filename>: Replaced by + <filename>stress-ng</filename>. + </para></listitem> + <listitem><para> + <filename>vulkan</filename>: Split into + <filename>vulkan-loader</filename>, + <filename>vulkan-headers</filename>, and + <filename>vulkan-tools</filename>. + </para></listitem> + <listitem><para> + <filename>weston-conf</filename>: Functionality moved to + <filename>weston-init</filename>. + </para></listitem> + </itemizedlist> + </para> + </section> + + <section id='migration-3.0-packaging-changes'> + <title>Packaging Changes</title> + + <para> + The following packaging changes have occurred. + <itemizedlist> + <listitem><para> + The + <ulink url='https://en.wikipedia.org/wiki/GNOME_Web'>Epiphany</ulink> + browser has been dropped from + <filename>packagegroup-self-hosted</filename> as it has + not been needed inside + <filename>build-appliance-image</filename> for + quite some time and was causing resource problems. + </para></listitem> + <listitem><para> + <filename>libcap-ng</filename> Python support has been + moved to a separate <filename>libcap-ng-python</filename> + recipe to streamline the build process when the Python + bindings are not needed. + </para></listitem> + <listitem><para> + <filename>libdrm</filename> now packages the file + <filename>amdgpu.ids</filename> into a separate + <filename>libdrm-amdgpu</filename> package. + </para></listitem> + <listitem><para> + <filename>python3</filename>: The + <filename>runpy</filename> module is now in the + <filename>python3-core</filename> package as it is + required to support the common "python3 -m" command usage. + </para></listitem> + <listitem><para> + <filename>distcc</filename> now provides separate + <filename>distcc-client</filename> and + <filename>distcc-server</filename> packages as typically + one or the other are needed, rather than both. + </para></listitem> + <listitem><para> + <filename>python*-setuptools</filename> recipes now + separately package the <filename>pkg_resources</filename> + module in a <filename>python-pkg-resources</filename> / + <filename>python3-pkg-resources</filename> package as + the module is useful independent of the rest of the + setuptools package. + The main <filename>python-setuptools</filename> / + <filename>python3-setuptools</filename> package depends + on this new package so you should only need to update + dependencies unless you want to take advantage of the + increased granularity. + </para></listitem> + </itemizedlist> + </para> + </section> + + <section id='migration-3.0-cve-checking'> + <title>CVE Checking</title> + + <para> + <filename>cve-check-tool</filename> has been functionally replaced + by a new <filename>cve-update-db</filename> recipe and + functionality built into the <filename>cve-check</filename> class. + The result uses NVD JSON data feeds rather than the deprecated + XML feeds that <filename>cve-check-tool</filename> was using, + supports CVSSv3 scoring, and makes other improvements. + </para> + + <para> + Additionally, the <filename>CVE_CHECK_CVE_WHITELIST</filename> + variable has been replaced by + <filename>CVE_CHECK_WHITELIST</filename>. + </para> + </section> + + <section id='migration-3.0-bitbake-changes'> + <title>Bitbake Changes</title> + + <para> + The following BitBake changes have occurred. + <itemizedlist> + <listitem><para> + <filename>addtask</filename> statements now properly + validate dependent tasks. + Previously, an invalid task was silently ignored. + With this change, the invalid task generates a warning. + </para></listitem> + <listitem><para> + Other invalid <filename>addtask</filename> and + <filename>deltask</filename> usages now trigger these + warnings: "multiple target tasks arguments with + addtask / deltask", and "multiple before/after clauses". + </para></listitem> + <listitem><para> + The "multiconfig" prefix is now shortened to "mc". + "multiconfig" will continue to work, however it may be + removed in a future release. + </para></listitem> + <listitem><para> + The <filename>bitbake -g</filename> command no longer + generates a <filename>recipe-depends.dot</filename> file + as the contents (i.e. a reprocessed version of + <filename>task-depends.dot</filename>) were confusing. + </para></listitem> + <listitem><para> + The <filename>bb.build.FuncFailed</filename> exception, + previously raised by + <filename>bb.build.exec_func()</filename> when certain + other exceptions have occurred, has been removed. + The real underlying exceptions will be raised instead. + If you have calls to + <filename>bb.build.exec_func()</filename> in custom classes + or <filename>tinfoil-using</filename> scripts, any + references to <filename>bb.build.FuncFailed</filename> + should be cleaned up. + </para></listitem> + <listitem><para> + Additionally, the + <filename>bb.build.exec_func()</filename> no longer accepts + the "pythonexception" parameter. + The function now always raises exceptions. + Remove this argument in any calls to + <filename>bb.build.exec_func()</filename> in custom classes + or scripts. + </para></listitem> + <listitem><para> + The + <ulink url='&YOCTO_DOCS_BB_URL;#var-bb-BB_SETSCENE_VERIFY_FUNCTION2'><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename></ulink> + is no longer used. + In the unlikely event that you have any references to it, + they should be removed. + </para></listitem> + <listitem><para> + The <filename>RunQueueExecuteScenequeue</filename> and + <filename>RunQueueExecuteTasks</filename> events have been + removed since setscene tasks are now executed as part of + the normal runqueue. + Any event handling code in custom classes or scripts that + handles these two events need to be updated. + </para></listitem> + <listitem><para> + The arguments passed to functions used with + <ulink url='&YOCTO_DOCS_BB_URL;#var-bb-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></ulink> + have changed. + If you are using your own custom hash check function, see + <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=40a5e193c4ba45c928fccd899415ea56b5417725'></ulink> + for details. + </para></listitem> + <listitem><para> + Task specifications in <filename>BB_TASKDEPDATA</filename> + and class implementations used in signature generator + classes now use "<fn>:<task>" everywhere rather than + the "." delimiter that was being used in some places. + This change makes it consistent with all areas in the code. + Custom signature generator classes and code that reads + <filename>BB_TASKDEPDATA</filename> need to be updated to + use ':' as a separator rather than '.'. + </para></listitem> + </itemizedlist> + </para> + </section> + + <section id='migration-3.0-sanity-checks'> + <title>Sanity Checks</title> + + <para> + The following sanity check changes occurred. + <itemizedlist> + <listitem><para> + <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> + is now checked for usage of two problematic items: + <itemizedlist> + <listitem><para> + "${PN}" prefix/suffix use - Warnings always appear + if ${PN} is used. + You must fix the issue regardless of whether + multiconfig or anything else that would cause + prefixing/suffixing to happen. + </para></listitem> + <listitem><para> + Github archive tarballs - these are not guaranteed + to be stable. + Consequently, it is likely that the tarballs will + be refreshed and thus the SRC_URI checksums + will fail to apply. + It is recommended that you fetch either an official + release tarball or a specific revision from the + actual Git repository instead. + </para></listitem> + </itemizedlist> + Either one of these items now trigger a warning by default. + If you wish to disable this check, remove + <filename>src-uri-bad</filename> from + <link linkend='var-WARN_QA'><filename>WARN_QA</filename></link>. + </para></listitem> + <listitem><para> + The <filename>file-rdeps</filename> runtime dependency + check no longer expands + <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> + recursively as there is no mechanism to ensure they can be + fully computed, and thus races sometimes result in errors + either showing up or not. + Thus, you might now see errors for missing runtime + dependencies that were previously satisfied recursively. + Here is an example: package A contains a shell script + starting with <filename>#!/bin/bash</filename> but has no + dependency on bash. + However, package A depends on package B, which does depend + on bash. + You need to add the missing dependency or dependencies to + resolve the warning. + </para></listitem> + <listitem><para> + Setting <filename>DEPENDS_${PN}</filename> anywhere + (i.e. typically in a recipe) now triggers an error. + The error is triggered because + <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link> + is not a package-specific variable unlike RDEPENDS. + You should set <filename>DEPENDS</filename> instead. + </para></listitem> + <listitem><para> + systemd currently does not work well with the musl C + library because only upstream officially supports linking + the library with glibc. + Thus, a warning is shown when building systemd in + conjunction with musl. + </para></listitem> + </itemizedlist> + </para> + </section> + + <section id='migration-3.0-miscellaneous-changes'> + <title>Miscellaneous Changes</title> + + <para> + The following miscellaneous changes have occurred. + <itemizedlist> + <listitem><para> + The <filename>gnome</filename> + class has been removed because it now does very little. + You should update recipes that previously inherited this + class to do the following: + <literallayout class='monospaced'> + inherit gnomebase gtk-icon-cache gconf mime + </literallayout> + </para></listitem> + <listitem><para> + The + <filename>meta/recipes-kernel/linux/linux-dtb.inc</filename> + file has been removed. + This file was previously deprecated in favor of setting + <link linkend='var-KERNEL_DEVICETREE'><filename>KERNEL_DEVICETREE</filename></link> + in any kernel recipe and only produced a warning. + Remove any <filename>include</filename> or + <filename>require</filename> statements pointing to this + file. + </para></listitem> + <listitem><para> + <link linkend='var-TARGET_CFLAGS'><filename>TARGET_CFLAGS</filename></link>, + <link linkend='var-TARGET_CPPFLAGS'><filename>TARGET_CPPFLAGS</filename></link>, + <link linkend='var-TARGET_CXXFLAGS'><filename>TARGET_CXXFLAGS</filename></link>, + and + <link linkend='var-TARGET_LDFLAGS'><filename>TARGET_LDFLAGS</filename></link> + are no longer exported to the external environment. + This change did not require any changes to core recipes, + which is a good indicator that no changes will be + required. + However, if for some reason the software being built by one + of your recipes is expecting these variables to be set, + then building the recipe will fail. + In such cases, you must either export the variable or + variables in the recipe or change the scripts so that + exporting is not necessary. + </para></listitem> + <listitem><para> + You must change the host distro identifier used in + <link linkend='var-NATIVELSBSTRING'><filename>NATIVELSBSTRING</filename></link> + to use all lowercase characters even if it does not contain + a version number. + This change is necessary only if you are not using + <filename>uninative</filename> and + <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>. + </para></listitem> + <listitem><para> + In the <filename>base-files</filename> recipe, writing the + hostname into <filename>/etc/hosts</filename> and + <filename>/etc/hostname</filename> is now done within the + main + <link linkend='ref-tasks-install'><filename>do_install</filename></link> + function rather than in the + <filename>do_install_basefilesissue</filename> function. + The reason for the change is because + <filename>do_install_basefilesissue</filename> is more + easily overridden without having to duplicate the hostname + functionality. + If you have done the latter (e.g. in a + <filename>base-files</filename> bbappend), then you should + remove it from your customized + <filename>do_install_basefilesissue</filename> function. + </para></listitem> + <listitem><para> + The <filename>wic --expand</filename> command now uses + commas to separate "key:value" pairs rather than hyphens. + <note> + The wic command-line help is not updated. + </note> + You must update any scripts or commands where you use + <filename>wic --expand</filename> with multiple + "key:value" pairs. + </para></listitem> + <listitem><para> + UEFI image variable settings have been moved from various + places to a central + <filename>conf/image-uefi.conf</filename>. + This change should not influence any existing configuration + as the <filename>meta/conf/image-uefi.conf</filename> + in the core metadata sets defaults that can be overridden + in the same manner as before. + </para></listitem> + <listitem><para> + <filename>conf/distro/include/world-broken.inc</filename> + has been removed. + For cases where certain recipes need to be disabled when + using the musl C library, these recipes now have + <filename>COMPATIBLE_HOST_libc-musl</filename> set with a + comment that explains why. + </para></listitem> + </itemizedlist> + </para> + </section> +</section> + + +<section id='moving-to-the-yocto-project-3.1-release'> + <title>Moving to the Yocto Project 3.1 Release</title> + + <para> + This section provides migration information for moving to the + Yocto Project 3.1 Release from the prior release. + </para> + + <section id='migration-3.1-minimum-system-requirements'> + <title>Minimum system requirements</title> + + <para> + The following versions / requirements of build host components have been updated: + <itemizedlist> + <listitem><para>gcc 5.0</para></listitem> + <listitem><para>python 3.5</para></listitem> + <listitem><para>tar 1.28</para></listitem> + <listitem><para><filename>rpcgen</filename> is now required on the host (part of the <filename>libc-dev-bin</filename> package on Ubuntu, Debian and related distributions, and the <filename>glibc</filename> package on RPM-based distributions).</para></listitem> + </itemizedlist> + + Additionally, the <filename>makeinfo</filename> and <filename>pod2man</filename> + tools are <emphasis>no longer</emphasis> required on the host. + </para> + </section> + + <section id='migration-3.1-mpc8315e-rdb-removed'> + <title>mpc8315e-rdb machine removed</title> + + <para> + The MPC8315E-RDB machine is old/obsolete and unobtainable, thus given the maintenance burden + the <filename>mpc8315e-rdb</filename> machine configuration that supported it has been removed + in this release. The removal does leave a gap in official PowerPC reference hardware + support; this may change in future if a suitable machine with accompanying support resources + is found. + </para> + </section> + + <section id='migration-3.1-python-2-removed'> + <title>Python 2 removed</title> + + <para> + Due to the expiration of upstream support in January 2020, support for Python 2 has now been removed; it is recommended that you use Python 3 instead. If absolutely needed there is a meta-python2 community layer containing Python 2, related classes and various Python 2-based modules, however it should not be considered as supported. + </para> + </section> + + <section id='migration-3.1-reproducible-builds'> + <title>Reproducible builds now enabled by default</title> + + <para> + In order to avoid unnecessary differences in output files (aiding binary reproducibility), the Poky distribution configuration (<filename><link linkend='var-DISTRO'>DISTRO</link> = "poky"</filename>) now inherits the <filename>reproducible_build</filename> class by default. + </para> + </section> + + <section id='migration-3.1-ptest-feature-impact'> + <title>Impact of ptest feature is now more significant</title> + + <para> + The Poky distribution configuration (<filename><link linkend='var-DISTRO'>DISTRO</link> = "poky"</filename>) enables ptests by default to enable runtime testing of various components. In this release, a dependency needed to be added that has resulted in a significant increase in the number of components that will be built just when building a simple image such as core-image-minimal. If you do not need runtime tests enabled for core components, then it is recommended that you remove "ptest" from <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link> to save a significant amount of build time e.g. by adding the following in your configuration: + + <literallayout class='monospaced'> + DISTRO_FEATURES_remove = "ptest" + </literallayout> + </para> + </section> + + <section id='migration-3.1-removed-recipes'> + <title>Removed recipes</title> + + <para> + The following recipes have been removed: + + <itemizedlist> + <listitem><para><filename>chkconfig</filename>: obsolete</para></listitem> + <listitem><para><filename>console-tools</filename>: obsolete</para></listitem> + <listitem><para><filename>enchant</filename>: replaced by <filename>enchant2</filename></para></listitem> + <listitem><para><filename>foomatic-filters</filename>: obsolete</para></listitem> + <listitem><para><filename>libidn</filename>: no longer needed, moved to meta-oe</para></listitem> + <listitem><para><filename>libmodulemd</filename>: replaced by <filename>libmodulemd-v1</filename></para></listitem> + <listitem><para><filename>linux-yocto</filename>: drop 4.19, 5.2 version recipes (5.4 now provided)</para></listitem> + <listitem><para><filename>nspr</filename>: no longer needed, moved to meta-oe</para></listitem> + <listitem><para><filename>nss</filename>: no longer needed, moved to meta-oe</para></listitem> + <listitem><para><filename>python</filename>: Python 2 removed (Python 3 preferred)</para></listitem> + <listitem><para><filename>python-setuptools</filename>: Python 2 version removed (python3-setuptools preferred)</para></listitem> + <listitem><para><filename>sysprof</filename>: no longer needed, moved to meta-oe</para></listitem> + <listitem><para><filename>texi2html</filename>: obsolete</para></listitem> + <listitem><para><filename>u-boot-fw-utils</filename>: functionally replaced by <filename>libubootenv</filename></para></listitem> + </itemizedlist> + </para> + </section> + + <section id='migration-3.1-features-check'> + <title>features_check class replaces distro_features_check</title> + + <para> + The <filename>distro_features_check</filename> class has had its functionality expanded, now supporting <filename>ANY_OF_MACHINE_FEATURES</filename>, <filename>REQUIRED_MACHINE_FEATURES</filename>, <filename>CONFLICT_MACHINE_FEATURES</filename>, <filename>ANY_OF_COMBINED_FEATURES</filename>, <filename>REQUIRED_COMBINED_FEATURES</filename>, <filename>CONFLICT_COMBINED_FEATURES</filename>. As a result the class has now been renamed to <filename>features_check</filename>; the <filename>distro_features_check</filename> class still exists but generates a warning and redirects to the new class. In preparation for a future removal of the old class it is recommended that you update recipes currently inheriting <filename>distro_features_check</filename> to inherit <filename>features_check</filename> instead. + </para> + </section> + + <section id='migration-3.1-removed-classes'> + <title>Removed classes</title> + + <para> + The following classes have been removed: + + <itemizedlist> + <listitem><para><filename>distutils-base</filename>: moved to meta-python2</para></listitem> + <listitem><para><filename>distutils</filename>: moved to meta-python2</para></listitem> + <listitem><para><filename>libc-common</filename>: merged into the glibc recipe as nothing else used it.</para></listitem> + <listitem><para><filename>python-dir</filename>: moved to meta-python2</para></listitem> + <listitem><para><filename>pythonnative</filename>: moved to meta-python2</para></listitem> + <listitem><para><filename>setuptools</filename>: moved to meta-python2</para></listitem> + <listitem><para><filename>tinderclient</filename>: dropped as it was obsolete.</para></listitem> + </itemizedlist> + </para> + </section> + + <section id='migration-3.1-src-uri-checksums'> + <title>SRC_URI checksum behaviour</title> + + <para> + Previously, recipes by tradition included both SHA256 and MD5 checksums for remotely fetched files in <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>, even though only one is actually mandated. However, the MD5 checksum does not add much given its inherent weakness; thus when a checksum fails only the SHA256 sum will now be printed. The md5sum will still be verified if it is specified. + </para> + </section> + + + <section id='migration-3.1-npm'> + <title>npm fetcher changes</title> + + <para> + The npm fetcher has been completely reworked in this release. The npm fetcher now only fetches the package source itself and no longer the dependencies; there is now also an npmsw fetcher which explicitly fetches the shrinkwrap file and the dependencies. This removes the slightly awkward <filename>NPM_LOCKDOWN</filename> and <filename>NPM_SHRINKWRAP</filename> variables which pointed to local files; the lockdown file is no longer needed at all. Additionally, the package name in <filename>npm://</filename> entries in <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> is now specified using a <filename>package</filename> parameter instead of the earlier <filename>name</filename> which overlapped with the generic <filename>name</filename> parameter. All recipes using the npm fetcher will need to be changed as a result. + </para> + <para> + An example of the new scheme: + <literallayout class='monospaced'> +SRC_URI = "npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \ + npmsw://${THISDIR}/npm-shrinkwrap.json" + </literallayout> + Another example where the sources are fetched from git rather than an npm repository: + <literallayout class='monospaced'> +SRC_URI = "git://github.com/foo/bar.git;protocol=https \ + npmsw://${THISDIR}/npm-shrinkwrap.json" + </literallayout> + </para> + <para> + devtool and recipetool have also been updated to match with the npm fetcher changes. Other than producing working and more complete recipes for npm sources, there is also a minor change to the command line for devtool: the <filename>--fetch-dev</filename> option has been renamed to <filename>--npm-dev</filename> as it is npm-specific. + </para> + </section> + + + <section id='migration-3.1-packaging-changes'> + <title>Packaging changes</title> + + <para> + <itemizedlist> + <listitem><para><filename>intltool</filename> has been removed from <filename>packagegroup-core-sdk</filename> as it is rarely needed to build modern software - gettext can do most of the things it used to be needed for. <filename>intltool</filename> has also been removed from <filename>packagegroup-core-self-hosted</filename> as it is not needed to for standard builds.</para></listitem> + <listitem><para>git: <filename>git-am</filename>, <filename>git-difftool</filename>, <filename>git-submodule</filename>, and <filename>git-request-pull</filename> are no longer perl-based, so are now installed with the main <filename>git</filename> package instead of within <filename>git-perltools</filename>.</para></listitem> + <listitem><para>The <filename>ldconfig</filename> binary built as part of glibc has now been moved to its own <filename>ldconfig</filename> package (note no <filename>glibc-</filename> prefix). This package is in the <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> of the main <filename>glibc</filename> package if <filename>ldconfig</filename> is present in <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.</para></listitem> + <listitem><para><filename>libevent</filename> now splits each shared library into its own package (as Debian does). Since these are shared libraries and will be pulled in through the normal shared library dependency handling, there should be no impact to existing configurations other than less unnecessary libraries being installed in some cases.</para></listitem> + <listitem><para>linux-firmware now has a new package for <filename>bcm4366c</filename> and includes available NVRAM config files into the <filename>bcm43340</filename>, <filename>bcm43362</filename>, <filename>bcm43430</filename> and <filename>bcm4356-pcie</filename> packages.</para></listitem> + <listitem><para><filename>harfbuzz</filename> now splits the new <filename>libharfbuzz-subset.so</filename> library into its own package to reduce the main package size in cases where <filename>libharfbuzz-subset.so</filename> is not needed.</para></listitem> + </itemizedlist> + </para> + </section> + + <section id='migration-3.1-package-qa-warnings'> + <title>Additional warnings</title> + + <para> + Warnings will now be shown at <filename>do_package_qa</filename> time in the following circumstances: + + <itemizedlist> + <listitem><para>A recipe installs <filename>.desktop</filename> files containing <filename>MimeType</filename> keys but does not inherit the new <filename>mime-xdg</filename> class</para></listitem> + <listitem><para>A recipe installs <filename>.xml</filename> files into <filename>${datadir}/mime/packages</filename> but does not inherit the <filename>mime</filename> class</para></listitem> + </itemizedlist> + </para> + </section> + + <section id='migration-3.1-x86-live-wic'> + <title><filename>wic</filename> image type now used instead of <filename>live</filename> by default for x86</title> + + <para> + <filename>conf/machine/include/x86-base.inc</filename> (inherited by most x86 machine configurations) now specifies <filename>wic</filename> instead of <filename>live</filename> by default in <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>. The <filename>live</filename> image type will likely be removed in a future release so it is recommended that you use <filename>wic</filename> instead. + </para> + </section> + + <section id='migration-3.1-misc'> + <title>Miscellaneous changes</title> + + <para> + <itemizedlist> + <listitem><para>The undocumented <filename>SRC_DISTRIBUTE_LICENSES</filename> variable has now been removed in favour of a new <filename>AVAILABLE_LICENSES</filename> variable which is dynamically set based upon license files found in <filename>${COMMON_LICENSE_DIR}</filename> and <filename>${LICENSE_PATH}</filename>.</para></listitem> + <listitem><para>The tune definition for big-endian microblaze machines is now <filename>microblaze</filename> instead of <filename>microblazeeb</filename>.</para></listitem> + <listitem><para><filename>newlib</filename> no longer has built-in syscalls. <filename>libgloss</filename> should then provide the syscalls, <filename>crt0.o</filename> and other functions that are no longer part of <filename>newlib</filename> itself. If you are using <filename>TCLIBC = "newlib"</filename> this now means that you must link applications with both <filename>newlib</filename> and <filename>libgloss</filename>, whereas before <filename>newlib</filename> would run in many configurations by itself.</para></listitem> + </itemizedlist> + </para> + </section> + +</section> + + </chapter> <!-- vim: expandtab tw=80 ts=4 diff --git a/external/poky/documentation/ref-manual/ref-classes.xml b/external/poky/documentation/ref-manual/ref-classes.xml index d602851c..f9bbddd7 100644 --- a/external/poky/documentation/ref-manual/ref-classes.xml +++ b/external/poky/documentation/ref-manual/ref-classes.xml @@ -318,35 +318,6 @@ </para> </section> -<section id='ref-classes-bluetooth'> - <title><filename>bluetooth.bbclass</filename></title> - - <para> - The <filename>bluetooth</filename> class defines a variable that - expands to the recipe (package) providing core - bluetooth support on the platform. - </para> - - <para> - For details on how the class works, see the - <filename>meta/classes/bluetooth.bbclass</filename> file in the Yocto - Project - <link linkend='source-directory'>Source Directory</link>. - </para> -</section> - -<section id='ref-classes-bugzilla'> - <title><filename>bugzilla.bbclass</filename></title> - - <para> - The <filename>bugzilla</filename> class supports setting up an - instance of Bugzilla in which you can automatically files bug reports - in response to build failures. - For this class to work, you need to enable the XML-RPC interface in - the instance of Bugzilla. - </para> -</section> - <section id='ref-classes-buildhistory'> <title><filename>buildhistory.bbclass</filename></title> @@ -457,6 +428,14 @@ variable to specify additional configuration options to be passed using the <filename>cmake</filename> command line. </para> + + <para> + On the occasion that you would be installing custom CMake toolchain + files supplied by the application being built, you should install them + to the preferred CMake Module directory: + <filename>${D}${datadir}/cmake/</filename> Modules during + <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>. + </para> </section> <section id='ref-classes-cml1'> @@ -714,39 +693,6 @@ </para> </section> -<section id='ref-classes-distrodata'> - <title><filename>distrodata.bbclass</filename></title> - - <para> - The <filename>distrodata</filename> class - provides for automatic checking for upstream recipe updates. - The class creates a comma-separated value (CSV) spreadsheet that - contains information about the recipes. - The information provides the - <link linkend='ref-tasks-distrodata'><filename>do_distrodata</filename></link> - and - <filename>do_distro_check</filename> tasks, which do upstream checking - and also verify if a package is used in multiple major distributions. - </para> - - <para> - The class is not included by default. - To use it, you must set the - <link linkend='var-INHERIT'><filename>INHERIT</filename></link> - variable: - <literallayout class='monospaced'> - INHERIT+= "distrodata" - </literallayout> - </para> - - <para> - The <filename>distrodata</filename> class also provides the - <link linkend='ref-tasks-checkpkg'><filename>do_checkpkg</filename></link> - task, which can be used against a simple recipe or against an - image to get all its recipe information. - </para> -</section> - <section id='ref-classes-distutils'> <title><filename>distutils*.bbclass</filename></title> @@ -776,11 +722,6 @@ some of the <filename>distutils*</filename> classes to provide common Python2 support. </para> - - <para> - The <filename>distutils-tools</filename> class supports recipes for - additional "distutils" tools. - </para> </section> <section id='ref-classes-distutils3'> @@ -987,21 +928,6 @@ </para> </section> -<section id='ref-classes-gnome'> - <title><filename>gnome.bbclass</filename></title> - - <para> - The <filename>gnome</filename> class supports recipes that - build software from the GNOME stack. - This class inherits the - <link linkend='ref-classes-gnomebase'><filename>gnomebase</filename></link>, - <link linkend='ref-classes-gtk-icon-cache'><filename>gtk-icon-cache</filename></link>, - <link linkend='ref-classes-gconf'><filename>gconf</filename></link> and - <link linkend='ref-classes-mime'><filename>mime</filename></link> classes. - The class also disables GObject introspection where applicable. - </para> -</section> - <section id='ref-classes-gnomebase'> <title><filename>gnomebase.bbclass</filename></title> @@ -2335,13 +2261,16 @@ This check was removed for YP 2.3 release <title><filename>npm.bbclass</filename></title> <para> - Provides support for building Node.js software fetched using the npm - package manager. + Provides support for building Node.js software fetched using the + <ulink url='https://en.wikipedia.org/wiki/Npm_(software)'>node package manager (NPM)</ulink>. <note> Currently, recipes inheriting this class must use the <filename>npm://</filename> fetcher to have dependencies fetched and packaged automatically. </note> + For information on how to create NPM packages, see the + "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-node-package-manager-npm-packages'>Creating Node Package Manager (NPM) Packages</ulink>" + section in the Yocto Project Development Tasks Manual. </para> </section> diff --git a/external/poky/documentation/ref-manual/ref-devtool-reference.xml b/external/poky/documentation/ref-manual/ref-devtool-reference.xml index b974d0f5..11f7399c 100644 --- a/external/poky/documentation/ref-manual/ref-devtool-reference.xml +++ b/external/poky/documentation/ref-manual/ref-devtool-reference.xml @@ -34,7 +34,7 @@ You can run <filename>devtool --help</filename> to see all the commands: <literallayout class='monospaced'> - $ devtool --help + $ devtool -h NOTE: Starting bitbake server... usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q] [--color COLOR] [-h] @@ -43,50 +43,48 @@ OpenEmbedded development tool options: - --basepath BASEPATH Base directory of SDK / build directory - --bbpath BBPATH Explicitly specify the BBPATH, rather than getting it - from the metadata - -d, --debug Enable debug output - -q, --quiet Print only errors - --color COLOR Colorize output (where COLOR is auto, always, never) - -h, --help show this help message and exit + --basepath BASEPATH Base directory of SDK / build directory + --bbpath BBPATH Explicitly specify the BBPATH, rather than getting it + from the metadata + -d, --debug Enable debug output + -q, --quiet Print only errors + --color COLOR Colorize output (where COLOR is auto, always, never) + -h, --help show this help message and exit subcommands: Beginning work on a recipe: - add Add a new recipe - modify Modify the source for an existing recipe - upgrade Upgrade an existing recipe + add Add a new recipe + modify Modify the source for an existing recipe + upgrade Upgrade an existing recipe Getting information: - status Show workspace status - search Search available recipes - latest-version Report the latest version of an existing recipe + status Show workspace status + search Search available recipes + latest-version Report the latest version of an existing recipe + check-upgrade-status Report upgradability for multiple (or all) recipes Working on a recipe in the workspace: - build Build a recipe - rename Rename a recipe file in the workspace - edit-recipe Edit a recipe file - find-recipe Find a recipe file - configure-help Get help on configure script options - update-recipe Apply changes from external source tree to recipe - reset Remove a recipe from your workspace - finish Finish working on a recipe in your workspace + build Build a recipe + rename Rename a recipe file in the workspace + edit-recipe Edit a recipe file + find-recipe Find a recipe file + configure-help Get help on configure script options + update-recipe Apply changes from external source tree to recipe + reset Remove a recipe from your workspace + finish Finish working on a recipe in your workspace Testing changes on target: - deploy-target Deploy recipe output files to live target machine - undeploy-target Undeploy recipe output files in live target machine - build-image Build image including workspace recipe packages + deploy-target Deploy recipe output files to live target machine + undeploy-target Undeploy recipe output files in live target machine + build-image Build image including workspace recipe packages Advanced: - create-workspace Set up workspace in an alternative location - export Export workspace into a tar archive - import Import exported tar archive into workspace - extract Extract the source for an existing recipe - sync Synchronize the source tree for an existing recipe + create-workspace Set up workspace in an alternative location + export Export workspace into a tar archive + import Import exported tar archive into workspace + extract Extract the source for an existing recipe + sync Synchronize the source tree for an existing recipe Use devtool <subcommand> --help to get help on a specific command </literallayout> - </para> - - <para> - As directed in the general help output, you can get more - syntax on a specific command by providing the command - name and using <filename>--help</filename>: + As directed in the general help output, you can get more syntax + on a specific command by providing the command name and using + "--help": <literallayout class='monospaced'> $ devtool add --help NOTE: Starting bitbake server... @@ -429,6 +427,108 @@ </para> </section> + <section id='devtool-checking-on-the-upgrade-status-of-a-recipe'> + <title>Checking on the Upgrade Status of a Recipe</title> + + <para> + Upstream recipes change over time. + Consequently, you might find that you need to determine if you + can upgrade a recipe to a newer version. + </para> + + <para> + To check on the upgrade status of a recipe, use the + <filename>devtool check-upgrade-status</filename> command. + The command displays a table of your current recipe versions, + the latest upstream versions, the email address of the recipe's + maintainer, and any additional information such as commit hash + strings and reasons you might not be able to upgrade a particular + recipe. + <note><title>NOTES:</title> + <itemizedlist> + <listitem><para> + For the <filename>oe-core</filename> layer, recipe + maintainers come from the + <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc'><filename>maintainers.inc</filename></ulink> + file. + </para></listitem> + <listitem><para> + If the recipe is using the + <ulink url='&YOCTO_DOCS_BB_URL;#git-fetcher'>Git fetcher</ulink> + rather than a tarball, the commit hash points to the + commit that matches the recipe's latest version tag. + </para></listitem> + </itemizedlist> + </note> + </para> + + <para> + As with all <filename>devtool</filename> commands, you can get + help on the individual command: + <literallayout class='monospaced'> + $ devtool check-upgrade-status -h + NOTE: Starting bitbake server... + usage: devtool check-upgrade-status [-h] [--all] [recipe [recipe ...]] + + Prints a table of recipes together with versions currently provided by + recipes, and latest upstream versions, when there is a later version available + + arguments: + recipe Name of the recipe to report (omit to report upgrade info for + all recipes) + + options: + -h, --help show this help message and exit + --all, -a Show all recipes, not just recipes needing upgrade + </literallayout> + </para> + + <para> + Unless you provide a specific recipe name on the command line, + the command checks all recipes in all configured layers. + </para> + + <para> + Following is a partial example table that reports on all the + recipes. + Notice the reported reason for not upgrading the + <filename>base-passwd</filename> recipe. + In this example, while a new version is available upstream, + you do not want to use it because the dependency on + <filename>cdebconf</filename> is not easily satisfied. + <note> + When a reason for not upgrading displays, the reason is + usually written into the recipe using the + <filename>RECIPE_NO_UPDATE_REASON</filename> variable. + See the + <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb'><filename>base-passwd.bb</filename></ulink> + recipe for an example. + </note> + <literallayout class='monospaced'> + $ devtool check-upgrade-status + ... + NOTE: acpid 2.0.30 2.0.31 + Ross Burton <ross.burton@intel.com> + NOTE: u-boot-fw-utils 2018.11 2019.01 + Marek Vasut <marek.vasut@gmail.com> + d3689267f92c5956e09cc7d1baa4700141662bff + NOTE: u-boot-tools 2018.11 2019.01 + Marek Vasut <marek.vasut@gmail.com> + d3689267f92c5956e09cc7d1baa4700141662bff + . + . + . + NOTE: base-passwd 3.5.29 3.5.45 + Anuj Mittal <anuj.mittal@intel.com> cannot be updated due to: Version + 3.5.38 requires cdebconf for update-passwd utility + NOTE: busybox 1.29.2 1.30.0 + Andrej Valek <andrej.valek@siemens.com> + NOTE: dbus-test 1.12.10 1.12.12 + Chen Qi <Qi.Chen@windriver.com> + </literallayout> + </para> + </section> + <section id='devtool-upgrading-a-recipe'> <title>Upgrading a Recipe</title> @@ -443,6 +543,13 @@ section of the Yocto Project Development Tasks Manual. This section overviews the <filename>devtool upgrade</filename> command. + <note> + Before you upgrade a recipe, you can check on its upgrade + status. + See the + "<link linkend='devtool-checking-on-the-upgrade-status-of-a-recipe'>Checking on the Upgrade Status of a Recipe</link>" + for more information. + </note> </para> <para> @@ -522,18 +629,18 @@ <title>Building Your Recipe</title> <para> - Use the <filename>devtool build</filename> command to cause the - OpenEmbedded build system to build your recipe. + Use the <filename>devtool build</filename> command to build your + recipe. The <filename>devtool build</filename> command is equivalent to - <filename>bitbake -c populate_sysroot</filename>. + the <filename>bitbake -c populate_sysroot</filename> command. </para> <para> When you use the <filename>devtool build</filename> command, - you must supply the root name of the recipe (i.e. no version, - paths, or extensions). + you must supply the root name of the recipe (i.e. do not provide + versions, paths, or extensions). You can use either the "-s" or the "--disable-parallel-make" - option to disable parallel makes during the build. + options to disable parallel makes during the build. Here is an example: <literallayout class='monospaced'> $ devtool build <replaceable>recipe</replaceable> diff --git a/external/poky/documentation/ref-manual/ref-features.xml b/external/poky/documentation/ref-manual/ref-features.xml index cb74df6d..294b297c 100644 --- a/external/poky/documentation/ref-manual/ref-features.xml +++ b/external/poky/documentation/ref-manual/ref-features.xml @@ -76,8 +76,6 @@ </para></listitem> <listitem><para><emphasis>ext2:</emphasis> Hardware HDD or Microdrive </para></listitem> - <listitem><para><emphasis>irda:</emphasis> Hardware has IrDA support - </para></listitem> <listitem><para><emphasis>keyboard:</emphasis> Hardware has a keyboard </para></listitem> <listitem><para><emphasis>pcbios:</emphasis> Support for booting through BIOS @@ -156,27 +154,6 @@ </para></listitem> <listitem><para><emphasis>bluetooth:</emphasis> Include bluetooth support (integrated BT only).</para></listitem> - <listitem><para><emphasis>bluez5:</emphasis> Include - BlueZ Version 5, which provides core Bluetooth layers and - protocols support. - <note> - The default value for the - <filename>DISTRO FEATURES</filename> variable includes - "bluetooth", which causes bluez5 to be backfilled in - for bluetooth support. - If you do not want bluez5 backfilled and would rather - use bluez4, you need to use the - <link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></link> - variable as follows: - <literallayout class='monospaced'> - DISTRO_FEATURES_BACKFILL_CONSIDERED = "bluez5" - </literallayout> - Setting this variable tells the OpenEmbedded build - system that you have considered but ruled - out using the bluez5 feature and that bluez4 will be - used. - </note> - </para></listitem> <listitem><para><emphasis>cramfs:</emphasis> Include CramFS support.</para></listitem> <listitem><para><emphasis>directfb:</emphasis> @@ -190,8 +167,6 @@ support.</para></listitem> <listitem><para><emphasis>ipv6:</emphasis> Include IPv6 support. </para></listitem> - <listitem><para><emphasis>irda:</emphasis> Include IrDA support. - </para></listitem> <listitem><para><emphasis>keyboard:</emphasis> Include keyboard support (e.g. keymaps will be loaded during boot). </para></listitem> @@ -235,6 +210,12 @@ <listitem><para><emphasis>usbhost:</emphasis> Include USB Host support (allows to connect external keyboard, mouse, storage, network etc).</para></listitem> + <listitem><para><emphasis>usrmerge:</emphasis> Merges the + <filename>/bin</filename>, <filename>/sbin</filename>, + <filename>/lib</filename>, and <filename>/lib64</filename> + directories into their respective counterparts in the + <filename>/usr</filename> directory to provide better package + and application compatibility.</para></listitem> <listitem><para><emphasis>wayland:</emphasis> Include the Wayland display server protocol and the library that supports it.</para></listitem> @@ -342,9 +323,6 @@ class. The current list of these valid features is as follows: <itemizedlist> - <listitem><para><emphasis>eclipse-debug:</emphasis> Provides - Eclipse remote debugging support. - </para></listitem> <listitem><para><emphasis>hwcodecs:</emphasis> Installs hardware acceleration codecs. </para></listitem> diff --git a/external/poky/documentation/ref-manual/ref-kickstart.xml b/external/poky/documentation/ref-manual/ref-kickstart.xml index a58f9d7c..1128bd50 100644 --- a/external/poky/documentation/ref-manual/ref-kickstart.xml +++ b/external/poky/documentation/ref-manual/ref-kickstart.xml @@ -117,9 +117,9 @@ This option is a Wic-specific option that names the source of the data that populates the partition. The most common value for this option is "rootfs", but you - can use any value that maps to a valid source plug-in. - For information on the source plug-ins, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#wic-using-the-wic-plug-ins-interface'>Using the Wic Plug-Ins Interface</ulink>" + can use any value that maps to a valid source plugin. + For information on the source plugins, see the + "<ulink url='&YOCTO_DOCS_DEV_URL;#wic-using-the-wic-plugin-interface'>Using the Wic Plugins Interface</ulink>" section in the Yocto Project Development Tasks Manual. </para> @@ -139,12 +139,12 @@ <filename>--source <replaceable>plugin-name</replaceable></filename>, Wic creates a partition as large as needed and fills it with the contents of the partition that is generated by the - specified plug-in name using the data pointed to by the + specified plugin name using the data pointed to by the <filename>-r</filename> command-line option or the equivalent rootfs derived from the <filename>-e</filename> command-line option. Exactly what those contents are and filesystem type used are - dependent on the given plug-in implementation. + dependent on the given plugin implementation. </para> <para>If you do not use the <filename>--source</filename> @@ -220,7 +220,7 @@ This option is a Wic-specific option that excludes the given relative path from the resulting image. This option is only effective with the rootfs source - plug-in. + plugin. </para></listitem> <listitem><para> <emphasis><filename>--extra-space</filename>:</emphasis> @@ -299,7 +299,7 @@ supports the following options: <note> Bootloader functionality and boot partitions are implemented by - the various <filename>--source</filename> plug-ins that + the various <filename>--source</filename> plugins that implement bootloader functionality. The bootloader command essentially provides a means of modifying bootloader configuration. diff --git a/external/poky/documentation/ref-manual/ref-manual-eclipse-customization.xsl b/external/poky/documentation/ref-manual/ref-manual-eclipse-customization.xsl deleted file mode 100644 index f3b75215..00000000 --- a/external/poky/documentation/ref-manual/ref-manual-eclipse-customization.xsl +++ /dev/null @@ -1,35 +0,0 @@ -<?xml version='1.0'?> -<xsl:stylesheet - xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - xmlns="http://www.w3.org/1999/xhtml" - xmlns:fo="http://www.w3.org/1999/XSL/Format" - version="1.0"> - - <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - -<!-- - - <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - - <xsl:import - href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" /> - ---> - - <xsl:param name="chunker.output.indent" select="'yes'"/> - <xsl:param name="chunk.quietly" select="1"/> - <xsl:param name="chunk.first.sections" select="1"/> - <xsl:param name="chunk.section.depth" select="10"/> - <xsl:param name="use.id.as.filename" select="1"/> - <xsl:param name="ulink.target" select="'_self'" /> - <xsl:param name="base.dir" select="'html/ref-manual/'"/> - <xsl:param name="html.stylesheet" select="'../book.css'"/> - <xsl:param name="eclipse.manifest" select="0"/> - <xsl:param name="create.plugin.xml" select="0"/> - <xsl:param name="suppress.navigation" select="1"/> - <xsl:param name="generate.index" select="0"/> - <xsl:param name="chapter.autolabel" select="1" /> - <xsl:param name="appendix.autolabel">A</xsl:param> - <xsl:param name="section.autolabel" select="1" /> - <xsl:param name="section.label.includes.component.label" select="1" /> -</xsl:stylesheet> diff --git a/external/poky/documentation/ref-manual/ref-manual.xml b/external/poky/documentation/ref-manual/ref-manual.xml index 104bbb9e..d7b82bb5 100644..100755 --- a/external/poky/documentation/ref-manual/ref-manual.xml +++ b/external/poky/documentation/ref-manual/ref-manual.xml @@ -22,11 +22,10 @@ <authorgroup> <author> - <firstname>Scott</firstname> <surname>Rifenbark</surname> <affiliation> - <orgname>Scotty's Documentation Services, INC</orgname> + <orgname>&ORGNAME;</orgname> </affiliation> - <email>srifenbark@gmail.com</email> + <email>&ORGEMAIL;</email> </author> </authorgroup> @@ -34,22 +33,17 @@ <revhistory> <revision> <revnumber>4.0+git</revnumber> - <date>24 November 2010</date> - <revremark>Released with the Yocto Project 0.9 Release</revremark> + <date>November 2010</date> + <revremark>The initial document released with the Yocto Project 0.9 Release</revremark> </revision> <revision> <revnumber>1.0</revnumber> - <date>6 April 2011</date> + <date>April 2011</date> <revremark>Released with the Yocto Project 1.0 Release.</revremark> </revision> <revision> - <revnumber>1.0.1</revnumber> - <date>23 May 2011</date> - <revremark>Released with the Yocto Project 1.0.1 Release.</revremark> - </revision> - <revision> <revnumber>1.1</revnumber> - <date>6 October 2011</date> + <date>October 2011</date> <revremark>Released with the Yocto Project 1.1 Release.</revremark> </revision> <revision> @@ -73,11 +67,6 @@ <revremark>Released with the Yocto Project 1.5 Release.</revremark> </revision> <revision> - <revnumber>1.5.1</revnumber> - <date>January 2014</date> - <revremark>Released with the Yocto Project 1.5.1 Release.</revremark> - </revision> - <revision> <revnumber>1.6</revnumber> <date>April 2014</date> <revremark>Released with the Yocto Project 1.6 Release.</revremark> @@ -128,24 +117,29 @@ <revremark>Released with the Yocto Project 2.6 Release.</revremark> </revision> <revision> - <revnumber>2.6.1</revnumber> - <date>February 2019</date> - <revremark>Released with the Yocto Project 2.6.1 Release.</revremark> + <revnumber>2.7</revnumber> + <date>May 2019</date> + <revremark>Released with the Yocto Project 2.7 Release.</revremark> </revision> <revision> - <revnumber>2.6.2</revnumber> - <date>April 2019</date> - <revremark>Released with the Yocto Project 2.6.2 Release.</revremark> + <revnumber>3.0</revnumber> + <date>October 2019</date> + <revremark>Released with the Yocto Project 3.0 Release.</revremark> </revision> <revision> - <revnumber>2.6.3</revnumber> - <date>August 2019</date> - <revremark>Released with the Yocto Project 2.6.3 Release.</revremark> + <revnumber>3.1</revnumber> + <date>April 2020</date> + <revremark>Released with the Yocto Project 3.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.4</revnumber> - <date>November 2019</date> - <revremark>Released with the Yocto Project 2.6.4 Release.</revremark> + <revnumber>3.1.1</revnumber> + <date>June 2020</date> + <revremark>Released with the Yocto Project 3.1.1 Release.</revremark> + </revision> + <revision> + <revnumber>3.1.2</revnumber> + <date>&REL_MONTH_YEAR;</date> + <revremark>Released with the Yocto Project 3.1.2 Release.</revremark> </revision> </revhistory> @@ -168,7 +162,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -185,18 +179,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. </para></listitem> - <listitem><para> + <listitem> + <para> To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - <filename>yocto@yoctoproject.com</filename> or log into - the freenode <filename>#yocto</filename> channel. - </para></listitem> + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + <filename>docs@lists.yoctoproject.org</filename> or + log into the freenode <filename>#yocto</filename> channel. + </para> + </listitem> </itemizedlist> </note> </legalnotice> diff --git a/external/poky/documentation/ref-manual/ref-structure.xml b/external/poky/documentation/ref-manual/ref-structure.xml index 8e0c9f5b..27f17dd9 100644 --- a/external/poky/documentation/ref-manual/ref-structure.xml +++ b/external/poky/documentation/ref-manual/ref-structure.xml @@ -8,11 +8,11 @@ <para> The <link linkend='source-directory'>Source Directory</link> - consists of several components. - Understanding them and knowing where they are located is key to using the - Yocto Project well. + consists of numerous files, directories and subdirectories; + understanding their locations and contents is key to using the + Yocto Project effectively. This chapter describes the Source Directory and gives information about - the various files and directories. + those files and directories. </para> <para> @@ -22,12 +22,12 @@ section in the Yocto Project Development Tasks Manual. </para> -<note> - The OpenEmbedded build system does not support file or directory names that - contain spaces. - Be sure that the Source Directory you use does not contain these types - of names. -</note> + <note> + The OpenEmbedded build system does not support file or directory names that + contain spaces. + Be sure that the Source Directory you use does not contain these types + of names. + </note> <section id='structure-core'> <title>Top-Level Core Components</title> @@ -48,18 +48,18 @@ <link linkend='metadata'>Metadata</link> interpreter, reads the Yocto Project Metadata and runs the tasks defined by that data. - Failures are usually from the Metadata and not from BitBake itself. - Consequently, most users do not need to worry about BitBake. + Failures are usually caused by errors in your Metadata and not from BitBake itself; + consequently, most users do not need to worry about BitBake. </para> <para> When you run the <filename>bitbake</filename> command, the - main BitBake executable, which resides in the - <filename>bitbake/bin/</filename> directory, starts. + main BitBake executable (which resides in the + <filename>bitbake/bin/</filename> directory) starts. Sourcing the environment setup script (i.e. <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>) - places the <filename>scripts</filename> and - <filename>bitbake/bin</filename> directories (in that order) into + places the <filename>scripts/</filename> and + <filename>bitbake/bin/</filename> directories (in that order) into the shell's <filename>PATH</filename> environment variable. </para> @@ -91,7 +91,7 @@ by providing a directory name when you <filename>source</filename> the setup script. For information on separating output from your local - Source Directory files, see the + Source Directory files (commonly described as an "out of tree" build), see the "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>" section. </para> @@ -104,8 +104,8 @@ This directory holds the source for the Yocto Project documentation as well as templates and tools that allow you to generate PDF and HTML versions of the manuals. - Each manual is contained in a sub-folder. - For example, the files for this manual reside in + Each manual is contained in its own sub-folder; + for example, the files for this reference manual reside in the <filename>ref-manual/</filename> directory. </para> </section> @@ -114,9 +114,9 @@ <title><filename>meta/</filename></title> <para> - This directory contains the OpenEmbedded-Core metadata. + This directory contains the minimal, underlying OpenEmbedded-Core metadata. The directory holds recipes, common classes, and machine - configuration for emulated targets (<filename>qemux86</filename>, + configuration for strictly emulated targets (<filename>qemux86</filename>, <filename>qemuarm</filename>, and so forth.) </para> </section> @@ -125,8 +125,8 @@ <title><filename>meta-poky/</filename></title> <para> - This directory contains the configuration for the Poky - reference distribution. + Designed above the <filename>meta/</filename> content, this directory + adds just enough metadata to define the Poky reference distribution. </para> </section> @@ -148,9 +148,6 @@ This directory adds additional recipes and append files used by the OpenEmbedded selftests to verify the behavior of the build system. - </para> - - <para> You do not have to add this layer to your <filename>bblayers.conf</filename> file unless you want to run the selftests. @@ -172,7 +169,7 @@ This directory contains various integration scripts that implement extra functionality in the Yocto Project environment (e.g. QEMU scripts). The <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link> - script appends this directory to the shell's + script prepends this directory to the shell's <filename>PATH</filename> environment variable. </para> @@ -202,7 +199,8 @@ up, a <link linkend='build-directory'>Build Directory</link> is created, your working directory becomes the Build Directory, - and you are presented with a list of common BitBake targets. + and you are presented with some simple suggestions as to what to do + next, including a list of some possible targets to build. Here is an example: <literallayout class='monospaced'> $ source oe-init-build-env @@ -217,14 +215,14 @@ meta-toolchain meta-ide-support - You can also run generated qemu images with a command like 'runqemu qemux86' + You can also run generated qemu images with a command like 'runqemu qemux86-64' </literallayout> - The script gets its default list of common targets from the - <filename>conf-notes.txt</filename> file, which is found in the + The default output of the <filename>oe-init-build-env</filename> script + is from the <filename>conf-notes.txt</filename> file, which is found in the <filename>meta-poky</filename> directory within the <link linkend='source-directory'>Source Directory</link>. - Should you have custom distributions, it is very easy to modify - this configuration file to include your targets for your + If you design a custom distribution, you can include your own version + of this configuration file to mention the targets defined by your distribution. See the "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>" @@ -234,20 +232,20 @@ <para> By default, running this script without a Build Directory - argument creates the <filename>build</filename> directory + argument creates the <filename>build/</filename> directory in your current working directory. If you provide a Build Directory argument when you <filename>source</filename> the script, you direct the OpenEmbedded build system to create a Build Directory of your choice. For example, the following command creates a Build Directory named - <filename>mybuilds</filename> that is outside of the + <filename>mybuilds/</filename> that is outside of the <link linkend='source-directory'>Source Directory</link>: <literallayout class='monospaced'> $ source &OE_INIT_FILE; ~/mybuilds </literallayout> The OpenEmbedded build system uses the template configuration files, which are found by default in the - <filename>meta-poky/conf</filename> directory in the + <filename>meta-poky/conf/</filename> directory in the Source Directory. See the "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>" @@ -280,28 +278,26 @@ <para> The OpenEmbedded build system creates the <link linkend='build-directory'>Build Directory</link> - when you run the build environment setup scripts (i.e. - <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>). - </para> - - <para> + when you run the build environment setup script + <link +linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>. If you do not give the Build Directory a specific name when you run - a setup script, the name defaults to <filename>build</filename>. + the setup script, the name defaults to <filename>build/</filename>. </para> <para> - The - <link linkend='var-TOPDIR'><filename>TOPDIR</filename></link> variable - points to the Build Directory. + For subsequent parsing and processing, the name of the Build + directory is available via the + <link linkend='var-TOPDIR'><filename>TOPDIR</filename></link> variable. </para> <section id='structure-build-buildhistory'> - <title><filename>build/buildhistory</filename></title> + <title><filename>build/buildhistory/</filename></title> <para> The OpenEmbedded build system creates this directory when you - enable the build history feature. - The directory tracks build information into image, packages, and + enable build history via the <filename>buildhistory</filename> class file. + The directory organizes build information into image, packages, and SDK subdirectories. For information on the build history feature, see the "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality'>Maintaining Build Output Quality</ulink>" @@ -320,14 +316,14 @@ Any variable set here overrides any variable set elsewhere within the environment unless that variable is hard-coded within a file (e.g. by using '=' instead of '?='). - Some variables are hard-coded for various reasons but these + Some variables are hard-coded for various reasons but such variables are relatively rare. </para> <para> - Edit this file to set the - <filename><link linkend='var-MACHINE'>MACHINE</link></filename> - for which you want to build, which package types you wish to use + At a minimum, you would normally edit this file to select the target + <filename><link linkend='var-MACHINE'>MACHINE</link></filename>, + which package types you wish to use (<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>), and the location from which you want to access downloaded files (<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>). @@ -338,16 +334,16 @@ start the build, the OpenEmbedded build system creates it from <filename>local.conf.sample</filename> when you <filename>source</filename> the top-level build environment - setup script (i.e. - <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>). + setup script + <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>. </para> <para> The source <filename>local.conf.sample</filename> file used depends on the <filename>$TEMPLATECONF</filename> script variable, - which defaults to <filename>meta-poky/conf</filename> + which defaults to <filename>meta-poky/conf/</filename> when you are building from the Yocto Project development - environment and defaults to <filename>meta/conf</filename> when + environment, and to <filename>meta/conf/</filename> when you are building from the OpenEmbedded-Core environment. Because the script variable points to the source of the <filename>local.conf.sample</filename> file, this implies that @@ -395,11 +391,12 @@ </para> <para> - The source <filename>bblayers.conf.sample</filename> file used + As with the <filename>local.conf</filename> file, + the source <filename>bblayers.conf.sample</filename> file used depends on the <filename>$TEMPLATECONF</filename> script variable, - which defaults to <filename>meta-poky/conf</filename> + which defaults to <filename>meta-poky/conf/</filename> when you are building from the Yocto Project development - environment and defaults to <filename>meta/conf</filename> when + environment, and to <filename>meta/conf/</filename> when you are building from the OpenEmbedded-Core environment. Because the script variable points to the source of the <filename>bblayers.conf.sample</filename> file, this implies that @@ -418,13 +415,13 @@ <link linkend='source-directory'>Source Directory</link>. You can find the Yocto Project version of the <filename>bblayers.conf.sample</filename> file in the - <filename>meta-poky/conf</filename> directory. + <filename>meta-poky/conf/</filename> directory. </note> </para> </section> <section id='structure-build-conf-sanity_info'> - <title><filename>build/conf/sanity_info</filename></title> + <title><filename>build/cache/sanity_info</filename></title> <para> This file indicates the state of the sanity checks and is created @@ -572,8 +569,11 @@ <title><filename>build/tmp/deploy/images/</filename></title> <para> - This directory receives complete filesystem images. - If you want to flash the resulting image from a build onto a device, look here for the image. + This directory is populated with the basic output objects of the + build (think of them as the "generated artifacts" of the build process), + including things like the boot loader image, kernel, root filesystem and more. + If you want to flash the resulting image from a build onto a device, + look here for the necessary components. </para> <para> @@ -604,7 +604,7 @@ <para> The OpenEmbedded build system creates this directory to hold - toolchain installer scripts, which when executed, install the + toolchain installer scripts which, when executed, install the sysroot that matches your target hardware. You can find out more about these installers in the "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>" @@ -1038,7 +1038,7 @@ <title><filename>meta/recipes-graphics/</filename></title> <para> - This directory contains X and other graphically related system libraries + This directory contains X and other graphically related system libraries. </para> </section> diff --git a/external/poky/documentation/ref-manual/ref-system-requirements.xml b/external/poky/documentation/ref-manual/ref-system-requirements.xml index 0db84e31..c6e1eb97 100644 --- a/external/poky/documentation/ref-manual/ref-system-requirements.xml +++ b/external/poky/documentation/ref-manual/ref-system-requirements.xml @@ -8,12 +8,12 @@ <para> Welcome to the Yocto Project Reference Manual! This manual provides reference information for the current release - of the Yocto Project. - The manual is best used after you have an understanding + of the Yocto Project, and + is most effectively used after you have an understanding of the basics of the Yocto Project. The manual is neither meant to be read as a starting point to the - Yocto Project nor read from start to finish. - Use this manual to find variable definitions, class + Yocto Project, nor read from start to finish. + Rather, use this manual to find variable definitions, class descriptions, and so forth as needed during the course of using the Yocto Project. </para> @@ -66,12 +66,15 @@ below. </para></listitem> <listitem><para> - The Yocto Project is not compatible with the - <ulink url='https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux'>Windows Subsystem for Linux</ulink> - (WSL). - You cannot use a - <link linkend='hardware-build-system-term'>build host</link> - that is running WSL. + You may use Windows Subsystem For Linux v2 to set up a build + host using Windows 10, but validation is not performed + against build hosts using WSLv2. + <note> + The Yocto Project is not compatible with WSLv1, it is + compatible but not officially supported nor validated + with WSLv2, if you still decide to use WSL please upgrade + to WSLv2. + </note> </para></listitem> <listitem><para> If you encounter problems, please go to @@ -89,69 +92,21 @@ </note> <itemizedlist> <listitem><para>Ubuntu 16.04 (LTS)</para></listitem> - <listitem><para>Ubuntu 18.04</para></listitem> + <listitem><para>Ubuntu 18.04 (LTS)</para></listitem> + <listitem><para>Ubuntu 19.04</para></listitem> + <listitem><para>Ubuntu 20.04</para></listitem> <listitem><para>Fedora 28</para></listitem> + <listitem><para>Fedora 29</para></listitem> + <listitem><para>Fedora 30</para></listitem> + <listitem><para>Fedora 31</para></listitem> + <listitem><para>Fedora 32</para></listitem> <listitem><para>CentOS 7.x</para></listitem> <listitem><para>Debian GNU/Linux 8.x (Jessie)</para></listitem> <listitem><para>Debian GNU/Linux 9.x (Stretch)</para></listitem> - <listitem><para>OpenSUSE 42.3</para></listitem> + <listitem><para>Debian GNU/Linux 10.x (Buster)</para></listitem> + <listitem><para>OpenSUSE Leap 15.1</para></listitem> </itemizedlist> </para> -<!-- -Checkout the poky distro you are interested in (by branch or tag). -From the poky directory, run the script: - -bitbake -e | grep ^SANITY_TESTED_DISTROS | sed -e 's/.*"\(.*\)".*/\1/g' -e 's!\\n!\n!g' | sed 's/^[\t]*//;s/[ \t]*$//' | grep -v Poky - -This returns a list of the supported distros for the release. - -Here is some old list items to show the form: - - - <listitem><para>Ubuntu 10.04</para></listitem> - <listitem><para>Ubuntu 11.10</para></listitem> - <listitem><para>Ubuntu 12.04 (LTS)</para></listitem> - <listitem><para>Ubuntu 13.10</para></listitem> - <listitem><para>Ubuntu 14.04 (LTS)</para></listitem> - <listitem><para>Ubuntu 14.10</para></listitem> - <listitem><para>Ubuntu 15.04</para></listitem> - <listitem><para>Ubuntu 15.10</para></listitem> - <listitem><para>Ubuntu 16.04 (LTS)</para></listitem> - <listitem><para>Ubuntu 16.10 (LTS)</para></listitem> - <listitem><para>Ubuntu 17.04</para></listitem> - <listitem><para>Fedora 16 (Verne)</para></listitem> - <listitem><para>Fedora 17 (Spherical)</para></listitem> - <listitem><para>Fedora 19 (Schrödinger's Cat)</para></listitem> - <listitem><para>Fedora release 20 (Heisenbug)</para></listitem> - <listitem><para>Fedora release 22</para></listitem> - <listitem><para>Fedora release 23</para></listitem> - <listitem><para>Fedora release 24</para></listitem> - <listitem><para>Fedora release 26</para></listitem> - <listitem><para>CentOS release 5.6 (Final)</para></listitem> - <listitem><para>CentOS release 5.7 (Final)</para></listitem> - <listitem><para>CentOS release 5.8 (Final)</para></listitem> - <listitem><para>CentOS release 6.3 (Final)</para></listitem> - <listitem><para>CentOS release 6.x</para></listitem> - <listitem><para>CentOS release 7.x</para></listitem> - <listitem><para>Debian GNU/Linux 6.0 (Squeeze)</para></listitem> - <listitem><para>Debian GNU/Linux 7.x (Wheezy)</para></listitem> - <listitem><para>Debian GNU/Linux 8.x (Jessie)</para></listitem> - <listitem><para>Debian GNU/Linux 9.x (Stretch)</para></listitem> - <listitem><para>Debian GNU/Linux 7.1 (Wheezy)</para></listitem> - <listitem><para>Debian GNU/Linux 7.2 (Wheezy)</para></listitem> - <listitem><para>Debian GNU/Linux 7.3 (Wheezy)</para></listitem> - <listitem><para>Debian GNU/Linux 7.4 (Wheezy)</para></listitem> - <listitem><para>Debian GNU/Linux 7.5 (Wheezy)</para></listitem> - <listitem><para>Debian GNU/Linux 7.6 (Wheezy)</para></listitem> - <listitem><para>openSUSE 11.4</para></listitem> - <listitem><para>openSUSE 12.1</para></listitem> - <listitem><para>openSUSE 12.2</para></listitem> - <listitem><para>openSUSE 12.3</para></listitem> - <listitem><para>openSUSE 13.1</para></listitem> - <listitem><para>openSUSE 13.2</para></listitem> - <listitem><para>openSUSE 42.1</para></listitem> - <listitem><para>openSUSE 42.2</para></listitem> ---> <note> While the Yocto Project Team attempts to ensure all Yocto Project @@ -168,7 +123,7 @@ Here is some old list items to show the form: <para> The list of packages you need on the host development system can be large when covering all build scenarios using the Yocto Project. - This section provides required packages according to + This section describes required packages according to Linux distribution and function. </para> @@ -178,19 +133,29 @@ Here is some old list items to show the form: <para> The following list shows the required packages by function given a supported Ubuntu or Debian Linux distribution: - <note> - If your build system has the - <filename>oss4-dev</filename> package installed, you - might experience QEMU build failures due to the package - installing its own custom - <filename>/usr/include/linux/soundcard.h</filename> on - the Debian system. - If you run into this situation, either of the following - solutions exist: - <literallayout class='monospaced'> + <note><title>Notes</title> + <itemizedlist> + <listitem><para> + If your build system has the + <filename>oss4-dev</filename> package installed, you + might experience QEMU build failures due to the package + installing its own custom + <filename>/usr/include/linux/soundcard.h</filename> on + the Debian system. + If you run into this situation, either of the following + solutions exist: + <literallayout class='monospaced'> $ sudo apt-get build-dep qemu $ sudo apt-get remove oss4-dev - </literallayout> + </literallayout> + </para></listitem> + <listitem><para> + For Debian-8, <filename>python3-git</filename> and <filename>pylint3</filename> are no longer available via <filename>apt-get</filename>. + <literallayout class='monospaced'> + $ sudo pip3 install GitPython pylint==1.9.5 + </literallayout> + </para></listitem> + </itemizedlist> </note> <itemizedlist> <listitem><para><emphasis>Essentials:</emphasis> @@ -199,26 +164,12 @@ Here is some old list items to show the form: <literallayout class='monospaced'> $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; </literallayout></para></listitem> - <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis> - Packages recommended if the host system has graphics - support or if you are going to use the Eclipse - IDE: - <literallayout class='monospaced'> - $ sudo apt-get install libsdl1.2-dev xterm - </literallayout></para></listitem> <listitem><para><emphasis>Documentation:</emphasis> Packages needed if you are going to build out the Yocto Project documentation manuals: <literallayout class='monospaced'> $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto </literallayout></para></listitem> - <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis> - Packages needed if you are going to run - <filename>oe-selftest</filename>: - <literallayout class='monospaced'> - $ sudo apt-get install python-git - </literallayout> - </para></listitem> </itemizedlist> </para> </section> @@ -236,27 +187,13 @@ Here is some old list items to show the form: <literallayout class='monospaced'> $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL; </literallayout></para></listitem> - <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis> - Packages recommended if the host system has graphics - support or if you are going to use the Eclipse - IDE: - <literallayout class='monospaced'> - $ sudo dnf install SDL-devel xterm - </literallayout></para></listitem> <listitem><para><emphasis>Documentation:</emphasis> Packages needed if you are going to build out the Yocto Project documentation manuals: <literallayout class='monospaced'> - $ sudo dnf install make docbook-style-dsssl docbook-style-xsl \ + $ sudo dnf install docbook-style-dsssl docbook-style-xsl \ docbook-dtds docbook-utils fop libxslt dblatex xmlto </literallayout></para></listitem> - <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis> - Packages needed if you are going to run - <filename>oe-selftest</filename>: - <literallayout class='monospaced'> - $ sudo dnf install python3-GitPython - </literallayout> - </para></listitem> </itemizedlist> </para> </section> @@ -274,48 +211,28 @@ Here is some old list items to show the form: <literallayout class='monospaced'> $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; </literallayout></para></listitem> - <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis> - Packages recommended if the host system has graphics - support or if you are going to use the Eclipse - IDE: - <literallayout class='monospaced'> - $ sudo zypper install libSDL-devel xterm - </literallayout></para></listitem> <listitem><para><emphasis>Documentation:</emphasis> Packages needed if you are going to build out the Yocto Project documentation manuals: <literallayout class='monospaced'> - $ sudo zypper install make dblatex xmlto - </literallayout></para></listitem> - <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis> - Packages needed if you are going to run - <filename>oe-selftest</filename>: - <literallayout class='monospaced'> - $ sudo zypper install python-GitPython + $ sudo zypper install dblatex xmlto </literallayout></para></listitem> </itemizedlist> - <note> - Sanity testing, through the - <link linkend='ref-classes-testimage*'>testimage</link> - classes, does not work on systems using the - <ulink url='https://en.opensuse.org/Portal:Wicked'>Wicked</ulink> - network manager. - </note> </para> </section> - <section id='centos-packages'> - <title>CentOS Packages</title> + <section id='centos-7-packages'> + <title>CentOS-7 Packages</title> <para> The following list shows the required packages by function - given a supported CentOS Linux distribution: + given a supported CentOS-7 Linux distribution: <itemizedlist> <listitem><para><emphasis>Essentials:</emphasis> Packages needed to build an image for a headless system: <literallayout class='monospaced'> - $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm + $ sudo yum install &CENTOS7_HOST_PACKAGES_ESSENTIAL; </literallayout> <note><title>Notes</title> <itemizedlist> @@ -328,43 +245,81 @@ Here is some old list items to show the form: Linux by default. You need to install these packages separately. - </para></listitem> + </para></listitem> <listitem><para> The <filename>makecache</filename> command consumes additional Metadata from <filename>epel-release</filename>. - </para></listitem> + </para></listitem> </itemizedlist> </note> - </para></listitem> - <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis> - Packages recommended if the host system has graphics - support or if you are going to use the Eclipse - IDE: - <literallayout class='monospaced'> - $ sudo yum install SDL-devel xterm - </literallayout></para></listitem> + </para></listitem> <listitem><para><emphasis>Documentation:</emphasis> Packages needed if you are going to build out the Yocto Project documentation manuals: <literallayout class='monospaced'> - $ sudo yum install make docbook-style-dsssl docbook-style-xsl \ + $ sudo yum install docbook-style-dsssl docbook-style-xsl \ docbook-dtds docbook-utils fop libxslt dblatex xmlto - </literallayout></para></listitem> - <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis> - Packages needed if you are going to run - <filename>oe-selftest</filename>: + </literallayout> + </para></listitem> + </itemizedlist> + </para> + </section> + + <section id='centos-8-packages'> + <title>CentOS-8 Packages</title> + + <para> + The following list shows the required packages by function + given a supported CentOS-8 Linux distribution: + <itemizedlist> + <listitem><para><emphasis>Essentials:</emphasis> + Packages needed to build an image for a headless + system: <literallayout class='monospaced'> - $ sudo yum install GitPython + $ sudo dnf install &CENTOS8_HOST_PACKAGES_ESSENTIAL; </literallayout> - </para></listitem> + <note><title>Notes</title> + <itemizedlist> + <listitem><para> + Extra Packages for Enterprise Linux + (i.e. <filename>epel-release</filename>) + is a collection of packages from Fedora + built on RHEL/CentOS for easy installation + of packages not included in enterprise + Linux by default. + You need to install these packages + separately. + </para></listitem> + <listitem><para> + The <filename>PowerTools</filename> repo + provides additional packages such as + <filename>rpcgen</filename> and + <filename>texinfo</filename>. + </para></listitem> + <listitem><para> + The <filename>makecache</filename> command + consumes additional Metadata from + <filename>epel-release</filename>. + </para></listitem> + </itemizedlist> + </note> + </para></listitem> + <listitem><para><emphasis>Documentation:</emphasis> + Packages needed if you are going to build out the + Yocto Project documentation manuals: + <literallayout class='monospaced'> + $ sudo dnf install docbook-style-dsssl docbook-style-xsl \ + docbook-dtds docbook-utils fop libxslt dblatex xmlto + </literallayout> + </para></listitem> </itemizedlist> </para> </section> </section> - <section id='required-git-tar-and-python-versions'> - <title>Required Git, tar, and Python Versions</title> + <section id='required-git-tar-python-and-gcc-versions'> + <title>Required Git, tar, Python and gcc Versions</title> <para> In order to use the build system, your host development system @@ -372,8 +327,8 @@ Here is some old list items to show the form: Python: <itemizedlist> <listitem><para>Git 1.8.3.1 or greater</para></listitem> - <listitem><para>tar 1.27 or greater</para></listitem> - <listitem><para>Python 3.4.0 or greater</para></listitem> + <listitem><para>tar 1.28 or greater</para></listitem> + <listitem><para>Python 3.5.0 or greater</para></listitem> </itemizedlist> </para> @@ -385,6 +340,89 @@ Here is some old list items to show the form: tarball or use BitBake to build the tarball. </para> + <para> + In addition, your host development system must meet the following + version requirement for gcc: + <itemizedlist> + <listitem><para>gcc 5.0 or greater</para></listitem> + </itemizedlist> + </para> + + <para> + If your host development system does not meet this requirement, + you can resolve this by installing a <filename>buildtools-extended</filename> + tarball that contains additional tools, the equivalent of <filename>buildtools-essential</filename>. + </para> + <section id='installing-a-pre-built-buildtools-tarball-with-install-buildtools-script'> + <title>Installing a Pre-Built <filename>buildtools</filename> Tarball with <filename>install-buildtools</filename> script</title> + + <para> + The <filename>install-buildtools</filename> script is the easiest + of the three methods by which you can get these tools. It downloads + a pre-built buildtools installer and automatically installs the tools + for you: + <orderedlist> + <listitem><para> + Execute the <filename>install-buildtools</filename> script. + Here is an example: + <literallayout class='monospaced'> + $ cd poky + $ scripts/install-buildtools --without-extended-buildtools \ + --base-url &YOCTO_DL_URL;/releases/yocto \ + --release yocto-&DISTRO; \ + --installer-version &DISTRO; + </literallayout> + <para> + During execution, the buildtools tarball will be downloaded, + the checksum of the download will be verified, the installer + will be run for you, and some basic checks will be run to + to make sure the installation is functional. + </para> + <para> + To avoid the need of <filename>sudo</filename> privileges, + the <filename>install-buildtools</filename> script will + by default tell the installer to install in: + <literallayout class='monospaced'> + <replaceable>/path/to/</replaceable>poky/buildtools + </literallayout> + </para> + <para> + If your host development system needs the additional tools + provided in the <filename>buildtools-extended</filename> + tarball, you can instead execute the + <filename>install-buildtools</filename> script with the + default parameters: + <literallayout class='monospaced'> + $ cd poky + $ scripts/install-buildtools + </literallayout> + </para> + </para></listitem> + <listitem><para> + Source the tools environment setup script by using a + command like the following: + <literallayout class='monospaced'> + $ source <replaceable>/path/to/</replaceable>poky/buildtools/environment-setup-x86_64-pokysdk-linux + </literallayout> + Of course, you need to supply your installation directory and be + sure to use the right file (i.e. i586 or x86_64). + </para> + <para> + After you have sourced the setup script, + the tools are added to <filename>PATH</filename> + and any other environment variables required to run the + tools are initialized. + The results are working versions versions of Git, tar, + Python and <filename>chrpath</filename>. And in the case of + the <filename>buildtools-extended</filename> tarball, additional + working versions of tools including <filename>gcc</filename>, + <filename>make</filename> and the other tools included in + <filename>packagegroup-core-buildessential</filename>. + </para></listitem> + </orderedlist> + </para> + </section> + <section id='downloading-a-pre-built-buildtools-tarball'> <title>Downloading a Pre-Built <filename>buildtools</filename> Tarball</title> @@ -394,14 +432,18 @@ Here is some old list items to show the form: <orderedlist> <listitem><para> Locate and download the <filename>*.sh</filename> at - <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;/buildtools/'></ulink>. + <ulink url='&YOCTO_RELEASE_DL_URL;/buildtools/'></ulink>. </para></listitem> <listitem><para> Execute the installation script. - Here is an example: + Here is an example for the traditional installer: <literallayout class='monospaced'> $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh </literallayout> + Here is an example for the extended installer: + <literallayout class='monospaced'> + $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh + </literallayout> During execution, a prompt appears that allows you to choose the installation directory. For example, you could choose the following: @@ -424,7 +466,11 @@ Here is some old list items to show the form: and any other environment variables required to run the tools are initialized. The results are working versions versions of Git, tar, - Python and <filename>chrpath</filename>. + Python and <filename>chrpath</filename>. And in the case of + the <filename>buildtools-extended</filename> tarball, additional + working versions of tools including <filename>gcc</filename>, + <filename>make</filename> and the other tools included in + <filename>packagegroup-core-buildessential</filename>. </para></listitem> </orderedlist> </para> @@ -440,7 +486,7 @@ Here is some old list items to show the form: <filename>.sh</filename> file and then take steps to transfer and run it on a machine that does not meet the minimal Git, tar, and Python - requirements. + (or gcc) requirements. </para> <para> @@ -458,6 +504,10 @@ Here is some old list items to show the form: <literallayout class='monospaced'> $ bitbake buildtools-tarball </literallayout> + or run the BitBake command to build the extended tarball: + <literallayout class='monospaced'> + $ bitbake buildtools-extended-tarball + </literallayout> <note> The <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link> @@ -471,21 +521,25 @@ Here is some old list items to show the form: subdirectory of the <link linkend='build-directory'>Build Directory</link>. The installer file has the string "buildtools" - in the name. + (or "buildtools-extended") in the name. </para></listitem> <listitem><para> Transfer the <filename>.sh</filename> file from the build host to the machine that does not meet the - Git, tar, or Python requirements. + Git, tar, or Python (or gcc) requirements. </para></listitem> <listitem><para> On the machine that does not meet the requirements, run the <filename>.sh</filename> file to install the tools. - Here is an example: + Here is an example for the traditional installer: <literallayout class='monospaced'> $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh </literallayout> + Here is an example for the extended installer: + <literallayout class='monospaced'> + $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh + </literallayout> During execution, a prompt appears that allows you to choose the installation directory. For example, you could choose the following: @@ -497,10 +551,10 @@ Here is some old list items to show the form: Source the tools environment setup script by using a command like the following: <literallayout class='monospaced'> - $ source /home/<replaceable>your_username</replaceable>/buildtools/environment-setup-i586-poky-linux + $ source /home/<replaceable>your_username</replaceable>/buildtools/environment-setup-x86_64-poky-linux </literallayout> Of course, you need to supply your installation directory and be - sure to use the right file (i.e. i585 or x86-64). + sure to use the right file (i.e. i586 or x86_64). </para> <para> After you have sourced the setup script, @@ -508,7 +562,11 @@ Here is some old list items to show the form: and any other environment variables required to run the tools are initialized. The results are working versions versions of Git, tar, - Python and <filename>chrpath</filename>. + Python and <filename>chrpath</filename>. And in the case of + the <filename>buildtools-extended</filename> tarball, additional + working versions of tools including <filename>gcc</filename>, + <filename>make</filename> and the other tools included in + <filename>packagegroup-core-buildessential</filename>. </para></listitem> </orderedlist> </para> diff --git a/external/poky/documentation/ref-manual/ref-tasks.xml b/external/poky/documentation/ref-manual/ref-tasks.xml index 8f3ff26d..011e0d74 100644 --- a/external/poky/documentation/ref-manual/ref-tasks.xml +++ b/external/poky/documentation/ref-manual/ref-tasks.xml @@ -158,32 +158,6 @@ </para> </section> - <section id='ref-tasks-distrodata'> - <title><filename>do_distrodata</filename></title> - - <para> - Provides information about the recipe. - </para> - - <para> - The <filename>distrodata</filename> task is included as part of the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class. - </para> - - <para> - To build the <filename>distrodata</filename> task, use the - <filename>bitbake</filename> command with the "-c" option and - task name: - <literallayout class='monospaced'> - $ bitbake core-image-minimal -c distrodata - </literallayout> - By default, the results are stored in - <link linkend='var-LOG_DIR'><filename>$LOG_DIR</filename></link> - (e.g. <filename>$BUILD_DIR/tmp/log</filename>). - </para> - </section> - <section id='ref-tasks-fetch'> <title><filename>do_fetch</filename></title> @@ -192,7 +166,8 @@ This task uses the <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> variable and the argument's prefix to determine the correct - fetcher module. + <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetcher</ulink> + module. </para> </section> @@ -635,9 +610,18 @@ </para> <para> - The <filename>checkpkg</filename> task is included as part of the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class. + To check the upstream version and status of a recipe, use the + following devtool commands: + <literallayout class='monospaced'> + $ devtool latest-version + $ devtool check-upgrade-status + </literallayout> + See the + "<link linkend='ref-devtool-reference'><filename>devtool</filename> Quick Reference</link>" + chapter for more information on <filename>devtool</filename>. + See the + "<ulink url='&YOCTO_DOCS_REF_URL;#devtool-checking-on-the-upgrade-status-of-a-recipe'>Checking on the Upgrade Status of a Recipe</ulink>" + section for information on checking the upgrade status of a recipe. </para> <para> diff --git a/external/poky/documentation/ref-manual/ref-terms.xml b/external/poky/documentation/ref-manual/ref-terms.xml index c573a521..722fa7ee 100644 --- a/external/poky/documentation/ref-manual/ref-terms.xml +++ b/external/poky/documentation/ref-manual/ref-terms.xml @@ -41,11 +41,13 @@ That append file would match any <filename>busybox_1.21.</filename><replaceable>x</replaceable><filename>.bb</filename> version of the recipe. - So, the append file would match the following recipe names: + So, the append file would match any of the following recipe names: <literallayout class='monospaced'> busybox_1.21.1.bb busybox_1.21.2.bb busybox_1.21.3.bb + busybox_1.21.10.bb + busybox_1.21.25.bb </literallayout> <note><title>Important</title> The use of the "<filename>%</filename>" character @@ -115,7 +117,7 @@ in your home directory within the existing directory <filename>mybuilds</filename>: <literallayout class='monospaced'> - $cd $HOME + $ cd $HOME $ source $HOME/poky/&OE_INIT_FILE; $HOME/mybuilds/YP-&POKYVERSION; </literallayout> </para></listitem> @@ -141,7 +143,7 @@ The system used to build images in a Yocto Project Development environment. The build system is sometimes referred to as the - development host. + <firstterm>development host</firstterm>. </para></listitem> <listitem><para> <emphasis>Classes:</emphasis> @@ -183,16 +185,11 @@ <listitem><para id='term-container-layer'> <emphasis>Container Layer:</emphasis> Layers that hold other layers. - An example of a container layer is the - <filename>meta-intel</filename> layer. - This layer contains BSP layers for the Intel-core2-32 - <trademark class='registered'>Intel</trademark> Common Core - (Intel-core2-32) and the Intel-corei7-64 - <trademark class='registered'>Intel</trademark> Common Core - (Intel-corei7-64). - the <filename>meta-intel</filename> layer also contains - the <filename>common/</filename> directory, which contains - common content across those layers. + An example of a container layer is OpenEmbedded's + <ulink url='https://github.com/openembedded/meta-openembedded'><filename>meta-openembedded</filename></ulink> + layer. + The <filename>meta-openembedded</filename> layer contains + many <filename>meta-*</filename> layers. </para></listitem> <listitem><para id='cross-development-toolchain'> <emphasis>Cross-Development Toolchain:</emphasis> @@ -398,7 +395,7 @@ Poky is not a product level distro. Rather, it is a good starting point for customization. <note> - Poky began an open-source + Poky began as an open-source project initially developed by OpenedHand. OpenedHand developed Poky from the existing OpenEmbedded build system to create a commercially diff --git a/external/poky/documentation/ref-manual/ref-variables.xml b/external/poky/documentation/ref-manual/ref-variables.xml index c7c5f27b..364cd09e 100644 --- a/external/poky/documentation/ref-manual/ref-variables.xml +++ b/external/poky/documentation/ref-manual/ref-variables.xml @@ -52,7 +52,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Extension to the Application Binary Interface (ABI) field of the GNU canonical architecture name (e.g. "eabi"). @@ -76,7 +75,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies whether to produce an output package even if it is empty. By default, BitBake does not produce empty packages. @@ -103,7 +101,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists commands in a package that need an alternative binary naming scheme. Sometimes the same command is provided in multiple packages. @@ -134,7 +131,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Used by the alternatives system to map duplicated commands to actual locations. For example, if the <filename>bracket</filename> command @@ -174,7 +170,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Used by the alternatives system to create default priorities for duplicated commands. You can use the variable to create a single default @@ -203,7 +198,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Used by the alternatives system to create default link locations for duplicated commands. You can use the variable to create a single default @@ -258,7 +252,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> An override list of append strings for each target specified with <link linkend='var-LABELS'><filename>LABELS</filename></link>. @@ -278,7 +271,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal command and arguments used to run <filename>ar</filename>. </para> @@ -291,7 +283,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When used with the <link linkend='ref-classes-archiver'><filename>archiver</filename></link> class, determines the type of information used to create @@ -334,8 +325,7 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - The minimal command and arguments used to run the + Minimal command and arguments needed to run the assembler. </para> </glossdef> @@ -347,7 +337,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists recipe names (<link linkend='var-PN'><filename>PN</filename></link> values) BitBake does not attempt to build. @@ -367,11 +356,10 @@ <glossentry id='var-ASSUME_SHLIBS'><glossterm>ASSUME_SHLIBS</glossterm> <info> - ASSUME_SHLIBS[doc] = Provides additional shlibs provider mapping information, which adds to or overwrites the information provided automatically by the system." + ASSUME_SHLIBS[doc] = "Provides additional shlibs provider mapping information, which adds to or overwrites the information provided automatically by the system." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Provides additional <filename>shlibs</filename> provider mapping information, which adds to or overwrites the information provided automatically by the system. @@ -406,7 +394,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The email address used to contact the original author or authors in order to send patches and forward bugs. </para> @@ -419,7 +406,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When the <link linkend='ref-classes-debian'><filename>debian</filename></link> class is inherited, which is the default behavior, @@ -442,7 +428,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Enables creating an automatic menu for the syslinux bootloader. You must set this variable in your recipe. @@ -459,7 +444,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When <filename><link linkend='var-SRCREV'>SRCREV</link></filename> is set to the value of this variable, it specifies to use @@ -495,13 +479,35 @@ </glossdef> </glossentry> + <glossentry id='var-AVAILABLE_LICENSES'><glossterm>AVAILABLE_LICENSES</glossterm> + <info> + AVAILABLE_LICENSES[doc] = "List of licenses found in the directories specified by COMMON_LICENSE_DIR and LICENSE_PATH." + </info> + <glossdef> + <para role="glossdeffirst"> + + List of licenses found in the directories specified + by <link linkend='var-COMMON_LICENSE_DIR'><filename>COMMON_LICENSE_DIR</filename></link> + and <link linkend='var-LICENSE_PATH'><filename>LICENSE_PATH</filename></link>. + + <note> + It is assumed that all changes + to <filename>COMMON_LICENSE_DIR</filename> + and <filename>LICENSE_PATH</filename> have been done + before <filename>AVAILABLE_LICENSES</filename> is + defined + (in <link linkend='ref-classes-license'>license.bbclass</link>). + </note> + </para> + </glossdef> + </glossentry> + <glossentry id='var-AVAILTUNES'><glossterm>AVAILTUNES</glossterm> <info> AVAILTUNES[doc] = "The list of defined CPU and Application Binary Interface (ABI) tunings (i.e. "tunes") available for use by the OpenEmbedded build system." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The list of defined CPU and Application Binary Interface (ABI) tunings (i.e. "tunes") available for use by the OpenEmbedded build system. @@ -536,7 +542,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The directory within the <link linkend='build-directory'>Build Directory</link> in which the OpenEmbedded build system places generated @@ -566,7 +571,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists "recommended-only" packages to not install. Recommended-only packages are packages installed only through the @@ -621,7 +625,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The library directory name for the CPU or Application Binary Interface (ABI) tune. The <filename>BASE_LIB</filename> applies only in the @@ -647,7 +650,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the base of the work directory for all recipes. The default value is "${TMPDIR}/work". </para> @@ -727,7 +729,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines how BitBake handles situations where an append file (<filename>.bbappend</filename>) has no corresponding recipe file (<filename>.bb</filename>). @@ -765,7 +766,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Monitors disk space and available inodes during the build and allows you to control the build based on these parameters. @@ -863,7 +863,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the disk space and free inode warning intervals. To set these intervals, define the variable in your <filename>conf/local.conf</filename> file in the @@ -931,20 +930,20 @@ <glossentry id='var-BB_GENERATE_MIRROR_TARBALLS'><glossterm>BB_GENERATE_MIRROR_TARBALLS</glossterm> <info> - BB_GENERATE_MIRROR_TARBALLS[doc] = "Causes tarballs of the Git repositories to be placed in the DL_DIR directory." + BB_GENERATE_MIRROR_TARBALLS[doc] = "Causes tarballs of the source control repositories to be placed in the DL_DIR directory." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - Causes tarballs of the Git repositories, including the - Git metadata, to be placed in the + Causes tarballs of the source control repositories + (e.g. Git repositories), including metadata, to be placed + in the <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link> directory. </para> <para> For performance reasons, creating and placing tarballs of - the Git repositories is not the default action by the + these repositories is not the default action by the OpenEmbedded build system. <literallayout class='monospaced'> BB_GENERATE_MIRROR_TARBALLS = "1" @@ -953,6 +952,13 @@ file in the <link linkend='build-directory'>Build Directory</link>. </para> + + <para> + Once you have the tarballs containing your source files, + you can clean up your <filename>DL_DIR</filename> + directory by deleting any Git or other source control + work directories. + </para> </glossdef> </glossentry> @@ -962,7 +968,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The maximum number of tasks BitBake should run in parallel at any one time. The OpenEmbedded build system automatically configures @@ -998,7 +1003,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the time (in seconds) after which to unload the BitBake server due to inactivity. Set <filename>BB_SERVER_TIMEOUT</filename> to determine how @@ -1024,7 +1028,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Allows you to extend a recipe so that it builds variants of the software. Common variants for recipes exist such as "natives" like <filename>quilt-native</filename>, which is a copy of Quilt built to run on the build system; @@ -1075,7 +1078,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists the names of configured layers. These names are used to find the other <filename>BBFILE_*</filename> variables. @@ -1091,7 +1093,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Variable that expands to match files from <link linkend='var-BBFILES'><filename>BBFILES</filename></link> in a particular layer. @@ -1108,7 +1109,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Assigns the priority for recipe files in each layer. </para> @@ -1151,7 +1151,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A space-separated list of recipe files BitBake uses to build software. </para> @@ -1173,7 +1172,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Activates content when identified layers are present. You identify the layers by the collections that the layers define. @@ -1220,7 +1218,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Variable that controls how BitBake displays logs on build failure. </para> </glossdef> @@ -1232,7 +1229,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> If <link linkend='var-BBINCLUDELOGS'><filename>BBINCLUDELOGS</filename></link> is set, specifies the maximum number of lines from the @@ -1249,7 +1245,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists the layers to enable during the build. This variable is defined in the <filename>bblayers.conf</filename> configuration file in the @@ -1278,7 +1273,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Prevents BitBake from processing recipes and recipe append files. </para> @@ -1336,13 +1330,12 @@ <glossentry id='var-BBMULTICONFIG'><glossterm>BBMULTICONFIG</glossterm> <info> - BBMULTICONFIG[doc] = "Specifies each separate configuration when you are building targets with multiple configurations." + BBMULTICONFIG[doc] = "Specifies each additional separate configuration when you are building targets with multiple configurations." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - Specifies each separate configuration when you are - building targets with multiple configurations. + Specifies each additional separate configuration when you + are building targets with multiple configurations. Use this variable in your <filename>conf/local.conf</filename> configuration file. Specify a <replaceable>multiconfigname</replaceable> for @@ -1376,7 +1369,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Used by BitBake to locate <filename>.bbclass</filename> and configuration files. This variable is analogous to the @@ -1405,7 +1397,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> If defined in the BitBake environment, <filename>BBSERVER</filename> points to the BitBake remote server. @@ -1415,7 +1406,7 @@ Use the following format to export the variable to the BitBake environment: <literallayout class='monospaced'> - export BBSERVER=localhost:$port" + export BBSERVER=localhost:$port </literallayout> </para> @@ -1434,7 +1425,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-binconfig-disabled'><filename>binconfig-disabled</filename></link> class, this variable specifies binary configuration @@ -1462,7 +1452,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-binconfig'><filename>binconfig</filename></link> class, this variable specifies a wildcard for @@ -1501,7 +1490,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The base recipe name and version but without any special recipe name suffix (i.e. <filename>-native</filename>, <filename>lib64-</filename>, and so forth). @@ -1519,7 +1507,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> This variable is a version of the <link linkend='var-PN'><filename>PN</filename></link> variable with common prefixes and suffixes @@ -1544,7 +1531,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a URL for an upstream bug tracking website for a recipe. The OpenEmbedded build system does not use this variable. @@ -1560,7 +1546,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the architecture of the build host (e.g. <filename>i686</filename>). The OpenEmbedded build system sets the value of @@ -1576,7 +1561,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the architecture-specific assembler flags for the build host. By default, the value of <filename>BUILD_AS_ARCH</filename> is empty. @@ -1590,7 +1574,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the architecture-specific C compiler flags for the build host. By default, the value of <filename>BUILD_CC_ARCH</filename> is empty. @@ -1604,7 +1587,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the linker command to be used for the build host when the C compiler is being used as the linker. By default, <filename>BUILD_CCLD</filename> points to GCC and passes as @@ -1621,7 +1603,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C compiler when building for the build host. When building in the <filename>-native</filename> context, @@ -1637,7 +1618,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C preprocessor (i.e. to both the C and the C++ compilers) when building for the build host. @@ -1654,7 +1634,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C++ compiler when building for the build host. When building in the <filename>-native</filename> context, @@ -1670,7 +1649,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the Fortran compiler command for the build host. By default, <filename>BUILD_FC</filename> points to Gfortran and passes as arguments the value of @@ -1686,7 +1664,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the linker command for the build host. By default, <filename>BUILD_LD</filename> points to the GNU linker (ld) and passes as arguments the value of @@ -1702,7 +1679,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies architecture-specific linker flags for the build host. By default, the value of <filename>BUILD_LD_ARCH</filename> is empty. @@ -1716,7 +1692,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the linker when building for the build host. When building in the <filename>-native</filename> context, @@ -1732,7 +1707,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the optimization flags passed to the C compiler when building for the build host or the SDK. The flags are passed through the @@ -1756,7 +1730,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the operating system in use on the build host (e.g. "linux"). The OpenEmbedded build system sets the value of @@ -1773,7 +1746,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The toolchain binary prefix used for native recipes. The OpenEmbedded build system uses the <filename>BUILD_PREFIX</filename> value to set the @@ -1789,7 +1761,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the command to be used to strip debugging symbols from binaries produced for the build host. By default, <filename>BUILD_STRIP</filename> points to @@ -1804,7 +1775,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the system, including the architecture and the operating system, to use when building for the build host (i.e. when building <filename>native</filename> @@ -1830,7 +1800,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the vendor name to use when building for the build host. The default value is an empty string (""). @@ -1844,7 +1813,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the location of the <link linkend='build-directory'>Build Directory</link>. You can define this directory indirectly through the @@ -1864,7 +1832,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link> class, this variable specifies whether or not to commit the @@ -1896,7 +1863,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link> class, this variable specifies the author to use for each @@ -1931,7 +1897,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link> class, this variable specifies the directory in which @@ -1956,7 +1921,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link> class, this variable specifies the build history features @@ -2009,7 +1973,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link> class, this variable specifies a list of paths to files @@ -2042,7 +2005,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link> class, this variable optionally specifies a remote @@ -2077,7 +2039,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C compiler when building for the SDK. When building in the <filename>nativesdk-</filename> @@ -2094,7 +2055,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C pre-processor (i.e. to both the C and the C++ compilers) when building for the SDK. @@ -2112,7 +2072,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C++ compiler when building for the SDK. When building in the <filename>nativesdk-</filename> @@ -2129,7 +2088,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the linker when building for the SDK. When building in the <filename>nativesdk-</filename> @@ -2146,7 +2104,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the location of the directory that holds build statistics when you use and enable the <link linkend='ref-classes-buildstats'><filename>buildstats</filename></link> @@ -2164,7 +2121,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> For the BusyBox recipe, specifies whether to split the output executable file into two parts: one for features that require <filename>setuid root</filename>, and one for @@ -2174,9 +2130,10 @@ <para> The <filename>BUSYBOX_SPLIT_SUID</filename> variable - defaults to "1", which results in a single output + defaults to "1", which results in splitting the output executable file. - Set the variable to "0" to split the output file. + Set the variable to "0" to get a single output executable + file. </para> </glossdef> </glossentry> @@ -2191,7 +2148,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the directory BitBake uses to store a cache of the <link linkend='metadata'>Metadata</link> @@ -2207,7 +2163,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal command and arguments used to run the C compiler. </para> @@ -2220,7 +2175,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C compiler. This variable is exported to an environment variable and thus made visible to the software being @@ -2256,7 +2210,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> An internal variable specifying the special class override that should currently apply (e.g. "class-target", "class-native", and so forth). @@ -2300,7 +2253,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> If set to "1" within a recipe, <filename>CLEANBROKEN</filename> specifies that the <filename>make clean</filename> command does @@ -2319,7 +2271,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Provides a list of hardware features that are enabled in both <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link> @@ -2342,7 +2293,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to <filename>meta/files/common-licenses</filename> in the <link linkend='source-directory'>Source Directory</link>, @@ -2357,7 +2307,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A regular expression that resolves to one or more hosts (when the recipe is native) or one or more targets (when the recipe is non-native) with which a recipe is compatible. @@ -2380,7 +2329,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A regular expression that resolves to one or more target machines with which a recipe is compatible. The regular expression is matched against @@ -2401,7 +2349,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines wildcards to match when installing a list of complementary packages for all the packages explicitly (or implicitly) installed in an image. @@ -2440,7 +2387,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Stores sysroot components for each recipe. The OpenEmbedded build system uses <filename>COMPONENTS_DIR</filename> when constructing @@ -2461,7 +2407,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Tracks the version of the local configuration file (i.e. <filename>local.conf</filename>). The value for <filename>CONF_VERSION</filename> @@ -2477,7 +2422,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Identifies editable or configurable files that are part of a package. If the Package Management System (PMS) is being used to update packages on the target system, it is possible that @@ -2531,7 +2475,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Identifies the initial RAM filesystem (initramfs) source files. The OpenEmbedded build system receives and uses @@ -2574,7 +2517,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of files that contains <filename>autoconf</filename> test results relevant to the current build. This variable is used by the Autotools utilities when running @@ -2589,7 +2531,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal arguments for GNU configure. </para> </glossdef> @@ -2601,7 +2542,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-distro_features_check'><filename>distro_features_check</filename></link> class, this @@ -2624,7 +2564,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A space-separated list of licenses to exclude from the source archived by the <link linkend='ref-classes-archiver'><filename>archiver</filename></link> @@ -2656,7 +2595,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A space-separated list of licenses to include in the source archived by the <link linkend='ref-classes-archiver'><filename>archiver</filename></link> @@ -2684,7 +2622,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of recipes to exclude in the source archived by the <link linkend='ref-classes-archiver'><filename>archiver</filename></link> @@ -2716,7 +2653,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of recipes to include in the source archived by the <link linkend='ref-classes-archiver'><filename>archiver</filename></link> @@ -2748,7 +2684,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A space-separated list of recipe types to include in the source archived by the <link linkend='ref-classes-archiver'><filename>archiver</filename></link> @@ -2778,7 +2713,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> If set to "1" along with the <link linkend='var-COPY_LIC_MANIFEST'><filename>COPY_LIC_MANIFEST</filename></link> variable, the OpenEmbedded build system copies @@ -2810,7 +2744,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> If set to "1", the OpenEmbedded build system copies the license manifest for the image to <filename>/usr/share/common-licenses/license.manifest</filename> @@ -2838,7 +2771,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the list of packages to be added to the image. You should only set this variable in the <filename>local.conf</filename> configuration file found @@ -2858,7 +2790,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the parent directory of the OpenEmbedded-Core Metadata layer (i.e. <filename>meta</filename>). </para> @@ -2884,7 +2815,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists files from the <link linkend='var-COREBASE'><filename>COREBASE</filename></link> directory that should be copied other than the layers @@ -2913,7 +2843,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal command and arguments used to run the C preprocessor. </para> @@ -2926,7 +2855,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C pre-processor (i.e. to both the C and the C++ compilers). This variable is exported to an environment @@ -2963,7 +2891,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The toolchain binary prefix for the target tools. The <filename>CROSS_COMPILE</filename> variable is the same as the @@ -2985,7 +2912,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The directory in which files checked out under the CVS system are stored. </para> @@ -2998,7 +2924,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal command and arguments used to run the C++ compiler. </para> @@ -3011,7 +2936,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C++ compiler. This variable is exported to an environment variable and thus made visible to the software being @@ -3051,7 +2975,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The destination directory. The location in the <link linkend='build-directory'>Build Directory</link> @@ -3077,7 +3000,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The date the build was started. Dates appear using the year, month, and day (YMD) format (e.g. "20150209" for February 9th, 2015). @@ -3091,7 +3013,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The date and time on which the current build started. The format is suitable for timestamps. </para> @@ -3104,7 +3025,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When the <link linkend='ref-classes-debian'><filename>debian</filename></link> class is inherited, which is the default behavior, @@ -3128,7 +3048,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When the <link linkend='ref-classes-debian'><filename>debian</filename></link> class is inherited, which is the default behavior, @@ -3152,7 +3071,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies to build packages with debugging information. This influences the value of the <filename><link linkend='var-SELECTED_OPTIMIZATION'>SELECTED_OPTIMIZATION</link></filename> @@ -3167,7 +3085,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The options to pass in <filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename> and <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename> when compiling @@ -3183,7 +3100,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a weak bias for recipe selection priority. </para> @@ -3213,7 +3129,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The default CPU and Application Binary Interface (ABI) tunings (i.e. the "tune") used by the OpenEmbedded build system. @@ -3238,7 +3153,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists a recipe's build-time dependencies. These are dependencies on other recipes whose contents (e.g. headers and shared libraries) are needed @@ -3361,7 +3275,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the general area that the OpenEmbedded build system uses to place images, packages, SDKs, and other output files that are ready to be used outside of the build system. @@ -3393,7 +3306,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the area that the OpenEmbedded build system uses to place Debian packages that are ready to be used outside of the build system. @@ -3433,7 +3345,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the area that the OpenEmbedded build system uses to place images and other associated output files that are ready to be deployed onto the target machine. @@ -3466,7 +3377,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the area that the OpenEmbedded build system uses to place IPK packages that are ready to be used outside of the build system. @@ -3505,7 +3415,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the area that the OpenEmbedded build system uses to place RPM packages that are ready to be used outside of the build system. @@ -3544,7 +3453,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the area that the OpenEmbedded build system uses to place tarballs that are ready to be used outside of the build system. @@ -3583,7 +3491,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-deploy'><filename>deploy</filename></link> class, the <filename>DEPLOYDIR</filename> points to a @@ -3611,7 +3518,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The package description used by package managers. If not set, <filename>DESCRIPTION</filename> takes the value of the @@ -3621,67 +3527,12 @@ </glossdef> </glossentry> - <glossentry id='var-DISK_SIGNATURE'><glossterm>DISK_SIGNATURE</glossterm> - <info> - DISK_SIGNATURE[doc] = "A 32-bit MBR disk signature used by directdisk images." - </info> - <glossdef> - <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - A 32-bit MBR disk signature used by - <filename>directdisk</filename> images. - </para> - - <para> - By default, the signature is set to an automatically - generated random value that allows the OpenEmbedded - build system to create a boot loader. - You can override the signature in the image recipe - by setting <filename>DISK_SIGNATURE</filename> to an - 8-digit hex string. - You might want to override - <filename>DISK_SIGNATURE</filename> if you want the disk - signature to remain constant between image builds. - </para> - - <para> - When using Linux 3.8 or later, you can use - <filename>DISK_SIGNATURE</filename> to specify the root - by UUID to allow the kernel to locate the root device - even if the device name changes due to differences in - hardware configuration. - By default, <filename>ROOT_VM</filename> is set - as follows: - <literallayout class='monospaced'> - ROOT_VM ?= "root=/dev/sda2" - </literallayout> - However, you can change this to locate the root device - using the disk signature instead: - <literallayout class='monospaced'> - ROOT_VM = "root=PARTUUID=${DISK_SIGNATURE}-02" - </literallayout> - </para> - - <para> - As previously mentioned, it is possible to set the - <filename>DISK_SIGNATURE</filename> variable in your - <filename>local.conf</filename> file to a fixed - value if you do not want <filename>syslinux.cfg</filename> - changing for each build. - You might find this useful when you want to upgrade the - root filesystem on a device without having to recreate or - modify the master boot record. - </para> - </glossdef> - </glossentry> - <glossentry id='var-DISTRO'><glossterm>DISTRO</glossterm> <info> DISTRO[doc] = "The short name of the distribution. If the variable is blank, meta/conf/distro/defaultsetup.conf will be used." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The short name of the distribution. For information on the long name of the distribution, see the @@ -3734,7 +3585,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a codename for the distribution being built. </para> </glossdef> @@ -3746,7 +3596,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of distro-specific packages to add to all images. This variable takes affect through <filename>packagegroup-base</filename> so the @@ -3766,7 +3615,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of distro-specific packages to add to all images if the packages exist. The packages might not exist or be empty (e.g. kernel modules). @@ -3782,7 +3630,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The software support you want in your distribution for various features. You define your distribution features in the distribution @@ -3819,7 +3666,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Features to be added to <filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename> if not also present in @@ -3831,7 +3677,7 @@ It is not intended to be user-configurable. It is best to just reference the variable to see which distro features are being backfilled for all distro configurations. - See the <link linkend='ref-features-backfill'>Feature Backfilling</link> section for + See the "<link linkend='ref-features-backfill'>Feature Backfilling</link>" section for more information. </para> </glossdef> @@ -3843,7 +3689,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Features from <filename><link linkend='var-DISTRO_FEATURES_BACKFILL'>DISTRO_FEATURES_BACKFILL</link></filename> that should not be backfilled (i.e. added to @@ -3861,7 +3706,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A convenience variable that gives you the default list of distro features with the exception of any features specific to the C library @@ -3877,7 +3721,7 @@ <filename>DISTRO_FEATURES_DEFAULT</filename> from a custom distro configuration file: <literallayout class='monospaced'> - DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} myfeature" + DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature" </literallayout> </para> </glossdef> @@ -3889,7 +3733,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of features that if present in the target <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link> @@ -3910,7 +3753,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of features that if present in the target <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link> value should be included in @@ -3924,13 +3766,13 @@ </glossdef> </glossentry> +<!-- <glossentry id='var-DISTRO_FEATURES_LIBC'><glossterm>DISTRO_FEATURES_LIBC</glossterm> <info> DISTRO_FEATURES_LIBC[doc] = "Specifies the list of distro features that are specific to the C library (libc)." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A convenience variable that specifies the list of distro features that are specific to the C library (<filename>libc</filename>). @@ -3940,6 +3782,7 @@ </para> </glossdef> </glossentry> +--> <glossentry id='var-DISTRO_FEATURES_NATIVE'><glossterm>DISTRO_FEATURES_NATIVE</glossterm> <info> @@ -3947,7 +3790,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of features that should be included in <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link> when building native recipes. @@ -3965,7 +3807,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of features that should be included in <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link> when building nativesdk recipes. @@ -3983,7 +3824,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The long name of the distribution. For information on the short name of the distribution, see the @@ -4035,7 +3875,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The version of the distribution. </para> </glossdef> @@ -4047,7 +3886,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A colon-separated list of overrides specific to the current distribution. By default, this list includes the value of @@ -4075,7 +3913,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The central download directory used by the build process to store downloads. By default, <filename>DL_DIR</filename> gets files @@ -4138,7 +3975,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-compress_doc'><filename>compress_doc</filename></link> class, this variable sets the compression policy used when @@ -4166,7 +4002,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When building bootable images (i.e. where <filename>hddimg</filename>, <filename>iso</filename>, or <filename>wic.vmdk</filename> is in @@ -4193,7 +4028,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Variable that controls which locales for <filename>glibc</filename> are generated during the build (useful if the target device has 64Mbytes @@ -4208,7 +4042,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When used with the <link linkend='ref-classes-report-error'><filename>report-error</filename></link> class, specifies the path used for storing the debug files @@ -4237,7 +4070,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the quality assurance checks whose failures are reported as errors by the OpenEmbedded build system. You set this variable in your distribution configuration @@ -4256,7 +4088,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Triggers the OpenEmbedded build system's shared libraries resolver to exclude an entire package when scanning for shared libraries. @@ -4295,7 +4126,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Directs BitBake to exclude a recipe from world builds (i.e. <filename>bitbake world</filename>). During world builds, BitBake locates, parses and builds all @@ -4325,7 +4155,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Used with file and pathnames to create a prefix for a recipe's version based on the recipe's <link linkend='var-PE'><filename>PE</filename></link> value. @@ -4347,7 +4176,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The full package version specification as it appears on the final packages produced by a recipe. The variable's value is normally used to fix a runtime @@ -4372,7 +4200,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When set, the <filename>EXTERNAL_KERNEL_TOOLS</filename> variable indicates that these tools are not in the source tree. @@ -4398,7 +4225,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-externalsrc'><filename>externalsrc</filename></link> class, this variable points to the source tree, which is @@ -4428,7 +4254,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-externalsrc'><filename>externalsrc</filename></link> class, this variable points to the directory in which the @@ -4459,7 +4284,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> For recipes inheriting the <link linkend='ref-classes-autotools'><filename>autotools</filename></link> class, you can use <filename>EXTRA_AUTORECONF</filename> to @@ -4482,7 +4306,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of additional features to include in an image. When listing more than one feature, separate them with a space. @@ -4563,7 +4386,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies additional options for the image creation command that has been specified in <link linkend='var-IMAGE_CMD'><filename>IMAGE_CMD</filename></link>. @@ -4583,7 +4405,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of recipes to build that do not provide packages for installing into the root filesystem. </para> @@ -4611,7 +4432,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of subdirectories of <filename>${</filename><link linkend='var-STAGING_BINDIR_NATIVE'><filename>STAGING_BINDIR_NATIVE</filename></link><filename>}</filename> added to the beginning of the environment variable @@ -4632,7 +4452,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Additional <ulink url='https://cmake.org/overview/'>CMake</ulink> options. @@ -4649,7 +4468,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Additional <filename>configure</filename> script options. See <link linkend='var-PACKAGECONFIG_CONFARGS'><filename>PACKAGECONFIG_CONFARGS</filename></link> @@ -4665,7 +4483,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Additional GNU <filename>make</filename> options. </para> @@ -4692,7 +4509,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-scons'><filename>scons</filename></link> class, this variable specifies additional configuration @@ -4708,7 +4524,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-extrausers'><filename>extrausers</filename></link> class, this variable provides image level user and group @@ -4750,7 +4565,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines one or more packages to include in an image when a specific item is included in <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>. @@ -4785,7 +4599,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the base URL of the server and location within the document-root that provides the metadata and packages required by OPKG to support runtime package @@ -4816,7 +4629,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The list of files and directories that are placed in a package. The @@ -4887,7 +4699,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the file specification to match <link linkend='var-SOLIBSDEV'><filename>SOLIBSDEV</filename></link>. In other words, <filename>FILES_SOLIBSDEV</filename> @@ -4911,7 +4722,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Extends the search path the OpenEmbedded build system uses when looking for files and patches as it processes recipes and append files. @@ -5008,13 +4818,20 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A subset of <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link> used by the OpenEmbedded build system for creating <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>. - You can find more information on how overrides are handled - in the - <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>. + The <filename>FILESOVERRIDES</filename> variable uses + overrides to automatically extend the + <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> + variable. + For an example of how that works, see the + <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> + variable description. + Additionally, you find more information on how overrides + are handled in the + "<ulink url='&YOCTO_DOCS_BB_URL;#conditional-syntax-overrides'>Conditional Syntax (Overrides)</ulink>" + section of the BitBake User Manual. </para> <para> @@ -5040,12 +4857,14 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - The default set of directories the OpenEmbedded build system - uses when searching for patches and files. - During the build process, BitBake searches each directory in - <filename>FILESPATH</filename> in the specified order when - looking for files and patches specified by each + The default set of directories the OpenEmbedded build + system uses when searching for patches and files. + </para> + + <para> + During the build process, BitBake searches each directory + in <filename>FILESPATH</filename> in the specified order + when looking for files and patches specified by each <filename>file://</filename> URI in a recipe's <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> statements. @@ -5060,23 +4879,62 @@ FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \ "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" </literallayout> - <note> - Do not hand-edit the <filename>FILESPATH</filename> - variable. - If you want the build system to look in directories - other than the defaults, extend the - <filename>FILESPATH</filename> variable by using the - <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link> - variable. + The <filename>FILESPATH</filename> variable is automatically + extended using the overrides from the + <link linkend='var-FILESOVERRIDES'><filename>FILESOVERRIDES</filename></link> + variable. + <note><title>Notes</title> + <itemizedlist> + <listitem><para> + Do not hand-edit the + <filename>FILESPATH</filename> variable. + If you want the build system to look in + directories other than the defaults, extend the + <filename>FILESPATH</filename> variable by + using the + <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link> + variable. + </para></listitem> + <listitem><para> + Be aware that the default + <filename>FILESPATH</filename> directories do + not map to directories in custom layers + where append files + (<filename>.bbappend</filename>) are used. + If you want the build system to find patches + or files that reside with your append files, + you need to extend the + <filename>FILESPATH</filename> variable by + using the <filename>FILESEXTRAPATHS</filename> + variable. + </para></listitem> + </itemizedlist> </note> - Be aware that the default <filename>FILESPATH</filename> - directories do not map to directories in custom layers - where append files (<filename>.bbappend</filename>) - are used. - If you want the build system to find patches or files - that reside with your append files, you need to extend - the <filename>FILESPATH</filename> variable by using - the <filename>FILESEXTRAPATHS</filename> variable. + </para> + + <para> + You can take advantage of this searching behavior in + useful ways. + For example, consider a case where the following + directory structure exists for general and machine-specific + configurations: + <literallayout class='monospaced'> + files/defconfig + files/MACHINEA/defconfig + files/MACHINEB/defconfig + </literallayout> + Also in the example, the <filename>SRC_URI</filename> + statement contains "file://defconfig". + Given this scenario, you can set + <link linkend='var-MACHINE'><filename>MACHINE</filename></link> + to "MACHINEA" and cause the build system to use files + from <filename>files/MACHINEA</filename>. + Set <filename>MACHINE</filename> to "MACHINEB" and the + build system uses files from + <filename>files/MACHINEB</filename>. + Finally, for any machine other than "MACHINEA" and + "MACHINEB", the build system uses files from + <filename>files/defconfig</filename>. </para> <para> @@ -5099,7 +4957,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Allows you to define your own file permissions settings table as part of your configuration for the packaging process. For example, suppose you need a consistent set of custom permissions for @@ -5139,7 +4996,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-fontcache'><filename>fontcache</filename></link> class, this variable specifies the runtime dependencies @@ -5156,7 +5012,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-fontcache'><filename>fontcache</filename></link> class, this variable identifies packages containing font @@ -5176,7 +5031,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Forces the removal of the packages listed in <filename>ROOTFS_RO_UNNEEDED</filename> during the generation of the root filesystem. @@ -5195,7 +5049,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The options to pass in <filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename> and <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename> @@ -5215,7 +5068,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Enables Position Independent Executables (PIE) within the GNU C Compiler (GCC). Enabling PIE in the GCC makes Return Oriented Programming @@ -5239,7 +5091,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the default version of the GNU C Compiler (GCC) used for compilation. By default, <filename>GCCVERSION</filename> is set to @@ -5261,7 +5112,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal command and arguments to run the GNU Debugger. </para> </glossdef> @@ -5273,7 +5123,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The directory in which a local copy of a Git repository is stored when it is cloned. </para> @@ -5286,7 +5135,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the list of GLIBC locales to generate should you not wish to generate all LIBC locals, which can be time consuming. @@ -5315,7 +5163,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-useradd'><filename>useradd</filename></link> class, this variable @@ -5344,7 +5191,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-useradd'><filename>useradd</filename></link> class, this variable @@ -5368,7 +5214,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Configures the GNU GRand Unified Bootloader (GRUB) to have graphics and serial in the boot menu. Set this variable to "1" in your @@ -5391,7 +5236,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Additional options to add to the GNU GRand Unified Bootloader (GRUB) configuration. Use a semi-colon character (<filename>;</filename>) to @@ -5413,7 +5257,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the timeout before executing the default <filename>LABEL</filename> in the GNU GRand Unified Bootloader (GRUB). @@ -5434,7 +5277,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-gtk-immodules-cache'><filename>gtk-immodules-cache</filename></link> class, this variable specifies the packages that contain the @@ -5454,7 +5296,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Website where more information about the software the recipe is building can be found. </para> @@ -5468,7 +5309,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The name of the target architecture, which is normally the same as <link linkend='var-TARGET_ARCH'><filename>TARGET_ARCH</filename></link>. @@ -5496,7 +5336,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies architecture-specific compiler flags that are passed to the C compiler. </para> @@ -5530,7 +5369,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the name of the target operating system, which is normally the same as the <link linkend='var-TARGET_OS'><filename>TARGET_OS</filename></link>. @@ -5548,7 +5386,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the prefix for the cross-compile toolchain. <filename>HOST_PREFIX</filename> is normally the same as <link linkend='var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></link>. @@ -5562,7 +5399,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the system, including the architecture and the operating system, for which the build is occurring in the context of the current recipe. @@ -5603,7 +5439,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A space-separated list (filter) of tools on the build host that should be allowed to be called from within build tasks. Using this filter helps reduce the possibility of host @@ -5627,7 +5462,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A space-separated list (filter) of tools on the build host that should be allowed to be called from within build tasks. Using this filter helps reduce the possibility of host @@ -5650,7 +5484,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the name of the vendor. <filename>HOST_VENDOR</filename> is normally the same as <link linkend='var-TARGET_VENDOR'><filename>TARGET_VENDOR</filename></link>. @@ -5668,7 +5501,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Disables or enables the <filename>icecc</filename> (Icecream) function. For more information on this function and best practices @@ -5697,7 +5529,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the <filename>icecc-create-env</filename> script that you provide. This variable is used by the @@ -5723,7 +5554,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Extra options passed to the <filename>make</filename> command during the <link linkend='ref-tasks-compile'><filename>do_compile</filename></link> @@ -5769,7 +5599,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The location of the <filename>icecc</filename> binary. You can set this variable in your <filename>local.conf</filename> file. @@ -5788,7 +5617,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Identifies user classes that you do not want the Icecream distributed compile support to consider. This variable is used by the @@ -5814,7 +5642,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Identifies user recipes that you do not want the Icecream distributed compile support to consider. This variable is used by the @@ -5840,7 +5667,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Identifies user recipes that use an empty <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link> variable that you want to force remote distributed @@ -5861,7 +5687,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The base name of image output files. This variable defaults to the recipe name (<filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>). @@ -5875,7 +5700,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A space-separated list of files installed into the boot partition when preparing an image using the Wic tool with the <filename>bootimg-partition</filename> source @@ -5932,7 +5756,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of classes that all images should inherit. You typically use this variable to specify the list of classes that register the different types of images @@ -5961,7 +5784,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the command to create the image file for a specific image type, which corresponds to the value set set in @@ -5995,7 +5817,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies one or more files that contain custom device tables that are passed to the <filename>makedevs</filename> command as part of creating @@ -6019,7 +5840,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The primary list of features to include in an image. Typically, you configure this variable in an image recipe. Although you can use this variable from your @@ -6055,7 +5875,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the formats the OpenEmbedded build system uses during the build when creating the root filesystem. For example, setting <filename>IMAGE_FSTYPES</filename> @@ -6076,11 +5895,12 @@ <note><title>Notes</title> <itemizedlist> <listitem><para> - If you add "live" to - <filename>IMAGE_FSTYPES</filename> inside an image - recipe, be sure that you do so prior to the - "inherit image" line of the recipe or the live - image will not build. + If an image recipe uses the "inherit image" line + and you are setting + <filename>IMAGE_FSTYPES</filename> inside the + recipe, you must set + <filename>IMAGE_FSTYPES</filename> prior to + using the "inherit image" line. </para></listitem> <listitem><para> Due to the way the OpenEmbedded build system @@ -6102,7 +5922,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Used by recipes to specify the packages to install into an image through the <link linkend='ref-classes-image'><filename>image</filename></link> @@ -6188,7 +6007,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the list of locales to install into the image during the root filesystem construction process. The OpenEmbedded build system automatically splits locale @@ -6230,7 +6048,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The manifest file for the image. This file lists all the installed packages that make up the image. @@ -6267,7 +6084,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The name of the output image files minus the extension. This variable is derived using the <link linkend='var-IMAGE_BASENAME'><filename>IMAGE_BASENAME</filename></link>, @@ -6288,7 +6104,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines a multiplier that the build system applies to the initial image size for cases when the multiplier times the returned disk usage value for the image is greater than the sum of @@ -6334,7 +6149,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the package type (i.e. DEB, RPM, IPK, or TAR) used by the OpenEmbedded build system. The variable is defined appropriately by the @@ -6386,7 +6200,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of functions to call once the OpenEmbedded build system creates the final image output files. @@ -6414,7 +6227,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of functions to call before the OpenEmbedded build system creates the final image output files. @@ -6442,7 +6254,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The location of the root filesystem while it is under construction (i.e. during the <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link> @@ -6459,7 +6270,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the alignment for the output image file in Kbytes. If the size of the image is not a multiple of @@ -6479,7 +6289,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines additional free disk space created in the image in Kbytes. By default, this variable is set to "0". This free disk space is added to the image after the build system determines @@ -6514,7 +6323,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the size in Kbytes for the generated image. The OpenEmbedded build system determines the final size for the generated image using an algorithm that takes into account the initial disk space used @@ -6564,7 +6372,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a dependency from one image type on another. Here is an example from the <link linkend='ref-classes-image-live'><filename>image-live</filename></link> @@ -6594,18 +6401,17 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the complete list of supported image types by default: <literallayout class='monospaced'> btrfs + container cpio cpio.gz cpio.lz4 cpio.lzma cpio.xz cramfs - elf ext2 ext2.bz2 ext2.gz @@ -6614,13 +6420,14 @@ ext3.gz ext4 ext4.gz - hdddirect + f2fs hddimg iso jffs2 jffs2.sum multiubi squashfs + squashfs-lz4 squashfs-lzo squashfs-xz tar @@ -6628,6 +6435,7 @@ tar.gz tar.lz4 tar.xz + tar.zst ubi ubifs wic @@ -6652,7 +6460,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Helps define the recipe revision for recipes that share a common <filename>include</filename> file. You can think of this variable as part of the recipe revision @@ -6718,7 +6525,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a space-separated list of license names (as they would appear in <link linkend='var-LICENSE'><filename>LICENSE</filename></link>) @@ -6740,6 +6546,25 @@ components that are required to produce a functional system image. </note> + + <note><title>Tips</title> + It is possible to define a list of licenses that are allowed + to be used instead of the licenses that are excluded. To do + this, define a + variable <filename>COMPATIBLE_LICENSES</filename> with the + names of the licences that are allowed. Then + define <filename>INCOMPATIBLE_LICENSE</filename> as: + <literallayout class='monospaced'> + INCOMPATIBLE_LICENSE = "${@' '.join(sorted(set(d.getVar('AVAILABLE_LICENSES').split()) - set(d.getVar('COMPATIBLE_LICENSES').split())))}" + </literallayout> + This will result + in <filename>INCOMPATIBLE_LICENSE</filename> containing the + names of all licences + from <link linkend='var-AVAILABLE_LICENSES'><filename>AVAILABLE_LICENSES</filename></link> + except the ones specified + in <filename>COMPATIBLE_LICENSES</filename>, thus only + allowing the latter licences to be used. + </note> </glossdef> </glossentry> @@ -6749,7 +6574,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Causes the named class or classes to be inherited globally. Anonymous functions in the class or classes are not executed for the @@ -6773,7 +6597,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists classes that will be inherited at the distribution level. It is unlikely that you want to edit this variable. @@ -6796,7 +6619,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Prevents the default dependencies, namely the C compiler and standard C library (libc), from being added to <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>. @@ -6817,7 +6639,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Prevents the OpenEmbedded build system from splitting out debug information during packaging. By default, the build system splits out debugging @@ -6848,7 +6669,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> If set to "1", causes the build to not strip binaries in resulting packages and prevents the <filename>-dbg</filename> package from containing the @@ -6866,13 +6686,49 @@ </glossdef> </glossentry> + <glossentry id='var-INHIBIT_SYSROOT_STRIP'><glossterm>INHIBIT_SYSROOT_STRIP</glossterm> + <info> + INHIBIT_SYSROOT_STRIP[doc] = "If set to "1", causes the build to not strip binaries in the resulting sysroot." + </info> + <glossdef> + <para role="glossdeffirst"> + If set to "1", causes the build to not strip binaries in + the resulting sysroot. + </para> + + <para> + By default, the OpenEmbedded build system strips + binaries in the resulting sysroot. + When you specifically set the + <filename>INHIBIT_SYSROOT_STRIP</filename> variable to + "1" in your recipe, you inhibit this stripping. + </para> + + <para> + If you want to use this variable, include the + <link linkend='ref-classes-staging'><filename>staging</filename></link> + class. + This class uses a <filename>sys_strip()</filename> + function to test for the variable and acts accordingly. + <note> + Use of the <filename>INHIBIT_SYSROOT_STRIP</filename> + variable occurs in rare and special circumstances. + For example, suppose you are building bare-metal + firmware by using an external GCC toolchain. + Furthermore, even if the toolchain's binaries are + strippable, other files exist that are needed for the + build that are not strippable. + </note> + </para> + </glossdef> + </glossentry> + <glossentry id='var-INITRAMFS_FSTYPES'><glossterm>INITRAMFS_FSTYPES</glossterm> <info> INITRAMFS_FSTYPES[doc] = "Defines the format for the output image of an initial RAM filesystem (initramfs), which is used during boot." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the format for the output image of an initial RAM filesystem (initramfs), which is used during boot. Supported formats are the same as those supported by the @@ -6901,7 +6757,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the <link linkend='var-PROVIDES'><filename>PROVIDES</filename></link> name of an image recipe that is used to build an initial @@ -6969,7 +6824,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Controls whether or not the image recipe specified by <link linkend='var-INITRAMFS_IMAGE'><filename>INITRAMFS_IMAGE</filename></link> is run through an extra pass @@ -7035,7 +6889,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The link name of the initial RAM filesystem image. This variable is set in the <filename>meta/classes/kernel-artifact-names.bbclass</filename> @@ -7065,7 +6918,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The base name of the initial RAM filesystem image. This variable is set in the <filename>meta/classes/kernel-artifact-names.bbclass</filename> @@ -7090,7 +6942,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Indicates list of filesystem images to concatenate and use as an initial RAM disk (<filename>initrd</filename>). </para> @@ -7110,7 +6961,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When building a "live" bootable image (i.e. when <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link> contains "live"), <filename>INITRD_IMAGE</filename> @@ -7133,7 +6983,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The filename of the initialization script as installed to <filename>${sysconfdir}/init.d</filename>. </para> @@ -7151,7 +7000,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of the packages that contain initscripts. If multiple packages are specified, you need to append the package name to the other <filename>INITSCRIPT_*</filename> as an override. @@ -7171,7 +7019,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the options to pass to <filename>update-rc.d</filename>. Here is an example: <literallayout class='monospaced'> @@ -7209,7 +7056,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the QA checks to skip for a specific package within a recipe. For example, to skip the check for symbolic link @@ -7236,7 +7082,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> By default, the <filename>tzdata</filename> recipe packages an <filename>/etc/timezone</filename> file. Set the <filename>INSTALL_TIMEZONE_FILE</filename> @@ -7252,7 +7097,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When the IPK backend is in use and package management is enabled on the target, you can use this variable to set up <filename>opkg</filename> in the target image @@ -7312,7 +7156,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the kernel architecture used when assembling the configuration. Architectures supported for this release are: @@ -7339,7 +7182,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A regular expression used by the build process to explicitly identify the kernel branch that is validated, patched, and configured during a build. @@ -7380,7 +7222,6 @@ KBRANCH_genericx86-64 = "standard/base" KBRANCH_edgerouter = "standard/edgerouter" KBRANCH_beaglebone = "standard/beaglebone" - KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb" </literallayout> The <filename>KBRANCH</filename> statements identify the kernel branch to use when building for each @@ -7395,7 +7236,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When used with the <link linkend='ref-classes-kernel-yocto'><filename>kernel-yocto</filename></link> class, specifies an "in-tree" kernel configuration file @@ -7451,7 +7291,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies an alternate kernel image type for creation in addition to the kernel image type specified using the <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link> @@ -7466,7 +7305,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the name of all of the build artifacts. You can change the name of the artifacts by changing the <filename>KERNEL_ARTIFACT_NAME</filename> variable. @@ -7505,7 +7343,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of classes defining kernel image types that the <link linkend='ref-classes-kernel'><filename>kernel</filename></link> class should inherit. @@ -7526,7 +7363,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the name of the generated Linux kernel device tree (i.e. the <filename>.dtb</filename>) file. <note> @@ -7535,15 +7371,9 @@ However, providing just the <filename>.dtb</filename> file is preferred. </note> - In order to use this variable, you must have the include - files in your kernel recipe: - <literallayout class='monospaced'> - require recipes-kernel/linux/linux-dtb.inc - </literallayout> - or - <literallayout class='monospaced'> - require recipes-kernel/linux/linux-yocto.inc - </literallayout> + In order to use this variable, the + <link linkend='ref-classes-kernel-devicetree'><filename>kernel-devicetree</filename></link> + class must be inherited. </para> </glossdef> </glossentry> @@ -7554,7 +7384,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The link name of the kernel device tree binary (DTB). This variable is set in the <filename>meta/classes/kernel-artifact-names.bbclass</filename> @@ -7584,7 +7413,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The base name of the kernel device tree binary (DTB). This variable is set in the <filename>meta/classes/kernel-artifact-names.bbclass</filename> @@ -7609,7 +7437,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies additional <filename>make</filename> command-line arguments the OpenEmbedded build system passes on when compiling the kernel. @@ -7623,7 +7450,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Includes additional kernel metadata. In the OpenEmbedded build system, the default Board Support Packages (BSPs) @@ -7672,7 +7498,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The link name of the kernel flattened image tree (FIT) image. This variable is set in the <filename>meta/classes/kernel-artifact-names.bbclass</filename> @@ -7702,7 +7527,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The base name of the kernel flattened image tree (FIT) image. This variable is set in the <filename>meta/classes/kernel-artifact-names.bbclass</filename> @@ -7727,7 +7551,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The link name for the kernel image. This variable is set in the <filename>meta/classes/kernel-artifact-names.bbclass</filename> @@ -7757,7 +7580,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the maximum size of the kernel image file in kilobytes. If <filename>KERNEL_IMAGE_MAXSIZE</filename> is set, @@ -7788,7 +7610,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The base name of the kernel image. This variable is set in the <filename>meta/classes/kernel-artifact-names.bbclass</filename> @@ -7813,7 +7634,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The type of kernel to build for a device, usually set by the machine configuration files and defaults to "zImage". This variable is used @@ -7835,7 +7655,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists kernel modules that need to be auto-loaded during boot. <note> @@ -7889,7 +7708,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Provides a list of modules for which the OpenEmbedded build system expects to find <filename>module_conf_</filename><replaceable>modname</replaceable> @@ -7908,7 +7726,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The location of the kernel sources. This variable is set to the value of the <link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link> @@ -7940,7 +7757,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The location of the kernel sources. This variable is set to the value of the <link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link> @@ -7972,7 +7788,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the version of the kernel as extracted from <filename>version.h</filename> or <filename>utsrelease.h</filename> within the kernel sources. @@ -7990,7 +7805,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies whether the data referenced through <link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link> is needed or not. @@ -8012,7 +7826,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Provides a short description of a configuration fragment. You use this variable in the <filename>.scc</filename> file that describes a configuration fragment file. @@ -8032,7 +7845,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The machine as known by the kernel. Sometimes the machine name used by the kernel does not match the machine name used by the OpenEmbedded build @@ -8079,7 +7891,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the kernel type to be used in assembling the configuration. The linux-yocto recipes define "standard", "tiny", @@ -8109,7 +7920,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Provides a list of targets for automatic configuration. </para> @@ -8127,7 +7937,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists the layers, separated by spaces, on which this recipe depends. Optionally, you can specify a specific layer version for a @@ -8158,7 +7967,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When used inside the <filename>layer.conf</filename> configuration file, this variable provides the path of the current layer. This variable is not available outside of <filename>layer.conf</filename> @@ -8173,7 +7981,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists the layers, separated by spaces, recommended for use with this layer. </para> @@ -8206,7 +8013,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists the versions of the <link linkend='oe-core'>OpenEmbedded-Core</link> for which a layer is compatible. @@ -8253,7 +8059,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Optionally specifies the version of a layer as a single number. You can use this within <link linkend='var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link> @@ -8272,7 +8077,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal command and arguments used to run the linker. </para> @@ -8285,7 +8089,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the linker. This variable is exported to an environment variable and thus made visible to the software being @@ -8321,7 +8124,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the lead (or primary) compiled library file (i.e. <filename>.so</filename>) that the <link linkend='ref-classes-debian'><filename>debian</filename></link> @@ -8342,7 +8144,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Checksums of the license text in the recipe source code. </para> @@ -8371,7 +8172,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The list of source licenses for the recipe. Follow these rules: <itemizedlist> @@ -8436,7 +8236,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Setting <filename>LICENSE_CREATE_PACKAGE</filename> to "1" causes the OpenEmbedded build system to create an extra package (i.e. @@ -8479,7 +8278,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies additional flags for a recipe you must whitelist through <link linkend='var-LICENSE_FLAGS_WHITELIST'><filename>LICENSE_FLAGS_WHITELIST</filename></link> @@ -8507,7 +8305,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists license flags that when specified in <link linkend='var-LICENSE_FLAGS'><filename>LICENSE_FLAGS</filename></link> within a recipe should not prevent that recipe from being @@ -8527,7 +8324,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Path to additional licenses used during the build. By default, the OpenEmbedded build system uses <filename>COMMON_LICENSE_DIR</filename> to define the directory that holds common license text used during the build. @@ -8546,7 +8342,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the kernel type to be used in assembling the configuration. The linux-yocto recipes define "standard", "tiny", and @@ -8579,7 +8374,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The Linux version from <filename>kernel.org</filename> on which the Linux kernel image being built using the OpenEmbedded build system is based. @@ -8610,7 +8404,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A string extension compiled into the version string of the Linux kernel built with the OpenEmbedded build system. @@ -8643,7 +8436,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the directory to which the OpenEmbedded build system writes overall log files. The default directory is <filename>${TMPDIR}/log</filename>. @@ -8667,7 +8459,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the target device for which the image is built. You define <filename>MACHINE</filename> in the <filename>local.conf</filename> file found in the @@ -8704,7 +8495,6 @@ MACHINE ?= "genericx86" MACHINE ?= "genericx86-64" MACHINE ?= "beaglebone" - MACHINE ?= "mpc8315e-rdb" MACHINE ?= "edgerouter" </literallayout> The last five are Yocto Project reference hardware boards, which @@ -8723,7 +8513,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the name of the machine-specific architecture. This variable is set automatically from <link linkend='var-MACHINE'><filename>MACHINE</filename></link> @@ -8741,7 +8530,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of required machine-specific packages to install as part of the image being built. The build process depends on these packages being present. @@ -8778,7 +8566,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of recommended machine-specific packages to install as part of the image being built. The build process does not depend on these packages being present. @@ -8842,7 +8629,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of machine-specific packages to install as part of the image being built that are not essential for the machine to boot. However, the build process for more fully-featured images @@ -8888,7 +8674,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of machine-specific packages to install as part of the image being built that are not essential for booting the machine. The image being built has no build dependency on this list of packages. @@ -8933,7 +8718,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the list of hardware features the <link linkend='var-MACHINE'><filename>MACHINE</filename></link> is capable of supporting. @@ -8960,7 +8744,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Features to be added to <filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename> if not also present in @@ -8984,7 +8767,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Features from <filename><link linkend='var-MACHINE_FEATURES_BACKFILL'>MACHINE_FEATURES_BACKFILL</link></filename> that should not be backfilled (i.e. added to @@ -9002,7 +8784,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A colon-separated list of overrides that apply to the current machine. By default, this list includes the value of @@ -9043,7 +8824,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The email address of the distribution maintainer. </para> </glossdef> @@ -9055,7 +8835,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies additional paths from which the OpenEmbedded build system gets source code. When the build system searches for source code, it first @@ -9084,7 +8863,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a prefix has been added to <link linkend='var-PN'><filename>PN</filename></link> to create a special version of a recipe or package (i.e. a Multilib version). @@ -9136,7 +8914,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> This variable has been replaced by the <filename>KERNEL_MODULE_AUTOLOAD</filename> variable. You should replace all occurrences of @@ -9165,7 +8942,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies <ulink url='http://linux.die.net/man/5/modprobe.d'><filename>modprobe.d</filename></ulink> syntax lines for inclusion in the @@ -9226,7 +9002,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Controls creation of the <filename>modules-*.tgz</filename> file. Set this variable to "0" to disable creation of this @@ -9242,7 +9017,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The link name of the kernel module tarball. This variable is set in the <filename>meta/classes/kernel-artifact-names.bbclass</filename> @@ -9272,7 +9046,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The base name of the kernel module tarball. This variable is set in the <filename>meta/classes/kernel-artifact-names.bbclass</filename> @@ -9299,7 +9072,6 @@ <glossdef> <para role="glossdeffirst"> --> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> <!-- Serves the same purpose as <link linkend='var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></link>, @@ -9326,7 +9098,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Uniquely identifies the type of the target system for which packages are being built. This variable allows output for different types of target @@ -9365,7 +9136,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A string identifying the host distribution. Strings consist of the host distributor ID followed by the release, as reported by the @@ -9395,7 +9165,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal command and arguments to run <filename>nm</filename>. </para> @@ -9408,7 +9177,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Avoids QA errors when you use a non-common, non-CLOSED license in a recipe. Packages exist, such as the linux-firmware package, with @@ -9442,7 +9210,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Prevents installation of all "recommended-only" packages. Recommended-only packages are packages installed only through the @@ -9503,7 +9270,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Disables auto package from splitting <filename>.debug</filename> files. If a recipe requires <filename>FILES_${PN}-dbg</filename> to be set manually, @@ -9529,7 +9295,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal command and arguments to run <filename>objcopy</filename>. </para> @@ -9542,7 +9307,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal command and arguments to run <filename>objdump</filename>. </para> @@ -9555,7 +9319,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-binconfig'><filename>binconfig</filename></link> class, this variable @@ -9589,7 +9352,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> An internal variable used to tell the OpenEmbedded build system what Python modules to import for every Python function run by the system. @@ -9608,7 +9370,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The name of the build environment setup script for the purposes of setting up the environment within the extensible SDK. @@ -9630,7 +9391,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Controls how the OpenEmbedded build system spawns interactive terminals on the host development system (e.g. using the BitBake command with the @@ -9662,7 +9422,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The directory from which the top-level build environment setup script is sourced. The Yocto Project provides a top-level build environment @@ -9686,7 +9445,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Declares the oldest version of the Linux kernel that the produced binaries must support. This variable is passed into the build of the Embedded @@ -9709,7 +9467,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A colon-separated list of overrides that currently apply. Overrides are a BitBake mechanism that allows variables to be selectively overridden at the end of parsing. @@ -9773,7 +9530,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The recipe name and version. <filename>P</filename> is comprised of the following: <literallayout class='monospaced'> @@ -9789,7 +9545,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The architecture of the resulting package or packages. </para> @@ -9825,7 +9580,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of architectures compatible with the target machine. This variable is set automatically and should not @@ -9845,7 +9599,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Enables easily adding packages to <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename> before <filename>${<link linkend='var-PN'>PN</link>}</filename> @@ -9861,7 +9614,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> This variable, which is set in the <filename>local.conf</filename> configuration file found in the <filename>conf</filename> folder of the @@ -9911,7 +9663,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Determines how to split up the binary and debug information when creating <filename>*-dbg</filename> packages to be used with the GNU Project Debugger (GDB). @@ -9933,7 +9684,6 @@ <filename>/bin/.debug</filename>. Source files are placed in <filename>/usr/src/debug</filename>. - This is the default behavior. </para></listitem> <listitem><para> "debug-file-directory": Debug symbol files are @@ -9957,6 +9707,7 @@ ".debug" previously described with the exception that all source files are placed in a separate <filename>*-src</filename> pkg. + This is the default behavior. </para></listitem> </itemizedlist> </para> @@ -9976,7 +9727,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Prevents specific packages from being installed when you are installing complementary packages. </para> @@ -10002,7 +9752,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists packages that should not be installed into an image. For example: <literallayout class='monospaced'> @@ -10054,7 +9803,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the list of architectures compatible with the device CPU. This variable is useful when you build for several different devices that use miscellaneous processors such as XScale and ARM926-EJS. @@ -10068,7 +9816,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Optionally specifies the package architectures used as part of the package feed URIs during the build. When used, the <filename>PACKAGE_FEED_ARCHS</filename> @@ -10123,7 +9870,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the base path used when constructing package feed URIs. The <filename>PACKAGE_FEED_BASE_PATHS</filename> variable @@ -10170,7 +9916,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the front portion of the package feed URI used by the OpenEmbedded build system. Each final package feed URI is comprised of @@ -10209,35 +9954,12 @@ </glossdef> </glossentry> - <glossentry id='var-PACKAGE_GROUP'><glossterm>PACKAGE_GROUP</glossterm> - <info> - PACKAGE_GROUP[doc] = "Defines one or more packages to include in an image when a specific item is included in IMAGE_FEATURES." - </info> - <glossdef> - <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - The <filename>PACKAGE_GROUP</filename> variable has been - renamed to - <link linkend='var-FEATURE_PACKAGES'><filename>FEATURE_PACKAGES</filename></link>. - See the variable description for - <filename>FEATURE_PACKAGES</filename> for information. - </para> - - <para> - If if you use the <filename>PACKAGE_GROUP</filename> - variable, the OpenEmbedded build system issues a warning - message. - </para> - </glossdef> - </glossentry> - <glossentry id='var-PACKAGE_INSTALL'><glossterm>PACKAGE_INSTALL</glossterm> <info> PACKAGE_INSTALL[doc] = "List of the packages to be installed into the image. The variable is generally not user-defined and uses IMAGE_INSTALL as part of the list." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The final list of packages passed to the package manager for installation into the image. </para> @@ -10272,7 +9994,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of packages the OpenEmbedded build system attempts to install when creating an image. If a listed package fails to install, the build system @@ -10288,7 +10009,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of functions run to pre-process the <link linkend='var-PKGD'><filename>PKGD</filename></link> directory prior to splitting the files out to individual @@ -10303,7 +10023,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of dependencies for post-installation and pre-installation scripts on native/cross tools. If your post-installation or pre-installation script can @@ -10328,18 +10047,25 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> This variable provides a means of enabling or disabling features of a recipe on a per-recipe basis. <filename>PACKAGECONFIG</filename> blocks are defined in recipes when you specify features and then arguments that define feature behaviors. - Here is the basic block structure: + Here is the basic block structure (broken over multiple + lines for readability): <literallayout class='monospaced'> PACKAGECONFIG ??= "f1 f2 f3 ..." - PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1,rt-recs-f1" - PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2,rt-recs-f2" - PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3,rt-recs-f3" + PACKAGECONFIG[f1] = "\ + --with-f1, \ + --without-f1, \ + build-deps-for-f1, \ + runtime-deps-for-f1, \ + runtime-recommends-for-f1, \ + packageconfig-conflicts-for-f1 \ + " + PACKAGECONFIG[f2] = "\ + ... and so on and so on ... </literallayout> </para> @@ -10348,7 +10074,7 @@ variable itself specifies a space-separated list of the features to enable. Following the features, you can determine the behavior of - each feature by providing up to five order-dependent + each feature by providing up to six order-dependent arguments, which are separated by commas. You can omit any argument you like but must retain the separating commas. @@ -10378,6 +10104,10 @@ (<link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>) that should be added if the feature is enabled. </para></listitem> + <listitem><para>Any conflicting (that is, mutually + exclusive) <filename>PACKAGECONFIG</filename> + settings for this feature. + </para></listitem> </orderedlist> </para> @@ -10385,25 +10115,23 @@ Consider the following <filename>PACKAGECONFIG</filename> block taken from the <filename>librsvg</filename> recipe. - In this example the feature is <filename>croco</filename>, + In this example the feature is <filename>gtk</filename>, which has three arguments that determine the feature's behavior. <literallayout class='monospaced'> - PACKAGECONFIG ??= "croco" - PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco" + PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3" </literallayout> - The <filename>--with-croco</filename> and - <filename>libcroco</filename> arguments apply only if + The <filename>--with-gtk3</filename> and + <filename>gtk+3</filename> arguments apply only if the feature is enabled. - In this case, <filename>--with-croco</filename> is + In this case, <filename>--with-gtk3</filename> is added to the configure script argument list and - <filename>libcroco</filename> is added to + <filename>gtk+3</filename> is added to <filename>DEPENDS</filename>. On the other hand, if the feature is disabled say through a <filename>.bbappend</filename> file in another layer, then - the second argument <filename>--without-croco</filename> is - added to the configure script rather than - <filename>--with-croco</filename>. + the second argument <filename>--without-gtk3</filename> is + added to the configure script instead. </para> <para> @@ -10457,7 +10185,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A space-separated list of configuration options generated from the <link linkend='var-PACKAGECONFIG'><filename>PACKAGECONFIG</filename></link> @@ -10488,7 +10215,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> For recipes inheriting the <link linkend='ref-classes-packagegroup'><filename>packagegroup</filename></link> class, setting @@ -10509,7 +10235,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The list of packages the recipe creates. The default value is the following: <literallayout class='monospaced'> @@ -10550,7 +10275,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A promise that your recipe satisfies runtime dependencies for optional modules that are found in other recipes. <filename>PACKAGES_DYNAMIC</filename> @@ -10593,7 +10317,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of functions run to perform additional splitting of files into individual packages. Recipes can either prepend to this variable or prepend @@ -10615,7 +10338,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Extra options passed to the <filename>make</filename> command during the <link linkend='ref-tasks-compile'><filename>do_compile</filename></link> @@ -10672,7 +10394,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Extra options passed to the <filename>make install</filename> command during the <link linkend='ref-tasks-install'><filename>do_install</filename></link> @@ -10709,7 +10430,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Determines the action to take when a patch fails. You can set this variable to one of two values: "noop" and "user". @@ -10737,7 +10457,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the utility used to apply patches for a recipe during the <link linkend='ref-tasks-patch'><filename>do_patch</filename></link> @@ -10768,7 +10487,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The epoch of the recipe. By default, this variable is unset. The variable is used to make upgrades possible when the @@ -10790,7 +10508,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the recipe or package name and includes all version and revision numbers (i.e. <filename>glibc-2.13-r20+svnr15508/</filename> and <filename>bash-4.2-r1/</filename>). @@ -10808,7 +10525,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-pixbufcache'><filename>pixbufcache</filename></link> class, this variable identifies packages that contain @@ -10829,7 +10545,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The name of the resulting package created by the OpenEmbedded build system. <note> @@ -10853,7 +10568,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The path to <filename>pkg-config</filename> files for the current build context. <filename>pkg-config</filename> reads this variable @@ -10868,7 +10582,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the destination directory for files to be packaged before they are split into individual packages. This directory defaults to the following: @@ -10889,7 +10602,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to a shared, global-state directory that holds data generated during the packaging process. During the packaging process, the @@ -10920,7 +10632,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the parent directory for files to be packaged after they have been split into individual packages. This directory defaults to the following: @@ -10944,7 +10655,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to a temporary work area where the <link linkend='ref-tasks-package'><filename>do_package</filename></link> task saves package metadata. @@ -10973,7 +10683,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The epoch of the package(s) built by the recipe. By default, <filename>PKGE</filename> is set to <link linkend='var-PE'><filename>PE</filename></link>. @@ -10987,7 +10696,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The revision of the package(s) built by the recipe. By default, <filename>PKGR</filename> is set to <link linkend='var-PR'><filename>PR</filename></link>. @@ -11001,7 +10709,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The version of the package(s) built by the recipe. By default, <filename>PKGV</filename> is set to @@ -11012,11 +10719,10 @@ <glossentry id='var-PN'><glossterm>PN</glossterm> <info> - PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package. + PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> This variable can have two separate functions depending on the context: a recipe name or a resulting package name. </para> @@ -11053,7 +10759,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists recipes you do not want the OpenEmbedded build system to build. This variable works in conjunction with the @@ -11080,7 +10785,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of functions to call once the OpenEmbedded build system has created the host part of the SDK. @@ -11109,7 +10813,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of functions to call once the OpenEmbedded build system has created the target part of the SDK. @@ -11138,7 +10841,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The revision of the recipe. The default value for this variable is "r0". Subsequent revisions of the recipe conventionally have the @@ -11194,7 +10896,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> If multiple recipes provide the same item, this variable determines which recipe is preferred and thus provides the item (i.e. the preferred provider). @@ -11244,7 +10945,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> If multiple versions of recipes exist, this variable determines which version is given preference. You must always suffix the variable with the @@ -11264,7 +10964,7 @@ Here are two examples: <literallayout class='monospaced'> PREFERRED_VERSION_python = "3.4.0" - PREFERRED_VERSION_linux-yocto = "4.12%" + PREFERRED_VERSION_linux-yocto = "5.0%" </literallayout> <note><title>Important</title> The use of the "<filename>%</filename>" character @@ -11310,14 +11010,14 @@ to set a machine-specific override. Here is an example: <literallayout class='monospaced'> - PREFERRED_VERSION_linux-yocto_qemux86 = "4.12%" + PREFERRED_VERSION_linux-yocto_qemux86 = "5.0%" </literallayout> Although not recommended, worst case, you can also use the "forcevariable" override, which is the strongest override possible. Here is an example: <literallayout class='monospaced'> - PREFERRED_VERSION_linux-yocto_forcevariable = "4.12%" + PREFERRED_VERSION_linux-yocto_forcevariable = "5.0%" </literallayout> <note> The <filename>_forcevariable</filename> override is @@ -11336,7 +11036,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies additional paths from which the OpenEmbedded build system gets source code. When the build system searches for source code, it first @@ -11385,7 +11084,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Indicates the importance of a package. </para> @@ -11411,7 +11109,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies libraries installed within a recipe that should be ignored by the OpenEmbedded build system's shared library resolver. @@ -11453,29 +11150,40 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of aliases by which a particular recipe can be known. By default, a recipe's own <filename><link linkend='var-PN'>PN</link></filename> is implicitly already in its <filename>PROVIDES</filename> - list. + list and therefore does not need to mention that it provides itself. If a recipe uses <filename>PROVIDES</filename>, the additional aliases are synonyms for the recipe and can - be useful satisfying dependencies of other recipes during + be useful for satisfying dependencies of other recipes during the build as specified by <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>. </para> <para> Consider the following example - <filename>PROVIDES</filename> statement from a recipe - file <filename>libav_0.8.11.bb</filename>: + <filename>PROVIDES</filename> statement from the recipe + file <filename>eudev_3.2.9.bb</filename>: <literallayout class='monospaced'> - PROVIDES += "libpostproc" + PROVIDES = "udev" </literallayout> The <filename>PROVIDES</filename> statement results in - the "libav" recipe also being known as "libpostproc". + the "eudev" recipe also being available as simply "udev". + + <note> + Given that a recipe's own recipe name is already + implicitly in its own <filename>PROVIDES</filename> list, + it is unnecessary to add aliases with the "+=" operator; + using a simple assignment will be sufficient. In other + words, while you could write: + <literallayout class='monospaced'> + PROVIDES += "udev" + </literallayout> + in the above, the "+=" is overkill and unnecessary. + </note> </para> <para> @@ -11530,7 +11238,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The network based <link linkend='var-PR'><filename>PR</filename></link> service host and port. @@ -11560,7 +11267,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies whether or not <ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Package Test</ulink> (ptest) functionality is enabled when building a recipe. @@ -11579,7 +11285,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The version of the recipe. The version is normally extracted from the recipe filename. For example, if the recipe is named @@ -11605,7 +11310,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When used by recipes that inherit the <link linkend='ref-classes-distutils3'><filename>distutils3</filename></link>, <link linkend='ref-classes-setuptools3'><filename>setuptools3</filename></link>, @@ -11641,7 +11345,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When used by recipes that inherit the <link linkend='ref-classes-distutils3'><filename>distutils3</filename></link>, <link linkend='ref-classes-setuptools3'><filename>setuptools3</filename></link>, @@ -11649,8 +11352,7 @@ or <link linkend='ref-classes-setuptools'><filename>setuptools</filename></link> classes, specifies the major Python version being built. - For Python 2.x, <filename>PYTHON_PN</filename> would - be "python2". For Python 3.x, the variable would be + For Python 3.x, <filename>PYTHON_PN</filename> would be "python3". You do not have to set this variable as the OpenEmbedded build system automatically sets it for you. @@ -11678,7 +11380,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal command and arguments to run <filename>ranlib</filename>. </para> @@ -11691,7 +11392,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The list of packages that conflict with packages. Note that packages will not be installed if conflicting packages are not first removed. @@ -11740,7 +11440,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists runtime dependencies of a package. These dependencies are other packages that must be installed in order for the package to function correctly. @@ -11903,7 +11602,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-distro_features_check'><filename>distro_features_check</filename></link> class, this @@ -11926,7 +11624,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> With <filename>rm_work</filename> enabled, this variable specifies a list of recipes whose work directories should not be removed. @@ -11942,7 +11639,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the root home directory. By default, this directory is set as follows in the BitBake configuration file: @@ -11979,7 +11675,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Indicates a filesystem image to include as the root filesystem. </para> @@ -11999,7 +11694,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of functions to call after the OpenEmbedded build system has installed packages. You can specify functions separated by semicolons: @@ -12026,7 +11720,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of functions to call once the OpenEmbedded build system has created the root filesystem. You can specify functions separated by semicolons: @@ -12053,7 +11746,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of functions to call after the OpenEmbedded build system has removed unnecessary packages. @@ -12086,7 +11778,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of functions to call before the OpenEmbedded build system has created the root filesystem. You can specify functions separated by semicolons: @@ -12113,7 +11804,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of package name aliases that a package also provides. These aliases are useful for satisfying runtime dependencies of other packages both during the build and on the target @@ -12142,7 +11832,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of packages that extends the usability of a package being built. The package being built does not depend on this list of @@ -12235,7 +11924,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of packages replaced by a package. The package manager uses this variable to determine which package should be installed to replace other package(s) @@ -12291,7 +11979,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of additional packages that you can suggest for installation by the package manager at the time a package is installed. @@ -12320,7 +12007,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The location in the <link linkend='build-directory'>Build Directory</link> where unpacked recipe source code resides. @@ -12373,7 +12059,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of command-line utilities that should be checked for during the initial sanity checking process when running BitBake. @@ -12389,7 +12074,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of the host distribution identifiers that the build system has been tested against. Identifiers consist of the host distributor ID @@ -12414,7 +12098,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The target architecture for the SDK. Typically, you do not directly set this variable. Instead, use @@ -12429,7 +12112,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The directory set up and used by the <link linkend='ref-classes-populate-sdk'><filename>populate_sdk_base</filename></link> class to which the SDK is deployed. @@ -12448,7 +12130,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The parent directory used by the OpenEmbedded build system when creating SDK output. The @@ -12474,7 +12155,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Controls whether or not shared state artifacts are copied into the extensible SDK. The default value of "full" copies all of the required @@ -12498,7 +12178,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The manifest file for the host part of the SDK. This file lists all the installed packages that make up the host part of the SDK. @@ -12531,7 +12210,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When set to "1", specifies to include the packagedata for all recipes in the "world" target in the extensible SDK. Including this data allows the @@ -12556,7 +12234,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When set to "1", specifies to include the toolchain in the extensible SDK. Including the toolchain is useful particularly when @@ -12564,7 +12241,7 @@ is set to "minimal" to keep the SDK reasonably small but you still want to provide a usable toolchain. For example, suppose you want to use the toolchain from an - IDE (e.g. Eclipse) or from other tools and you do not + IDE or from other tools and you do not want to perform additional steps to install the toolchain. </para> @@ -12583,7 +12260,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of classes to remove from the <link linkend='var-INHERIT'><filename>INHERIT</filename></link> value globally within the extensible SDK configuration. @@ -12617,7 +12293,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of variables not allowed through from the OpenEmbedded build system configuration into the extensible SDK configuration. @@ -12661,7 +12336,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of variables allowed through from the OpenEmbedded build system configuration into the extensible SDK configuration. @@ -12697,7 +12371,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The base name for SDK output files. The name is derived from the <link linkend='var-DISTRO'><filename>DISTRO</filename></link>, @@ -12720,7 +12393,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the operating system for which the SDK will be built. The default value is the value of @@ -12735,7 +12407,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The location used by the OpenEmbedded build system when creating SDK output. The @@ -12765,7 +12436,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of architectures compatible with the SDK machine. This variable is set automatically and should not @@ -12785,7 +12455,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of functions to call once the OpenEmbedded build system creates the SDK. You can specify functions separated by semicolons: @@ -12813,7 +12482,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The toolchain binary prefix used for <filename>nativesdk</filename> recipes. The OpenEmbedded build system uses the @@ -12831,7 +12499,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of shared state tasks added to the extensible SDK. By default, the following tasks are added: <literallayout class='monospaced'> @@ -12858,7 +12525,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the system, including the architecture and the operating system, for which the SDK will be built. </para> @@ -12882,7 +12548,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The manifest file for the target part of the SDK. This file lists all the installed packages that make up the target part of the SDK. @@ -12915,7 +12580,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of targets to install from shared state as part of the standard or extensible SDK installation. The default value is "${PN}" (i.e. the image from which @@ -12935,7 +12599,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The title to be printed when running the SDK installer. By default, this title is based on the <link linkend='var-DISTRO_NAME'><filename>DISTRO_NAME</filename></link> @@ -12968,7 +12631,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> An optional URL for an update server for the extensible SDK. If set, the value is used as the default update server when @@ -12984,7 +12646,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the name of the SDK vendor. </para> </glossdef> @@ -12996,13 +12657,12 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the version of the SDK. The distribution configuration file (e.g. <filename>/meta-poky/conf/distro/poky.conf</filename>) defines the <filename>SDK_VERSION</filename> as follows: <literallayout class='monospaced'> - SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}" + SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}" </literallayout> </para> @@ -13022,7 +12682,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The default installation directory for the Extensible SDK. By default, this directory is based on the <link linkend='var-DISTRO'><filename>DISTRO</filename></link> @@ -13052,7 +12711,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Equivalent to <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>. However, this variable applies to the SDK generated from an @@ -13070,7 +12728,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The machine for which the SDK is built. In other words, the SDK is built such that it runs on the target you specify with the @@ -13102,7 +12759,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the path offered to the user for installation of the SDK that is generated by the OpenEmbedded build system. @@ -13120,7 +12776,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The full path to the sysroot used for cross-compilation within an SDK as it will be when installed into the default @@ -13135,7 +12790,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The section in which packages should be categorized. Package management utilities can make use of this variable. </para> @@ -13148,7 +12802,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the optimization flags passed to the C compiler when building for the target. The flags are passed through the default value of the @@ -13173,7 +12826,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines a serial console (TTY) to enable using <ulink url='https://en.wikipedia.org/wiki/Getty_(Unix)'>getty</ulink>. Provide a value that specifies the baud rate followed by @@ -13199,7 +12851,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines a serial console (TTY) to enable using <ulink url='https://en.wikipedia.org/wiki/Getty_(Unix)'>getty</ulink>. Provide a value that specifies the baud rate followed by @@ -13218,7 +12869,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies serial consoles, which must be listed in <link linkend='var-SERIAL_CONSOLES'><filename>SERIAL_CONSOLES</filename></link>, to check against <filename>/proc/console</filename> @@ -13244,7 +12894,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of recipe dependencies that should not be used to determine signatures of tasks from one recipe when they depend on tasks from another recipe. @@ -13296,7 +12945,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of recipes that are completely stable and will never change. The ABI for the recipes in the list are presented by @@ -13320,7 +12968,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the number of bits for the target system CPU. The value should be either "32" or "64". </para> @@ -13333,7 +12980,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the endian byte order of the target system. The value should be either "le" for little-endian or "be" for big-endian. </para> @@ -13342,12 +12988,10 @@ <glossentry id='var-SKIP_FILEDEPS'><glossterm>SKIP_FILEDEPS</glossterm> <info> - SKIP_FILEDEPS[doc] = "Enables you to remove all files from - the "Provides" section of an RPM package." + SKIP_FILEDEPS[doc] = "Enables you to remove all files from the 'Provides' section of an RPM package." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Enables removal of all files from the "Provides" section of an RPM package. Removal of these files is required for packages containing @@ -13374,7 +13018,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Groups together machines based upon the same family of SOC (System On Chip). You typically set this variable in a common @@ -13396,7 +13039,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the suffix for shared libraries used on the target platform. By default, this suffix is ".so.*" for all Linux-based @@ -13418,7 +13060,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines the suffix for the development symbolic link (symlink) for shared libraries on the target platform. By default, this suffix is ".so" for Linux-based @@ -13440,7 +13081,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When you are fetching files to create a mirror of sources (i.e. creating a source mirror), setting <filename>SOURCE_MIRROR_FETCH</filename> to "1" in your @@ -13472,7 +13112,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Defines your own <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link> from which to first fetch source before attempting to fetch @@ -13503,7 +13142,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Maps commonly used license names to their SPDX counterparts found in <filename>meta/files/common-licenses/</filename>. For the default <filename>SPDXLICENSEMAP</filename> @@ -13525,7 +13163,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of prefixes for <link linkend='var-PN'><filename>PN</filename></link> used by the OpenEmbedded build system to create variants of recipes or packages. The list specifies the prefixes to strip off during certain circumstances @@ -13540,7 +13177,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The file type for the Secondary Program Loader (SPL). Some devices use an SPL from which to boot (e.g. the BeagleBone development board). @@ -13582,7 +13218,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The list of source files - local or remote. This variable tells the OpenEmbedded build system which bits to pull in for the build and how to pull them in. @@ -13677,6 +13312,9 @@ a secure shell.</para></listitem> <listitem><para><emphasis><filename>svn://</filename> -</emphasis> Fetches files from a Subversion (<filename>svn</filename>) revision control repository.</para></listitem> + <listitem><para><emphasis><filename>npm://</filename> -</emphasis> Fetches JavaScript + modules from a registry. + </para></listitem> </itemizedlist> </para> @@ -13771,7 +13409,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> By default, the OpenEmbedded build system automatically detects whether <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> contains files that are machine-specific. @@ -13788,7 +13425,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The date of the source code used to build the package. This variable applies only if the source was fetched from a Source Code Manager (SCM). </para> @@ -13801,7 +13437,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Returns the version string of the current package. This string is used to help define the value of <link linkend='var-PV'><filename>PV</filename></link>. @@ -13839,7 +13474,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The revision of the source code used to build the package. This variable applies to Subversion, Git, Mercurial, and Bazaar only. @@ -13869,7 +13503,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The directory for the shared state cache. </para> </glossdef> @@ -13881,7 +13514,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> If set to "1", allows fetches from mirrors that are specified in <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link> @@ -13904,7 +13536,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Configures the OpenEmbedded build system to search other mirror locations for prebuilt cache data objects before building out the data. @@ -13927,7 +13558,7 @@ <para> When pointing to sstate build artifacts on another machine that uses a different GCC version for native builds, - you must configure <filename>SSTATE_MIRROR</filename> + you must configure <filename>SSTATE_MIRRORS</filename> with a regular expression that maps local search paths to server paths. The paths need to take into account @@ -13965,7 +13596,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Controls the list of files the OpenEmbedded build system scans for hardcoded installation paths. The variable uses a space-separated list of filenames (not paths) with standard @@ -14000,7 +13630,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/lib</filename> subdirectory of the sysroot directory for the build host. @@ -14014,7 +13643,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/lib</filename> subdirectory of the sysroot directory for the target for which the current recipe is being built @@ -14029,7 +13657,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/usr/bin</filename> subdirectory of the sysroot directory for the target for which the current @@ -14045,7 +13672,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the directory containing binary configuration scripts. These scripts provide configuration information for @@ -14071,7 +13697,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/usr/bin</filename> subdirectory of the sysroot directory for the build host. @@ -14085,7 +13710,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/usr/share</filename> subdirectory of the sysroot directory for the target for which the current recipe is being built @@ -14100,7 +13724,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/usr/share</filename> subdirectory of the sysroot directory for the build host. </para> @@ -14113,7 +13736,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Helps construct the <filename>recipe-sysroots</filename> directory, which is used during packaging. </para> @@ -14152,7 +13774,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the sysroot directory for the system on which the component is built to run (the system that hosts the component). @@ -14223,7 +13844,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the sysroot directory used when building components that run on the build host itself. </para> @@ -14236,7 +13856,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the sysroot used for the system for which the component generates code. For components that do not generate code, which is the @@ -14268,7 +13887,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/etc</filename> subdirectory of the sysroot directory for the build host. @@ -14282,7 +13900,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/usr</filename> subdirectory of the sysroot directory for the target for which the current recipe is being built @@ -14297,7 +13914,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/usr/include</filename> subdirectory of the sysroot directory for the target for which the current @@ -14313,7 +13929,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/usr/include</filename> subdirectory of the sysroot directory for the build host. </para> @@ -14326,7 +13941,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the directory containing the kernel build artifacts. Recipes building software that needs to access kernel @@ -14345,7 +13959,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The directory with kernel headers that are required to build out-of-tree modules. </para> @@ -14358,7 +13971,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/usr/lib</filename> subdirectory of the sysroot directory for the target for which the current recipe is being built @@ -14373,7 +13985,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the path to the <filename>/usr/lib</filename> subdirectory of the sysroot directory for the build host. </para> @@ -14386,7 +13997,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the base path used to create recipe stamp files. The path to an actual stamp file is constructed by evaluating this string and then appending additional information. @@ -14423,7 +14033,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the base directory in which the OpenEmbedded build system places stamps. The default directory is @@ -14438,7 +14047,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The minimal command and arguments to run <filename>strip</filename>, which is used to strip symbols. @@ -14452,7 +14060,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The short (72 characters or less) summary of the binary package for packaging systems such as <filename>opkg</filename>, <filename>rpm</filename>, or <filename>dpkg</filename>. @@ -14470,7 +14077,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The directory in which files checked out of a Subversion system are stored. </para> @@ -14483,7 +14089,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the kernel boot default console. If you want to use a console other than the default, set this variable in your recipe as follows where "X" is @@ -14508,7 +14113,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Lists additional options to add to the syslinux file. You need to set this variable in your recipe. If you want to list multiple options, separate the options @@ -14529,7 +14133,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the alternate serial port or turns it off. To turn off serial, set this variable to an empty string in your recipe. @@ -14553,7 +14156,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> An <filename>.LSS</filename> file used as the background for the VGA boot menu when you use the boot menu. You need to set this variable in your recipe. @@ -14574,7 +14176,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the alternate console=tty... kernel boot argument. The variable's default value is set in the <link linkend='ref-classes-syslinux'><filename>syslinux</filename></link> @@ -14596,7 +14197,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the temporary directory under the work directory (default "<filename>${</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link><filename>}/sysroot-destdir</filename>") @@ -14614,7 +14214,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Directories that are staged into the sysroot by the <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link> task. @@ -14638,7 +14237,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Directories that are not staged into the sysroot by the <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link> task. @@ -14668,7 +14266,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Extra directories staged into the sysroot by the <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link> task for <filename>-native</filename> recipes, in addition @@ -14703,7 +14300,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of functions to execute after files are staged into the sysroot. These functions are usually used to apply additional @@ -14719,7 +14315,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-systemd'><filename>systemd</filename></link> class, this variable specifies whether the specified service @@ -14749,7 +14344,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When <link linkend='var-EFI_PROVIDER'><filename>EFI_PROVIDER</filename></link> is set to "systemd-boot", the @@ -14777,7 +14371,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When <link linkend='var-EFI_PROVIDER'><filename>EFI_PROVIDER</filename></link> is set to "systemd-boot", the @@ -14807,7 +14400,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When <link linkend='var-EFI_PROVIDER'><filename>EFI_PROVIDER</filename></link> is set to "systemd-boot", the @@ -14835,7 +14427,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-systemd'><filename>systemd</filename></link> class, this variable locates the systemd unit files when @@ -14865,7 +14456,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-systemd'><filename>systemd</filename></link> class, this variable specifies the systemd service name for @@ -14890,7 +14480,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When using <ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services'>SysVinit</ulink>, specifies a space-separated list of the virtual terminals @@ -14919,7 +14508,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> This variable points to a directory were BitBake places temporary files, which consist mostly of task logs and scripts, when building a particular recipe. @@ -14948,7 +14536,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The target machine's architecture. The OpenEmbedded build system supports many architectures. @@ -14981,7 +14568,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies architecture-specific assembler flags for the target system. <filename>TARGET_AS_ARCH</filename> is initialized from @@ -15001,7 +14587,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies architecture-specific C compiler flags for the target system. <filename>TARGET_CC_ARCH</filename> is initialized from @@ -15025,7 +14610,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> This is a specific kernel compiler flag for a CPU or Application Binary Interface (ABI) tune. The flag is used rarely and only for cases where a @@ -15050,7 +14634,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C compiler when building for the target. When building in the target context, @@ -15074,7 +14657,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C pre-processor (i.e. to both the C and the C++ compilers) when building for the target. @@ -15099,7 +14681,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the C++ compiler when building for the target. When building in the target context, @@ -15123,7 +14704,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the method for handling FPU code. For FPU-less targets, which include most ARM CPUs, the variable must be set to "soft". @@ -15138,7 +14718,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies architecture-specific linker flags for the target system. <filename>TARGET_LD_ARCH</filename> is initialized from @@ -15158,7 +14737,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the flags to pass to the linker when building for the target. When building in the target context, @@ -15184,7 +14762,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the target's operating system. The variable can be set to "linux" for glibc-based systems (GNU C Library) and to "linux-musl" for musl libc. @@ -15200,7 +14777,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the prefix used for the toolchain binary target tools. </para> @@ -15236,7 +14812,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the system, including the architecture and the operating system, for which the build is occurring in the context of the current recipe. @@ -15279,7 +14854,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the name of the target vendor. </para> </glossdef> @@ -15287,11 +14861,10 @@ <glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm> <info> - TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or "newlib." + TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or 'newlib'." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the GNU standard C library (<filename>libc</filename>) variant to use during the build process. @@ -15311,7 +14884,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a suffix to be appended onto the <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> value. @@ -15342,7 +14914,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the toolchain selector. <filename>TCMODE</filename> controls the characteristics of the generated packages and images by telling the @@ -15414,7 +14985,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The location the OpenEmbedded build system uses to export tests when the <link linkend='var-TEST_EXPORT_ONLY'><filename>TEST_EXPORT_ONLY</filename></link> @@ -15434,7 +15004,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies to export the tests only. Set this variable to "1" if you do not want to run the tests but you want them to be exported in a manner that @@ -15449,7 +15018,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Holds the SSH log and the boot log for QEMU machines. The <filename>TEST_LOG_DIR</filename> variable defaults to <filename>"${WORKDIR}/testimage"</filename>. @@ -15468,7 +15036,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> For automated hardware testing, specifies the command to use to control the power of the target machine under test. Typically, this command would point to a script that @@ -15488,7 +15055,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> For automated hardware testing, specifies additional arguments to pass through to the command specified in <link linkend='var-TEST_POWERCONTROL_CMD'><filename>TEST_POWERCONTROL_CMD</filename></link>. @@ -15507,7 +15073,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The time in seconds allowed for an image to boot before automated runtime tests begin to run against an image. @@ -15531,7 +15096,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> For automated hardware testing, specifies the command to use to connect to the serial console of the target machine under test. @@ -15557,7 +15121,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> For automated hardware testing, specifies additional arguments to pass through to the command specified in <link linkend='var-TEST_SERIALCONTROL_CMD'><filename>TEST_SERIALCONTROL_CMD</filename></link>. @@ -15576,7 +15139,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The IP address of the build machine (host machine). This IP address is usually automatically detected. However, if detection fails, this variable needs to be set @@ -15599,12 +15161,11 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the target controller to use when running tests against a test image. - The default controller to use is "QemuTarget": + The default controller to use is "qemu": <literallayout class='monospaced'> - TEST_TARGET = "QemuTarget" + TEST_TARGET = "qemu" </literallayout> </para> @@ -15623,21 +15184,21 @@ You can provide the following arguments with <filename>TEST_TARGET</filename>: <itemizedlist> - <listitem><para><emphasis>"QemuTarget":</emphasis> + <listitem><para><emphasis>"qemu":</emphasis> Boots a QEMU image and runs the tests. See the "<ulink url='&YOCTO_DOCS_DEV_URL;#qemu-image-enabling-tests'>Enabling Runtime Tests on QEMU</ulink>" section in the Yocto Project Development Tasks Manual for more information. </para></listitem> - <listitem><para><emphasis>"SimpleRemoteTarget":</emphasis> + <listitem><para><emphasis>"simpleremote":</emphasis> Runs the tests on target hardware that is already up and running. The hardware can be on the network or it can be a device running an image on QEMU. You must also set <link linkend='var-TEST_TARGET_IP'><filename>TEST_TARGET_IP</filename></link> - when you use "SimpleRemoteTarget". + when you use "simpleremote". <note> This argument is defined in <filename>meta/lib/oeqa/controllers/simpleremote.py</filename>. @@ -15660,7 +15221,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The IP address of your hardware under test. The <filename>TEST_TARGET_IP</filename> variable has no effect when @@ -15690,7 +15250,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> An ordered list of tests (modules) to run against an image when performing automated runtime testing. </para> @@ -15749,7 +15308,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Automatically runs the series of automated tests for images when an image is successfully built. Setting <filename>TESTIMAGE_AUTO</filename> to "1" @@ -15790,7 +15348,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The directory in which the file BitBake is currently parsing is located. Do not manually set this variable. @@ -15804,7 +15361,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The time the build was started. Times appear using the hour, minute, and second (HMS) format (e.g. "140159" for one minute and fifty-nine @@ -15819,7 +15375,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> This variable is the base directory the OpenEmbedded build system uses for all build output and intermediate files (other than the shared state cache). @@ -15861,7 +15416,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> This variable lists packages the OpenEmbedded build system uses when building an SDK, which contains a cross-development environment. @@ -15903,7 +15457,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> This variable defines the name used for the toolchain output. The @@ -15929,7 +15482,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> This variable lists packages the OpenEmbedded build system uses when it creates the target part of an SDK (i.e. the part built for the target hardware), which @@ -15962,7 +15514,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The top-level <link linkend='build-directory'>Build Directory</link>. BitBake automatically sets this variable when you @@ -15978,7 +15529,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A sanitized version of <link linkend='var-TARGET_ARCH'><filename>TARGET_ARCH</filename></link>. This variable is used where the architecture is needed in @@ -16000,7 +15550,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The GNU canonical architecture for a specific architecture (i.e. <filename>arm</filename>, <filename>armeb</filename>, @@ -16059,7 +15608,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies architecture-specific assembler flags for the target system. The set of flags is based on the selected tune features. @@ -16090,7 +15638,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies architecture-specific C compiler flags for the target system. The set of flags is based on the selected tune features. @@ -16115,7 +15662,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies architecture-specific linker flags for the target system. The set of flags is based on the selected tune features. @@ -16146,7 +15692,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Features used to "tune" a compiler for optimal use given a specific processor. The features are defined within the tune files and allow @@ -16180,7 +15725,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The package architecture understood by the packaging system to define the architecture, ABI, and tuning of output packages. @@ -16211,7 +15755,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> An underlying Application Binary Interface (ABI) used by a particular tuning in a given toolchain layer. Providers that use prebuilt libraries can use the @@ -16239,7 +15782,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> If set, the OpenEmbedded system ignores the <link linkend='var-TUNEABI_WHITELIST'><filename>TUNEABI_WHITELIST</filename></link> variable. @@ -16266,7 +15808,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A whitelist of permissible <link linkend='var-TUNEABI'><filename>TUNEABI</filename></link> values. @@ -16294,7 +15835,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies CPU or Application Binary Interface (ABI) tuning features that conflict with <replaceable>feature</replaceable>. </para> @@ -16320,7 +15860,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a valid CPU or Application Binary Interface (ABI) tuning feature. The specified feature is stored as a flag. @@ -16350,7 +15889,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Configures the <link linkend='var-UBOOT_MACHINE'><filename>UBOOT_MACHINE</filename></link> and can also define @@ -16393,7 +15931,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the entry point for the U-Boot image. During U-Boot image creation, the <filename>UBOOT_ENTRYPOINT</filename> variable is passed @@ -16409,7 +15946,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the load address for the U-Boot image. During U-Boot image creation, the <filename>UBOOT_LOADADDRESS</filename> variable is passed @@ -16425,11 +15961,10 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Appends a string to the name of the local version of the U-Boot image. For example, assuming the version of the U-Boot image - built was "2013.10, the full version string reported by + built was "2013.10", the full version string reported by U-Boot would be "2013.10-yocto" given the following statement: <literallayout class='monospaced'> @@ -16445,7 +15980,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the value passed on the <filename>make</filename> command line when building a U-Boot image. @@ -16469,7 +16003,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the target called in the <filename>Makefile</filename>. The default target is "all". @@ -16483,7 +16016,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Points to the generated U-Boot extension. For example, <filename>u-boot.sb</filename> has a <filename>.sb</filename> extension. @@ -16502,7 +16034,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the target used for building U-Boot. The target is passed directly as part of the "make" command (e.g. SPL and AIS). @@ -16519,7 +16050,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a list of options that, if reported by the configure script as being invalid, should not generate a warning during the @@ -16557,7 +16087,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> For recipes inheriting the <link linkend='ref-classes-update-rc.d'><filename>update-rc.d</filename></link> class, <filename>UPDATERCPN</filename> specifies @@ -16580,17 +16109,16 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - When the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class is enabled globally, you can perform a per-recipe - check for what the latest upstream source code version is - by calling + You can perform a per-recipe check for what the latest + upstream source code version is by calling <filename>bitbake -c checkpkg</filename> <replaceable>recipe</replaceable>. If the recipe source code is provided from Git repositories, the OpenEmbedded build system determines the latest upstream version by picking the latest tag from the list of all repository tags. + </para> + + <para> You can use the <filename>UPSTREAM_CHECK_GITTAGREGEX</filename> variable to provide a regular expression to filter only the @@ -16609,12 +16137,8 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - When the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class is enabled globally, use the - <filename>UPSTREAM_CHECK_REGEX</filename> variable to - specify a different regular expression instead of the + Use the <filename>UPSTREAM_CHECK_REGEX</filename> variable + to specify a different regular expression instead of the default one when the package checking system is parsing the page found using <link linkend='var-UPSTREAM_CHECK_URI'><filename>UPSTREAM_CHECK_URI</filename></link>. @@ -16631,13 +16155,9 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - When the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class is enabled globally, you can perform a per-recipe - check for what the latest upstream source code version is - by calling <filename>bitbake -c checkpkg</filename> - <replaceable>recipe</replaceable>. + You can perform a per-recipe check for what the latest + upstream source code version is by calling + <filename>bitbake -c checkpkg</filename> <replaceable>recipe</replaceable>. If the source code is provided from tarballs, the latest version is determined by fetching the directory listing where the tarball is and attempting to find a later tarball. @@ -16658,7 +16178,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Determines if <filename>devtmpfs</filename> is used for <filename>/dev</filename> population. The default value used for <filename>USE_DEVFS</filename> @@ -16683,7 +16202,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When using <ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services'>SysVinit</ulink>, determines whether or not to run a @@ -16709,7 +16227,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> A list of classes to globally inherit. These classes are used by the OpenEmbedded build system to enable extra features (e.g. @@ -16733,18 +16250,20 @@ <glossentry id='var-USERADD_ERROR_DYNAMIC'><glossterm>USERADD_ERROR_DYNAMIC</glossterm> <info> - USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in files/passwd and files/group files. If set to 'warn', a warning will be issued instead." + USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in any of the files listed in USERADD_UID_TABLES and USERADD_GID_TABLES. If set to 'warn', a warning will be issued instead." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - If set to "error", forces the OpenEmbedded build system to - produce an error if the user identification - (<filename>uid</filename>) and group identification - (<filename>gid</filename>) values are not defined - in <filename>files/passwd</filename> - and <filename>files/group</filename> files. - If set to "warn", a warning will be issued instead. + + If set to <filename>error</filename>, forces the + OpenEmbedded build system to produce an error if the user + identification (<filename>uid</filename>) and group + identification (<filename>gid</filename>) values are not + defined in any of the files listed + in <link linkend='var-USERADD_UID_TABLES'><filename>USERADD_UID_TABLES</filename></link> + and <link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>. If + set to <filename>warn</filename>, a warning will be issued + instead. </para> <para> @@ -16771,6 +16290,20 @@ <link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link> variables. </para> + + <note> + There is a difference in behavior between + setting <filename>USERADD_ERROR_DYNAMIC</filename> + to <filename>error</filename> and setting it + to <filename>warn</filename>. When it is set + to <filename>warn</filename>, the build system will report a + warning for every undefined <filename>uid</filename> and + <filename>gid</filename> in any recipe. But when it is set + to <filename>error</filename>, it will only report errors + for recipes that are actually built. This saves you from + having to add static IDs for recipes that you know will + never be built. + </note> </glossdef> </glossentry> @@ -16780,7 +16313,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a password file to use for obtaining static group identification (<filename>gid</filename>) values when the OpenEmbedded build system adds a group to the @@ -16816,7 +16348,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-useradd'><filename>useradd</filename></link> class, this variable @@ -16853,7 +16384,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When inheriting the <link linkend='ref-classes-useradd'><filename>useradd</filename></link> class, this variable @@ -16884,7 +16414,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies a password file to use for obtaining static user identification (<filename>uid</filename>) values when the OpenEmbedded build system adds a user to the @@ -16920,7 +16449,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> When set to "useradd-staticids", causes the OpenEmbedded build system to base all user and group additions on a static @@ -16973,7 +16501,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the persistence of the target's <filename>/var/log</filename> directory, which is used to house postinstall target log files. @@ -16998,7 +16525,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the quality assurance checks whose failures are reported as warnings by the OpenEmbedded build system. You set this variable in your distribution configuration @@ -17070,7 +16596,7 @@ "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic'>Creating Partitioned Images Using Wic</ulink>" section in the Yocto Project Development Tasks Manual. For details on the kickstart file format, see the - "<link linkend='ref-kickstart'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link> + "<link linkend='ref-kickstart'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>" Chapter. </para> </glossdef> @@ -17082,7 +16608,6 @@ </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> The pathname of the work directory in which the OpenEmbedded build system builds a recipe. This directory is located within the @@ -17140,12 +16665,10 @@ <glossentry id='var-XSERVER'><glossterm>XSERVER</glossterm> <info> - XSERVER[doc] = "Specifies the packages that should be installed - to provide an X server and drivers for the current machine." + XSERVER[doc] = "Specifies the packages that should be installed to provide an X server and drivers for the current machine." </info> <glossdef> <para role="glossdeffirst"> -<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> Specifies the packages that should be installed to provide an X server and drivers for the current machine, assuming your image directly includes diff --git a/external/poky/documentation/ref-manual/resources.xml b/external/poky/documentation/ref-manual/resources.xml index be046961..afe8e288 100644 --- a/external/poky/documentation/ref-manual/resources.xml +++ b/external/poky/documentation/ref-manual/resources.xml @@ -155,7 +155,7 @@ </para></listitem> <listitem><para> <emphasis> - <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual:</ulink> + <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>: </emphasis> A comprehensive guide to the BitBake tool. If you want information on BitBake, see this manual. @@ -247,14 +247,6 @@ </para></listitem> <listitem><para> <emphasis> - <ulink url='&YOCTO_DOCS_SDK_URL;#adt-eclipse'>Eclipse IDE Yocto Plug-in</ulink>: - </emphasis> - Instructions that demonstrate how an application developer - uses the Eclipse Yocto Project Plug-in feature within - the Eclipse IDE. - </para></listitem> - <listitem><para> - <emphasis> <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>FAQ</ulink>: </emphasis> A list of commonly asked questions and their answers. diff --git a/external/poky/documentation/sdk-manual/figures/sdk-eclipse-dev-flow.png b/external/poky/documentation/sdk-manual/figures/sdk-eclipse-dev-flow.png Binary files differdeleted file mode 100644 index 9f986e0d..00000000 --- a/external/poky/documentation/sdk-manual/figures/sdk-eclipse-dev-flow.png +++ /dev/null diff --git a/external/poky/documentation/sdk-manual/sdk-appendix-customizing.xml b/external/poky/documentation/sdk-manual/sdk-appendix-customizing.xml index 7454c90b..911658f9 100644 --- a/external/poky/documentation/sdk-manual/sdk-appendix-customizing.xml +++ b/external/poky/documentation/sdk-manual/sdk-appendix-customizing.xml @@ -503,7 +503,7 @@ have set <filename>SDK_EXT_TYPE</filename> to "minimal", which by default, excludes the toolchain. Also, it is helpful if you are building a small SDK for use with - an IDE, such as <trademark class='trade'>Eclipse</trademark>, or some + an IDE or some other tool where you do not want to take extra steps to install a toolchain. </para> diff --git a/external/poky/documentation/sdk-manual/sdk-appendix-neon.xml b/external/poky/documentation/sdk-manual/sdk-appendix-neon.xml deleted file mode 100644 index 0fb92985..00000000 --- a/external/poky/documentation/sdk-manual/sdk-appendix-neon.xml +++ /dev/null @@ -1,956 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" -[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > - -<appendix id='sdk-appendix-neon-yp-eclipse-plug-in'> - <title>Using <trademark class='trade'>Eclipse</trademark> Neon</title> - - <para> - This release of the Yocto Project supports both the Oxygen and Neon - versions of the Eclipse IDE. - This appendix presents information that describes how to obtain and - configure the Neon version of Eclipse. - It also provides a basic project example that you can work through - from start to finish. - For general information on using the Eclipse IDE and the Yocto - Project Eclipse Plug-In, see the - "<link linkend='application-development-workflow-using-eclipse'>Application Development Workflow Using <trademark class='trade'>Eclipse</trademark></link>" - section. - </para> - - <section id='neon-setting-up-the-eclipse-ide'> - <title>Setting Up the Neon Version of the Eclipse IDE</title> - - <para> - To develop within the Eclipse IDE, you need to do the following: - <orderedlist> - <listitem><para>Install the Neon version of the Eclipse - IDE.</para></listitem> - <listitem><para>Configure the Eclipse IDE. - </para></listitem> - <listitem><para>Install the Eclipse Yocto Plug-in. - </para></listitem> - <listitem><para>Configure the Eclipse Yocto Plug-in. - </para></listitem> - </orderedlist> - <note> - Do not install Eclipse from your distribution's package - repository. - Be sure to install Eclipse from the official Eclipse - download site as directed in the next section. - </note> - </para> - - <section id='neon-installing-eclipse-ide'> - <title>Installing the Neon Eclipse IDE</title> - - <para> - Follow these steps to locate, install, and configure - Neon Eclipse: - <orderedlist> - <listitem><para><emphasis>Locate the Neon Download:</emphasis> - Open a browser and go to - <ulink url='http://www.eclipse.org/neon/'>http://www.eclipse.org/neon/</ulink>. - </para></listitem> - <listitem><para><emphasis>Download the Tarball:</emphasis> - Click the "Download" button and look for the - "Eclipse IDE for C/C++ Developers" Neon 3 Package. - Select the correct platform download link listed at - the right. - For example, click on "64-bit" next to Linux if your - build host is running a 64-bit Linux distribution. - Click through the process to save the file. - </para></listitem> - <listitem><para><emphasis>Unpack the Tarball:</emphasis> - Move to a directory and unpack the tarball. - The following commands unpack the tarball into the - home directory: - <literallayout class='monospaced'> - $ cd ~ - $ tar -xzvf ~/Downloads/eclipse-cpp-neon-3-linux-gtk-x86_64.tar.gz - </literallayout> - Everything unpacks into a folder named "Eclipse". - </para></listitem> - <listitem><para><emphasis>Launch Eclipse:</emphasis> - The following commands launch Eclipse assuming you - unpacked it in your home directory: - <literallayout class='monospaced'> - $ cd ~/eclipse - $ ./eclipse - </literallayout> - Accept the default "workspace" once Eclipse launches. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='neon-configuring-the-neon-eclipse-ide'> - <title>Configuring the Neon Eclipse IDE</title> - - <para> - Follow these steps to configure the Neon Eclipse IDE. - <note><title>Notes</title> - <itemizedlist> - <listitem><para> - Depending on how you installed Eclipse and what - you have already done, some of the options do - not appear. - If you cannot find an option as directed by the - manual, it has already been installed. - </para></listitem> - <listitem><para> - If you want to see all options regardless of - whether they are installed or not, deselect the - "Hide items that are already installed" - check box. - </para></listitem> - </itemizedlist> - </note> - <orderedlist> - <listitem><para>Be sure Eclipse is running and - you are in your workbench. - </para></listitem> - <listitem><para>Select "Install New Software" from - the "Help" pull-down menu. - </para></listitem> - <listitem><para>Select - "Neon - http://download.eclipse.org/releases/neon" - from the "Work with:" pull-down menu. - </para></listitem> - <listitem><para>Expand the box next to - "Linux Tools" and select the following - <literallayout class='monospaced'> - C/C++ Remote (Over TCF/TE) Run/Debug Launcher - TM Terminal - </literallayout> - </para></listitem> - <listitem><para>Expand the box next to "Mobile and - Device Development" and select the following - boxes: - <literallayout class='monospaced'> - C/C++ Remote (Over TCF/TE) Run/Debug Launcher - Remote System Explorer User Actions - TM Terminal - TCF Remote System Explorer add-in - TCF Target Explorer - </literallayout> - </para></listitem> - <listitem><para>Expand the box next to - "Programming Languages" and select the - following box: - <literallayout class='monospaced'> - C/C++ Development Tools SDK - </literallayout> - </para></listitem> - <listitem><para> - Complete the installation by clicking through - appropriate "Next" and "Finish" buttons. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='neon-installing-the-eclipse-yocto-plug-in'> - <title>Installing or Accessing the Neon Eclipse Yocto Plug-in</title> - - <para> - You can install the Eclipse Yocto Plug-in into the Eclipse - IDE one of two ways: use the Yocto Project's Eclipse - Update site to install the pre-built plug-in or build and - install the plug-in from the latest source code. - </para> - - <section id='neon-new-software'> - <title>Installing the Pre-built Plug-in from the Yocto Project Eclipse Update Site</title> - - <para> - To install the Neon Eclipse Yocto Plug-in from the update - site, follow these steps: - <orderedlist> - <listitem><para>Start up the Eclipse IDE. - </para></listitem> - <listitem><para>In Eclipse, select "Install New - Software" from the "Help" menu. - </para></listitem> - <listitem><para>Click "Add..." in the "Work with:" - area. - </para></listitem> - <listitem><para>Enter - <filename>&ECLIPSE_DL_PLUGIN_URL;/neon</filename> - in the URL field and provide a meaningful name - in the "Name" field. - </para></listitem> - <listitem><para> - Click "OK" to have the entry automatically - populate the "Work with:" field and to have - the items for installation appear in the window - below. - </para></listitem> - <listitem><para>Check the boxes next to the following: - <literallayout class='monospaced'> - Yocto Project SDK Plug-in - Yocto Project Documentation plug-in - </literallayout> - </para></listitem> - <listitem><para>Complete the remaining software - installation steps and then restart the Eclipse - IDE to finish the installation of the plug-in. - <note> - You can click "OK" when prompted about - installing software that contains unsigned - content. - </note> - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='neon-zip-file-method'> - <title>Installing the Plug-in Using the Latest Source Code</title> - - <para> - To install the Neon Eclipse Yocto Plug-in from the latest - source code, follow these steps: - <orderedlist> - <listitem><para> - Be sure your build host has JDK version 1.8 - or greater. - On a Linux build host you can determine the - version using the following command: - <literallayout class='monospaced'> - $ java -version - </literallayout> - </para></listitem> - <listitem><para>install X11-related packages: - <literallayout class='monospaced'> - $ sudo apt-get install xauth - </literallayout> - </para></listitem> - <listitem><para>In a new terminal shell, create a Git - repository with: - <literallayout class='monospaced'> - $ cd ~ - $ git clone git://git.yoctoproject.org/eclipse-yocto - </literallayout> - </para></listitem> - <listitem><para> - Use Git to create the correct tag: - <literallayout class='monospaced'> - $ cd ~/eclipse-yocto - $ git checkout -b neon/&DISTRO_NAME_NO_CAP; remotes/origin/neon/&DISTRO_NAME_NO_CAP; - </literallayout> - This creates a local tag named - <filename>neon/&DISTRO_NAME_NO_CAP;</filename> - based on the branch - <filename>origin/neon/&DISTRO_NAME_NO_CAP;</filename>. - You are put into a detached HEAD state, - which is fine since you are only going to - be building and not developing. - </para></listitem> - <listitem><para>Change to the - <filename>scripts</filename> - directory within the Git repository: - <literallayout class='monospaced'> - $ cd scripts - </literallayout> - </para></listitem> - <listitem><para>Set up the local build environment - by running the setup script: - <literallayout class='monospaced'> - $ ./setup.sh - </literallayout> - When the script finishes execution, - it prompts you with instructions on how to run - the <filename>build.sh</filename> script, which - is also in the <filename>scripts</filename> - directory of the Git repository created - earlier. - </para></listitem> - <listitem><para> - Run the <filename>build.sh</filename> - script as directed. - Be sure to provide the tag name, - documentation branch, and a release name.</para> - - <para>Following is an example: - <literallayout class='monospaced'> - $ ECLIPSE_HOME=/home/scottrif/eclipse-yocto/scripts/eclipse ./build.sh -l neon/&DISTRO_NAME_NO_CAP; master yocto-&DISTRO; 2>&1 | tee build.log - </literallayout> - The previous example command adds the tag - you need for - <filename>neon/&DISTRO_NAME_NO_CAP;</filename> - to <filename>HEAD</filename>, then tells - the build script to use the local (-l) Git - checkout for the build. - After running the script, the file - <filename>org.yocto.sdk-</filename><replaceable>release</replaceable><filename>-</filename><replaceable>date</replaceable><filename>-archive.zip</filename> - is in the current directory. - </para></listitem> - <listitem><para>If necessary, start the Eclipse IDE - and be sure you are in the Workbench. - </para></listitem> - <listitem><para>Select "Install New Software" from - the "Help" pull-down menu. - </para></listitem> - <listitem><para>Click "Add". - </para></listitem> - <listitem><para>Provide anything you want in the - "Name" field. - </para></listitem> - <listitem><para>Click "Archive" and browse to the - ZIP file you built earlier. - This ZIP file should not be "unzipped", and must - be the <filename>*archive.zip</filename> file - created by running the - <filename>build.sh</filename> script. - </para></listitem> - <listitem><para>Click the "OK" button. - </para></listitem> - <listitem><para>Check the boxes that appear in - the installation window to install the - following: - <literallayout class='monospaced'> - Yocto Project SDK Plug-in - Yocto Project Documentation plug-in - </literallayout> - </para></listitem> - <listitem><para>Finish the installation by clicking - through the appropriate buttons. - You can click "OK" when prompted about - installing software that contains unsigned - content. - </para></listitem> - <listitem><para>Restart the Eclipse IDE if - necessary. - </para></listitem> - </orderedlist> - </para> - - <para> - At this point you should be able to configure the - Eclipse Yocto Plug-in as described in the - "<link linkend='neon-configuring-the-eclipse-yocto-plug-in'>Configuring the Neon Eclipse Yocto Plug-in</link>" - section.</para> - </section> - </section> - - <section id='neon-configuring-the-eclipse-yocto-plug-in'> - <title>Configuring the Neon Eclipse Yocto Plug-In</title> - - <para> - Configuring the Neon Eclipse Yocto Plug-in involves setting the - Cross Compiler options and the Target options. - The configurations you choose become the default settings - for all projects. - You do have opportunities to change them later when - you configure the project (see the following section). - </para> - - <para> - To start, you need to do the following from within the - Eclipse IDE: - <orderedlist> - <listitem><para> - Choose "Preferences" from the - "Window" menu to display the Preferences Dialog. - </para></listitem> - <listitem><para> - Click "Yocto Project SDK" to display - the configuration screen. - </para></listitem> - </orderedlist> - The following sub-sections describe how to configure the - the plug-in. - <note> - Throughout the descriptions, a start-to-finish example for - preparing a QEMU image for use with Eclipse is referenced - as the "wiki" and is linked to the example on the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'> Cookbook guide to Making an Eclipse Debug Capable Image</ulink> - wiki page. - </note> - </para> - - <section id='neon-configuring-the-cross-compiler-options'> - <title>Configuring the Cross-Compiler Options</title> - - <para> - Cross Compiler options enable Eclipse to use your specific - cross compiler toolchain. - To configure these options, you must select - the type of toolchain, point to the toolchain, specify - the sysroot location, and select the target - architecture. - <itemizedlist> - <listitem><para> - <emphasis>Selecting the Toolchain Type:</emphasis> - Choose between "Standalone pre-built toolchain" - and - "Build system derived toolchain" for Cross Compiler - Options. - <itemizedlist> - <listitem><para> - <emphasis>Standalone Pre-built Toolchain:</emphasis> - Select this type when you are using - a stand-alone cross-toolchain. - For example, suppose you are an - application developer and do not - need to build a target image. - Instead, you just want to use an - architecture-specific toolchain on - an existing kernel and target root - filesystem. - In other words, you have downloaded - and installed a pre-built toolchain - for an existing image. - </para></listitem> - <listitem><para> - <emphasis>Build System Derived Toolchain:</emphasis> - Select this type if you built the - toolchain as part of the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>. - When you select "Build system derived - toolchain", you are using the toolchain - built and bundled inside the Build - Directory. - For example, suppose you created a - suitable image using the steps in the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>wiki</ulink>. - In this situation, you would select - "Build system derived toolchain". - </para></listitem> - </itemizedlist> - </para></listitem> - <listitem><para> - <emphasis>Specify the Toolchain Root Location:</emphasis> - If you are using a stand-alone pre-built - toolchain, you should be pointing to where it is - installed (e.g. - <filename>/opt/poky/&DISTRO;</filename>). - See the - "<link linkend='sdk-installing-the-sdk'>Installing the SDK</link>" - section for information about how the SDK is - installed.</para> - - <para>If you are using a build system derived - toolchain, the path you provide for the - "Toolchain Root Location" field is the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink> - from which you run the - <filename>bitbake</filename> command (e.g - <filename>/home/scottrif/poky/build</filename>).</para> - <para>For more information, see the - "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>" - section. - </para></listitem> - <listitem><para> - <emphasis>Specify Sysroot Location:</emphasis> - This location is where the root filesystem for - the target hardware resides. - </para> - - <para>This location depends on where you - separately extracted and installed the - target filesystem when you either built - it or downloaded it. - <note> - If you downloaded the root filesystem - for the target hardware rather than - built it, you must download the - <filename>sato-sdk</filename> image - in order to build any c/c++ projects. - </note> - As an example, suppose you prepared an image - using the steps in the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>wiki</ulink>. - If so, the <filename>MY_QEMU_ROOTFS</filename> - directory is found in the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink> - and you would browse to and select that directory - (e.g. <filename>/home/scottrif/build/MY_QEMU_ROOTFS</filename>). - </para> - - <para>For more information on how to install the - toolchain and on how to extract and install the - sysroot filesystem, see the - "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>" - section. - </para></listitem> - <listitem><para> - <emphasis>Select the Target Architecture:</emphasis> - The target architecture is the type of hardware - you are going to use or emulate. - Use the pull-down "Target Architecture" menu - to make your selection. - The pull-down menu should have the supported - architectures. - If the architecture you need is not listed in - the menu, you will need to build the image. - See the - "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-building-a-simple-image'>Building a Simple Image</ulink>" - section of the Yocto Project Development Tasks - Manual for more information. - You can also see the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>wiki</ulink>. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='neon-configuring-the-target-options'> - <title>Configuring the Target Options</title> - - <para> - You can choose to emulate hardware using the QEMU - emulator, or you can choose to run your image on actual - hardware. - <itemizedlist> - <listitem><para> - <emphasis>QEMU:</emphasis> - Select this option if you will be using the - QEMU emulator. - If you are using the emulator, you also need to - locate the kernel and specify any custom - options.</para> - - <para>If you selected the Build system derived - toolchain, the target kernel you built will be - located in the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink> - in - <filename>tmp/deploy/images/<replaceable>machine</replaceable></filename> - directory. - As an example, suppose you performed the steps in - the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>wiki</ulink>. - In this case, you specify your Build Directory path - followed by the image (e.g. - <filename>/home/scottrif/poky/build/tmp/deploy/images/qemux86/bzImage-qemux86.bin</filename>). - </para> - - <para>If you selected the standalone pre-built - toolchain, the pre-built image you downloaded is - located in the directory you specified when you - downloaded the image.</para> - - <para>Most custom options are for advanced QEMU - users to further customize their QEMU instance. - These options are specified between paired - angled brackets. - Some options must be specified outside the - brackets. - In particular, the options - <filename>serial</filename>, - <filename>nographic</filename>, and - <filename>kvm</filename> must all be outside the - brackets. - Use the <filename>man qemu</filename> command - to get help on all the options and their use. - The following is an example: - <literallayout class='monospaced'> - serial ‘<-m 256 -full-screen>’ - </literallayout> - Regardless of the mode, Sysroot is already - defined as part of the Cross-Compiler Options - configuration in the "Sysroot Location:" field. - </para></listitem> - <listitem><para> - <emphasis>External HW:</emphasis> - Select this option if you will be using actual - hardware. - </para></listitem> - </itemizedlist> - </para> - - <para> - Click the "Apply" and "OK" to save your plug-in - configurations. - </para> - </section> - </section> - </section> - - <section id='neon-creating-the-project'> - <title>Creating the Project</title> - - <para> - You can create two types of projects: Autotools-based, or - Makefile-based. - This section describes how to create Autotools-based projects - from within the Eclipse IDE. - For information on creating Makefile-based projects in a - terminal window, see the - "<link linkend='makefile-based-projects'>Makefile-Based Projects</link>" - section. - <note> - Do not use special characters in project names - (e.g. spaces, underscores, etc.). Doing so can - cause the configuration to fail. - </note> - </para> - - <para> - To create a project based on a Yocto template and then display - the source code, follow these steps: - <orderedlist> - <listitem><para> - Select "C Project" from the "File -> New" menu. - </para></listitem> - <listitem><para> - Expand "Yocto Project SDK Autotools Project". - </para></listitem> - <listitem><para> - Select "Hello World ANSI C Autotools Projects". - This is an Autotools-based project based on a Yocto - template. - </para></listitem> - <listitem><para> - Put a name in the "Project name:" field. - Do not use hyphens as part of the name - (e.g. "hello"). - </para></listitem> - <listitem><para> - Click "Next". - </para></listitem> - <listitem><para> - Add appropriate information in the various fields. - </para></listitem> - <listitem><para> - Click "Finish". - </para></listitem> - <listitem><para> - If the "open perspective" prompt appears, - click "Yes" so that you are in the C/C++ perspective. - </para></listitem> - <listitem><para> - The left-hand navigation pane shows your project. - You can display your source by double clicking the - project's source file. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='neon-configuring-the-cross-toolchains'> - <title>Configuring the Cross-Toolchains</title> - - <para> - The earlier section, - "<link linkend='neon-configuring-the-eclipse-yocto-plug-in'>Configuring the Neon Eclipse Yocto Plug-in</link>", - sets up the default project configurations. - You can override these settings for a given project by following - these steps: - <orderedlist> - <listitem><para> - Select "Yocto Project Settings" from - the "Project -> Properties" menu. - This selection brings up the Yocto Project Settings - Dialog and allows you to make changes specific to an - individual project.</para> - <para>By default, the Cross Compiler Options and Target - Options for a project are inherited from settings you - provided using the Preferences Dialog as described - earlier in the - "<link linkend='neon-configuring-the-eclipse-yocto-plug-in'>Configuring the Neon Eclipse Yocto Plug-in</link>" section. - The Yocto Project Settings Dialog allows you to override - those default settings for a given project. - </para></listitem> - <listitem><para> - Make or verify your configurations for the project and - click "OK". - </para></listitem> - <listitem><para> - Right-click in the navigation pane and select - "Reconfigure Project" from the pop-up menu. - This selection reconfigures the project by running - <ulink url='https://en.wikipedia.org/wiki/GNU_Build_System'>Autotools GNU utility programs</ulink> - such as Autoconf, Automake, and so forth in the - workspace for your project. - Click on the "Console" tab beneath your source code - to see the results of reconfiguring your project. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='neon-building-the-project'> - <title>Building the Project</title> - - <para> - To build the project select "Build All" from the - "Project" menu. - The console should update and you can note the cross-compiler - you are using. - <note> - When building "Yocto Project SDK Autotools" projects, the - Eclipse IDE might display error messages for - Functions/Symbols/Types that cannot be "resolved", even when - the related include file is listed at the project navigator and - when the project is able to build. - For these cases only, it is recommended to add a new linked - folder to the appropriate sysroot. - Use these steps to add the linked folder: - <orderedlist> - <listitem><para> - Select the project. - </para></listitem> - <listitem><para> - Select "Folder" from the "File > New" menu. - </para></listitem> - <listitem><para> - In the "New Folder" Dialog, select "Link to alternate - location (linked folder)". - </para></listitem> - <listitem><para> - Click "Browse" to navigate to the include folder inside - the same sysroot location selected in the Yocto Project - configuration preferences. - </para></listitem> - <listitem><para> - Click "OK". - </para></listitem> - <listitem><para> - Click "Finish" to save the linked folder. - </para></listitem> - </orderedlist> - </note> - </para> - </section> - - <section id='neon-starting-qemu-in-user-space-nfs-mode'> - <title>Starting QEMU in User-Space NFS Mode</title> - - <para> - To start the QEMU emulator from within Eclipse, follow these - steps: - <note> - See the - "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>Using the Quick EMUlator (QEMU)</ulink>" - chapter in the Yocto Project Development Tasks Manual - for more information on using QEMU. - </note> - <orderedlist> - <listitem><para>Expose and select "External Tools - Configurations ..." from the "Run -> External Tools" menu. - </para></listitem> - <listitem><para> - Locate and select your image in the navigation panel to - the left (e.g. <filename>qemu_i586-poky-linux</filename>). - </para></listitem> - <listitem><para> - Click "Run" to launch QEMU. - <note> - The host on which you are running QEMU must have - the <filename>rpcbind</filename> utility running to be - able to make RPC calls on a server on that machine. - If QEMU does not invoke and you receive error messages - involving <filename>rpcbind</filename>, follow the - suggestions to get the service running. - As an example, on a new Ubuntu 16.04 LTS installation, - you must do the following in order to get QEMU to - launch: - <literallayout class='monospaced'> - $ sudo apt-get install rpcbind - </literallayout> - After installing <filename>rpcbind</filename>, you - need to edit the - <filename>/etc/init.d/rpcbind</filename> file to - include the following line: - <literallayout class='monospaced'> - OPTIONS="-i -w" - </literallayout> - After modifying the file, you need to start the - service: - <literallayout class='monospaced'> - $ sudo service portmap restart - </literallayout> - </note> - </para></listitem> - <listitem><para>If needed, enter your host root password in - the shell window at the prompt. - This sets up a <filename>Tap 0</filename> connection - needed for running in user-space NFS mode. - </para></listitem> - <listitem><para>Wait for QEMU to launch. - </para></listitem> - <listitem><para>Once QEMU launches, you can begin operating - within that environment. - One useful task at this point would be to determine the - IP Address for the user-space NFS by using the - <filename>ifconfig</filename> command. - The IP address of the QEMU machine appears in the - xterm window. - You can use this address to help you see which particular - IP address the instance of QEMU is using. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='neon-deploying-and-debugging-the-application'> - <title>Deploying and Debugging the Application</title> - - <para> - Once the QEMU emulator is running the image, you can deploy - your application using the Eclipse IDE and then use - the emulator to perform debugging. - Follow these steps to deploy the application. - <note> - Currently, Eclipse does not support SSH port forwarding. - Consequently, if you need to run or debug a remote - application using the host display, you must create a - tunneling connection from outside Eclipse and keep - that connection alive during your work. - For example, in a new terminal, run the following: - <literallayout class='monospaced'> - $ ssh -XY <replaceable>user_name</replaceable>@<replaceable>remote_host_ip</replaceable> - </literallayout> - Using the above form, here is an example: - <literallayout class='monospaced'> - $ ssh -XY root@192.168.7.2 - </literallayout> - After running the command, add the command to be executed - in Eclipse's run configuration before the application - as follows: - <literallayout class='monospaced'> - export DISPLAY=:10.0 - </literallayout> - Be sure to not destroy the connection during your QEMU - session (i.e. do not - exit out of or close that shell). - </note> - <orderedlist> - <listitem><para> - Select "Debug Configurations..." from the - "Run" menu.</para></listitem> - <listitem><para> - In the left area, expand - "C/C++Remote Application". - </para></listitem> - <listitem><para> - Locate your project and select it to bring - up a new tabbed view in the Debug Configurations Dialog. - </para></listitem> - <listitem><para> - Click on the "Debugger" tab to see the - cross-tool debugger you are using. - Be sure to change to the debugger perspective in Eclipse. - </para></listitem> - <listitem><para> - Click on the "Main" tab. - </para></listitem> - <listitem><para>Create a new connection to the QEMU instance - by clicking on "new".</para></listitem> - <listitem><para> - Select "SSH", which means - Secure Socket Shell. - Optionally, you can select a TCF connection instead. - </para></listitem> - <listitem><para> - Click "Next". - </para></listitem> - <listitem><para> - Clear out the "Connection name" field and - enter any name you want for the connection. - </para></listitem> - <listitem><para> - Put the IP address for the connection in - the "Host" field. - For QEMU, the default is "192.168.7.2". - However, if a previous QEMU session did not exit - cleanly, the IP address increments (e.g. - "192.168.7.3"). - <note> - You can find the IP address for the current QEMU - session by looking in the xterm that opens when - you launch QEMU. - </note> - </para></listitem> - <listitem><para> - Enter "root", which - is the default for QEMU, for the "User" field. - Be sure to leave the password field empty. - </para></listitem> - <listitem><para>Click "Finish" to close the - New Connections Dialog. - </para></listitem> - <listitem><para> - If necessary, use the drop-down menu now in the - "Connection" field and pick the IP Address you entered. - </para></listitem> - <listitem><para> - Assuming you are connecting as the root user, - which is the default for QEMU x86-64 SDK images provided by - the Yocto Project, in the "Remote Absolute File Path for - C/C++ Application" field, browse to - <filename>/home/root/</filename><replaceable>ProjectName</replaceable> - (e.g. <filename>/home/root/hello</filename>). - You could also browse to any other path you have write - access to on the target such as - <filename>/usr/bin</filename>. - This location is where your application will be located on - the QEMU system. - If you fail to browse to and specify an appropriate - location, QEMU will not understand what to remotely - launch. - Eclipse is helpful in that it auto fills your application - name for you assuming you browsed to a directory. - <note><title>Tips</title> - <itemizedlist> - <listitem><para> - If you are prompted to provide a username - and to optionally set a password, be sure - you provide "root" as the username and you - leave the password field blank. - </para></listitem> - <listitem><para> - If browsing to a directory fails or times - out, but you can - <filename>ssh</filename> into your QEMU - or target from the command line and you - have proxies set up, it is likely that - Eclipse is sending the SSH traffic to a - proxy. - In this case, either use TCF , or click on - "Configure proxy settings" in the - connection dialog and add the target IP - address to the "bypass proxy" section. - You might also need to change - "Active Provider" from Native to Manual. - </para></listitem> - </itemizedlist> - </note> - </para></listitem> - <listitem><para> - Be sure you change to the "Debug" perspective in Eclipse. - </para></listitem> - <listitem><para> - Click "Debug" - </para></listitem> - <listitem><para> - Accept the debug perspective. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='neon-using-Linuxtools'> - <title>Using Linuxtools</title> - - <para> - As mentioned earlier in the manual, performance tools exist - (Linuxtools) that enhance your development experience. - These tools are aids in developing and debugging applications and - images. - You can run these tools from within the Eclipse IDE through the - "Linuxtools" menu. - </para> - - <para> - For information on how to configure and use these tools, see - <ulink url='http://www.eclipse.org/linuxtools/'>http://www.eclipse.org/linuxtools/</ulink>. - </para> - </section> -</appendix> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/external/poky/documentation/sdk-manual/sdk-appendix-obtain.xml b/external/poky/documentation/sdk-manual/sdk-appendix-obtain.xml index 2cadcc1e..86b6d7dd 100644 --- a/external/poky/documentation/sdk-manual/sdk-appendix-obtain.xml +++ b/external/poky/documentation/sdk-manual/sdk-appendix-obtain.xml @@ -216,12 +216,6 @@ TOOLCHAIN_TARGET_TASK_append = " libc-staticdev" </literallayout> </para></listitem> - <listitem><para> - For additional information on building the - installer, see the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>Cookbook guide to Making an <trademark class='trade'>Eclipse</trademark> Debug Capable Image</ulink> - wiki page. - </para></listitem> </itemizedlist> </note> </para></listitem> @@ -259,9 +253,6 @@ <listitem><para> You want to use the root filesystem as the target sysroot. - For example, the Eclipse IDE environment with the Eclipse - Yocto Plug-in installed allows you to use QEMU to boot - under NFS. </para></listitem> <listitem><para> You want to develop your target application @@ -306,8 +297,7 @@ <replaceable>arch</replaceable> is a string representing the target architecture: beaglebone-yocto, beaglebone-yocto-lsb, edgerouter, edgerouter-lsb, - genericx86, genericx86-64, genericx86-64-lsb, genericx86-lsb, - mpc8315e-rdb, mpc8315e-rdb-lsb, and qemu*. + genericx86, genericx86-64, genericx86-64-lsb, genericx86-lsb and qemu*. <!--> <replaceable>date_time</replaceable> is a date and time stamp. diff --git a/external/poky/documentation/sdk-manual/sdk-eclipse-project.xml b/external/poky/documentation/sdk-manual/sdk-eclipse-project.xml deleted file mode 100644 index 15a9ae75..00000000 --- a/external/poky/documentation/sdk-manual/sdk-eclipse-project.xml +++ /dev/null @@ -1,1248 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" -[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > - -<chapter id='sdk-eclipse-project'> - - <title>Developing Applications Using <trademark class='trade'>Eclipse</trademark></title> - - <para> - If you are familiar with the popular Eclipse IDE, you can use an - Eclipse Yocto Plug-in to allow you to develop, deploy, and test your - application all from within Eclipse. - This chapter describes general workflow using the SDK and Eclipse - and how to configure and set up Eclipse. - <note><title>Notes</title> - <itemizedlist> - <listitem><para> - This chapter assumes development of applications on top of - an image prepared using the Yocto Project. - As such, inclusion of a pre-built image or the building of - an image is included in the workflow. - </para></listitem> - <listitem><para> - The chapter also assumes development on a build host that - is set up to use the Yocto Project. - Realize that you can easily use Eclipse and the Yocto - Project plug-in to develop an application for any number - of images developed and tested on different machines. - </para></listitem> - </itemizedlist> - </note> - </para> - - <section id='application-development-workflow-using-eclipse'> - <title>Application Development Workflow Using <trademark class='trade'>Eclipse</trademark></title> - - <para> - The following figure and supporting list summarize a - general workflow for application development that uses the - SDK within the Eclipse IDE. - The application developed runs on top of an image created using - the Yocto Project. - </para> - - <para> - <imagedata fileref="figures/sdk-eclipse-dev-flow.png" - width="7in" depth="7in" align="center" scale="100" /> - </para> - - <para> - <orderedlist> - <listitem><para> - <emphasis>Prepare the Host System for the Yocto Project</emphasis>: - Because this example workflow assumes development on a - system set up to use the Yocto Project, you need to be - sure your - <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink> - can use the Yocto Project. - See the - "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-preparing-the-build-host'>Preparing the Build Host</ulink>" - section in the Yocto Project Development Tasks Manual for - information on how to set up your build host. - <note> - Be sure you install the "xterm" package, which is a - <ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-build-host'>graphical and Eclipse plug-in extra</ulink> - needed by Eclipse. - </note> - </para></listitem> - <listitem><para> - <emphasis>Secure the Yocto Project Kernel Target Image</emphasis>: - This example workflow assumes application development on - top of an image built using the Yocto Project. - Depending on whether you are using a pre-built image - that matches your target architecture or you are using an - image you build using the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded Build System</ulink> - and where you are going to run the image while you - develop your application (QEMU or real hardware), the - area from which you get the image differs. - <itemizedlist> - <listitem><para> - Download the image from - <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink> - if your target architecture is supported and - you are going to develop and test your - application on actual hardware. - </para></listitem> - <listitem><para> - Download the image from - <ulink url='&YOCTO_QEMU_DL_URL;'> - <filename>machines/qemu</filename></ulink> if - your target architecture is supported and you - are going to develop and test your application - using the - <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>QEMU Emulator</ulink>. - </para></listitem> - <listitem><para> - Build your image if you cannot find a pre-built - image that matches your target architecture. - If your target architecture is similar to a - supported architecture, you can modify the - kernel image before you build it. - See the - "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#using-devtool-to-patch-the-kernel'>Using <filename>devtool</filename> to Patch the Kernel</ulink>" - section in the Yocto Project Linux Kernel - Development Manual for an example. - You can also see the - "<ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage#Making_a_Suitable_Qemux86_Image'>Making a Suitable Qemux86 Image</ulink>" - wiki for steps needed to build an image suitable - for QEMU and for debugging within the Eclipse IDE. - </para></listitem> - </itemizedlist> - </para></listitem> - <listitem> - <para><emphasis>Install the SDK</emphasis>: - The SDK provides a target-specific cross-development - toolchain, the root filesystem, the QEMU emulator, and - other tools that can help you develop your application. - For information on how to install the SDK, see the - "<link linkend='sdk-installing-the-sdk'>Installing the SDK</link>" - section. - </para></listitem> - <listitem><para> - <emphasis>Secure the Target Root Filesystem and the Cross-Development Toolchain</emphasis>: - You need to find and download the appropriate root - filesystem and the cross-development toolchain.</para> - - <para>You can find the tarballs for the root filesystem - in the same area used for the kernel image. - Depending on the type of image you are running, the - root filesystem you need differs. - For example, if you are developing an application that - runs on an image that supports Sato, you need to get a - root filesystem that supports Sato.</para> - - <para>You can find the cross-development toolchains at - <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'><filename>toolchains</filename></ulink>. - Be sure to get the correct toolchain for your - development host and your target architecture. - See the "<link linkend='sdk-locating-pre-built-sdk-installers'>Locating Pre-Built SDK Installers</link>" - section for information and the - "<link linkend='sdk-installing-the-sdk'>Installing the SDK</link>" - section for installation information. - <note> - As an alternative to downloading an SDK, you can - build the SDK installer. - For information on building the installer, see the - "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>" - section. - Another helpful resource for building an installer - is the - "<ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>Cookbook guide to Making an Eclipse Debug Capable Image</ulink>" - wiki page. - </note> - </para></listitem> - <listitem><para> - <emphasis>Create and Build Your Application</emphasis>: - You need to have source files for your application. - Once you have the files, you can use the Eclipse IDE - to import them and build the project. - </para></listitem> - <listitem><para> - <emphasis>Deploy the Image With the Application</emphasis>: - Using the Eclipse IDE, you can deploy your image to the - hardware or to QEMU through the project's preferences. - You can also use Eclipse to load and test your image - under QEMU. - See the - "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>Using the Quick EMUlator (QEMU)</ulink>" - chapter in the Yocto Project Development Tasks Manual - for information on using QEMU. - </para></listitem> - <listitem><para> - <emphasis>Test and Debug the Application</emphasis>: - Once your application is deployed, you need to test it. - Within the Eclipse IDE, you can use the debugging - environment along with supported performance enhancing - <ulink url='http://www.eclipse.org/linuxtools/'>Linux Tools</ulink>. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='adt-eclipse'> - <title>Working Within Eclipse</title> - - <para> - The Eclipse IDE is a popular development environment and it - fully supports development using the Yocto Project. - </para> - - <para> - When you install and configure the Eclipse Yocto Project - Plug-in into the Eclipse IDE, you maximize your Yocto - Project experience. - Installing and configuring the Plug-in results in an - environment that has extensions specifically designed to let - you more easily develop software. - These extensions allow for cross-compilation, deployment, and - execution of your output into a QEMU emulation session as well - as actual target hardware. - You can also perform cross-debugging and profiling. - The environment also supports performance enhancing - <ulink url='http://www.eclipse.org/linuxtools/'>tools</ulink> - that allow you to perform remote profiling, tracing, - collection of power data, collection of latency data, and - collection of performance data. - <note> - This release of the Yocto Project supports both the Oxygen - and Neon versions of the Eclipse IDE. - This section provides information on how to use the Oxygen - release with the Yocto Project. - For information on how to use the Neon version of Eclipse - with the Yocto Project, see - "<link linkend='sdk-appendix-neon-yp-eclipse-plug-in'>Appendix D</link>". - </note> - </para> - - <section id='oxygen-setting-up-the-eclipse-ide'> - <title>Setting Up the Oxygen Version of the Eclipse IDE</title> - - <para> - To develop within the Eclipse IDE, you need to do the - following: - <orderedlist> - <listitem><para> - Install the Oxygen version of the Eclipse IDE. - </para></listitem> - <listitem><para> - Configure the Eclipse IDE. - </para></listitem> - <listitem><para> - Install the Eclipse Yocto Plug-in. - </para></listitem> - <listitem><para> - Configure the Eclipse Yocto Plug-in. - </para></listitem> - </orderedlist> - <note> - Do not install Eclipse from your distribution's package - repository. - Be sure to install Eclipse from the official Eclipse - download site as directed in the next section. - </note> - </para> - - <section id='oxygen-installing-eclipse-ide'> - <title>Installing the Oxygen Eclipse IDE</title> - - <para> - Follow these steps to locate, install, and configure - Oxygen Eclipse: - <orderedlist> - <listitem><para> - <emphasis>Locate the Oxygen Download:</emphasis> - Open a browser and go to - <ulink url='http://www.eclipse.org/oxygen/'>http://www.eclipse.org/oxygen/</ulink>. - </para></listitem> - <listitem><para> - <emphasis>Download the Tarball:</emphasis> - Click through the "Download" buttons to - download the file. - </para></listitem> - <listitem><para> - <emphasis>Unpack the Tarball:</emphasis> - Move to a clean directory and unpack the - tarball. - Here is an example: - <literallayout class='monospaced'> - $ cd ~ - $ tar -xzvf ~/Downloads/eclipse-inst-linux64.tar.gz - </literallayout> - Everything unpacks into a folder named - "eclipse-installer". - </para></listitem> - <listitem><para> - <emphasis>Launch the Installer:</emphasis> - Use the following commands to launch the - installer: - <literallayout class='monospaced'> - $ cd ~/eclipse-installer - $ ./eclipse-inst - </literallayout> - </para></listitem> - <listitem><para> - <emphasis>Select Your IDE:</emphasis> - From the list, select the "Eclipse IDE for - C/C++ Developers". - </para></listitem> - <listitem><para> - <emphasis>Install the Software:</emphasis> - Click "Install" to begin the installation. - Accept all the certificates and any license - agreements. - Click "Install" again to finish the installation. - </para></listitem> - <listitem><para> - <emphasis>Launch Oxygen:</emphasis> - Accept the default "workspace" and click the - "Launch" button. - You should see the Eclipse welcome page from which - can click "workbench" to enter your workspace. - <note> - The executable for Eclipse is located in the - <filename>eclipse/cpp-oxygen/eclipse</filename> - folder. - To launch Eclipse outside of the installation - process, simply execute that binary. - Here is an example: - <literallayout class='monospaced'> - $ ~/eclipse/cpp-oxygen/eclipse/eclipse - </literallayout> - </note> - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='oxygen-configuring-the-eclipse-ide'> - <title>Configuring the Oxygen Eclipse IDE</title> - - <para> - Follow these steps to configure the Oxygen Eclipse IDE. - <note><title>Notes</title> - <itemizedlist> - <listitem><para> - Depending on how you installed Eclipse and what - you have already done, some of the options do - not appear. - If you cannot find an option as directed by the - manual, it has already been installed. - </para></listitem> - <listitem><para> - If you want to see all options regardless of - whether they are installed or not, deselect the - "Hide items that are already installed" - check box. - </para></listitem> - </itemizedlist> - </note> - <orderedlist> - <listitem><para> - Be sure Eclipse is running and you are in your - workbench. - Just click "workbench" if you are not in your - default workspace. - </para></listitem> - <listitem><para> - Select "Install New Software" from the "Help" - pull-down menu. - </para></listitem> - <listitem><para> - Select - "Oxygen - http://download.eclipse.org/releases/oxygen" - from the "Work with:" pull-down menu. - </para></listitem> - <listitem><para> - Expand the box next to "Linux Tools" and select - the following: - <literallayout class='monospaced'> - C/C++ Remote (Over TCF/TE) Run/Debug Launcher - TM Terminal - </literallayout> - </para></listitem> - <listitem><para> - Expand the box next to "Mobile and Device - Development" and select the following - boxes: - <literallayout class='monospaced'> - C/C++ Remote (Over TCF/TE) Run/Debug Launcher - Remote System Explorer User Actions - TM Terminal - TCF Remote System Explorer add-in - TCF Target Explorer - </literallayout> - </para></listitem> - <listitem><para> - Expand the box next to "Programming Languages" - and select the following box: - <literallayout class='monospaced'> - C/C++ Development Tools SDK - </literallayout> - </para></listitem> - <listitem><para> - Complete the installation by clicking through - appropriate "Next" and "Finish" buttons and then - restart the Eclipse IDE. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='oxygen-installing-the-eclipse-yocto-plug-in'> - <title>Installing or Accessing the Oxygen Eclipse Yocto Plug-in</title> - - <para> - You can install the Eclipse Yocto Plug-in into the - Eclipse IDE one of two ways: use the Yocto Project's - Eclipse Update site to install the pre-built plug-in, - or build and install the plug-in from the latest - source code. - </para> - - <section id='oxygen-new-software'> - <title>Installing the Pre-built Plug-in from the Yocto Project Eclipse Update Site</title> - - <para> - To install the Oxygen Eclipse Yocto Plug-in from the - update site, follow these steps: - <orderedlist> - <listitem><para> - Start up the Eclipse IDE. - </para></listitem> - <listitem><para> - In Eclipse, select "Install New - Software" from the "Help" menu. - </para></listitem> - <listitem><para> - Click "Add..." in the "Work with:" area. - </para></listitem> - <listitem><para> - Enter - <filename>&ECLIPSE_DL_PLUGIN_URL;/oxygen</filename> - in the URL field and provide a meaningful - name in the "Name" field. - </para></listitem> - <listitem><para> - Click "OK" to have the entry automatically - populate the "Work with:" field and to have - the items for installation appear in the window - below. - </para></listitem> - <listitem><para> - Check the boxes next to the following: - <literallayout class='monospaced'> - Yocto Project SDK Plug-in - Yocto Project Documentation plug-in - </literallayout> - </para></listitem> - <listitem><para> - Complete the remaining software - installation steps and then restart the - Eclipse IDE to finish the installation of - the plug-in. - <note> - You can click "OK" when prompted about - installing software that contains - unsigned content. - </note> - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='oxygen-zip-file-method'> - <title>Installing the Plug-in Using the Latest Source Code</title> - - <para> - To install the Oxygen Eclipse Yocto Plug-in from the - latest source code, follow these steps: - <orderedlist> - <listitem><para> - Be sure your build host has JDK version 1.8 - or greater. - On a Linux build host you can determine the - version using the following command: - <literallayout class='monospaced'> - $ java -version - </literallayout> - </para></listitem> - <listitem><para> - Install X11-related packages: - <literallayout class='monospaced'> - $ sudo apt-get install xauth - </literallayout> - </para></listitem> - <listitem><para> - In a new terminal shell, create a - Git repository with: - <literallayout class='monospaced'> - $ cd ~ - $ git clone git://git.yoctoproject.org/eclipse-yocto - </literallayout> - </para></listitem> - <listitem><para> - Use Git to create the correct tag: - <literallayout class='monospaced'> - $ cd ~/eclipse-yocto - $ git checkout -b oxygen/&DISTRO_NAME_NO_CAP; remotes/origin/oxygen/&DISTRO_NAME_NO_CAP; - </literallayout> - This creates a local tag named - <filename>oxygen/&DISTRO_NAME_NO_CAP;</filename> - based on the branch - <filename>origin/oxygen/&DISTRO_NAME_NO_CAP;</filename>. - You are put into a detached HEAD state, - which is fine since you are only going to - be building and not developing. - </para></listitem> - <listitem><para> - Change to the <filename>scripts</filename> - directory within the Git repository: - <literallayout class='monospaced'> - $ cd scripts - </literallayout> - </para></listitem> - <listitem><para> - Set up the local build environment - by running the setup script: - <literallayout class='monospaced'> - $ ./setup.sh - </literallayout> - When the script finishes execution, - it prompts you with instructions on how to - run the <filename>build.sh</filename> - script, which is also in the - <filename>scripts</filename> directory of - the Git repository created earlier. - </para></listitem> - <listitem><para> - Run the <filename>build.sh</filename> - script as directed. - Be sure to provide the tag name, - documentation branch, and a release name. - </para> - <para> - Following is an example: - <literallayout class='monospaced'> - $ ECLIPSE_HOME=/home/scottrif/eclipse-yocto/scripts/eclipse ./build.sh -l oxygen/&DISTRO_NAME_NO_CAP; master yocto-&DISTRO; 2>&1 | tee build.log - </literallayout> - The previous example command adds the tag - you need for - <filename>oxygen/&DISTRO_NAME_NO_CAP;</filename> - to <filename>HEAD</filename>, then tells - the build script to use the local (-l) Git - checkout for the build. - After running the script, the file - <filename>org.yocto.sdk-</filename><replaceable>release</replaceable><filename>-</filename><replaceable>date</replaceable><filename>-archive.zip</filename> - is in the current directory. - </para></listitem> - <listitem><para> - If necessary, start the Eclipse IDE - and be sure you are in the Workbench. - </para></listitem> - <listitem><para> - Select "Install New Software" from - the "Help" pull-down menu. - </para></listitem> - <listitem><para> - Click "Add". - </para></listitem> - <listitem><para> - Provide anything you want in the - "Name" field. - </para></listitem> - <listitem><para> - Click "Archive" and browse to the - ZIP file you built earlier. - This ZIP file should not be "unzipped", and - must be the - <filename>*archive.zip</filename> file - created by running the - <filename>build.sh</filename> script. - </para></listitem> - <listitem><para> - Click the "OK" button. - </para></listitem> - <listitem><para> - Check the boxes that appear in - the installation window to install the - following: - <literallayout class='monospaced'> - Yocto Project SDK Plug-in - Yocto Project Documentation plug-in - </literallayout> - </para></listitem> - <listitem><para> - Finish the installation by clicking - through the appropriate buttons. - You can click "OK" when prompted about - installing software that contains unsigned - content. - </para></listitem> - <listitem><para> - Restart the Eclipse IDE if necessary. - </para></listitem> - </orderedlist> - </para> - - <para> - At this point you should be able to configure the - Eclipse Yocto Plug-in as described in the - "<link linkend='oxygen-configuring-the-eclipse-yocto-plug-in'>Configuring the Oxygen Eclipse Yocto Plug-in</link>" - section. - </para> - </section> - </section> - - <section id='oxygen-configuring-the-eclipse-yocto-plug-in'> - <title>Configuring the Oxygen Eclipse Yocto Plug-In</title> - - <para> - Configuring the Oxygen Eclipse Yocto Plug-in involves - setting the Cross Compiler options and the Target - options. - The configurations you choose become the default - settings for all projects. - You do have opportunities to change them later when - you configure the project (see the following section). - </para> - - <para> - To start, you need to do the following from within the - Eclipse IDE: - <orderedlist> - <listitem><para> - Choose "Preferences" from the "Window" menu to - display the Preferences Dialog. - </para></listitem> - <listitem><para> - Click "Yocto Project SDK" to display - the configuration screen. - </para></listitem> - </orderedlist> - The following sub-sections describe how to configure - the plug-in. - <note> - Throughout the descriptions, a start-to-finish - example for preparing a QEMU image for use with - Eclipse is referenced as the "wiki" and is linked - to the example on the - "<ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'> Cookbook guide to Making an Eclipse Debug Capable Image</ulink>" - wiki page. - </note> - </para> - - <section id='oxygen-configuring-the-cross-compiler-options'> - <title>Configuring the Cross-Compiler Options</title> - - <para> - Cross Compiler options enable Eclipse to use your - specific cross compiler toolchain. - To configure these options, you must select - the type of toolchain, point to the toolchain, - specify the sysroot location, and select the target - architecture. - <itemizedlist> - <listitem><para> - <emphasis>Selecting the Toolchain Type:</emphasis> - Choose between "Standalone pre-built toolchain" - and "Build system derived toolchain" for - Cross Compiler Options. - <itemizedlist> - <listitem><para> - <emphasis>Standalone Pre-built Toolchain:</emphasis> - Select this type when you are using - a stand-alone cross-toolchain. - For example, suppose you are an - application developer and do not - need to build a target image. - Instead, you just want to use an - architecture-specific toolchain on - an existing kernel and target root - filesystem. - In other words, you have downloaded - and installed a pre-built toolchain - for an existing image. - </para></listitem> - <listitem><para> - <emphasis>Build System Derived Toolchain:</emphasis> - Select this type if you built the - toolchain as part of the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>. - When you select "Build system derived - toolchain", you are using the toolchain - built and bundled inside the Build - Directory. - For example, suppose you created a - suitable image using the steps in the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>wiki</ulink>. - In this situation, you would select - "Build system derived toolchain". - </para></listitem> - </itemizedlist> - </para></listitem> - <listitem><para> - <emphasis>Specify the Toolchain Root Location:</emphasis> - If you are using a stand-alone pre-built - toolchain, you should be pointing to where - it is installed (e.g. - <filename>/opt/poky/&DISTRO;</filename>). - See the - "<link linkend='sdk-installing-the-sdk'>Installing the SDK</link>" - section for information about how the SDK is - installed.</para> - - <para>If you are using a build system - derived toolchain, the path you provide for - the "Toolchain Root Location" field is the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink> - from which you run the - <filename>bitbake</filename> command (e.g - <filename>/home/scottrif/poky/build</filename>). - </para> - <para>For more information, see the - "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>" - section. - </para></listitem> - <listitem><para> - <emphasis>Specify Sysroot Location:</emphasis> - This location is where the root filesystem - for the target hardware resides. - </para> - - <para>This location depends on where you - separately extracted and installed the - target filesystem when you either built - it or downloaded it. - <note> - If you downloaded the root filesystem - for the target hardware rather than - built it, you must download the - <filename>sato-sdk</filename> image - in order to build any c/c++ projects. - </note> - As an example, suppose you prepared an - image using the steps in the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>wiki</ulink>. - If so, the - <filename>MY_QEMU_ROOTFS</filename> - directory is found in the Build Directory - and you would browse to and select that - directory (e.g. - <filename>/home/scottrif/poky/build/MY_QEMU_ROOTFS</filename>). - </para> - - <para>For more information on how to - install the toolchain and on how to extract - and install the sysroot filesystem, see the - "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>" - section. - </para></listitem> - <listitem><para> - <emphasis>Select the Target Architecture:</emphasis> - The target architecture is the type of - hardware you are going to use or emulate. - Use the pull-down "Target Architecture" - menu to make your selection. - The pull-down menu should have the - supported architectures. - If the architecture you need is not listed - in the menu, you will need to build the - image. - See the - "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-building-a-simple-image'>Building a Simple Image</ulink>" - section of the Yocto Project Development Tasks - Manual for more information. - You can also see the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>wiki</ulink>. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='oxygen-configuring-the-target-options'> - <title>Configuring the Target Options</title> - - <para> - You can choose to emulate hardware using the QEMU - emulator, or you can choose to run your image on - actual hardware. - <itemizedlist> - <listitem><para> - <emphasis>QEMU:</emphasis> - Select this option if you will be using the - QEMU emulator. - If you are using the emulator, you also - need to locate the kernel and specify any - custom options.</para> - - <para>If you selected the Build system derived - toolchain, the target kernel you built will be - located in the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink> - in - <filename>tmp/deploy/images/<replaceable>machine</replaceable></filename> - directory. - As an example, suppose you performed the - steps in the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>wiki</ulink>. - In this case, you specify your Build - Directory path followed by the image (e.g. - <filename>/home/scottrif/poky/build/tmp/deploy/images/qemux86/bzImage-qemux86.bin</filename>). - </para> - - <para>If you selected the standalone - pre-built toolchain, the pre-built image - you downloaded is located in the directory - you specified when you downloaded the - image.</para> - - <para>Most custom options are for advanced - QEMU users to further customize their QEMU - instance. - These options are specified between paired - angled brackets. - Some options must be specified outside the - brackets. - In particular, the options - <filename>serial</filename>, - <filename>nographic</filename>, and - <filename>kvm</filename> must all be - outside the brackets. - Use the <filename>man qemu</filename> - command to get help on all the options and - their use. - The following is an example: - <literallayout class='monospaced'> - serial ‘<-m 256 -full-screen>’ - </literallayout> - Regardless of the mode, Sysroot is already - defined as part of the Cross-Compiler - Options configuration in the "Sysroot - Location:" field. - </para></listitem> - <listitem><para> - <emphasis>External HW:</emphasis> - Select this option if you will be using - actual hardware. - </para></listitem> - </itemizedlist> - </para> - - <para> - Click "Apply and Close" to save your plug-in - configurations. - </para> - </section> - </section> - </section> - - <section id='oxygen-creating-the-project'> - <title>Creating the Project</title> - - <para> - You can create two types of projects: Autotools-based, or - Makefile-based. - This section describes how to create Autotools-based - projects from within the Eclipse IDE. - For information on creating Makefile-based projects in a - terminal window, see the - "<link linkend='makefile-based-projects'>Makefile-Based Projects</link>" - section. - <note> - Do not use special characters in project names - (e.g. spaces, underscores, etc.). Doing so can - cause configuration to fail. - </note> - </para> - - <para> - To create a project based on a Yocto template and then - display the source code, follow these steps: - <orderedlist> - <listitem><para> - Select "C/C++ Project" from the "File -> New" menu. - </para></listitem> - <listitem><para> - Select "C Managed Build" from the available options and - click "Next". - </para></listitem> - <listitem><para> - Expand "Yocto Project SDK Autotools Project". - </para></listitem> - <listitem><para> - Select "Hello World ANSI C Autotools Projects". - This is an Autotools-based project based on a Yocto - template. - </para></listitem> - <listitem><para> - Put a name in the "Project name:" field. - Do not use hyphens as part of the name - (e.g. "hello"). - </para></listitem> - <listitem><para> - Click "Next". - </para></listitem> - <listitem><para> - Add appropriate information in the various fields. - </para></listitem> - <listitem><para> - Click "Finish". - </para></listitem> - <listitem><para> - If the "open perspective" prompt appears, - click "Yes" so that you in the C/C++ perspective. - </para></listitem> - <listitem><para>The left-hand navigation pane shows - your project. - You can display your source by double clicking the - project's source file. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='oxygen-configuring-the-cross-toolchains'> - <title>Configuring the Cross-Toolchains</title> - - <para> - The earlier section, - "<link linkend='oxygen-configuring-the-eclipse-yocto-plug-in'>Configuring the Oxygen Eclipse Yocto Plug-in</link>", - sets up the default project configurations. - You can override these settings for a given project by - following these steps: - <orderedlist> - <listitem><para> - Select "Yocto Project Settings" from - the "Project -> Properties" menu. - This selection brings up the Yocto Project Settings - Dialog and allows you to make changes specific to - an individual project.</para> - <para>By default, the Cross Compiler Options and - Target Options for a project are inherited from - settings you provided using the Preferences Dialog - as described earlier in the - "<link linkend='oxygen-configuring-the-eclipse-yocto-plug-in'>Configuring the Oxygen Eclipse Yocto Plug-in</link>" - section. - The Yocto Project Settings Dialog allows you to - override those default settings for a given - project. - </para></listitem> - <listitem><para> - Make or verify your configurations for the - project and click "Apply and Close". - </para></listitem> - <listitem><para> - Right-click in the navigation pane and select - "Reconfigure Project" from the pop-up menu. - This selection reconfigures the project by running - <ulink url='https://en.wikipedia.org/wiki/GNU_Build_System'>Autotools GNU utility programs</ulink> - such as Autoconf, Automake, and so forth in the - workspace for your project. - Click on the "Console" tab beneath your source code - to see the results of reconfiguring your project. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='oxygen-building-the-project'> - <title>Building the Project</title> - <para> - To build the project select "Build All" from the - "Project" menu. - The console should update and you can note the - cross-compiler you are using (i.e. - <filename>i586-poky-linux-gcc</filename> in this example). - <note> - When building "Yocto Project SDK Autotools" projects, - the Eclipse IDE might display error messages for - Functions/Symbols/Types that cannot be "resolved", - even when the related include file is listed at the - project navigator and when the project is able to - build. - For these cases only, it is recommended to add a new - linked folder to the appropriate sysroot. - Use these steps to add the linked folder: - <orderedlist> - <listitem><para> - Select the project. - </para></listitem> - <listitem><para> - Select "Folder" from the "File -> New" menu. - </para></listitem> - <listitem><para> - In the "New Folder" Dialog, click the "Advanced" - button and then activate "Link to - alternate location (linked folder)" button. - </para></listitem> - <listitem><para> - Click "Browse" to navigate to the include - folder inside the same sysroot location - selected in the Yocto Project - configuration preferences. - </para></listitem> - <listitem><para> - Click "Finish" to save the linked folder. - </para></listitem> - </orderedlist> - </note> - </para> - </section> - - <section id='oxygen-starting-qemu-in-user-space-nfs-mode'> - <title>Starting QEMU in User-Space NFS Mode</title> - - <para> - To start the QEMU emulator from within Eclipse, follow - these steps: - <note> - See the - "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>Using the Quick EMUlator (QEMU)</ulink>" - chapter in the Yocto Project Development Tasks Manual - for more information on using QEMU. - </note> - <orderedlist> - <listitem><para>Expose and select "External Tools - Configurations ..." from the "Run -> External - Tools" menu. - </para></listitem> - <listitem><para> - Locate and select your image in the navigation - panel to the left - (e.g. <filename>qemu_i586-poky-linux</filename>). - </para></listitem> - <listitem><para> - Click "Run" to launch QEMU. - <note> - The host on which you are running QEMU must - have the <filename>rpcbind</filename> utility - running to be able to make RPC calls on a - server on that machine. - If QEMU does not invoke and you receive error - messages involving - <filename>rpcbind</filename>, follow the - suggestions to get the service running. - As an example, on a new Ubuntu 16.04 LTS - installation, you must do the following in a new - shell in order to get QEMU to launch: - <literallayout class='monospaced'> - $ sudo apt-get install rpcbind - </literallayout> - After installing <filename>rpcbind</filename>, - you need to edit the - <filename>/etc/init.d/rpcbind</filename> file - to include the following line: - <literallayout class='monospaced'> - OPTIONS="-i -w" - </literallayout> - After modifying the file, you need to start the - service: - <literallayout class='monospaced'> - $ sudo service portmap restart - </literallayout> - </note> - </para></listitem> - <listitem><para> - If needed, enter your host root password in - the shell window at the prompt. - This sets up a <filename>Tap 0</filename> - connection needed for running in user-space NFS - mode. - </para></listitem> - <listitem><para> - Wait for QEMU to launch. - </para></listitem> - <listitem><para> - Once QEMU launches, you can begin operating - within that environment. - One useful task at this point would be to determine - the IP Address for the user-space NFS by using the - <filename>ifconfig</filename> command. - The IP address of the QEMU machine appears in the - xterm window. - You can use this address to help you see which - particular - IP address the instance of QEMU is using. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='oxygen-deploying-and-debugging-the-application'> - <title>Deploying and Debugging the Application</title> - - <para> - Once the QEMU emulator is running the image, you can deploy - your application using the Eclipse IDE and then use - the emulator to perform debugging. - Follow these steps to deploy the application. - <note> - Currently, Eclipse does not support SSH port - forwarding. - Consequently, if you need to run or debug a remote - application using the host display, you must create a - tunneling connection from outside Eclipse and keep - that connection alive during your work. - For example, in a new terminal, run the following: - <literallayout class='monospaced'> - $ ssh -XY <replaceable>user_name</replaceable>@<replaceable>remote_host_ip</replaceable> - </literallayout> - Using the above form, here is an example: - <literallayout class='monospaced'> - $ ssh -XY root@192.168.7.2 - </literallayout> - After running the command, add the command to be - executed in Eclipse's run configuration before the - application as follows: - <literallayout class='monospaced'> - export DISPLAY=:10.0 - </literallayout> - Be sure to not destroy the connection during your QEMU - session (i.e. do not - exit out of or close that shell). - </note> - <orderedlist> - <listitem><para> - Select "Debug Configurations..." from the - "Run" menu. - </para></listitem> - <listitem><para> - In the left area, expand - "C/C++Remote Application". - </para></listitem> - <listitem><para> - Locate your project and select it to bring - up a new tabbed view in the Debug Configurations - Dialog. - </para></listitem> - <listitem><para> - Click on the "Debugger" tab to see the - cross-tool debugger you are using. - Be sure to change to the debugger perspective in - Eclipse. - </para></listitem> - <listitem><para> - Click on the "Main" tab. - </para></listitem> - <listitem><para> - Create a new connection to the QEMU instance - by clicking on "new".</para></listitem> - <listitem><para>Select "SSH", which - means Secure Socket Shell and then click "OK". - Optionally, you can select a TCF connection - instead. - </para></listitem> - <listitem><para> - Clear out the "Connection name" field and - enter any name you want for the connection. - </para></listitem> - <listitem><para> - Put the IP address for the connection in - the "Host" field. - For QEMU, the default is "192.168.7.2". - However, if a previous QEMU session did not exit - cleanly, the IP address increments (e.g. - "192.168.7.3"). - <note> - You can find the IP address for the current - QEMU session by looking in the xterm that - opens when you launch QEMU. - </note> - </para></listitem> - <listitem><para> - Enter "root", which - is the default for QEMU, for the "User" field. - Be sure to leave the password field empty. - </para></listitem> - <listitem><para> - Click "Finish" to close the New Connections Dialog. - </para></listitem> - <listitem><para> - If necessary, use the drop-down menu now in the - "Connection" field and pick the IP Address you - entered. - </para></listitem> - <listitem><para> - Assuming you are connecting as the root - user, which is the default for QEMU x86-64 SDK - images provided by the Yocto Project, in the - "Remote Absolute File Path for C/C++ Application" - field, browse to - <filename>/home/root/</filename><replaceable>ProjectName</replaceable> - (e.g. <filename>/home/root/hello</filename>). - You could also browse to any other path you have - write access to on the target such as - <filename>/usr/bin</filename>. - This location is where your application will be - located on the QEMU system. - If you fail to browse to and specify an appropriate - location, QEMU will not understand what to remotely - launch. - Eclipse is helpful in that it auto fills your - application name for you assuming you browsed to a - directory. - <note><title>Tips</title> - <itemizedlist> - <listitem><para> - If you are prompted to provide a username - and to optionally set a password, be sure - you provide "root" as the username and you - leave the password field blank. - </para></listitem> - <listitem><para> - If browsing to a directory fails or times - out, but you can - <filename>ssh</filename> into your QEMU - or target from the command line and you - have proxies set up, it is likely that - Eclipse is sending the SSH traffic to a - proxy. - In this case, either use TCF , or click on - "Configure proxy settings" in the - connection dialog and add the target IP - address to the "bypass proxy" section. - You might also need to change - "Active Provider" from Native to Manual. - </para></listitem> - </itemizedlist> - </note> - </para></listitem> - <listitem><para> - Be sure you change to the "Debug" perspective in - Eclipse. - </para></listitem> - <listitem><para> - Click "Debug" - </para></listitem> - <listitem><para> - Accept the debug perspective. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='oxygen-using-Linuxtools'> - <title>Using Linuxtools</title> - - <para> - As mentioned earlier in the manual, performance tools exist - (Linuxtools) that enhance your development experience. - These tools are aids in developing and debugging - applications and images. - You can run these tools from within the Eclipse IDE through - the "Linuxtools" menu. - </para> - - <para> - For information on how to configure and use these tools, - see - <ulink url='http://www.eclipse.org/linuxtools/'>http://www.eclipse.org/linuxtools/</ulink>. - </para> - </section> - </section> -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/external/poky/documentation/sdk-manual/sdk-extensible.xml b/external/poky/documentation/sdk-manual/sdk-extensible.xml index 09f06088..94d2a241 100644 --- a/external/poky/documentation/sdk-manual/sdk-extensible.xml +++ b/external/poky/documentation/sdk-manual/sdk-extensible.xml @@ -27,8 +27,7 @@ <para> In addition to the functionality available through <filename>devtool</filename>, you can alternatively make use of the - toolchain directly, for example from Makefile, Autotools, and - <trademark class='trade'>Eclipse</trademark>-based projects. + toolchain directly, for example from Makefile and Autotools. See the "<link linkend='sdk-working-projects'>Using the SDK Toolchain Directly</link>" chapter for more information. @@ -119,11 +118,6 @@ For information on building the installer, see the "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>" section. - Another helpful resource for building an installer is the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>Cookbook guide to Making an Eclipse Debug Capable Image</ulink> - wiki page. - This wiki page focuses on development when using the Eclipse - IDE. </note> </para> @@ -157,7 +151,7 @@ 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 + You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed [Y/n]? Y Extracting SDK..............done Setting it up... Extracting buildtools... @@ -624,7 +618,23 @@ 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. + original location.</para> + + <para>Additionally, if you have any non-patch + local files (i.e. files referred to with + <filename>file://</filename> entries in + <filename>SRC_URI</filename> statement excluding + <filename>*.patch/</filename> or + <filename>*.diff</filename>), these files are + copied to an + <filename>oe-local-files</filename> 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. </para></listitem> <listitem><para> <emphasis>Middle</emphasis>: @@ -639,10 +649,10 @@ </para> <para>The following command tells - <filename>devtool</filename> what recipe with + <filename>devtool</filename> the recipe with which to work and, in this case, identifies a local area for the extracted source files that - is outside of the default + exists outside of the default <filename>devtool</filename> workspace: <literallayout class='monospaced'> $ devtool modify <replaceable>recipe srctree</replaceable> @@ -656,8 +666,12 @@ the recipe's <filename>SRC_URI</filename> statements to locate the source files and any associated patch files. - Once the files are located, the command by - default extracts them into + Non-patch files are copied to an + <filename>oe-local-files</filename> folder + under the newly created source tree.</para> + + <para>Once the files are located, the command + by default extracts them into <replaceable>srctree</replaceable>.</para> <para>Within workspace, @@ -691,9 +705,21 @@ </literallayout> </para> - <para>Once the command finishes, it creates only - an append file for the recipe in the - <filename>devtool</filename> workspace. + <para>If an <filename>oe-local-files</filename> + 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 <filename>devtool finish</filename> + command, any non-patch files that might exist + next to the recipe are removed because it + appears to <filename>devtool</filename> that + you have deleted those files.</para> + + <para>Once the + <filename>devtool modify</filename> command + finishes, it creates only an append file for + the recipe in the <filename>devtool</filename> + workspace. The recipe and the source code remain in their original locations. </para></listitem> @@ -784,7 +810,12 @@ original recipe in the original layer or the command creates a <filename>.bbappend</filename> file in a different layer as provided by - <replaceable>layer</replaceable>.</para> + <replaceable>layer</replaceable>. + Any work you did in the + <filename>oe-local-files</filename> directory is + preserved in the original files next to the recipe + during the <filename>devtool finish</filename> + command.</para> <para>As a final process of the <filename>devtool finish</filename> command, the state @@ -831,7 +862,9 @@ versioning schemes, extract code into or out of the <filename>devtool</filename> <ulink url='&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure'>workspace</ulink>, - and work with any source file forms that the fetchers support. + and work with any source file forms that the + <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetchers</ulink> + support. </para> <para> @@ -902,7 +935,23 @@ 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. + all within the workspace.</para> + + <para>Additionally, if you have any non-patch + local files (i.e. files referred to with + <filename>file://</filename> entries in + <filename>SRC_URI</filename> statement excluding + <filename>*.patch/</filename> or + <filename>*.diff</filename>), these files are + copied to an + <filename>oe-local-files</filename> 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. </para></listitem> <listitem><para> <emphasis>Resolve any Conflicts created by the Upgrade</emphasis>: @@ -980,10 +1029,18 @@ 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. + workspace.</para> + + <para>Any work you did in the + <filename>oe-local-files</filename> directory is + preserved in the original files next to the recipe + during the <filename>devtool finish</filename> + command.</para> + + <para> If you specify a destination layer that is the same as the original source, then the old version of the - recipe and associated files will be removed prior to + recipe and associated files are removed prior to adding the new version. <literallayout class='monospaced'> $ devtool finish <replaceable>recipe layer</replaceable> diff --git a/external/poky/documentation/sdk-manual/sdk-intro.xml b/external/poky/documentation/sdk-manual/sdk-intro.xml index 8642be61..9169fe9c 100644 --- a/external/poky/documentation/sdk-manual/sdk-intro.xml +++ b/external/poky/documentation/sdk-manual/sdk-intro.xml @@ -14,9 +14,6 @@ This manual provides information that explains how to use both the Yocto Project extensible and standard SDKs to develop applications and images. - Additionally, the manual also provides information on how to use - the popular <trademark class='trade'>Eclipse</trademark> IDE as part - of your application development workflow within the SDK environment. <note> Prior to the 2.0 Release of the Yocto Project, application development was primarily accomplished through the use of the @@ -112,21 +109,6 @@ However, QEMU plays an important role in the development process that revolves around use of the SDK. </para></listitem> - <listitem><para> - The Eclipse IDE Yocto Plug-in. - This plug-in is available for you if you are an Eclipse - user. - In the same manner as QEMU, the plug-in is not literally part - of the SDK but is rather available for use as part of the - development process. - </para></listitem> - <listitem><para> - Various performance-related - <ulink url='http://www.eclipse.org/linuxtools/index.php'>tools</ulink> - that can enhance your development experience. - These tools are also separate from the actual SDK but can be - independently obtained and used in the development process. - </para></listitem> </itemizedlist> </para> @@ -271,53 +253,6 @@ </itemizedlist> </para> </section> - - <section id='eclipse-overview'> - <title><trademark class='trade'>Eclipse</trademark> Yocto Plug-in</title> - - <para> - The Eclipse IDE is a popular development environment and it fully - supports development using the Yocto Project. - When you install and configure the Eclipse Yocto Project Plug-in - into the Eclipse IDE, you maximize your Yocto Project experience. - Installing and configuring the Plug-in results in an environment - that has extensions specifically designed to let you more easily - develop software. - These extensions allow for cross-compilation, deployment, and - execution of your output into a QEMU emulation session. - You can also perform cross-debugging and profiling. - The environment also supports many performance-related - <ulink url='http://www.eclipse.org/linuxtools/index.php'>tools</ulink> - that enhance your development experience. - <note> - Previous releases of the Eclipse Yocto Plug-in supported - "user-space tools" (i.e. LatencyTOP, PowerTOP, Perf, SystemTap, - and Lttng-ust) that also added to the development experience. - These tools have been deprecated with the release of the - Eclipse Yocto Plug-in. - </note> - </para> - - <para> - For information about the application development workflow that - uses the Eclipse IDE and for a detailed example of how to install - and configure the Eclipse Yocto Project Plug-in, see the - "<link linkend='sdk-eclipse-project'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></link>" - Chapter. - </para> - </section> - - <section id='performance-enhancing-tools'> - <title>Performance Enhancing Tools</title> - - <para> - Supported performance enhancing tools are available that let you - profile, debug, and perform tracing on your projects developed - using Eclipse. - For information on these tools see - <ulink url='http://www.eclipse.org/linuxtools/'>http://www.eclipse.org/linuxtools/</ulink>. - </para> - </section> </section> <section id='sdk-development-model'> diff --git a/external/poky/documentation/sdk-manual/sdk-manual-eclipse-customization.xsl b/external/poky/documentation/sdk-manual/sdk-manual-eclipse-customization.xsl deleted file mode 100644 index 77ba5f57..00000000 --- a/external/poky/documentation/sdk-manual/sdk-manual-eclipse-customization.xsl +++ /dev/null @@ -1,35 +0,0 @@ -<?xml version='1.0'?> -<xsl:stylesheet - xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - xmlns="http://www.w3.org/1999/xhtml" - xmlns:fo="http://www.w3.org/1999/XSL/Format" - version="1.0"> - - <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - -<!-- - - <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" /> - - <xsl:import - href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" /> - ---> - - <xsl:param name="chunker.output.indent" select="'yes'"/> - <xsl:param name="chunk.quietly" select="1"/> - <xsl:param name="chunk.first.sections" select="1"/> - <xsl:param name="chunk.section.depth" select="10"/> - <xsl:param name="use.id.as.filename" select="1"/> - <xsl:param name="ulink.target" select="'_self'" /> - <xsl:param name="base.dir" select="'html/adt-manual/'"/> - <xsl:param name="html.stylesheet" select="'../book.css'"/> - <xsl:param name="eclipse.manifest" select="0"/> - <xsl:param name="create.plugin.xml" select="0"/> - <xsl:param name="suppress.navigation" select="1"/> - <xsl:param name="generate.index" select="0"/> - <xsl:param name="chapter.autolabel" select="1" /> - <xsl:param name="appendix.autolabel" select="1" /> - <xsl:param name="section.autolabel" select="1" /> - <xsl:param name="section.label.includes.component.label" select="1" /> -</xsl:stylesheet> diff --git a/external/poky/documentation/sdk-manual/sdk-manual.xml b/external/poky/documentation/sdk-manual/sdk-manual.xml index d4f615f7..a557549e 100644..100755 --- a/external/poky/documentation/sdk-manual/sdk-manual.xml +++ b/external/poky/documentation/sdk-manual/sdk-manual.xml @@ -22,11 +22,10 @@ <authorgroup> <author> - <firstname>Scott</firstname> <surname>Rifenbark</surname> <affiliation> - <orgname>Scotty's Documentation Services, INC</orgname> + <orgname>&ORGNAME;</orgname> </affiliation> - <email>srifenbark@gmail.com</email> + <email>&ORGEMAIL;</email> </author> </authorgroup> @@ -34,7 +33,7 @@ <revision> <revnumber>2.1</revnumber> <date>April 2016</date> - <revremark>Released with the Yocto Project 2.1 Release.</revremark> + <revremark>The initial document released with the Yocto Project 2.1 Release.</revremark> </revision> <revision> <revnumber>2.2</revnumber> @@ -62,24 +61,29 @@ <revremark>Released with the Yocto Project 2.6 Release.</revremark> </revision> <revision> - <revnumber>2.6.1</revnumber> - <date>February 2019</date> - <revremark>Released with the Yocto Project 2.6.1 Release.</revremark> + <revnumber>2.7</revnumber> + <date>May 2019</date> + <revremark>Released with the Yocto Project 2.7 Release.</revremark> </revision> <revision> - <revnumber>2.6.2</revnumber> - <date>April 2019</date> - <revremark>Released with the Yocto Project 2.6.2 Release.</revremark> + <revnumber>3.0</revnumber> + <date>October 2019</date> + <revremark>Released with the Yocto Project 3.0 Release.</revremark> </revision> <revision> - <revnumber>2.6.3</revnumber> - <date>August 2019</date> - <revremark>Released with the Yocto Project 2.6.3 Release.</revremark> + <revnumber>3.1</revnumber> + <date>April 2020</date> + <revremark>Released with the Yocto Project 3.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.4</revnumber> - <date>November 2019</date> - <revremark>Released with the Yocto Project 2.6.4 Release.</revremark> + <revnumber>3.1.1</revnumber> + <date>June 2020</date> + <revremark>Released with the Yocto Project 3.1.1 Release.</revremark> + </revision> + <revision> + <revnumber>3.1.2</revnumber> + <date>&REL_MONTH_YEAR;</date> + <revremark>Released with the Yocto Project 3.1.2 Release.</revremark> </revision> </revhistory> @@ -102,7 +106,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -119,18 +123,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. </para></listitem> - <listitem><para> + <listitem> + <para> To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - <filename>yocto@yoctoproject.com</filename> or log into - the freenode <filename>#yocto</filename> channel. - </para></listitem> + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + <filename>docs@lists.yoctoproject.org</filename> or + log into the freenode <filename>#yocto</filename> channel. + </para> + </listitem> </itemizedlist> </note> </legalnotice> @@ -145,16 +151,12 @@ <xi:include href="sdk-working-projects.xml"/> - <xi:include href="sdk-eclipse-project.xml"/> - <xi:include href="sdk-appendix-obtain.xml"/> <xi:include href="sdk-appendix-customizing.xml"/> <xi:include href="sdk-appendix-customizing-standard.xml"/> - <xi:include href="sdk-appendix-neon.xml"/> - <!-- <index id='index'> <title>Index</title> </index> diff --git a/external/poky/documentation/sdk-manual/sdk-using.xml b/external/poky/documentation/sdk-manual/sdk-using.xml index dd220c34..66b15cd6 100644 --- a/external/poky/documentation/sdk-manual/sdk-using.xml +++ b/external/poky/documentation/sdk-manual/sdk-using.xml @@ -18,8 +18,8 @@ </para> <para> - You can use a standard SDK to work on Makefile, Autotools, and - <trademark class='trade'>Eclipse</trademark>-based projects. + You can use a standard SDK to work on Makefile and Autotools-based + projects. See the "<link linkend='sdk-working-projects'>Using the SDK Toolchain Directly</link>" chapter for more information. @@ -111,11 +111,6 @@ For information on building the installer, see the "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>" section. - Another helpful resource for building an installer is the - <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>Cookbook guide to Making an Eclipse Debug Capable Image</ulink> - wiki page. - This wiki page focuses on development when using the Eclipse - IDE. </note> </para> @@ -149,7 +144,7 @@ Poky (Yocto Project Reference Distro) SDK installer version &DISTRO; =============================================================== Enter target directory for SDK (default: /opt/poky/&DISTRO;): - You are about to install the SDK to "/opt/poky/&DISTRO;". Proceed[Y/n]? Y + You are about to install the SDK to "/opt/poky/&DISTRO;". Proceed [Y/n]? Y Extracting SDK........................................ ..............................done Setting it up...done SDK has been successfully set up and is ready to be used. diff --git a/external/poky/documentation/sdk-manual/sdk-working-projects.xml b/external/poky/documentation/sdk-manual/sdk-working-projects.xml index d8cc4229..521271d5 100644 --- a/external/poky/documentation/sdk-manual/sdk-working-projects.xml +++ b/external/poky/documentation/sdk-manual/sdk-working-projects.xml @@ -7,12 +7,8 @@ <title>Using the SDK Toolchain Directly</title> <para> - You can use the SDK toolchain directly with Makefile, - Autotools, and <trademark class='trade'>Eclipse</trademark>-based - projects. - This chapter covers the first two, while the - "<link linkend='sdk-eclipse-project'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></link>" - Chapter covers the latter. + You can use the SDK toolchain directly with Makefile and + Autotools-based projects. </para> <section id='autotools-based-projects'> diff --git a/external/poky/documentation/toaster-manual/toaster-manual.xml b/external/poky/documentation/toaster-manual/toaster-manual.xml index 15f1702e..fbc05120 100644..100755 --- a/external/poky/documentation/toaster-manual/toaster-manual.xml +++ b/external/poky/documentation/toaster-manual/toaster-manual.xml @@ -22,11 +22,10 @@ <authorgroup> <author> - <firstname>Kristi</firstname> <surname>Rifenbark</surname> <affiliation> - <orgname>Scotty's Documentation Services, INC</orgname> + <orgname>&ORGNAME;</orgname> </affiliation> - <email>kristi@buzzcollectivemarketing.com</email> + <email>&ORGEMAIL;</email> </author> </authorgroup> @@ -34,7 +33,7 @@ <revision> <revnumber>1.8</revnumber> <date>April 2015</date> - <revremark>Released with the Yocto Project 1.8 Release.</revremark> + <revremark>The initial document released with the Yocto Project 1.8 Release.</revremark> </revision> <revision> <revnumber>2.0</revnumber> @@ -72,24 +71,29 @@ <revremark>Released with the Yocto Project 2.6 Release.</revremark> </revision> <revision> - <revnumber>2.6.1</revnumber> - <date>February 2019</date> - <revremark>Released with the Yocto Project 2.6.1 Release.</revremark> + <revnumber>2.7</revnumber> + <date>May 2019</date> + <revremark>Released with the Yocto Project 2.7 Release.</revremark> </revision> <revision> - <revnumber>2.6.2</revnumber> - <date>April 2019</date> - <revremark>Released with the Yocto Project 2.6.2 Release.</revremark> + <revnumber>3.0</revnumber> + <date>October 2019</date> + <revremark>Released with the Yocto Project 3.0 Release.</revremark> </revision> <revision> - <revnumber>2.6.3</revnumber> - <date>August 2019</date> - <revremark>Released with the Yocto Project 2.6.3 Release.</revremark> + <revnumber>3.1</revnumber> + <date>April 2020</date> + <revremark>Released with the Yocto Project 3.1 Release.</revremark> </revision> <revision> - <revnumber>2.6.4</revnumber> - <date>November 2019</date> - <revremark>Released with the Yocto Project 2.6.4 Release.</revremark> + <revnumber>3.1.1</revnumber> + <date>June 2020</date> + <revremark>Released with the Yocto Project 3.1.1 Release.</revremark> + </revision> + <revision> + <revnumber>3.1.2</revnumber> + <date>&REL_MONTH_YEAR;</date> + <revremark>Released with the Yocto Project 3.1.2 Release.</revremark> </revision> </revhistory> @@ -112,7 +116,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -129,18 +133,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink> + <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. </para></listitem> - <listitem><para> + <listitem> + <para> To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - <filename>yocto@yoctoproject.com</filename> or log into - the freenode <filename>#yocto</filename> channel. - </para></listitem> + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + <filename>docs@lists.yoctoproject.org</filename> or + log into the freenode <filename>#yocto</filename> channel. + </para> + </listitem> </itemizedlist> </note> diff --git a/external/poky/documentation/tools/mega-manual.sed b/external/poky/documentation/tools/mega-manual.sed index 34c2ada6..933f23ea 100644 --- a/external/poky/documentation/tools/mega-manual.sed +++ b/external/poky/documentation/tools/mega-manual.sed @@ -1,40 +1,36 @@ -# Processes poky-ref-manual and yocto-project-qs manual (<word>-<word>-<word> style). -# This style is for manual folders like "yocto-project-qs" and "poky-ref-manual". -# This is the old way that did it. Can't do that now that we have "bitbake-user-manual" strings -# in the mega-manual. -# s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/[a-z]*-[a-z]*-[a-z]*/[a-z]*-[a-z]*-[a-z]*.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/yocto-project-qs/yocto-project-qs.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/poky-ref-manual/poky-ref-manual.html#@"link" href="#@g +# Processes bitbake-user-manual (<word>-<word>-<word> style). +# This style is for manual three-word folders, which currently is only the BitBake User Manual. +# We used to have the "yocto-project-qs" and "poky-ref-manual" folders but no longer do. +# s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/[a-z]*-[a-z]*-[a-z]*/[a-z]*-[a-z]*-[a-z]*.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/bitbake-user-manual/bitbake-user-manual.html#@"link" href="#@g -# Processes all other manuals (<word>-<word> style) except for the BitBake User Manual because -# it is not included in the mega-manual. +# Processes all other manuals (<word>-<word> style). # This style is for manual folders that use two word, which is the standard now (e.g. "ref-manual"). -# This was the one-liner that worked before we introduced the BitBake User Manual, which is -# not in the mega-manual. -# s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g +# Here is the one-liner: +# s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/sdk-manual/sdk-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/bsp-guide/bsp-guide.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/dev-manual/dev-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/overview-manual/overview-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/kernel-dev/kernel-dev.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/profile-manual/profile-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/ref-manual/ref-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.6.4/toaster-manual/toaster-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/sdk-manual/sdk-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/bsp-guide/bsp-guide.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/dev-manual/dev-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/overview-manual/overview-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/kernel-dev/kernel-dev.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/profile-manual/profile-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1.2/toaster-manual/toaster-manual.html#@"link" href="#@g # Process cases where just an external manual is referenced without an id anchor -s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6.4/brief-yoctoprojectqs/brief-yoctoprojectqs.html" target="_top">Yocto Project Quick Build</a>@Yocto Project Quick Build@g -s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6.4/yocto-project-qs/yocto-project-qs.html" target="_top">Yocto Project Quick Start</a>@Yocto Project Quick Start@g -s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6.4/dev-manual/dev-manual.html" target="_top">Yocto Project Development Tasks Manual</a>@Yocto Project Development Tasks Manual@g -s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6.4/overview-manual/overview-manual.html" target="_top">Yocto Project Overview and Concepts Manual</a>@Yocto project Overview and Concepts Manual@g -s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6.4/sdk-manual/sdk-manual.html" target="_top">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g -s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6.4/bsp-guide/bsp-guide.html" target="_top">Yocto Project Board Support Package (BSP) Developer's Guide</a>@Yocto Project Board Support Package (BSP) Developer's Guide@g -s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6.4/profile-manual/profile-manual.html" target="_top">Yocto Project Profiling and Tracing Manual</a>@Yocto Project Profiling and Tracing Manual@g -s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6.4/kernel-dev/kernel-dev.html" target="_top">Yocto Project Linux Kernel Development Manual</a>@Yocto Project Linux Kernel Development Manual@g -s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6.4/ref-manual/ref-manual.html" target="_top">Yocto Project Reference Manual</a>@Yocto Project Reference Manual@g -s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6.4/toaster-manual/toaster-manual.html" target="_top">Toaster User Manual</a>@Toaster User Manual@g +s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1.2/brief-yoctoprojectqs/brief-yoctoprojectqs.html" target="_top">Yocto Project Quick Build</a>@Yocto Project Quick Build@g +s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1.2/bitbake-user-manual/bitbake-user-manual.html" target="_top">BitBake User Manual</a>@BitBake User Manual@g +s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1.2/dev-manual/dev-manual.html" target="_top">Yocto Project Development Tasks Manual</a>@Yocto Project Development Tasks Manual@g +s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1.2/overview-manual/overview-manual.html" target="_top">Yocto Project Overview and Concepts Manual</a>@Yocto project Overview and Concepts Manual@g +s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1.2/sdk-manual/sdk-manual.html" target="_top">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g +s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1.2/bsp-guide/bsp-guide.html" target="_top">Yocto Project Board Support Package (BSP) Developer's Guide</a>@Yocto Project Board Support Package (BSP) Developer's Guide@g +s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1.2/profile-manual/profile-manual.html" target="_top">Yocto Project Profiling and Tracing Manual</a>@Yocto Project Profiling and Tracing Manual@g +s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1.2/kernel-dev/kernel-dev.html" target="_top">Yocto Project Linux Kernel Development Manual</a>@Yocto Project Linux Kernel Development Manual@g +s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html" target="_top">Yocto Project Reference Manual</a>@Yocto Project Reference Manual@g +s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1.2/toaster-manual/toaster-manual.html" target="_top">Toaster User Manual</a>@Toaster User Manual@g # Process a single, rouge occurrence of a linked reference to the Mega-Manual. -s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6.4/mega-manual/mega-manual.html" target="_top">Yocto Project Mega-Manual</a>@Yocto Project Mega-Manual@g +s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1.2/mega-manual/mega-manual.html" target="_top">Yocto Project Mega-Manual</a>@Yocto Project Mega-Manual@g |
