From 1a4b7ee28bf7413af6513fb45ad0d0736048f866 Mon Sep 17 00:00:00 2001 From: Brad Bishop Date: Sun, 16 Dec 2018 17:11:34 -0800 Subject: reset upstream subtrees to yocto 2.6 Reset the following subtrees on thud HEAD: poky: 87e3a9739d meta-openembedded: 6094ae18c8 meta-security: 31dc4e7532 meta-raspberrypi: a48743dc36 meta-xilinx: c42016e2e6 Also re-apply backports that didn't make it into thud: poky: 17726d0 systemd-systemctl-native: handle Install wildcards meta-openembedded: 4321a5d libtinyxml2: update to 7.0.1 042f0a3 libcereal: Add native and nativesdk classes e23284f libcereal: Allow empty package 030e8d4 rsyslog: curl-less build with fmhttp PACKAGECONFIG 179a1b9 gtest: update to 1.8.1 Squashed OpenBMC subtree compatibility updates: meta-aspeed: Brad Bishop (1): aspeed: add yocto 2.6 compatibility meta-ibm: Brad Bishop (1): ibm: prepare for yocto 2.6 meta-ingrasys: Brad Bishop (1): ingrasys: set layer compatibility to yocto 2.6 meta-openpower: Brad Bishop (1): openpower: set layer compatibility to yocto 2.6 meta-phosphor: Brad Bishop (3): phosphor: set layer compatibility to thud phosphor: libgpg-error: drop patches phosphor: react to fitimage artifact rename Ed Tanous (4): Dropbear: upgrade options for latest upgrade yocto2.6: update openssl options busybox: remove upstream watchdog patch systemd: Rebase CONFIG_CGROUP_BPF patch Change-Id: I7b1fe71cca880d0372a82d94b5fd785323e3a9e7 Signed-off-by: Brad Bishop --- poky/documentation/Makefile | 3 +- .../brief-yoctoprojectqs/brief-yoctoprojectqs.xml | 41 +- poky/documentation/bsp-guide/bsp-guide.xml | 10 +- poky/documentation/bsp-guide/bsp.xml | 4 +- .../dev-manual/dev-manual-common-tasks.xml | 396 ++++++---- poky/documentation/dev-manual/dev-manual-intro.xml | 4 +- poky/documentation/dev-manual/dev-manual-start.xml | 448 ++++++----- poky/documentation/dev-manual/dev-manual.xml | 10 +- .../dev-manual/figures/multiconfig_files.png | Bin 0 -> 18611 bytes .../documentation/kernel-dev/kernel-dev-common.xml | 2 +- poky/documentation/kernel-dev/kernel-dev.xml | 10 +- .../mega-manual/figures/multiconfig_files.png | Bin 0 -> 18611 bytes poky/documentation/mega-manual/mega-manual.xml | 10 +- .../overview-manual/overview-manual-yp-intro.xml | 2 +- .../overview-manual/overview-manual.xml | 10 +- poky/documentation/poky.ent | 24 +- .../profile-manual/profile-manual-intro.xml | 4 +- .../profile-manual/profile-manual-usage.xml | 4 +- .../profile-manual/profile-manual.xml | 10 +- poky/documentation/ref-manual/migration.xml | 655 +++++++++++++++- poky/documentation/ref-manual/ref-classes.xml | 160 ++-- poky/documentation/ref-manual/ref-manual.xml | 10 +- .../ref-manual/ref-release-process.xml | 2 +- .../ref-manual/ref-system-requirements.xml | 45 +- poky/documentation/ref-manual/ref-tasks.xml | 11 +- poky/documentation/ref-manual/ref-terms.xml | 32 +- poky/documentation/ref-manual/ref-variables.xml | 853 +++++++++++++++------ .../sdk-manual/sdk-appendix-customizing.xml | 76 +- .../sdk-manual/sdk-appendix-obtain.xml | 2 +- .../sdk-manual/sdk-eclipse-project.xml | 4 +- poky/documentation/sdk-manual/sdk-manual.xml | 10 +- .../toaster-manual/toaster-manual-start.xml | 2 +- .../toaster-manual/toaster-manual.xml | 10 +- poky/documentation/tools/mega-manual.sed | 48 +- 34 files changed, 2178 insertions(+), 734 deletions(-) create mode 100644 poky/documentation/dev-manual/figures/multiconfig_files.png create mode 100644 poky/documentation/mega-manual/figures/multiconfig_files.png (limited to 'poky/documentation') diff --git a/poky/documentation/Makefile b/poky/documentation/Makefile index e41d5a0f60..093422f69f 100644 --- a/poky/documentation/Makefile +++ b/poky/documentation/Makefile @@ -165,6 +165,7 @@ 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 endif @@ -261,7 +262,7 @@ TARFILES = mega-manual.html mega-style.css \ figures/image-generation.png figures/key-dev-elements.png\ figures/sdk-generation.png figures/recipe-workflow.png \ figures/build-workspace-directory.png figures/mega-title.png \ - figures/toaster-title.png figures/hosted-service.png \ + figures/toaster-title.png figures/hosted-service.png figures/multiconfig_files.png \ figures/simple-configuration.png figures/poky-reference-distribution.png \ figures/compatible-layers.png figures/import-layer.png figures/new-project.png \ figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \ diff --git a/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml b/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml index 62c4964f5f..f8b01ecc4c 100644 --- a/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml +++ b/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml @@ -37,17 +37,30 @@ hardware. You will use Yocto Project to build a reference embedded OS called Poky. - - The examples in this paper assume you are using a native Linux - system running a recent Ubuntu Linux distribution. - If the machine you want to use - Yocto Project on to build an image is not a native Linux - system, you can still perform these steps by using CROss - PlatformS (CROPS) and setting up a Poky container. - See the - Setting Up to Use CROss PlatformS (CROPS)" - section in the Yocto Project Development Tasks Manual for more - information. + Notes + + + The examples in this paper assume you are using a + native Linux system running a recent Ubuntu Linux + distribution. + If the machine you want to use Yocto Project on to + build an image + (build host) + is not a native Linux system, you can + still perform these steps by using CROss PlatformS + (CROPS) and setting up a Poky container. + See the + Setting Up to Use CROss PlatformS (CROPS)" + section in the Yocto Project Development Tasks Manual for more + information. + + + You cannot use a build host that is using the + Windows Subsystem for Linux + (WSL). + The Yocto Project is not compatible with WSL. + + @@ -75,6 +88,10 @@ Linux distributions that support the Yocto Project, see the "Supported Linux Distributions" section in the Yocto Project Reference Manual. + For detailed information on preparing your build host, see + the + "Preparing the Build Host" + section in the Yocto Project Development Tasks Manual. @@ -110,7 +127,7 @@ For host package requirements on all supported Linux distributions, see the - "Required Packages for the Host Development System" + "Required Packages for the Build Host" section in the Yocto Project Reference Manual. diff --git a/poky/documentation/bsp-guide/bsp-guide.xml b/poky/documentation/bsp-guide/bsp-guide.xml index 0389c725ff..0d5b6b1365 100644 --- a/poky/documentation/bsp-guide/bsp-guide.xml +++ b/poky/documentation/bsp-guide/bsp-guide.xml @@ -122,14 +122,14 @@ Released with the Yocto Project 2.5 Release. - 2.5.1 - September 2018 - The initial document released with the Yocto Project 2.5.1 Release. + 2.6 + November 2018 + Released with the Yocto Project 2.6 Release. - 2.5.2 + 2.6.1 &REL_MONTH_YEAR; - The initial document released with the Yocto Project 2.5.2 Release. + Released with the Yocto Project 2.6.1 Release. diff --git a/poky/documentation/bsp-guide/bsp.xml b/poky/documentation/bsp-guide/bsp.xml index 00a28b0327..0bb0b68ab2 100644 --- a/poky/documentation/bsp-guide/bsp.xml +++ b/poky/documentation/bsp-guide/bsp.xml @@ -187,7 +187,7 @@ Set Up the Build Environment: Be sure you are set up to use BitBake in a shell. See the - "Preparing the Build Host" + "Preparing the Build Host" section in the Yocto Project Development Tasks Manual for information on how to get a build host ready that is either a native Linux machine or a machine that uses CROPS. @@ -1012,7 +1012,7 @@ to Support Development Using the Yocto Project: See the - "Preparing the Build Host" + "Preparing the Build Host" section in the Yocto Project Development Tasks Manual for options on how to get a system ready to use the Yocto Project. diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.xml b/poky/documentation/dev-manual/dev-manual-common-tasks.xml index fe1bfba6cf..c75e718d67 100644 --- a/poky/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/poky/documentation/dev-manual/dev-manual-common-tasks.xml @@ -189,8 +189,8 @@ Yocto Project releases for which the current version is compatible. - This variable is a good way to indicate how - up-to-date your particular layer is. + This variable is a good way to indicate if + your particular layer is current. @@ -3237,30 +3237,22 @@ post-installation script to be delayed until the first boot. For example, the script might need to be executed on the device itself. - To delay script execution until boot time, use the following - structure in the post-installation script: - - pkg_postinst_PACKAGENAME() { - if [ x"$D" = "x" ]; then - # Actions to carry out on the device go here - else - exit 1 - fi - } - - - - - The previous example delays execution until the image boots - again because the environment variable D - points to the directory containing the image when - the root filesystem is created at build time but is unset - when executed on the first boot. + To delay script execution until boot time, you must explicitly + mark post installs to defer to the target. + You can use pkg_postinst_ontarget() or + call + postinst-intercepts defer_to_first_boot + from pkg_postinst(). + Any failure of a pkg_postinst() script + (including exit 1) triggers an error during the + do_rootfs + task. - If you have recipes that use pkg_postinst - scripts and they require the use of non-standard native + If you have recipes that use + pkg_postinst function + and they require the use of non-standard native tools that have dependencies during rootfs construction, you need to use the PACKAGE_WRITE_DEPS @@ -3279,8 +3271,8 @@ pkg_prerm, and pkg_postrm, respectively. These scrips work in exactly the same way as does - pkg_postinst with the exception that they - run at different times. + pkg_postinst with the exception + that they run at different times. Also, because of when they run, they are not applicable to being run at image creation time like pkg_postinst. @@ -4264,7 +4256,7 @@ You need to be sure that your development host is set up to use the Yocto Project. For information on how to set up your host, see the - "Preparing the Build Host" + "Preparing the Build Host" section. @@ -5321,104 +5313,215 @@ -
- Building Targets with Multiple Configurations +
+ Building Images for Multiple Targets Using Multiple Configurations - Bitbake also has functionality that allows you to build - multiple targets at the same time, where each target uses - a different configuration. + You can use a single bitbake command + to build multiple images or packages for different targets + where each image or package requires a different configuration + (multiple configuration builds). + The builds, in this scenario, are sometimes referred to as + "multiconfigs", and this section uses that term throughout. - In order to accomplish this, you setup each of the configurations - you need to use in parallel by placing the configuration files in - your current build directory alongside the usual - local.conf file. + This section describes how to set up for multiple + configuration builds and how to account for cross-build + dependencies between the multiconfigs. - - Follow these guidelines to create an environment that supports - multiple configurations: - - - Create Configuration Files: - You need to create a single configuration file for each - configuration for which you want to add support. - These files would contain lines such as the following: - - MACHINE = "A" - - The files would contain any other variables that can - be set and built in the same directory. - - You can change the - TMPDIR - to not conflict. - +
+ Setting Up and Running a Multiple Configuration Build - - Furthermore, the configuration file must be located in the - current build directory in a directory named - multiconfig under the build's - conf directory where - local.conf resides. - The reason for this restriction is because the - BBPATH variable is not constructed - until the layers are parsed. - Consequently, using the configuration file as a - pre-configuration file is not possible unless it is - located in the current working directory. - - - Add the BitBake Multi-Config Variable to you Local Configuration File: - Use the - BBMULTICONFIG - variable in your conf/local.conf - configuration file to specify each separate configuration. - For example, the following line tells BitBake it should load - conf/multiconfig/configA.conf, - conf/multiconfig/configB.conf, and - conf/multiconfig/configC.conf. - - BBMULTICONFIG = "configA configB configC" - - - - Launch BitBake: - Use the following BitBake command form to launch the - build: - - $ bitbake [multiconfig:multiconfigname:]target [[[multiconfig:multiconfigname:]target] ... ] - - Following is an example that supports building a minimal - image for configuration A alongside a standard - core-image-sato, which takes its - configuration from local.conf: - - $ bitbake multiconfig:configA:core-image-minimal core-image-sato - - - - + + To accomplish a multiple configuration build, you must + define each target's configuration separately using + a parallel configuration file in the + Build Directory, + and you must follow a required file hierarchy. + Additionally, you must enable the multiple configuration + builds in your local.conf file. + - - Support for multiple configurations in this current release of - the Yocto Project (&DISTRO_NAME; &DISTRO;) has some known issues: - - - No inter-multi-configuration dependencies exist. - - - Shared State (sstate) optimizations do not exist. - Consequently, if the build uses the same object twice + + Follow these steps to set up and execute multiple + configuration builds: + + + Create Separate Configuration Files: + You need to create a single configuration file for + each build target (each multiconfig). + Minimally, each configuration file must define the + machine and the temporary directory BitBake uses + for the build. + Suggested practice dictates that you do not + overlap the temporary directories + used during the builds. + However, it is possible that you can share the + temporary directory + (TMPDIR). + For example, consider a scenario with two + different multiconfigs for the same + MACHINE: "qemux86" built for + two distributions such as "poky" and "poky-lsb". + In this case, you might want to use the same + TMPDIR. + + Here is an example showing the minimal + statements needed in a configuration file for + a "qemux86" target whose temporary build directory + is tmpmultix86: + + MACHINE="qemux86" + TMPDIR="${TOPDIR}/tmpmultix86" + + + The location for these multiconfig + configuration files is specific. + They must reside in the current build directory in + a sub-directory of conf named + multiconfig. + Following is an example that defines two + configuration files for the "x86" and "arm" + multiconfigs: + + + + The reason for this required file hierarchy + is because the BBPATH variable + is not constructed until the layers are parsed. + Consequently, using the configuration file as a + pre-configuration file is not possible unless it is + located in the current working directory. + + + Add the BitBake Multi-configuration Variable to the Local Configuration File: + Use the + BBMULTICONFIG + variable in your + conf/local.conf configuration + file to specify each multiconfig. + Continuing with the example from the previous + figure, the BBMULTICONFIG + variable needs to enable two multiconfigs: "x86" + and "arm" by specifying each configuration file: + + BBMULTICONFIG = "x86 arm" + + + + Launch BitBake: + Use the following BitBake command form to launch the + multiple configuration build: + + $ bitbake [multiconfig:multiconfigname:]target [[[multiconfig:multiconfigname:]target] ... ] + + For the example in this section, the following + command applies: + + $ bitbake multiconfig:x86:core-image-minimal multiconfig:arm:core-image-sato + + The previous BitBake command builds a + core-image-minimal image that + is configured through the + x86.conf configuration file + and builds a core-image-sato + image that is configured through the + arm.conf configuration file. + + + + Support for multiple configuration builds in the + Yocto Project &DISTRO; (&DISTRO_NAME;) Release does + not include Shared State (sstate) optimizations. + Consequently, if a build uses the same object twice in, for example, two different TMPDIR directories, the build - will either load from an existing sstate cache at the - start or build the object twice. - - - + either loads from an existing sstate cache for that + build at the start or builds the object fresh. + + +
+ +
+ Enabling Multiple Configuration Build Dependencies + + + Sometimes dependencies can exist between targets + (multiconfigs) in a multiple configuration build. + For example, suppose that in order to build a + core-image-sato image for an "x86" + multiconfig, the root filesystem of an "arm" + multiconfig must exist. + This dependency is essentially that the + do_image + task in the core-image-sato recipe + depends on the completion of the + do_rootfs + task of the core-image-minimal + recipe. + + + + To enable dependencies in a multiple configuration + build, you must declare the dependencies in the recipe + using the following statement form: + + task_or_package[mcdepends] = "multiconfig:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend" + + To better show how to use this statement, consider the + example scenario from the first paragraph of this section. + The following statement needs to be added to the recipe + that builds the core-image-sato + image: + + do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_rootfs" + + In this example, the + from_multiconfig is "x86". + The to_multiconfig is "arm". + The task on which the do_image task + in the recipe depends is the do_rootfs + task from the core-image-minimal + recipe associated with the "arm" multiconfig. + + + + Once you set up this dependency, you can build the + "x86" multiconfig using a BitBake command as follows: + + $ bitbake multiconfig:x86:core-image-sato + + This command executes all the tasks needed to create + the core-image-sato image for the + "x86" multiconfig. + Because of the dependency, BitBake also executes through + the do_rootfs task for the "arm" + multiconfig build. + + + + Having a recipe depend on the root filesystem of another + build might not seem that useful. + Consider this change to the statement in the + core-image-sato recipe: + + do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_image" + + In this case, BitBake must create the + core-image-minimal image for the + "arm" build since the "x86" build depends on it. + + + + Because "x86" and "arm" are enabled for multiple + configuration builds and have separate configuration + files, BitBake places the artifacts for each build in the + respective temporary build directories (i.e. + TMPDIR). + +
@@ -7159,13 +7262,12 @@ easier-to-use and more flexible replacements for an existing functionality in OE-Core's image-live - class and mkefidisk.sh script. - The difference between - Wic and those examples is - that with Wic the - functionality of those scripts is implemented - by a general-purpose partitioning language, which is - based on Redhat kickstart syntax. + class. + The difference between Wic and those examples is + that with Wic the functionality of those scripts is + implemented by a general-purpose partitioning language, + which is based on Redhat kickstart syntax. +
@@ -11400,8 +11502,8 @@ within a separately started QEMU or any other virtual machine manager. - "Systemd-bootTarget": - Choose "Systemd-bootTarget" if your hardware is + "SystemdbootTarget": + Choose "SystemdbootTarget" if your hardware is an EFI-based machine with systemd-boot as bootloader and core-image-testmaster @@ -11409,10 +11511,10 @@ Also, your hardware under test must be in a DHCP-enabled network that gives it the same IP address for each reboot. - If you choose "Systemd-bootTarget", there are + If you choose "SystemdbootTarget", there are additional requirements and considerations. See the - "Selecting Systemd-bootTarget" + "Selecting SystemdbootTarget" section, which follows, for more information. "BeagleBoneTarget": @@ -11458,12 +11560,12 @@
-
- Selecting Systemd-bootTarget +
+ Selecting SystemdbootTarget If you did not set TEST_TARGET to - "Systemd-bootTarget", then you do not need any information + "SystemdbootTarget", then you do not need any information in this section. You can skip down to the "Running Tests" @@ -11472,7 +11574,7 @@ If you did set TEST_TARGET to - "Systemd-bootTarget", you also need to perform a one-time + "SystemdbootTarget", you also need to perform a one-time setup of your master image by doing the following: Set EFI_PROVIDER: @@ -11543,7 +11645,7 @@ The final thing you need to do when setting - TEST_TARGET to "Systemd-bootTarget" is + TEST_TARGET to "SystemdbootTarget" is to set up the test image: Set up your local.conf file: @@ -11552,7 +11654,7 @@ IMAGE_FSTYPES += "tar.gz" INHERIT += "testimage" - TEST_TARGET = "Systemd-bootTarget" + TEST_TARGET = "SystemdbootTarget" TEST_TARGET_IP = "192.168.2.3" @@ -11687,16 +11789,15 @@ To run the tests automatically after the OpenEmbedded build system successfully creates an image, first set the - TEST_IMAGE + TESTIMAGE_AUTO variable to "1" in your local.conf file in the Build Directory: - TEST_IMAGE = "1" + TESTIMAGE_AUTO = "1" Next, build your image. - If the image successfully builds, the tests will be - run: + If the image successfully builds, the tests run: bitbake core-image-sato @@ -11969,7 +12070,7 @@ The target controller object used to deploy and start an image on a particular target (e.g. QemuTarget, SimpleRemote, and - Systemd-bootTarget). + SystemdbootTarget). Tests usually use the following: ip: @@ -15072,6 +15173,31 @@
+ +
+ Copying Licenses that Do Not Exist + + + Some packages, such as the linux-firmware package, have many + licenses that are not in any way common. + You can avoid adding a lot of these types of common license + files, which are only applicable to a specific package, by using + the + NO_GENERIC_LICENSE + variable. + Using this variable also avoids QA errors when you use a + non-common, non-CLOSED license in a recipe. + + + + The following is an example that uses the + LICENSE.Abilis.txt + file as the license from the fetched source: + + NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt" + + +
diff --git a/poky/documentation/dev-manual/dev-manual-intro.xml b/poky/documentation/dev-manual/dev-manual-intro.xml index f457c8033a..3a34094b8c 100644 --- a/poky/documentation/dev-manual/dev-manual-intro.xml +++ b/poky/documentation/dev-manual/dev-manual-intro.xml @@ -19,7 +19,7 @@ - The following list describes what you can get from this manual: + This manual provides the following: Procedures that help you get going with the Yocto Project. @@ -44,7 +44,7 @@ - This manual will not give you the following: + This manual does not provide the following: Redundant Step-by-step Instructions: diff --git a/poky/documentation/dev-manual/dev-manual-start.xml b/poky/documentation/dev-manual/dev-manual-start.xml index d8726b4857..3f971ba4b0 100644 --- a/poky/documentation/dev-manual/dev-manual-start.xml +++ b/poky/documentation/dev-manual/dev-manual-start.xml @@ -10,8 +10,10 @@ This chapter provides procedures related to getting set up to use the Yocto Project. You can learn about creating a team environment that develops using the - Yocto Project, how to set up a build host, how to locate Yocto Project - source repositories, and how to create local Git repositories. + Yocto Project, how to set up a + build host, + how to locate Yocto Project source repositories, and how to create local + Git repositories.
@@ -19,69 +21,71 @@ It might not be immediately clear how you can use the Yocto - Project in a team development environment, or scale it for a large - team of developers. + 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, these characteristics can cause a struggle if you are trying + However, this flexibility could cause difficulties if you are trying to create a working setup that scales across a large team. To help you understand how to set up this type of environment, - this section presents a procedure that gives you the information - to learn how to get the results you want. + this section presents a procedure that gives you information + 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 work well. + technologies that have proved to work well in the past. Keep in mind, the procedure here is a starting point. - You can build off it and customize it to fit any + You can build off these steps and customize the procedure to fit any particular working environment and set of practices. Determine Who is Going to be Developing: You need to understand who is going to be doing anything related to the Yocto Project and what their roles would be. - Making this determination is essential to completing the + Making this determination is essential to completing steps two and three, which are to get your equipment together and set up your development environment's hardware topology. The following roles exist: - - - Application Development: - These types of developers do application level work - on top of an existing software stack. - - - Core System Development: - These types of developers work on the contents of the - operating system image itself. - - - Build Engineer: - This type of developer manages Autobuilders and - releases. - Not all environments need a Build Engineer. - - - Test Engineer: - This type of developer creates and manages automated - tests needed to ensure all application and core - system development meets desired quality standards. - - + + + Application Developer: + This type of developer does application level work + on top of an existing software stack. + + + Core System Developer: + This type of developer works on the contents of the + operating system image itself. + + + Build Engineer: + This type of developer manages Autobuilders and + releases. + Not all environments need a Build Engineer. + + + Test Engineer: + This type of developer creates and manages automated + tests that are used to ensure all application and + core system development meets desired quality + standards. + + Gather the Hardware: Based on the size and make-up of the team, get the hardware together. - Any development, build, or test engineer should be using - a system that is running a supported Linux distribution. - Systems, in general, should be high performance (e.g. dual, - six-core Xeons with 24 Gbytes of RAM and plenty of disk space). + Ideally, any development, build, or test engineer uses + a system that runs a supported Linux distribution. + These systems, in general, should be high performance + (e.g. dual, six-core Xeons with 24 Gbytes of RAM and plenty + of disk space). You can help ensure efficiency by having any machines used for testing or that run Autobuilders be as high performance as possible. @@ -107,11 +111,12 @@ Use Git as Your Source Control Manager (SCM): Keeping your Metadata - 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 recommends using + (i.e. recipes, configuration files, classes, and so forth) + 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 + recommends using Git. Git is a distributed system that is easy to backup, allows you to work remotely, and then connects back to the @@ -129,20 +134,19 @@ being used to generate the web interface that lets you view the repositories. The gitolite software identifies users - using SSH keys and allows branch-based - access controls to repositories that you can control as little - or as much as necessary. - + using SSH keys and allows branch-based access controls to + repositories that you can control as little or as much as + necessary. The setup of these services is beyond the scope of this manual. - However, sites such as these exist that describe how to - perform setup: + However, sites such as the following exist that describe + how to perform setup: Git documentation: - Describes how to install gitolite - on the server. + Describes how to install + gitolite on the server. Gitolite: @@ -150,8 +154,8 @@ Interfaces, frontends, and tools: - Documentation on how to create interfaces and frontends - for Git. + Documentation on how to create interfaces and + frontends for Git. @@ -161,23 +165,22 @@ As mentioned earlier, application developers are creating applications on top of existing software stacks. Following are some best practices for setting up machines - that do application development: + used for application development: - Use a pre-built toolchain that - contains the software stack itself. + Use a pre-built toolchain that contains the software + stack itself. Then, develop the application code on top of the stack. This method works well for small numbers of relatively isolated applications. - When possible, use the Yocto Project - plug-in for the + When possible, use the Yocto Project plug-in for the Eclipse IDE and SDK development practices. For more information, see the - "Yocto Project Application Development and the Extensible Software Development Kit (eSDK)" + Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. @@ -186,27 +189,29 @@ toolchain downloads or as updates through a package update mechanism using opkg to provide updates to an existing toolchain. - The exact mechanics of how and when to do this are a - question for local policy. + The exact mechanics of how and when to do this depend + on local policy. - Use multiple toolchains installed locally - into different locations to allow development across + Use multiple toolchains installed locally into + different locations to allow development across versions. Set up the Core Development Machines: - As mentioned earlier, these types of developers work on the - contents of the operating system itself. + As mentioned earlier, core developers work on the contents of + the operating system itself. Following are some best practices for setting up machines used for developing images: - Have the Yocto Project build system itself available on - the developer workstations so developers can run their own - builds and directly rebuild the software stack. + Have the + OpenEmbedded build system + available on the developer workstations so developers + can run their own builds and directly rebuild the + software stack. Keep the core system unchanged as much as @@ -228,8 +233,9 @@ Autobuilders are often the core of the development environment. It is here that changes from individual developers are brought - together and centrally tested and subsequent decisions about - releases can be made. + together and centrally tested. + Based on this automated build and test environment, subsequent + decisions about releases can be made. Autobuilders also allow for "continuous integration" style testing of software components and regression identification and tracking. @@ -239,22 +245,23 @@ The Yocto Project team has found this implementation works well in this role. A public example of this is the Yocto Project - Autobuilders, which we use to test the overall health of the - project. + Autobuilders, which the Yocto Project team uses to test the + overall health of the project. The features of this system are: - Highlights when commits break the build. - + Highlights when commits break the build. + - Populates an sstate cache from which - developers can pull rather than requiring local - builds. + Populates an + sstate cache + from which developers can pull rather than requiring + local builds. - Allows commit hook triggers, - which trigger builds when commits are made. + Allows commit hook triggers, which trigger builds when + commits are made. Allows triggering of automated image booting @@ -275,19 +282,19 @@ Allows scheduling of builds so that resources can be used efficiently. - - - - Set up Test Machines: - Use a small number of shared, high performance systems - for testing purposes. - Developers can use these systems for wider, more - extensive testing while they continue to develop - locally using their primary development system. - - - Document Policies and Change Flow: - The Yocto Project itself uses a hierarchical structure and a + + + + Set up Test Machines: + Use a small number of shared, high performance systems + for testing purposes. + Developers can use these systems for wider, more + extensive testing while they continue to develop + locally using their primary development system. + + + Document Policies and Change Flow: + The Yocto Project uses a hierarchical structure and a pull model. Scripts exist to create and send pull requests (i.e. create-pull-request and @@ -330,16 +337,20 @@ Maintain your Metadata in layers that make sense for your situation. - See the "Understanding - and Creating Layers" section for more information on - layers. + See the + "The Yocto Project Layer Model" + section in the Yocto Project Overview and Concepts + Manual and the + "Understanding and Creating Layers" + section for more information on layers. Separate the project's Metadata and code by using separate Git repositories. See the "Yocto Project Source Repositories" - section for information on these repositories. + section in the Yocto Project Overview and Concepts + Manual for information on these repositories. See the "Locating Yocto Project Source Files" section for information on how to set up local Git @@ -360,7 +371,8 @@ The Yocto Project community encourages you - to send patches to the project to fix bugs or add features. + to send patches to the project to fix bugs or add + features. If you do submit patches, follow the project commit guidelines for writing good commit messages. See the "Submitting a Change to the Yocto Project" @@ -369,10 +381,12 @@ Send changes to the core sooner than later as others are likely to run into the same issues. - For some guidance on mailing lists to use, see the list in the + For some guidance on mailing lists to use, see the list + in the "Submitting a Change to the Yocto Project" section. - For a description of the available mailing lists, see the + For a description of the available mailing lists, see + the "Mailing Lists" section in the Yocto Project Reference Manual. @@ -382,22 +396,28 @@
-
+
Preparing the Build Host - This section provides procedures to set up your development host to - use the Yocto Project. - You can use the Yocto Project on a native Linux development host or - you can use + This section provides procedures to set up a system to be used as your + build host + for development using the Yocto Project. + Your build host can be a native Linux machine (recommended) or it can + be a machine (Linux, Mac, or Windows) that uses CROPS, which leverages - Docker Containers, - to prepare any Linux, Mac, or Windows development host. + Docker Containers. + + You cannot use a build host that is using the + Windows Subsystem for Linux + (WSL). + The Yocto Project is not compatible with WSL. + - Once your development host is set up to use the Yocto Project, + Once your build host is set up to use the Yocto Project, further steps are necessary depending on what you want to accomplish. See the following references for information on how to prepare for @@ -432,7 +452,7 @@ Follow these steps to prepare a native Linux machine as your - Yocto Project development host: + Yocto Project Build Host: Use a Supported Linux Distribution: @@ -450,8 +470,8 @@ Have Enough Free Memory: - You should have at least 50 Gbytes of free disk space - for building images. + Your system should have at least 50 Gbytes of free disk + space for building images. Meet Minimal Version Requirements: @@ -480,14 +500,14 @@ Install Development Host Packages: Required development host packages vary depending on your - build machine and what you want to do with the Yocto + build host and what you want to do with the Yocto Project. Collectively, the number of required packages is large if you want to be able to cover all cases. For lists of required packages for all scenarios, see the - "Required Packages for the Host Development System" + "Required Packages for the Build Host" section in the Yocto Project Reference Manual. @@ -514,7 +534,7 @@ With - CROPS, + CROPS, which leverages Docker Containers, you can create a Yocto Project development environment that @@ -525,66 +545,101 @@ Follow these general steps to prepare a Windows, Mac, or Linux - machine as your Yocto Project development host: + machine as your Yocto Project build host: - Go to the Docker Installation Site: + Determine What Your Build Host Needs: Docker is a software container platform that you need to install - on the host development machine. - To start the installation process, see the - Docker Installation - site. + on the build host. + Depending on your build host, you might have to install + different software to support Docker containers. + Go to the Docker installation page and read about the + platform requirements in + "Supported Platforms" + your build host needs to run containers. - Choose Your Docker Edition: - Docker comes in several editions. - For the Yocto Project, the stable community edition - (i.e. "Docker CE Stable") is adequate. - You can learn more about the Docker editions from the - site. + Choose What To Install: + Depending on whether or not your build host meets system + requirements, you need to install "Docker CE Stable" or + the "Docker Toolbox". + Most situations call for Docker CE. + However, if you have a build host that does not meet + requirements (e.g. Pre-Windows 10 or Windows 10 "Home" + version), you must install Docker Toolbox instead. Go to the Install Site for Your Platform: Click the link for the Docker edition associated with - your development host machine's native software. - For example, if your machine is running Microsoft + your build host's native software. + For example, if your build host is running Microsoft Windows Version 10 and you want the Docker CE Stable edition, click that link under "Supported Platforms". - - Understand What You Need: - The install page has pre-requisites your machine must - meet. - Be sure you read through this page and make sure your - machine meets the requirements to run Docker. - If your machine does not meet the requirements, the page - has instructions to handle exceptions. - For example, to run Docker on Windows 10, you must have - the pro version of the operating system. - If you have the home version, you need to install the - Docker Toolbox. - - - Another example is that a Windows machine needs to - have Microsoft Hyper-V. - If you have a legacy version of the the Microsoft - operating system or for any other reason you do not have - Microsoft Hyper-V, you would have to enter the BIOS and - enable virtualization. - Install the Software: Once you have understood all the pre-requisites, you can download and install the appropriate software. Follow the instructions for your specific machine and - the type of the software you need to install. + the type of the software you need to install: + + + Install + Docker CE for Windows + for Windows build hosts that meet requirements. + + + Install + Docker CE for Macs + for Mac build hosts that meet requirements. + + + Install + Docker Toolbox for Windows + for Windows build hosts that do not meet Docker + requirements. + + + Install + Docker Toolbox for MacOS + for Mac build hosts that do not meet Docker + requirements. + + + Install + Docker CE for CentOS + for Linux build hosts running the CentOS + distribution. + + + Install + Docker CE for Debian + for Linux build hosts running the Debian + distribution. + + + Install + Docker CE for Fedora + for Linux build hosts running the Fedora + distribution. + + + Install + Docker CE for Ubuntu + for Linux build hosts running the Ubuntu + distribution. + + Optionally Orient Yourself With Docker: If you are unfamiliar with Docker and the container concept, you can learn more here - . + + + Launch Docker or Docker Toolbox: You should be able to launch Docker or the Docker Toolbox and have a terminal shell on your development host. @@ -593,7 +648,7 @@ Go to and follow the directions for your particular - development host (i.e. Linux, Mac, or Windows). + build host (i.e. Linux, Mac, or Windows). Once you complete the setup instructions for your machine, you have the Poky, Extensible SDK, and Toaster @@ -622,8 +677,8 @@ Locating Yocto Project Source Files - This section contains procedures related to locating Yocto Project - files. + 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. Notes @@ -670,7 +725,7 @@ Select the Repository: - Click on the repository in which you are interested (i.e. + Click on the repository in which you are interested (e.g. poky). @@ -704,6 +759,7 @@ The procedure in this section exists should you desire a tarball snapshot of any given component. + Follow these steps to locate and download a particular tarball: Access the Index of Releases: @@ -753,7 +809,10 @@ uses a "DOWNLOADS" page from which you can locate and download tarballs of any Yocto Project release. Rather than Git repositories, these files represent snapshot - tarballs. + tarballs similar to the tarballs located in the Index of Releases + described in the + "Accessing Index of Releases" + section. Tip The recommended method for accessing Yocto Project components is to use Git to clone a repository and work from @@ -771,18 +830,23 @@ Get to the Downloads Area: Select the "DOWNLOADS" item from the pull-down - "SOFTWARE" tab menu. + "SOFTWARE" tab menu near the top of the page. Select a Yocto Project Release: Use the menu next to "RELEASE" to display and choose - a Yocto Project release (e.g. sumo, rocko, pyro, and - so forth. - For a "map" of Yocto Project releases to version numbers, - see the - Releases - wiki page. - + a recent or past supported Yocto Project release + (e.g. &DISTRO_NAME_NO_CAP;, + &DISTRO_NAME_NO_CAP_MINUS_ONE;, and so forth). + Tip + For a "map" of Yocto Project releases to version + numbers, see the + Releases + wiki page. + + You can use the "RELEASE ARCHIVE" link to reveal a menu of + all Yocto Project releases. + Download Tools or Board Support Packages (BSPs): From the "DOWNLOADS" page, you can download tools or @@ -799,8 +863,9 @@ Yocto Project maintains an area for nightly builds that contains tarball releases at . - These builds include Yocto Project releases, SDK installation - scripts, and experimental builds. + These builds include Yocto Project releases ("poky"), + toolchains, Yocto Project plugins for Eclipse, and builds for + supported machines. @@ -808,14 +873,21 @@ Yocto Project component, use the following procedure: - Access the Nightly Builds: + Locate the Index of Nightly Builds: Open a browser and go to to access the Nightly Builds. + + Select a Date: + Click on the date in which you are interested. + If you want the latest builds, use "CURRENT". + Select a Build: - Click on any build by date in which you are interested. + Choose the area in which you are interested. + For example, if you are looking for the most recent + toolchains, select the "toolchain" link. Find the Tarball: @@ -831,27 +903,23 @@
-
+
Cloning and Checking Out Branches - To use the Yocto Project, you need a release of the Yocto Project - locally installed on your development system. - The locally installed set of files is referred to as the + To use the Yocto Project for development, you need a release locally + installed on your development system. + This locally installed set of files is referred to as the Source Directory in the Yocto Project documentation. - You create your Source Directory by using + The preferred method of creating your Source Directory is by using Git to clone a local copy of the upstream poky repository. - Tip - The preferred method of getting the Yocto Project Source - Directory set up is to clone the repository. - - Working from a copy of the upstream repository allows you - to contribute back into the Yocto Project or simply work with + Working from a cloned copy of the upstream repository allows you + to contribute back into the Yocto Project or to simply work with the latest software on a development branch. Because Git maintains and creates an upstream repository with a complete history of changes and you are working with a local @@ -871,21 +939,23 @@ Set Your Directory: - Be in the directory where you want to create your local - copy of poky. + Change your working directory to where you want to + create your local copy of + poky. Clone the Repository: - The following command clones the repository and uses + The following example command clones the + poky repository and uses the default name "poky" for your local repository: $ git clone git://git.yoctoproject.org/poky Cloning into 'poky'... - remote: Counting objects: 367178, done. - remote: Compressing objects: 100% (88161/88161), done. - remote: Total 367178 (delta 272761), reused 366942 (delta 272525) - Receiving objects: 100% (367178/367178), 133.26 MiB | 6.40 MiB/s, done. - Resolving deltas: 100% (272761/272761), done. + 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. Checking connectivity... done. Unless you specify a specific development branch or @@ -900,8 +970,8 @@ Checking Out By Tag in Poky" sections, respectively. - Once the repository is created, you can change to - that directory and check its status. + Once the local repository is created, you can + change to that directory and check its status. Here, the single "master" branch exists on your system and by default, it is checked out: @@ -916,6 +986,10 @@ Your local repository of poky is identical to the upstream poky repository at the time from which it was cloned. + As you work with the local branch, you can periodically + use the git pull ‐‐rebase + command to be sure you are up-to-date with the upstream + branch. diff --git a/poky/documentation/dev-manual/dev-manual.xml b/poky/documentation/dev-manual/dev-manual.xml index d473142f36..b54c0d65d5 100644 --- a/poky/documentation/dev-manual/dev-manual.xml +++ b/poky/documentation/dev-manual/dev-manual.xml @@ -107,14 +107,14 @@ Released with the Yocto Project 2.5 Release. - 2.5.1 - September 2018 - The initial document released with the Yocto Project 2.5.1 Release. + 2.6 + November 2018 + Released with the Yocto Project 2.6 Release. - 2.5.2 + 2.6.1 &REL_MONTH_YEAR; - The initial document released with the Yocto Project 2.5.2 Release. + Released with the Yocto Project 2.6.1 Release. diff --git a/poky/documentation/dev-manual/figures/multiconfig_files.png b/poky/documentation/dev-manual/figures/multiconfig_files.png new file mode 100644 index 0000000000..0b59338b3a Binary files /dev/null and b/poky/documentation/dev-manual/figures/multiconfig_files.png differ diff --git a/poky/documentation/kernel-dev/kernel-dev-common.xml b/poky/documentation/kernel-dev/kernel-dev-common.xml index 4c6fc35dab..9052876122 100644 --- a/poky/documentation/kernel-dev/kernel-dev-common.xml +++ b/poky/documentation/kernel-dev/kernel-dev-common.xml @@ -25,7 +25,7 @@ Before you can do any kernel development, you need to be sure your build host is set up to use the Yocto Project. For information on how to get set up, see the - "Preparing the Build Host" + "Preparing the Build Host" section in the Yocto Project Development Tasks Manual. Part of preparing the system is creating a local Git repository of the diff --git a/poky/documentation/kernel-dev/kernel-dev.xml b/poky/documentation/kernel-dev/kernel-dev.xml index e5e6fd1d71..fc46c205b5 100644 --- a/poky/documentation/kernel-dev/kernel-dev.xml +++ b/poky/documentation/kernel-dev/kernel-dev.xml @@ -92,14 +92,14 @@ Released with the Yocto Project 2.5 Release. - 2.5.1 - September 2018 - The initial document released with the Yocto Project 2.5.1 Release. + 2.6 + November 2018 + Released with the Yocto Project 2.6 Release. - 2.5.2 + 2.6.1 &REL_MONTH_YEAR; - The initial document released with the Yocto Project 2.5.2 Release. + Released with the Yocto Project 2.6.1 Release. diff --git a/poky/documentation/mega-manual/figures/multiconfig_files.png b/poky/documentation/mega-manual/figures/multiconfig_files.png new file mode 100644 index 0000000000..0b59338b3a Binary files /dev/null and b/poky/documentation/mega-manual/figures/multiconfig_files.png differ diff --git a/poky/documentation/mega-manual/mega-manual.xml b/poky/documentation/mega-manual/mega-manual.xml index 4a68999de0..7a4199198b 100644 --- a/poky/documentation/mega-manual/mega-manual.xml +++ b/poky/documentation/mega-manual/mega-manual.xml @@ -76,14 +76,14 @@ Released with the Yocto Project 2.5 Release. - 2.5.1 - September 2018 - The initial document released with the Yocto Project 2.5.1 Release. + 2.6 + November 2018 + Released with the Yocto Project 2.6 Release. - 2.5.2 + 2.6.1 &REL_MONTH_YEAR; - The initial document released with the Yocto Project 2.5.2 Release. + Released with the Yocto Project 2.6.1 Release. diff --git a/poky/documentation/overview-manual/overview-manual-yp-intro.xml b/poky/documentation/overview-manual/overview-manual-yp-intro.xml index ccf5e274a7..d34b640e21 100644 --- a/poky/documentation/overview-manual/overview-manual-yp-intro.xml +++ b/poky/documentation/overview-manual/overview-manual-yp-intro.xml @@ -1296,7 +1296,7 @@ It is worth noting that the term "package" can, in general, have subtle meanings. For example, the packages referred to in the - "Required Packages for the Host Development System" + "Required Packages for the Build Host" section in the Yocto Project Reference Manual are compiled binaries that, when installed, add functionality to your Linux distribution. diff --git a/poky/documentation/overview-manual/overview-manual.xml b/poky/documentation/overview-manual/overview-manual.xml index d7f04abe95..320ca35530 100644 --- a/poky/documentation/overview-manual/overview-manual.xml +++ b/poky/documentation/overview-manual/overview-manual.xml @@ -37,14 +37,14 @@ The initial document released with the Yocto Project 2.5 Release. - 2.5.1 - September 2018 - The initial document released with the Yocto Project 2.5.1 Release. + 2.6 + November 2018 + Released with the Yocto Project 2.6 Release. - 2.5.2 + 2.6.1 &REL_MONTH_YEAR; - The initial document released with the Yocto Project 2.5.2 Release. + Released with the Yocto Project 2.6.1 Release. diff --git a/poky/documentation/poky.ent b/poky/documentation/poky.ent index 1b71b8070e..c76fe7b2d3 100644 --- a/poky/documentation/poky.ent +++ b/poky/documentation/poky.ent @@ -1,17 +1,17 @@ - - - - - - - - - - + + + + + + + + + + - - + + diff --git a/poky/documentation/profile-manual/profile-manual-intro.xml b/poky/documentation/profile-manual/profile-manual-intro.xml index d38d61a820..f16db3f0f2 100644 --- a/poky/documentation/profile-manual/profile-manual-intro.xml +++ b/poky/documentation/profile-manual/profile-manual-intro.xml @@ -92,7 +92,9 @@ EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs" Additionally, in order to generate the right type of - debuginfo, we also need to add the following to local.conf: + debuginfo, we also need to set + PACKAGE_DEBUG_SPLIT_STYLE + in the local.conf file: PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory' diff --git a/poky/documentation/profile-manual/profile-manual-usage.xml b/poky/documentation/profile-manual/profile-manual-usage.xml index c0873e13ab..a1b565157d 100644 --- a/poky/documentation/profile-manual/profile-manual-usage.xml +++ b/poky/documentation/profile-manual/profile-manual-usage.xml @@ -375,7 +375,9 @@ EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs" Additionally, in order to generate the type of debuginfo that - perf understands, we also need to add the following to local.conf: + perf understands, we also need to set + PACKAGE_DEBUG_SPLIT_STYLE + in the local.conf file: PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory' diff --git a/poky/documentation/profile-manual/profile-manual.xml b/poky/documentation/profile-manual/profile-manual.xml index 7629386aaa..10ca68e501 100644 --- a/poky/documentation/profile-manual/profile-manual.xml +++ b/poky/documentation/profile-manual/profile-manual.xml @@ -92,14 +92,14 @@ Released with the Yocto Project 2.5 Release. - 2.5.1 - September 2018 - The initial document released with the Yocto Project 2.5.1 Release. + 2.6 + November 2018 + Released with the Yocto Project 2.6 Release. - 2.5.2 + 2.6.1 &REL_MONTH_YEAR; - The initial document released with the Yocto Project 2.5.2 Release. + Released with the Yocto Project 2.6.1 Release. diff --git a/poky/documentation/ref-manual/migration.xml b/poky/documentation/ref-manual/migration.xml index b060968000..c648d8d442 100644 --- a/poky/documentation/ref-manual/migration.xml +++ b/poky/documentation/ref-manual/migration.xml @@ -3619,7 +3619,7 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. The - KERNEL_IMAGE_BASE_NAME + KERNEL_IMAGE_BASE_NAME variable no longer uses the KERNEL_IMAGETYPE variable to create the image's base name. @@ -5557,8 +5557,9 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message. incompatible with other implementations. - By default, the cmake class uses - ninja instead of + By default, the + cmake + class uses ninja instead of make for building. This improves build performance. If a recipe is broken with ninja, then @@ -5608,7 +5609,11 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message. Any failure of a pkg_postinst() script (including exit 1) will trigger a warning during - do_rootfs. + do_rootfs. + + For more information, see the + "Post-Installation Scripts" + section in the Yocto Project Development Tasks Manual. The elf image type has been removed. @@ -5678,6 +5683,648 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message.
+ +
+ Moving to the Yocto Project 2.6 Release + + + This section provides migration information for moving to the + Yocto Project 2.6 Release from the prior release. + + +
+ GCC 8.2 is Now Used by Default + + + The GNU Compiler Collection version 8.2 is now used by default + for compilation. + For more information on what has changed in the GCC 8.x release, + see + . + + + + If you still need to compile with version 7.x, GCC 7.3 is + also provided. + You can select this version by setting the + and can be selected by setting the + GCCVERSION + variable to "7.%" in your configuration. + +
+ +
+ Removed Recipes + + + The following recipes have been removed: + + beecrypt: No longer needed since moving to RPM 4. + bigreqsproto: Replaced by xorgproto. + calibrateproto: Removed in favor of xinput. + compositeproto: Replaced by xorgproto. + damageproto: Replaced by xorgproto. + dmxproto: Replaced by xorgproto. + dri2proto: Replaced by xorgproto. + dri3proto: Replaced by xorgproto. + eee-acpi-scripts: Became obsolete. + fixesproto: Replaced by xorgproto. + fontsproto: Replaced by xorgproto. + fstests: Became obsolete. + gccmakedep: No longer used. + glproto: Replaced by xorgproto. + gnome-desktop3: No longer needed. This recipe has moved to meta-oe. + icon-naming-utils: No longer used since the Sato theme was removed in 2016. + inputproto: Replaced by xorgproto. + kbproto: Replaced by xorgproto. + libusb-compat: Became obsolete. + libuser: Became obsolete. + libnfsidmap: No longer an external requirement since nfs-utils 2.2.1. libnfsidmap is now integrated. + libxcalibrate: No longer needed with xinput + mktemp: Became obsolete. The mktemp command is provided by both busybox and coreutils. + ossp-uuid: Is not being maintained and has mostly been replaced by uuid.h in util-linux. + pax-utils: No longer needed. Previous QA tests that did use this recipe are now done at build time. + pcmciautils: Became obsolete. + pixz: No longer needed. xz now supports multi-threaded compression. + presentproto: Replaced by xorgproto. + randrproto: Replaced by xorgproto. + recordproto: Replaced by xorgproto. + renderproto: Replaced by xorgproto. + resourceproto: Replaced by xorgproto. + scrnsaverproto: Replaced by xorgproto. + trace-cmd: Became obsolete. perf replaced this recipe's functionally. + videoproto: Replaced by xorgproto. + wireless-tools: Became obsolete. Superseded by iw. + xcmiscproto: Replaced by xorgproto. + xextproto: Replaced by xorgproto. + xf86dgaproto: Replaced by xorgproto. + xf86driproto: Replaced by xorgproto. + xf86miscproto: Replaced by xorgproto. + xf86-video-omapfb: Became obsolete. Use kernel modesetting driver instead. + xf86-video-omap: Became obsolete. Use kernel modesetting driver instead. + xf86vidmodeproto: Replaced by xorgproto. + xineramaproto: Replaced by xorgproto. + xproto: Replaced by xorgproto. + yasm: No longer needed since previous usages are now satisfied by nasm. + + +
+ +
+ Packaging Changes + + + The following packaging changes have been made: + + + cmake: + cmake.m4 and + toolchain files have been moved to the + main package. + + + iptables: + The iptables modules have been split + into separate packages. + + + alsa-lib: + libasound is now in the main + alsa-lib package instead of + libasound. + + + glibc: + libnss-db is now in its own package + along with a /var/db/makedbs.sh + script to update databases. + + + python and python3: + The main package has been removed from the recipe. + You must install specific packages or + python-modules / + python3-modules for everything. + + + systemtap: + Moved systemtap-exporter into its own + package. + + + +
+ +
+ XOrg Protocol dependencies + + + The "*proto" upstream repositories have been combined into one + "xorgproto" repository. + Thus, the corresponding recipes have also been combined into a + single xorgproto recipe. + Any recipes that depend upon the older *proto + recipes need to be changed to depend on the newer + xorgproto recipe instead. + + + + For names of recipes removed because of this repository change, + see the + Removed Recipes + section. + +
+ +
+ <filename>distutils</filename> and <filename>distutils3</filename> Now Prevent Fetching Dependencies During the <filename>do_configure</filename> Task + + + Previously, it was possible for Python recipes that inherited + the + distutils + and + distutils3 + classes to fetch code during the + do_configure + task to satisfy dependencies mentioned in + setup.py if those dependencies were not + provided in the sysroot (i.e. recipes providing the dependencies + were missing from + DEPENDS). + + This change affects classes beyond just the two mentioned + (i.e. distutils and + distutils3). + Any recipe that inherits distutils* + classes are affected. + For example, the setuptools and + setuptools3 recipes are affected since + they inherit the distutils* classes. + + + + + Fetching these types of dependencies that are not provided in the + sysroot negatively affects the ability to reproduce builds. + This type of fetching is now explicitly disabled. + Consequently, any missing dependencies in Python recipes that + use these classes now result in an error during the + do_configure task. + +
+ +
+ <filename>linux-yocto</filename> Configuration Audit Issues Now Correctly Reported + + + Due to a bug, the kernel configuration audit functionality was + not writing out any resulting warnings during the build. + This issue is now corrected. + You might notice these warnings now if you have a custom kernel + configuration with a linux-yocto style + kernel recipe. + +
+ +
+ Image/Kernel Artifact Naming Changes + + + The following changes have been made: + + + Name variables (e.g. + IMAGE_NAME) + use a new IMAGE_VERSION_SUFFIX + variable instead of + DATETIME. + Using IMAGE_VERSION_SUFFIX allows + easier and more direct changes. + + The IMAGE_VERSION_SUFFIX + variable is set in the + bitbake.conf configuration file as + follows: + + IMAGE_VERSION_SUFFIX = "-${DATETIME}" + + + + Several variables have changed names for consistency: + + Old Variable Name New Variable Name + ======================================================== + KERNEL_IMAGE_BASE_NAME KERNEL_IMAGE_NAME + KERNEL_IMAGE_SYMLINK_NAME KERNEL_IMAGE_LINK_NAME + MODULE_TARBALL_BASE_NAME MODULE_TARBALL_NAME + MODULE_TARBALL_SYMLINK_NAME MODULE_TARBALL_LINK_NAME + INITRAMFS_BASE_NAME INITRAMFS_NAME + + + + The MODULE_IMAGE_BASE_NAME variable + has been removed. + The module tarball name is now controlled directly with the + MODULE_TARBALL_NAME + variable. + + + The + KERNEL_DTB_NAME + and + KERNEL_DTB_LINK_NAME + variables have been introduced to control kernel Device + Tree Binary (DTB) artifact names instead of mangling + KERNEL_IMAGE_* variables. + + + The + KERNEL_FIT_NAME + and + KERNEL_FIT_LINK_NAME + variables have been introduced to specify the name of + flattened image tree (FIT) kernel images similar to other + deployed artifacts. + + + The + MODULE_TARBALL_NAME + and + MODULE_TARBALL_LINK_NAME + variable values no longer include the "module-" prefix or + ".tgz" suffix. + These parts are now hardcoded so that the values are + consistent with other artifact naming variables. + + + Added the + INITRAMFS_LINK_NAME + variable so that the symlink can be controlled similarly + to other artifact types. + + + INITRAMFS_NAME + now uses + "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + instead of + "${PV}-${PR}-${MACHINE}-${DATETIME}", which + makes it consistent with other variables. + + + +
+ +
+ <filename>SERIAL_CONSOLE</filename> Deprecated + + + The + SERIAL_CONSOLE + variable has been functionally replaced by the + SERIAL_CONSOLES + variable for some time. + With the Yocto Project 2.6 release, + SERIAL_CONSOLE has been officially deprecated. + + + + SERIAL_CONSOLE will continue to work as + before for the 2.6 release. + However, for the sake of future compatibility, it is recommended + that you replace all instances of + SERIAL_CONSOLE with + SERIAL_CONSOLES. + + The only difference in usage is that + SERIAL_CONSOLES expects entries to be + separated using semicolons as compared to + SERIAL_CONSOLE, which expects spaces. + + +
+ +
+ Configure Script Reports Unknown Options as Errors + + + If the configure script reports an unknown option, this now + triggers a QA error instead of a warning. + Any recipes that previously got away with specifying such unknown + options now need to be fixed. + +
+ +
+ Override Changes + + + The following changes have occurred: + + + The virtclass-native and + virtclass-nativesdk Overrides Have + Been Removed: + The virtclass-native and + virtclass-nativesdk overrides have + been deprecated since 2012 in favor of + class-native and + class-nativesdk, respectively. + Both virtclass-native and + virtclass-nativesdk are now dropped. + + The virtclass-multilib- overrides + for multilib are still valid. + + + + The forcevariable + Override Now Has a Higher Priority Than + libc Overrides: + The forcevariable override is + documented to be the highest priority override. + However, due to a long-standing quirk of how + OVERRIDES + is set, the libc overrides (e.g. + libc-glibc, + libc-musl, and so forth) erroneously + had a higher priority. + This issue is now corrected. + + It is likely this change will not cause any + problems. + However, it is possible with some unusual configurations + that you might see a change in behavior if you were + relying on the previous behavior. + Be sure to check how you use + forcevariable and + libc-* overrides in your custom + layers and configuration files to ensure they make sense. + + + The build-${BUILD_OS} + Override Has Been Removed: + The build-${BUILD_OS}, which is + typically build-linux, override has + been removed because building on a host operating system + other than a recent version of Linux is neither supported + nor recommended. + Dropping the override avoids giving the impression that + other host operating systems might be supported. + + + The "_remove" operator now preserves whitespace. + Consequently, when specifying list items to remove, be + aware that leading and trailing whitespace resulting from + the removal is retained. + + See the + "Removal (Override Style Syntax)" + section in the BitBake User Manual for a detailed example. + + + +
+ +
+ <filename>systemd</filename> Configuration is Now Split Into <filename>systemd-conf</filename> + + + The configuration for the systemd recipe + has been moved into a system-conf recipe. + Moving this configuration to a separate recipe avoids the + systemd recipe from becoming machine-specific + for cases where machine-specific configurations need to be applied + (e.g. for qemu* machines). + + + + Currently, the new recipe packages the following files: + + ${sysconfdir}/machine-id + ${sysconfdir}/systemd/coredump.conf + ${sysconfdir}/systemd/journald.conf + ${sysconfdir}/systemd/logind.conf + ${sysconfdir}/systemd/system.conf + ${sysconfdir}/systemd/user.conf + + If you previously used bbappend files to append the + systemd recipe to change any of the + listed files, you must do so for the + systemd-conf recipe instead. + +
+ +
+ Automatic Testing Changes + + + This section provides information about automatic testing + changes: + + + TEST_IMAGE Variable Removed: + Prior to this release, you set the + TEST_IMAGE variable to "1" to + enable automatic testing for successfully built images. + The TEST_IMAGE variable no longer + exists and has been replaced by the + TESTIMAGE_AUTO + variable. + + + Inheriting the testimage and + testsdk Classes: + Best practices now dictate that you use the + IMAGE_CLASSES + variable rather than the + INHERIT + variable when you inherit the + testimage + and + testsdk + classes used for automatic testing. + + + +
+ +
+ OpenSSL Changes + + + OpenSSL has been + upgraded from 1.0 to 1.1. + By default, this upgrade could cause problems for recipes that + have both versions in their dependency chains. + The problem is that both versions cannot be installed together + at build time. + + It is possible to have both versions of the library at runtime. + + +
+ +
+ BitBake Changes + + + The server logfile bitbake-cookerdaemon.log is + now always placed in the + Build Directory + instead of the current directory. + +
+ +
+ Security Changes + + + The Poky distribution now uses security compiler flags by + default. + Inclusion of these flags could cause new failures due to stricter + checking for various potential security issues in code. + +
+ +
+ Post Installation Changes + + + You must explicitly mark post installs to defer to the target. + If you want to explicitly defer a postinstall to first boot on + the target rather than at rootfs creation time, use + pkg_postinst_ontarget() or call + postinst-intercepts defer_to_first_boot from + pkg_postinst(). + Any failure of a pkg_postinst() script + (including exit 1) triggers an error during the + do_rootfs task. + + + + For more information on post-installation behavior, see the + "Post-Installation Scripts" + section in the Yocto Project Development Tasks Manual. + +
+ +
+ Python 3 Profile-Guided Optimization + + + The python3 recipe now enables profile-guided + optimization. + Using this optimization requires a little extra build time in + exchange for improved performance on the target at runtime. + Additionally, the optimization is only enabled if the current + MACHINE + has support for user-mode emulation in QEMU (i.e. "qemu-usermode" + is in + MACHINE_FEATURES, + which it is by default). + + + + If you wish to disable Python profile-guided optimization + regardless of the value of + MACHINE_FEATURES, then ensure that + PACKAGECONFIG + for the python3 recipe does not contain "pgo". + You could accomplish the latter using the following at the + configuration level: + + PACKAGECONFIG_remove_pn-python3 = "pgo" + + Alternatively, you can set + PACKAGECONFIG using an append file for the + python3 recipe. + +
+ +
+ Miscellaneous Changes + + + The following miscellaneous changes occurred: + + + Default to using the Thumb-2 instruction set for armv7a + and above. + If you have any custom recipes that build software that + needs to be built with the ARM instruction set, change the + recipe to set the instruction set as follows: + + ARM_INSTRUCTION_SET = "arm" + + + + run-postinsts no longer uses + /etc/*-postinsts for + dpkg/opkg in favor of built-in + postinst support. + RPM behavior remains unchanged. + + + The NOISO and + NOHDD variables are no longer used. + You now control building *.iso and + *.hddimg image types directly + by using the + IMAGE_FSTYPES + variable. + + + The scripts/contrib/mkefidisk.sh + has been removed in favor of Wic. + + + kernel-modules has been removed from + RRECOMMENDS + for qemumips and + qemumips64 machines. + Removal also impacts the x86-base.inc + file. + + genericx86 and + genericx86-64 retain + kernel-modules as part of the + RRECOMMENDS variable setting. + + + + The LGPLv2_WHITELIST_GPL-3.0 + variable has been removed. + If you are setting this variable in your configuration, + set or append it to the + WHITELIST_GPL-3.0 variable instead. + + + ${ASNEEDED} is now included in + the + TARGET_LDFLAGS + variable directly. + The remaining definitions from + meta/conf/distro/include/as-needed.inc + have been moved to corresponding recipes. + + + Support for DSA host keys has been dropped from the + OpenSSH recipes. + If you are still using DSA keys, you must switch over to a + more secure algorithm as recommended by OpenSSH upstream. + + + The dhcp recipe now uses the + dhcpd6.conf configuration file in + dhcpd6.service for IPv6 DHCP rather + than re-using dhcpd.conf, which is + now reserved for IPv4. + + + +
+
+ Ubuntu 14.04 (LTS) Ubuntu 14.10 Ubuntu 15.04 - Ubuntu 15.10 + Ubuntu 15.10 --> Ubuntu 16.04 (LTS) - + Fedora 19 (Schrödinger's Cat) + Fedora release 20 (Heisenbug) Fedora release 22 Fedora release 23 - + Fedora release 26 + CentOS release 7.x - Debian GNU/Linux 8.x (Jessie) Debian GNU/Linux 9.x (Stretch) - - - openSUSE 13.2 + openSUSE 13.1 + openSUSE 13.2 --> openSUSE 42.1 + openSUSE 42.2 @@ -132,8 +143,8 @@
-
- Required Packages for the Host Development System +
+ Required Packages for the Build Host The list of packages you need on the host development system can diff --git a/poky/documentation/ref-manual/ref-tasks.xml b/poky/documentation/ref-manual/ref-tasks.xml index e6cf68670b..8f3ff26d24 100644 --- a/poky/documentation/ref-manual/ref-tasks.xml +++ b/poky/documentation/ref-manual/ref-tasks.xml @@ -596,15 +596,6 @@
-
- <filename>do_rm_work_all</filename> - - - Top-level task for removing work files after the build system has - finished with them. - -
-
<filename>do_unpack</filename> @@ -895,7 +886,7 @@ Boots an image and performs runtime tests within the image immediately after it has been built. This task is enabled when you set - TEST_IMAGE + TESTIMAGE_AUTO equal to "1". diff --git a/poky/documentation/ref-manual/ref-terms.xml b/poky/documentation/ref-manual/ref-terms.xml index cc09d3f8af..c573a521a7 100644 --- a/poky/documentation/ref-manual/ref-terms.xml +++ b/poky/documentation/ref-manual/ref-terms.xml @@ -29,11 +29,31 @@ information in the similarly-named recipe file. For an example of an append file in use, see the "Using .bbappend Files in Your Layer" - section in the Yocto Project Development Tasks Manual. - - Append files can also use wildcard patterns in their - version numbers so they can be applied to more than one - version of the underlying recipe file. + section in the Yocto Project Development Tasks Manual. + + When you name an append file, you can use the + "%" wildcard character to allow for + matching recipe names. + For example, suppose you have an append file named as follows: + + busybox_1.21.%.bbappend + + That append file would match any + busybox_1.21.x.bb + version of the recipe. + So, the append file would match the following recipe names: + + busybox_1.21.1.bb + busybox_1.21.2.bb + busybox_1.21.3.bb + + Important + The use of the "%" character + is limited in that it only works directly in front of the + .bbappend portion of the append file's + name. + You cannot use the wildcard character in any other + location of the name. @@ -329,7 +349,7 @@ It is worth noting that the term "package" can, in general, have subtle meanings. For example, the packages referred to in the - "Required Packages for the Host Development System" + "Required Packages for the Build Host" section are compiled binaries that, when installed, add functionality to your Linux distribution. diff --git a/poky/documentation/ref-manual/ref-variables.xml b/poky/documentation/ref-manual/ref-variables.xml index e88389647d..9e51b7591c 100644 --- a/poky/documentation/ref-manual/ref-variables.xml +++ b/poky/documentation/ref-manual/ref-variables.xml @@ -679,6 +679,20 @@ BB_ALLOWED_NETWORKS = "*.gnu.org" + Important + The use of the "*" + character only works at the beginning of + a host name and it must be isolated from + the remainder of the host name. + You cannot use the wildcard character in any + other location of the name or combined with + the front part of the name. + + For example, + *.foo.bar is supported, + while *aa.foo.bar is not. + + Mirrors not in the host list are skipped and @@ -1133,12 +1147,22 @@ BBFILES - BBFILES[doc] = "List of recipe files used by BitBake to build software." + BBFILES[doc] = "A space-separated list of recipe files BitBake uses to build software." - List of recipe files used by BitBake to build software. + A space-separated list of recipe files BitBake uses to + build software. + + + + When specifying recipe files, you can pattern match using + Python's + glob + syntax. + For details on the syntax, see the documentation by + following the previous link. @@ -1267,15 +1291,19 @@ match any of the expressions. It is as if BitBake does not see them at all. Consequently, matching files are not parsed or otherwise - used by BitBake. + used by BitBake. + + The values you provide are passed to Python's regular expression compiler. + Consequently, the syntax follows Python's Regular + Expression (re) syntax. The expressions are compared against the full paths to the files. For complete syntax information, see Python's - documentation for the appropriate release at - . + documentation at + . @@ -1336,7 +1364,7 @@ BBMULTICONFIG in an environment that supports building targets with multiple configurations, see the - "Building Targets with Multiple Configurations" + "Building Images for Multiple Targets Using Multiple Configurations" section in the Yocto Project Development Tasks Manual. @@ -1443,6 +1471,17 @@ set up during compilation so that they are correct for use when installed into the sysroot and called by the build processes of other recipes. + + The BINCONFIG_GLOB variable + uses + shell globbing, + which is recognition and expansion of wildcards during + pattern matching. + Shell globbing is very similar to + fnmatch + and + glob. + @@ -2366,6 +2405,14 @@ Defines wildcards to match when installing a list of complementary packages for all the packages explicitly (or implicitly) installed in an image. + + The COMPLEMENTARY_GLOB variable + uses Unix filename pattern matching + (fnmatch), + which is similar to the Unix style pathname pattern + expansion + (glob). + The resulting list of complementary packages is associated with an item that can be added to IMAGE_FEATURES. @@ -4586,7 +4633,12 @@ - Additional cmake options. + Additional + CMake + options. + See the + cmake + class for additional information. @@ -4782,23 +4834,38 @@ FILES_${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile" + Notes + + + When specifying files or paths, you can pattern + match using Python's + glob + syntax. + For details on the syntax, see the + documentation by following the previous link. + + + When specifying paths as part of the + FILES variable, it is + good practice to use appropriate path + variables. + For example, use ${sysconfdir} + rather than /etc, or + ${bindir} rather than + /usr/bin. + You can find a list of these variables at the + top of the + meta/conf/bitbake.conf + file in the + Source Directory. + You will also find the default values of the + various FILES_* variables + in this file. + + + - - When specifying paths as part of the - FILES variable, it is good practice - to use appropriate path variables. - For example, use ${sysconfdir} rather - than /etc, or - ${bindir} rather than - /usr/bin. - You can find a list of these variables at the top of the - meta/conf/bitbake.conf file in the - Source Directory. - You will also find the default values of the various - FILES_* variables in this file. - - If some of the files you provide with the FILES variable are editable and you @@ -5166,6 +5233,28 @@ + GCCVERSION + + GCCVERSION[doc] = "Specifies the default version of the GNU C Compiler (GCC) to use." + + + + + Specifies the default version of the GNU C Compiler (GCC) + used for compilation. + By default, GCCVERSION is set to + "8.x" in the + meta/conf/distro/include/tcmode-default.inc + include file: + + GCCVERSION ?= "8.%" + + You can override this value by setting it in a configuration + file such as the local.conf. + + + + GDB GDB[doc] = "The minimal command and arguments to run the GNU Debugger." @@ -6940,6 +7029,61 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" + INITRAMFS_LINK_NAME + + INITRAMFS_LINK_NAME[doc] = "The link name of the initial RAM filesystem image." + + + + + The link name of the initial RAM filesystem image. + This variable is set in the + meta/classes/kernel-artifact-names.bbclass + file as follows: + + INITRAMFS_LINK_NAME ?= "initramfs-${KERNEL_ARTIFACT_LINK_NAME}" + + The value of the KERNEL_ARTIFACT_LINK_NAME + variable, which is set in the same file, has the following + value: + + KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" + + + + + See the + MACHINE + variable for additional information. + + + + + INITRAMFS_NAME + + INITRAMFS_NAME[doc] = "The base name of the initial RAM filesystem image." + + + + + The base name of the initial RAM filesystem image. + This variable is set in the + meta/classes/kernel-artifact-names.bbclass + file as follows: + + INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}" + + The value of the + KERNEL_ARTIFACT_NAME + variable, which is set in the same file, has the following + value: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + + + + + INITRD INITRD[doc] = "Indicates a list of filesystem images to concatenate and use as an initial RAM disk (initrd)." @@ -7316,6 +7460,45 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" + KERNEL_ARTIFACT_NAME + + KERNEL_ARTIFACT_NAME[doc] = "Specifies the name of all of the build artifacts." + + + + + Specifies the name of all of the build artifacts. + You can change the name of the artifacts by changing the + KERNEL_ARTIFACT_NAME variable. + + + + The value of KERNEL_ARTIFACT_NAME, + which is set in the + meta/classes/kernel-artifact-names.bbclass + file, has the following default value: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + + + + + See the + PKGE, + PKGV, + PKGR, + and + MACHINE + variables for additional information. + + The IMAGE_VERSION_SUFFIX variable + is set to + DATETIME. + + + + + KERNEL_CLASSES KERNEL_CLASSES[doc] = "A list of classes defining kernel image types that kernel class should inherit." @@ -7365,6 +7548,61 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" + KERNEL_DTB_LINK_NAME + + KERNEL_DTB_LINK_NAME[doc] = "The link name of the kernel device tree binary (DTB)." + + + + + The link name of the kernel device tree binary (DTB). + This variable is set in the + meta/classes/kernel-artifact-names.bbclass + file as follows: + + KERNEL_DTB_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" + + The value of the KERNEL_ARTIFACT_LINK_NAME + variable, which is set in the same file, has the following + value: + + KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" + + + + + See the + MACHINE + variable for additional information. + + + + + KERNEL_DTB_NAME + + KERNEL_DTB_NAME[doc] = "The base name of the kernel device tree binary (DTB)." + + + + + The base name of the kernel device tree binary (DTB). + This variable is set in the + meta/classes/kernel-artifact-names.bbclass + file as follows: + + KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}" + + The value of the + KERNEL_ARTIFACT_NAME + variable, which is set in the same file, has the following + value: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + + + + + KERNEL_EXTRA_ARGS KERNEL_EXTRA_ARGS[doc] = "Specifies additional make command-line arguments the OpenEmbedded build system passes on when compiling the kernel." @@ -7422,38 +7660,93 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" - KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" - KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" - KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc" - + KERNEL_FEATURES_append_qemuall = " cfg/virtio.scc" + KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc" + KERNEL_FEATURES_append_qemux86-64 = " cfg/sound.scc" - KERNEL_IMAGE_BASE_NAME + KERNEL_FIT_LINK_NAME - KERNEL_IMAGE_BASE_NAME[doc] = "The base name of the kernel image." + KERNEL_FIT_LINK_NAME[doc] = "The link name of the kernel flattened image tree (FIT) image." - The base name of the kernel image. + The link name of the kernel flattened image tree (FIT) image. This variable is set in the - kernel class - as follows: + meta/classes/kernel-artifact-names.bbclass + file as follows: + + KERNEL_FIT_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" + + The value of the KERNEL_ARTIFACT_LINK_NAME + variable, which is set in the same file, has the following + value: - KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" + KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" See the - PKGE, - PKGV, - PKGR, - MACHINE, - and - DATETIME - variables for additional information. + MACHINE + variable for additional information. + + + + + KERNEL_FIT_NAME + + KERNEL_FIT_NAME[doc] = "The base name of the kernel flattened image tree (FIT) image." + + + + + The base name of the kernel flattened image tree (FIT) image. + This variable is set in the + meta/classes/kernel-artifact-names.bbclass + file as follows: + + KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}" + + The value of the + KERNEL_ARTIFACT_NAME + variable, which is set in the same file, has the following + value: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + + + + + + KERNEL_IMAGE_LINK_NAME + + KERNEL_IMAGE_LINK_NAME[doc] = "The link name for the kernel image." + + + + + The link name for the kernel image. + This variable is set in the + meta/classes/kernel-artifact-names.bbclass + file as follows: + + KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" + + The value of the KERNEL_ARTIFACT_LINK_NAME + variable, which is set in the same file, has the following + value: + + KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" + + + + + See the + MACHINE + variable for additional information. @@ -7489,6 +7782,31 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" + KERNEL_IMAGE_NAME + + KERNEL_IMAGE_NAME[doc] = "The base name of the kernel image." + + + + + The base name of the kernel image. + This variable is set in the + meta/classes/kernel-artifact-names.bbclass + file as follows: + + KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}" + + The value of the + KERNEL_ARTIFACT_NAME + variable, which is set in the same file, has the following + value: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + + + + + KERNEL_IMAGETYPE KERNEL_IMAGETYPE[doc] = "The type of kernel to build for a device, usually set by the machine configuration files and defaults to 'zImage'." @@ -8902,47 +9220,73 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" - MODULE_IMAGE_BASE_NAME + MODULE_TARBALL_DEPLOY - MODULE_IMAGE_BASE_NAME[doc] = "The base name of the kernel modules tarball." + MODULE_TARBALL_DEPLOY[doc] = "Controls creation of the modules-*.tgz file. Set this variable to "0" to disable creation of this file, which contains all of the kernel modules resulting from a kernel build." - The base name of the kernel modules tarball. + Controls creation of the modules-*.tgz + file. + Set this variable to "0" to disable creation of this + file, which contains all of the kernel modules resulting + from a kernel build. + + + + + MODULE_TARBALL_LINK_NAME + + MODULE_TARBALL_LINK_NAME[doc] = "The link name of the kernel module tarball." + + + + + The link name of the kernel module tarball. This variable is set in the - kernel class - as follows: + meta/classes/kernel-artifact-names.bbclass + file as follows: - MODULE_IMAGE_BASE_NAME ?= "modules-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" + MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" + + The value of the KERNEL_ARTIFACT_LINK_NAME + variable, which is set in the same file, has the following + value: + + KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" See the - PKGE, - PKGV, - PKGR, - MACHINE, - and - DATETIME - variables for additional information. + MACHINE + variable for additional information. - MODULE_TARBALL_DEPLOY + MODULE_TARBALL_NAME - MODULE_TARBALL_DEPLOY[doc] = "Controls creation of the modules-*.tgz file. Set this variable to "0" to disable creation of this file, which contains all of the kernel modules resulting from a kernel build." + MODULE_TARBALL_NAME[doc] = "The base name of the kernel module tarball." - Controls creation of the modules-*.tgz - file. - Set this variable to "0" to disable creation of this - file, which contains all of the kernel modules resulting - from a kernel build. + The base name of the kernel module tarball. + This variable is set in the + meta/classes/kernel-artifact-names.bbclass + file as follows: + + MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}" + + The value of the + KERNEL_ARTIFACT_NAME + variable, which is set in the same file, has the following + value: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + @@ -9058,6 +9402,40 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" + NO_GENERIC_LICENSE + + NO_GENERIC_LICENSE[doc] = "Used to allow copying a license that does not exist in common licenses." + + + + + Avoids QA errors when you use a non-common, non-CLOSED + license in a recipe. + Packages exist, such as the linux-firmware package, with + many licenses that are not in any way common. + Also, new licenses are added occasionally to avoid + introducing a lot of common license files, which are only + applicable to a specific package. + NO_GENERIC_LICENSE is used to allow + copying a license that does not exist in common licenses. + + + + The following example shows how to add + NO_GENERIC_LICENSE to a recipe: + + NO_GENERIC_LICENSE[license_name] = "license_file_in_fetched_source" + + The following is an example that uses the + LICENSE.Abilis.txt file as the license + from the fetched source: + + NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt" + + + + + NO_RECOMMENDATIONS NO_RECOMMENDATIONS[doc] = "When set to '1', no recommended packages will be installed. Some recommended packages might be required for certain system functionality, such as kernel-modules. It is up to the user to add packages to IMAGE_INSTALL as needed." @@ -9141,44 +9519,6 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" - - NOHDD - - NOHDD[doc] = "Causes the OpenEmbedded build system to skip building the .hddimg image." - - - - - Causes the OpenEmbedded build system to skip building the - .hddimg image. - The NOHDD variable is used with the - image-live - class. - Set the variable to "1" to prevent the - .hddimg image from being built. - - - - - NOISO - - NOISO[doc] = "Causes the OpenEmbedded build system to skip building the ISO image." - - - - - Causes the OpenEmbedded build system to skip building the - ISO image. - The NOISO variable is used with the - image-live - class. - Set the variable to "1" to prevent the ISO image from - being built. - To enable building an ISO image, set the variable to "0". - - - - O @@ -9612,6 +9952,12 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" ".debug" previously described with the exception that no source files are installed. . + + "debug-with-srcpkg": The same behavior as + ".debug" previously described with the exception + that all source files are placed in a separate + *-src pkg. + @@ -9991,9 +10337,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Here is the basic block structure: PACKAGECONFIG ??= "f1 f2 f3 ..." - PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1" - PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2" - PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-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" @@ -10002,7 +10348,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" 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 four order-dependent + each feature by providing up to five order-dependent arguments, which are separated by commas. You can omit any argument you like but must retain the separating commas. @@ -10028,6 +10374,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" (RDEPENDS) that should be added if the feature is enabled. + Additional runtime recommendations + (RRECOMMENDS) + that should be added if the feature is enabled. + @@ -10076,7 +10426,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" PACKAGECONFIG. You can either completely override the variable: - PACKAGECONFIG="f4 f5" + PACKAGECONFIG = "f4 f5" Or, you can just append the variable: @@ -10090,7 +10440,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" As with append files previously described, you can either completely override the variable: - PACKAGECONFIG_pn-recipename="f4 f5" + PACKAGECONFIG_pn-recipename = "f4 f5" Or, you can just amend the variable: @@ -10708,17 +11058,16 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" to build. This variable works in conjunction with the blacklist - class, which the recipe must inherit globally. + class, which is inherited globally. - To prevent a recipe from being built, inherit the class - globally and use the variable in your + To prevent a recipe from being built, use the + PNBLACKLIST variable in your local.conf file. Here is an example that prevents myrecipe from being built: - INHERIT += "blacklist" PNBLACKLIST[myrecipe] = "Not supported by our organization." @@ -10896,47 +11245,63 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" - If there are multiple versions of recipes available, this - variable determines which recipe should be given preference. + If multiple versions of recipes exist, this + variable determines which version is given preference. You must always suffix the variable with the PN you want to select, and you should set the PV accordingly for precedence. - You can use the "%" character as a - wildcard to match any number of characters, which can be - useful when specifying versions that contain long revision - numbers that could potentially change. + + + + The PREFERRED_VERSION variable + supports limited wildcard use through the + "%" character. + You can use the character to match any number of + characters, which can be useful when specifying versions + that contain long revision numbers that potentially change. Here are two examples: PREFERRED_VERSION_python = "3.4.0" PREFERRED_VERSION_linux-yocto = "4.12%" - - The specified version is matched against - PV, - which does not necessarily match the version part of - the recipe's filename. - For example, consider two recipes - foo_1.2.bb and - foo_git.bb where - foo_git.bb contains the following - assignment: - + Important + The use of the "%" character + is limited in that it only works at the end of the + string. + You cannot use the wildcard character in any other + location of the string. + + + + + The specified version is matched against + PV, + which does not necessarily match the version part of + the recipe's filename. + For example, consider two recipes + foo_1.2.bb and + foo_git.bb where + foo_git.bb contains the following + assignment: + PV = "1.1+git${SRCPV}" - - In this case, the correct way to select - foo_git.bb is by using an - assignment such as the following: - + + In this case, the correct way to select + foo_git.bb is by using an + assignment such as the following: + PREFERRED_VERSION_foo = "1.1+git%" - - Compare that previous example against the following - incorrect example, which does not work: - + + Compare that previous example against the following + incorrect example, which does not work: + PREFERRED_VERSION_foo = "git" - - + + + + Sometimes the PREFERRED_VERSION variable can be set by configuration files in a way that is hard to change. @@ -12566,22 +12931,33 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" SDK_TITLE - SDK_TITLE[doc] = "Specifies a title to be printed when running the SDK installer." + SDK_TITLE[doc] = "The title to be printed when running the SDK installer." - Specifies a title to be printed when running the SDK - installer. - The SDK_TITLE variable defaults to - "distro SDK" for the standard - SDK and "distro Extensible SDK" - for the extensible SDK, where - distro is the first one of + The title to be printed when running the SDK installer. + By default, this title is based on the DISTRO_NAME or DISTRO - that is set in your configuration. + variable and is set in the + populate_sdk_base + class as follows: + + SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" + + For the default distribution "poky", + SDK_TITLE is set to + "Poky (Yocto Project Reference Distro)". + + + + For information on how to change this default title, + see the + "Changing the Extensible SDK Installer Title" + section in the Yocto Project Application Development and + the Extensible Software Development Kit (eSDK) manual. @@ -12640,6 +13016,36 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" + SDKEXTPATH + + SDKEXTPATH[doc] = "The default installation directory for the extensible SDK." + + + + + The default installation directory for the Extensible SDK. + By default, this directory is based on the + DISTRO + variable and is set in the + populate_sdk_base + class as follows: + + SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" + + For the default distribution "poky", the + SDKEXTPATH is set to "poky_sdk". + + + + For information on how to change this default directory, + see the + "Changing the Default SDK Installation Directory" + section in the Yocto Project Application Development and + the Extensible Software Development Kit (eSDK) manual. + + + + SDKIMAGE_FEATURES SDKIMAGE_FEATURES[doc] = "Equivalent to IMAGE_FEATURES. However, this variable applies to the SDK generated from an image using the command 'bitbake -c populate_sdk imagename'." @@ -13506,7 +13912,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" MIRRORS and PREMIRRORS and points to the cache locations to check for the shared - objects. + state (sstate) objects. @@ -13518,6 +13924,25 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" other machines. + + When pointing to sstate build artifacts on another machine + that uses a different GCC version for native builds, + you must configure SSTATE_MIRROR + with a regular expression that maps local search paths + to server paths. + The paths need to take into account + NATIVELSBSTRING + set by the + uninative + class. + For example, the following maps the local search path + universal-4.9 to the server-provided + path server_url_sstate_path: + + SSTATE_MIRRORS ?= file://universal-4.9/(.*) http://server_url_sstate_path/universal-4.8/\1 \n + + + If a mirror uses the same structure as SSTATE_DIR, @@ -14860,6 +15285,26 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" + TCLIBC + + TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or "newlib." + + + + + Specifies the GNU standard C library + (libc) variant to use during the + build process. + This variable replaces POKYLIBC, + which is no longer supported. + + + + You can select "glibc", "musl", "newlib", or "baremetal" + + + + TCLIBCAPPEND TCLIBCAPPEND[doc] = "Specifies a suffix appended to TMPDIR that identifies the libc variant for the build." @@ -14891,25 +15336,6 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" - TCLIBC - - TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc' or 'musl'." - - - - - Specifies the GNU standard C library (libc) - variant to use during the build process. - This variable replaces POKYLIBC, which is no longer - supported. - - - - You can select "glibc" or "musl". - - - - TCMODE TCMODE[doc] = "Enables an external toolchain (where provided by an additional layer) if set to a value other than 'default'." @@ -15017,41 +15443,6 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" - TEST_IMAGE - - TEST_IMAGE[doc] = "Enables test booting of virtual machine images under the QEMU emulator after any root filesystems are created and runs tests against those images." - - - - - Automatically runs the series of automated tests for - images when an image is successfully built. - - - - These tests are written in Python making use of the - unittest module, and the majority of - them run commands on the target system over - ssh. - You can set this variable to "1" in your - local.conf file in the - Build Directory - to have the OpenEmbedded build system automatically run - these tests after an image successfully builds: - - TEST_IMAGE = "1" - - For more information on enabling, running, and writing - these tests, see the - "Performing Automated Runtime Testing" - section in the Yocto Project Development Tasks Manual and - the - "testimage*.bbclass" - section. - - - - TEST_LOG_DIR TEST_LOG_DIR[doc] = "Holds the SSH log and the boot log for QEMU machines. The TEST_LOG_DIR variable defaults to "${WORKDIR}/testimage"." @@ -15211,9 +15602,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Specifies the target controller to use when running tests against a test image. - The default controller to use is "qemu": + The default controller to use is "QemuTarget": - TEST_TARGET = "qemu" + TEST_TARGET = "QemuTarget" @@ -15232,35 +15623,24 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" You can provide the following arguments with TEST_TARGET: - "qemu" and "QemuTarget": + "QemuTarget": Boots a QEMU image and runs the tests. See the "Enabling Runtime Tests on QEMU" section in the Yocto Project Development Tasks Manual for more information. - "simpleremote" and "SimpleRemoteTarget": + "SimpleRemoteTarget": 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 TEST_TARGET_IP - when you use "simpleremote" or "SimpleRemoteTarget". + when you use "SimpleRemoteTarget". This argument is defined in - meta/lib/oeqa/targetcontrol.py. - The small caps names are kept for compatibility - reasons. - - - "GummibootTarget": - Automatically deploys and runs tests on an - EFI-enabled machine that has a master image - installed. - - This argument is defined in - meta/lib/oeqa/controllers/masterimage.py. + meta/lib/oeqa/controllers/simpleremote.py. @@ -15363,6 +15743,47 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" + TESTIMAGE_AUTO + + TESTIMAGE_AUTO[doc] = "Enables automatic testing of an image once it is built." + + + + + Automatically runs the series of automated tests for + images when an image is successfully built. + Setting TESTIMAGE_AUTO to "1" + causes any image that successfully builds to automatically + boot under QEMU. + Using the variable also adds in dependencies so that any + SDK for which testing is requested is automatically built + first. + + + + These tests are written in Python making use of the + unittest module, and the majority of + them run commands on the target system over + ssh. + You can set this variable to "1" in your + local.conf file in the + Build Directory + to have the OpenEmbedded build system automatically run + these tests after an image successfully builds: + + TESTIMAGE_AUTO = "1" + + For more information on enabling, running, and writing + these tests, see the + "Performing Automated Runtime Testing" + section in the Yocto Project Development Tasks Manual and + the + "testimage*.bbclass" + section. + + + + THISDIR THISDIR[doc] = "The directory in which the file BitBake is currently parsing is located." diff --git a/poky/documentation/sdk-manual/sdk-appendix-customizing.xml b/poky/documentation/sdk-manual/sdk-appendix-customizing.xml index c3215e6221..7454c90bee 100644 --- a/poky/documentation/sdk-manual/sdk-appendix-customizing.xml +++ b/poky/documentation/sdk-manual/sdk-appendix-customizing.xml @@ -7,7 +7,7 @@ Customizing the Extensible SDK - This appendix presents customizations you can apply to the extensible SDK. + This appendix describes customizations you can apply to the extensible SDK.
@@ -186,7 +186,13 @@ You can change the displayed title for the SDK installer by setting the SDK_TITLE - variable. + variable and then rebuilding the the SDK installer. + For information on how to build an SDK installer, see the + "Building an SDK Installer" + section. + + + By default, this title is derived from DISTRO_NAME when it is set. @@ -198,11 +204,28 @@ The - populate_sdk_ext + populate_sdk_base class defines the default value of the SDK_TITLE variable as follows: - SDK_TITLE_task-populate-sdk-ext = "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} Extensible SDK" + SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" + + + + + While several ways exist to change this variable, an efficient method + is to set the variable in your distribution's configuration file. + Doing so creates an SDK installer title that applies across your + distribution. + As an example, assume you have your own layer for your distribution + named "meta-mydistro" and you are using the same type of file + hierarchy as does the default "poky" distribution. + If so, you could update the SDK_TITLE variable + in the + ~/meta-mydistro/conf/distro/mydistro.conf file + using the following form: + + SDK_TITLE = "your_title"
@@ -265,6 +288,51 @@
+
+ Changing the Default SDK Installation Directory + + + When you build the installer for the Extensible SDK, the default + installation directory for the SDK is based on the + DISTRO + and + SDKEXTPATH + variables from within the + populate_sdk_base + class as follows: + + SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" + + You can change this default installation directory by specifically + setting the SDKEXTPATH variable. + + + + While a number of ways exist through which you can set this variable, + the method that makes the most sense is to set the variable in your + distribution's configuration file. + Doing so creates an SDK installer default directory that applies + across your distribution. + As an example, assume you have your own layer for your distribution + named "meta-mydistro" and you are using the same type of file + hierarchy as does the default "poky" distribution. + If so, you could update the SDKEXTPATH variable + in the + ~/meta-mydistro/conf/distro/mydistro.conf file + using the following form: + + SDKEXTPATH = "some_path_for_your_installed_sdk" + + + + + After building your installer, running it prompts the user for + acceptance of the + some_path_for_your_installed_sdk directory + as the default location to install the Extensible SDK. + +
+
Providing Additional Installable Extensible SDK Content diff --git a/poky/documentation/sdk-manual/sdk-appendix-obtain.xml b/poky/documentation/sdk-manual/sdk-appendix-obtain.xml index c608e6f546..2cadcc1e90 100644 --- a/poky/documentation/sdk-manual/sdk-appendix-obtain.xml +++ b/poky/documentation/sdk-manual/sdk-appendix-obtain.xml @@ -106,7 +106,7 @@ Set Up the Build Environment: Be sure you are set up to use BitBake in a shell. See the - "Preparing the Build Host" + "Preparing the Build Host" section in the Yocto Project Development Tasks Manual for information on how to get a build host ready that is either a native Linux machine or a machine that uses CROPS. diff --git a/poky/documentation/sdk-manual/sdk-eclipse-project.xml b/poky/documentation/sdk-manual/sdk-eclipse-project.xml index f8a586f54e..15a9ae7535 100644 --- a/poky/documentation/sdk-manual/sdk-eclipse-project.xml +++ b/poky/documentation/sdk-manual/sdk-eclipse-project.xml @@ -57,12 +57,12 @@ build host can use the Yocto Project. See the - "Preparing a Build Host" + "Preparing the Build Host" section in the Yocto Project Development Tasks Manual for information on how to set up your build host. Be sure you install the "xterm" package, which is a - graphical and Eclipse plug-in extra + graphical and Eclipse plug-in extra needed by Eclipse. diff --git a/poky/documentation/sdk-manual/sdk-manual.xml b/poky/documentation/sdk-manual/sdk-manual.xml index 2dabdb76c8..7f93d5f611 100644 --- a/poky/documentation/sdk-manual/sdk-manual.xml +++ b/poky/documentation/sdk-manual/sdk-manual.xml @@ -57,14 +57,14 @@ Released with the Yocto Project 2.5 Release. - 2.5.1 - September 2018 - The initial document released with the Yocto Project 2.5.1 Release. + 2.6 + November 2018 + Released with the Yocto Project 2.6 Release. - 2.5.2 + 2.6.1 &REL_MONTH_YEAR; - The initial document released with the Yocto Project 2.5.2 Release. + Released with the Yocto Project 2.6.1 Release. diff --git a/poky/documentation/toaster-manual/toaster-manual-start.xml b/poky/documentation/toaster-manual/toaster-manual-start.xml index 45f6046175..fc187ecd5e 100644 --- a/poky/documentation/toaster-manual/toaster-manual-start.xml +++ b/poky/documentation/toaster-manual/toaster-manual-start.xml @@ -18,7 +18,7 @@ Before you can use Toaster, you need to first set up your build system to run the Yocto Project. To do this, follow the instructions in the - "Preparing the Build Host" + "Preparing the Build Host" section of the Yocto Project Development Tasks Manual. For Ubuntu/Debian, you might also need to do an additional install diff --git a/poky/documentation/toaster-manual/toaster-manual.xml b/poky/documentation/toaster-manual/toaster-manual.xml index 8e25e43542..dcc2990dcd 100644 --- a/poky/documentation/toaster-manual/toaster-manual.xml +++ b/poky/documentation/toaster-manual/toaster-manual.xml @@ -67,14 +67,14 @@ Released with the Yocto Project 2.5 Release. - 2.5.1 - September 2018 - The initial document released with the Yocto Project 2.5.1 Release. + 2.6 + November 2018 + Released with the Yocto Project 2.6 Release. - 2.5.2 + 2.6.1 &REL_MONTH_YEAR; - The initial document released with the Yocto Project 2.5.2 Release. + Released with the Yocto Project 2.6.1 Release. diff --git a/poky/documentation/tools/mega-manual.sed b/poky/documentation/tools/mega-manual.sed index b174fad8f0..f6e205feb3 100644 --- a/poky/documentation/tools/mega-manual.sed +++ b/poky/documentation/tools/mega-manual.sed @@ -2,39 +2,39 @@ # 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.5.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/2.5.2/yocto-project-qs/yocto-project-qs.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/poky-ref-manual/poky-ref-manual.html#@"link" href="#@g +# s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/[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.1/yocto-project-qs/yocto-project-qs.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/poky-ref-manual/poky-ref-manual.html#@"link" href="#@g # Processes all other manuals (- style) except for the BitBake User Manual because # it is not included in the mega-manual. # 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.5.2/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g +# s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/sdk-manual/sdk-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/bsp-guide/bsp-guide.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/dev-manual/dev-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/overview-manual/overview-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/kernel-dev/kernel-dev.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/profile-manual/profile-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/ref-manual/ref-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/toaster-manual/toaster-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/sdk-manual/sdk-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/bsp-guide/bsp-guide.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/dev-manual/dev-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/overview-manual/overview-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/kernel-dev/kernel-dev.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/profile-manual/profile-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/ref-manual/ref-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.6.1/toaster-manual/toaster-manual.html#@"link" href="#@g # Process cases where just an external manual is referenced without an id anchor -s@Yocto Project Quick Build@Yocto Project Quick Build@g -s@Yocto Project Quick Start@Yocto Project Quick Start@g -s@Yocto Project Development Tasks Manual@Yocto Project Development Tasks Manual@g -s@Yocto Project Overview and Concepts Manual@Yocto project Overview and Concepts Manual@g -s@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g -s@Yocto Project Board Support Package (BSP) Developer's Guide@Yocto Project Board Support Package (BSP) Developer's Guide@g -s@Yocto Project Profiling and Tracing Manual@Yocto Project Profiling and Tracing Manual@g -s@Yocto Project Linux Kernel Development Manual@Yocto Project Linux Kernel Development Manual@g -s@Yocto Project Reference Manual@Yocto Project Reference Manual@g -s@Toaster User Manual@Toaster User Manual@g +s@Yocto Project Quick Build@Yocto Project Quick Build@g +s@Yocto Project Quick Start@Yocto Project Quick Start@g +s@Yocto Project Development Tasks Manual@Yocto Project Development Tasks Manual@g +s@Yocto Project Overview and Concepts Manual@Yocto project Overview and Concepts Manual@g +s@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g +s@Yocto Project Board Support Package (BSP) Developer's Guide@Yocto Project Board Support Package (BSP) Developer's Guide@g +s@Yocto Project Profiling and Tracing Manual@Yocto Project Profiling and Tracing Manual@g +s@Yocto Project Linux Kernel Development Manual@Yocto Project Linux Kernel Development Manual@g +s@Yocto Project Reference Manual@Yocto Project Reference Manual@g +s@Toaster User Manual@Toaster User Manual@g # Process a single, rouge occurrence of a linked reference to the Mega-Manual. -s@Yocto Project Mega-Manual@Yocto Project Mega-Manual@g +s@Yocto Project Mega-Manual@Yocto Project Mega-Manual@g -- cgit v1.2.3