From 424567d629b08785a6594d16427ee0fa8c31f384 Mon Sep 17 00:00:00 2001 From: Nicolas Dechesne Date: Mon, 27 Jul 2020 17:38:09 +0200 Subject: sphinx: manual updates for some links Some links were not found by the regexp, especially because of they are spanning across multiple lines. This patch is a manual fixup for these patterns. (From yocto-docs rev: 7a5cf8b372903d959d4a1f0882e6198f31f3cba5) Signed-off-by: Nicolas Dechesne Signed-off-by: Richard Purdie --- documentation/adt-manual/adt-command.rst | 4 +- documentation/adt-manual/adt-intro.rst | 14 +- documentation/adt-manual/adt-package.rst | 2 +- documentation/adt-manual/adt-prepare.rst | 29 ++-- .../brief-yoctoprojectqs/brief-yoctoprojectqs.rst | 12 +- documentation/bsp-guide/bsp.rst | 30 ++-- .../dev-manual/dev-manual-common-tasks.rst | 173 ++++++++++----------- documentation/dev-manual/dev-manual-qemu.rst | 8 +- documentation/dev-manual/dev-manual-start.rst | 7 +- documentation/kernel-dev/kernel-dev-common.rst | 31 ++-- .../kernel-dev/kernel-dev-concepts-appx.rst | 4 +- documentation/kernel-dev/kernel-dev-maint-appx.rst | 4 +- .../overview-manual/overview-manual-concepts.rst | 66 ++++---- .../overview-manual-development-environment.rst | 16 +- .../overview-manual/overview-manual-yp-intro.rst | 27 ++-- documentation/ref-manual/faq.rst | 11 +- documentation/ref-manual/migration.rst | 12 +- documentation/ref-manual/ref-classes.rst | 20 +-- documentation/ref-manual/ref-images.rst | 4 +- documentation/ref-manual/ref-release-process.rst | 2 +- documentation/ref-manual/ref-structure.rst | 15 +- .../ref-manual/ref-system-requirements.rst | 4 +- documentation/ref-manual/ref-tasks.rst | 2 +- documentation/ref-manual/ref-terms.rst | 4 +- documentation/ref-manual/ref-variables.rst | 117 +++++++------- .../sdk-manual/sdk-appendix-customizing.rst | 8 +- documentation/sdk-manual/sdk-appendix-obtain.rst | 8 +- documentation/sdk-manual/sdk-extensible.rst | 4 +- documentation/sdk-manual/sdk-intro.rst | 10 +- documentation/sdk-manual/sdk-working-projects.rst | 3 +- .../toaster-manual/toaster-manual-intro.rst | 4 +- .../toaster-manual/toaster-manual-reference.rst | 8 +- .../toaster-manual-setup-and-use.rst | 8 +- .../toaster-manual/toaster-manual-start.rst | 4 +- 34 files changed, 327 insertions(+), 348 deletions(-) diff --git a/documentation/adt-manual/adt-command.rst b/documentation/adt-manual/adt-command.rst index 8b86544f19..de854772bb 100644 --- a/documentation/adt-manual/adt-command.rst +++ b/documentation/adt-manual/adt-command.rst @@ -6,8 +6,8 @@ Using the Command Line Recall that earlier the manual discussed how to use an existing toolchain tarball that had been installed into the default installation -directory, ``/opt/poky/DISTRO``, which is outside of the `Build -Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ (see the section +directory, ``/opt/poky/DISTRO``, which is outside of the :term:`Build Directory` +(see the section "`Using a Cross-Toolchain Tarball) <#using-an-existing-toolchain-tarball>`__". And, that sourcing your architecture-specific environment setup script initializes a diff --git a/documentation/adt-manual/adt-intro.rst b/documentation/adt-manual/adt-intro.rst index 40612bdddf..d6228ad864 100644 --- a/documentation/adt-manual/adt-intro.rst +++ b/documentation/adt-manual/adt-intro.rst @@ -12,8 +12,8 @@ application. Fundamentally, the ADT consists of the following: - An architecture-specific cross-toolchain and matching sysroot both - built by the `OpenEmbedded build - system <&YOCTO_DOCS_DEV_URL;#build-system-term>`__. The toolchain and + built by the :term:`OpenEmbedded Build System`. + The toolchain and sysroot are based on a `Metadata <&YOCTO_DOCS_DEV_URL;#metadata>`__ configuration and extensions, which allows you to cross-develop on the host machine for the target hardware. @@ -33,8 +33,8 @@ Toolchain <&YOCTO_DOCS_DEV_URL;#cross-development-toolchain>`__ consists of a cross-compiler, cross-linker, and cross-debugger that are used to develop user-space applications for targeted hardware. This toolchain is created either by running the ADT Installer script, a toolchain -installer script, or through a `Build -Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ that is based on +installer script, or through a :term:`Build Directory` +that is based on your Metadata configuration or extension for your targeted device. The cross-toolchain works with a matching target sysroot. @@ -79,13 +79,13 @@ your application or image. QEMU is made available a number of ways: - If you use the ADT Installer script to install ADT, you can specify whether or not to install QEMU. -- If you have cloned the ``poky`` Git repository to create a `Source - Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__ and you have +- If you have cloned the ``poky`` Git repository to create a + :term:`Source Directory` and you have sourced the environment setup script, QEMU is installed and automatically available. - If you have downloaded a Yocto Project release and unpacked it to - create a `Source Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__ + create a :term:`Source Directory` and you have sourced the environment setup script, QEMU is installed and automatically available. diff --git a/documentation/adt-manual/adt-package.rst b/documentation/adt-manual/adt-package.rst index 38823a104f..dfa62163b3 100644 --- a/documentation/adt-manual/adt-package.rst +++ b/documentation/adt-manual/adt-package.rst @@ -59,7 +59,7 @@ add it into a working ``opkg`` repository. Use these commands: $ bitbake libglade $ bitbake package-index Next, source the cross-toolchain environment setup script found in the -`Source Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__. Follow +:term:`Source Directory`. Follow that by setting up the installation destination to point to your sysroot as sysroot_dir. Finally, have an OPKG configuration file conf_file that corresponds to the ``opkg`` repository you have just created. The diff --git a/documentation/adt-manual/adt-prepare.rst b/documentation/adt-manual/adt-prepare.rst index 12b1e7918c..27133d21b4 100644 --- a/documentation/adt-manual/adt-prepare.rst +++ b/documentation/adt-manual/adt-prepare.rst @@ -50,7 +50,7 @@ for more information. other mentioned benefits had you run the ADT Installer script. - *Use the toolchain from within the Build Directory:* If you already - have a `Build Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__, + have a :term:`Build Directory`, you can build the cross-toolchain within the directory. However, like the previous method mentioned, you only get the cross-toolchain and QEMU - you do not get any of the other benefits without taking @@ -79,9 +79,8 @@ the tarball using either of these methods: ` <&YOCTO_ADTINSTALLER_DL_URL;>`__ into any directory. - *Build the Tarball:* You can use - `BitBake <&YOCTO_DOCS_DEV_URL;#bitbake-term>`__ to generate the - tarball inside an existing `Build - Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__. + :term:`BitBake` to generate the + tarball inside an existing :term:`Build Directory`. If you use BitBake to generate the ADT Installer tarball, you must ``source`` the environment setup script @@ -90,8 +89,8 @@ the tarball using either of these methods: located in the Source Directory before running the ``bitbake`` command that creates the tarball. - The following example commands establish the `Source - Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__, check out the + The following example commands establish the + :term:`Source Directory`, check out the current release branch, set up the build environment while also creating the default Build Directory, and run the ``bitbake`` command that results in the tarball @@ -268,8 +267,8 @@ Using BitBake and the Build Directory ------------------------------------- A final way of making the cross-toolchain available is to use BitBake to -generate the toolchain within an existing `Build -Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__. This method does +generate the toolchain within an existing :term:`Build Directory`. +This method does not install the toolchain into the default ``/opt`` directory. As with the previous method, if you need to install the target sysroot, you must do that separately as well. @@ -280,8 +279,7 @@ Follow these steps to generate the toolchain into the Build Directory: environment setup script (i.e. ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ or ```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__) - located in the `Source - Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__. + located in the :term:`Source Directory`. 2. *Check your Local Configuration File:* At this point, you should be sure that the :term:`MACHINE` @@ -332,8 +330,8 @@ cross-development environment by sourcing the toolchain's environment setup script. If you used the ADT Installer or hand-installed cross-toolchain, then you can find this script in the directory you chose for installation. For this release, the default installation -directory is ````. If you installed the toolchain in the `Build -Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__, you can find the +directory is ````. If you installed the toolchain in the +:term:`Build Directory`, you can find the environment setup script for the toolchain in the Build Directory's ``tmp`` directory. @@ -432,8 +430,8 @@ this by including the ``eclipse-debug`` image feature. image features. To include the ``eclipse-debug`` image feature, modify your -``local.conf`` file in the `Build -Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ so that the +``local.conf`` file in the :term:`Build Directory` +so that the :term:`EXTRA_IMAGE_FEATURES` variable includes the "eclipse-debug" feature. After modifying the configuration file, you can rebuild the image. Once the image is @@ -484,8 +482,7 @@ Optionally Building a Toolchain Installer ========================================= As an alternative to locating and downloading a toolchain installer, you -can build the toolchain installer if you have a `Build -Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__. +can build the toolchain installer if you have a :term:`Build Directory`. .. note:: diff --git a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst b/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst index 712d5c7f8e..563c3f2d9a 100644 --- a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst +++ b/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst @@ -162,10 +162,10 @@ an entire Linux distribution, including the toolchain, from source. ' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86-64' Among other things, - the script creates the `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is - ``build`` in this case and is located in the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. After the + the script creates the + :term:`Build Directory`, which is + ``build`` in this case and is located in the :term:`Source Directory`. + After the script runs, your current working directory is set to the Build Directory. Later, when the build completes, the Build Directory contains all the files created during the build. @@ -271,8 +271,8 @@ Follow these steps to add a hardware layer: 4. *Add Your Layer to the Layer Configuration File:* Before you can use a layer during a build, you must add it to your ``bblayers.conf`` - file, which is found in the `Build - Directory's <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``conf`` + file, which is found in the + :term:`Build Directory` ``conf`` directory. Use the ``bitbake-layers add-layer`` command to add the layer to the diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst index e06b1259f0..361951b592 100644 --- a/documentation/bsp-guide/bsp.rst +++ b/documentation/bsp-guide/bsp.rst @@ -74,12 +74,12 @@ section in the Yocto Project Development Tasks Manual. The BSP layer's base directory (``meta-bsp_root_name``) is the root directory of that Layer. This directory is what you add to the :term:`BBLAYERS` variable in the -``conf/bblayers.conf`` file found in your `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is +``conf/bblayers.conf`` file found in your +:term:`Build Directory`, which is established after you run the OpenEmbedded build environment setup script (i.e. ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__). -Adding the root directory allows the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ to recognize the BSP +Adding the root directory allows the :term:`OpenEmbedded Build System` +to recognize the BSP layer and from it build an image. Here is an example: BBLAYERS ?= " \\ /usr/local/src/yocto/meta \\ /usr/local/src/yocto/meta-poky \\ /usr/local/src/yocto/meta-yocto-bsp \\ /usr/local/src/yocto/meta-mylayer @@ -144,8 +144,7 @@ section. machine that uses CROPS. 2. *Clone the ``poky`` Repository:* You need to have a local copy of the - Yocto Project `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (i.e. a local + Yocto Project :term:`Source Directory` (i.e. a local ``poky`` repository). See the "`Cloning the ``poky`` Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" and possibly the "`Checking Out by Branch in @@ -169,8 +168,7 @@ section. file. 1. *Navigate to Your Source Directory:* Typically, you set up the - ``meta-intel`` Git repository inside the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. + ``meta-intel`` Git repository inside the :term:`Source Directory` (e.g. ``poky``). $ cd /home/you/poky 2. *Clone the Layer:* $ git clone @@ -218,10 +216,10 @@ section. ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ environment setup script to define the OpenEmbedded build environment on your build host. $ source OE_INIT_FILE Among other things, the script - creates the `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is - ``build`` in this case and is located in the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. After the + creates the + :term:`Build Directory`, which is + ``build`` in this case and is located in the :term:`Source Directory`. + After the script runs, your current working directory is set to the ``build`` directory. @@ -629,8 +627,8 @@ types of files although, in practice, it is likely that you would have one or the other. For your BSP, you typically want to use an existing Yocto Project kernel -recipe found in the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ at +recipe found in the :term:`Source Directory` +at ``meta/recipes-kernel/linux``. You can append machine-specific changes to the kernel recipe by using a similarly named append file, which is located in the BSP Layer for your target device (e.g. the @@ -848,8 +846,8 @@ Yocto Project: - *File System Layout:* When possible, use the same directory names in your BSP layer as listed in the ``recipes.txt`` file, which is found - in ``poky/meta`` directory of the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ or in the + in ``poky/meta`` directory of the :term:`Source Directory` + or in the OpenEmbedded-Core Layer (``openembedded-core``) at ` `__. diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst index e1fe881437..c019057bf8 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.rst +++ b/documentation/dev-manual/dev-manual-common-tasks.rst @@ -48,8 +48,8 @@ Follow these general steps to create your layer without using tools: 2. *Create a Directory:* Create the directory for your layer. When you create the layer, be sure to create the directory in an area not - associated with the Yocto Project `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. the cloned + associated with the Yocto Project :term:`Source Directory` + (e.g. the cloned ``poky`` repository). While not strictly required, prepend the name of the directory with @@ -263,8 +263,7 @@ following list: repository that use the ``meta-layer_name`` format. - *Group Your Layers Locally:* Clone your repository alongside other - cloned ``meta`` directories from the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. + cloned ``meta`` directories from the :term:`Source Directory`. Making Sure Your Layer is Compatible With Yocto Project ------------------------------------------------------- @@ -449,8 +448,8 @@ does not have a corresponding recipe with a matching name. See the variable for information on how to handle this error. As an example, consider the main formfactor recipe and a corresponding -formfactor append file both from the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Here is the main +formfactor append file both from the :term:`Source Directory`. +Here is the main formfactor recipe, which is named ``formfactor_0.0.bb`` and located in the "meta" layer at ``meta/recipes-bsp/formfactor``: SUMMARY = "Device formfactor information" SECTION = "base" LICENSE = "MIT" @@ -769,8 +768,8 @@ high-level image features by using the variables. Although the functions for both variables are nearly equivalent, best practices dictate using ``IMAGE_FEATURES`` from within a recipe and using ``EXTRA_IMAGE_FEATURES`` from within your -``local.conf`` file, which is found in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. +``local.conf`` file, which is found in the +:term:`Build Directory`. To understand how these features work, the best reference is ``meta/classes/core-image.bbclass``. This class lists out the available @@ -996,8 +995,8 @@ application that builds using Autotools. Creating the base recipe using ``recipetool`` results in a recipe that has the pre-build dependencies, license requirements, and checksums configured. -To run the tool, you just need to be in your `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ and have sourced the +To run the tool, you just need to be in your +:term:`Build Directory` and have sourced the build environment setup script (i.e. ```oe-init-build-env`` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__). To get help on the tool, use the following command: $ recipetool -h @@ -1799,8 +1798,8 @@ different ways: To enable a service using systemd, your recipe needs to inherit the :ref:`systemd ` class. See - the ``systemd.bbclass`` file located in your `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. section for + the ``systemd.bbclass`` file located in your :term:`Source Directory` + section for more information. .. _new-recipe-packaging: @@ -2251,7 +2250,7 @@ could lead to compatibility problems with ABI in the future. However, sometimes you have no choice. The easiest solution is to create a recipe that uses the -```bin_package`` <&YOCTO_DOCS_REF_URL;#ref-classes-bin-package>`__ class +:ref:`bin_package ` class and to be sure that you are using default locations for build artifacts. In most cases, the ``bin_package`` class handles "skipping" the configure and compile steps as well as sets things up to grab packages @@ -2739,7 +2738,7 @@ The following steps describe how to set up the AUH utility: your build directory. - If you want to enable testing through the - ```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ + :ref:`testimage ` class, which is optional, you need to have the following set in your ``conf/local.conf`` file: INHERIT += "testimage" @@ -2856,8 +2855,8 @@ could add it easily using the script. For example, suppose you use the ``nano.bb`` recipe from the ``meta-oe`` layer in the ``meta-openembedded`` repository. For this example, assume that the layer has been cloned into following area: -/home/scottrif/meta-openembedded The following command from your `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ adds the layer to +/home/scottrif/meta-openembedded The following command from your +:term:`Build Directory` adds the layer to your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``): $ bitbake-layers add-layer /home/scottrif/meta-openembedded/meta-oe NOTE: Starting bitbake server... Parsing recipes: 100% @@ -3014,8 +3013,8 @@ You might find it helpful during development to modify the temporary source code used by recipes to build packages. For example, suppose you are developing a patch and you need to experiment a bit to figure out your solution. After you have initially built the package, you can -iteratively tweak the source code, which is located in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, and then you can +iteratively tweak the source code, which is located in the +:term:`Build Directory`, and then you can force a re-compile and quickly test your altered code. Once you settle on a solution, you can then preserve your changes in the form of patches. @@ -3024,8 +3023,8 @@ During a build, the unpacked temporary source code used by recipes to build packages is available in the Build Directory as defined by the :term:`S` variable. Below is the default value for the ``S`` variable as defined in the -``meta/conf/bitbake.conf`` configuration file in the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__: S = +``meta/conf/bitbake.conf`` configuration file in the +:term:`Source Directory`: S = "${WORKDIR}/${BP}" You should be aware that many recipes override the ``S`` variable. For example, recipes that fetch their source from Git usually set ``S`` to ``${WORKDIR}/git``. @@ -3096,8 +3095,8 @@ form of a patch all using Quilt. Follow these general steps: 1. *Find the Source Code:* Temporary source code used by the - OpenEmbedded build system is kept in the `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. See the + OpenEmbedded build system is kept in the + :term:`Build Directory`. See the "`Finding Temporary Source Code <#finding-the-temporary-source-code>`__" section to learn how to locate the directory that has the temporary source code for a @@ -3314,8 +3313,8 @@ build host running Linux. Build <&YOCTO_DOCS_BRIEF_URL;>`__ document. The build process creates an entire Linux distribution from source and -places it in your `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ under +places it in your +:term:`Build Directory` under ``tmp/deploy/images``. For detailed information on the build process using BitBake, see the "`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" section in the @@ -3372,8 +3371,8 @@ The following figure and list overviews the build process: The target is the name of the recipe you want to build. Common targets are the images in ``meta/recipes-core/images``, - ``meta/recipes-sato/images``, and so forth all found in the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Or, the target + ``meta/recipes-sato/images``, and so forth all found in the + :term:`Source Directory`. Or, the target can be the name of a recipe for a specific piece of software such as BusyBox. For more details about the images the OpenEmbedded build system supports, see the @@ -3557,8 +3556,8 @@ Follow these steps to create an initramfs image: 1. *Create the initramfs Image Recipe:* You can reference the ``core-image-minimal-initramfs.bb`` recipe found in the - ``meta/recipes-core`` directory of the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ as an example + ``meta/recipes-core`` directory of the :term:`Source Directory` + as an example from which to work. 2. *Decide if You Need to Bundle the initramfs Image Into the Kernel @@ -3715,8 +3714,8 @@ memory used for decompressing the kernel and for the ``__init__`` functions. To help you see where you currently are with kernel and root filesystem -sizes, you can use two tools found in the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ in the +sizes, you can use two tools found in the :term:`Source Directory` +in the ``scripts/tiny/`` directory: - ``ksize.py``: Reports component sizes for the kernel build objects. @@ -4049,8 +4048,8 @@ your tunings to best consider build times and package feed maintenance. Building Software from an External Source ----------------------------------------- -By default, the OpenEmbedded build system uses the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ when building source +By default, the OpenEmbedded build system uses the +:term:`Build Directory` when building source code. The build process involves fetching the source files, unpacking them, and then patching them if necessary before the build takes place. @@ -4158,8 +4157,7 @@ directory: 2. *Start With a Clean Build:* You can start with a clean build by removing the ``${``\ :term:`TMPDIR`\ ``}`` - directory or using a new `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. + directory or using a new :term:`Build Directory`. 3. *Build Your Target:* Use BitBake to build your target: $ bitbake target The build completes using the known local "snapshot" of source @@ -4258,7 +4256,7 @@ Following are additional factors that can affect build speed: contents could easily be rebuilt. - Inheriting the - ```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ class: + :ref:`rm_work ` class: Inheriting this class has shown to speed up builds due to significantly lower amounts of data stored in the data cache as well as on disk. Inheriting this class also makes cleanup of @@ -4409,8 +4407,8 @@ meet your needs. In order to enable Multilib, you first need to ensure your recipe is extended to support multiple libraries. Many standard recipes are already extended and support multiple libraries. You can check in the -``meta/conf/multilib.conf`` configuration file in the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ to see how this is +``meta/conf/multilib.conf`` configuration file in the +:term:`Source Directory` to see how this is done using the :term:`BBCLASSEXTEND` variable. Eventually, all recipes will be covered and this list will not be @@ -4436,8 +4434,8 @@ Using Multilib After you have set up the recipes, you need to define the actual combination of multiple libraries you want to build. You accomplish this -through your ``local.conf`` configuration file in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. An example +through your ``local.conf`` configuration file in the +:term:`Build Directory`. An example configuration would be as follows: MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" IMAGE_INSTALL_append = " @@ -4936,8 +4934,8 @@ Raw Mode Running Wic in raw mode allows you to specify all the partitions through the ``wic`` command line. The primary use for raw mode is if you have -built your kernel outside of the Yocto Project `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. In other words, you +built your kernel outside of the Yocto Project +:term:`Build Directory`. In other words, you can point to arbitrary kernel, root filesystem locations, and so forth. Contrast this behavior with cooked mode where Wic looks in the Build Directory (e.g. ``tmp/deploy/images/``\ machine). @@ -5210,8 +5208,8 @@ This next example demonstrates that through modification of the As mentioned earlier, you can use the command ``wic list images`` to show the list of existing kickstart files. The directory in which the ``directdisk-gpt.wks`` file resides is -``scripts/lib/image/canned-wks/``, which is located in the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``). +``scripts/lib/image/canned-wks/``, which is located in the +:term:`Source Directory` (e.g. ``poky``). Because available files reside in this directory, you can create and add your own custom files to the directory. Subsequent use of the ``wic list images`` command would then include your kickstart files. @@ -5520,8 +5518,8 @@ Security Flags The Yocto Project has security flags that you can enable that help make your build output more secure. The security flags are in the -``meta/conf/distro/include/security_flags.inc`` file in your `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``). +``meta/conf/distro/include/security_flags.inc`` file in your +:term:`Source Directory` (e.g. ``poky``). .. note:: @@ -5561,7 +5559,7 @@ system to make your images more secure: :ref:`extrausers ` class, which is the preferred method. For an example on how to set up both root and user passwords, see the - "```extrausers.bbclass`` <&YOCTO_DOCS_REF_URL;#ref-classes-extrausers>`__" + ":ref:`extrausers.bbclass `" section. .. note:: @@ -5663,8 +5661,8 @@ layer. The following steps provide some more detail: limited to the list in the previous bulleted item. - *Point to Your distribution configuration file:* In your - ``local.conf`` file in the `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, set your + ``local.conf`` file in the :term:`Build Directory`, + set your :term:`DISTRO` variable to point to your distribution's configuration file. For example, if your distribution's configuration file is named ``mydistro.conf``, then @@ -5704,8 +5702,8 @@ new build directory. The OpenEmbedded build system uses the environment variable ``TEMPLATECONF`` to locate the directory from which it gathers -configuration information that ultimately ends up in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``conf`` directory. +configuration information that ultimately ends up in the +:term:`Build Directory` ``conf`` directory. By default, ``TEMPLATECONF`` is set as follows in the ``poky`` repository: TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf} This is the directory used by the build system to find templates from which to build @@ -5762,7 +5760,7 @@ the :term:`Build Directory`: INHERIT += "rm_work" Adding this statement deletes the work directory used for building a recipe once the recipe is built. For more information on "rm_work", see the -```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ class in the +:ref:`rm_work ` class in the Yocto Project Reference Manual. Working with Packages @@ -5947,8 +5945,7 @@ The simplest form for a PR Service is for it to exist for a single host development system that builds the package feed (building system). For this scenario, you can enable a local PR Service by setting :term:`PRSERV_HOST` in your -``local.conf`` file in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: PRSERV_HOST = +``local.conf`` file in the :term:`Build Directory`: PRSERV_HOST = "localhost:0" Once the service is started, packages will automatically get increasing ``PR`` values and BitBake takes care of starting and stopping the server. @@ -6253,8 +6250,8 @@ to use. In your configuration, you use the :term:`PACKAGE_CLASSES` variable to specify the format: -1. Open the ``local.conf`` file inside your `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (e.g. +1. Open the ``local.conf`` file inside your + :term:`Build Directory` (e.g. ``~/poky/build/conf/local.conf``). 2. Select the desired package format as follows: PACKAGE_CLASSES ?= @@ -6582,8 +6579,8 @@ Adding ptest to Your Build To add package testing to your build, add the :term:`DISTRO_FEATURES` and :term:`EXTRA_IMAGE_FEATURES` -variables to your ``local.conf`` file, which is found in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: +variables to your ``local.conf`` file, which is found in the +:term:`Build Directory`: DISTRO_FEATURES_append = " ptest" EXTRA_IMAGE_FEATURES += "ptest-pkgs" Once your build is complete, the ptest files are installed into the ``/usr/lib/package/ptest`` directory within the image, where ``package`` @@ -7407,8 +7404,8 @@ dependency graphs, so you can see why something was pulled into the image. If you are just interested in this information and not interested in collecting specific package or SDK information, you can enable writing only image information without any history by adding the -following to your ``conf/local.conf`` file found in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT += +following to your ``conf/local.conf`` file found in the +:term:`Build Directory`: INHERIT += "buildhistory" BUILDHISTORY_COMMIT = "0" BUILDHISTORY_FEATURES = "image" Here, you set the :term:`BUILDHISTORY_FEATURES` @@ -7856,19 +7853,19 @@ You can start the tests automatically or manually: the OpenEmbedded build system successfully creates an image, first set the :term:`TESTIMAGE_AUTO` - variable to "1" in your ``local.conf`` file in the `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: TESTIMAGE_AUTO = + variable to "1" in your ``local.conf`` file in the + :term:`Build Directory`: TESTIMAGE_AUTO = "1" Next, build your image. If the image successfully builds, the tests run: bitbake core-image-sato - *Manually running tests:* To manually run the tests, first globally inherit the - ```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ class + :ref:`testimage ` class by editing your ``local.conf`` file: INHERIT += "testimage" Next, use BitBake to run the tests: bitbake -c testimage image -All test files reside in ``meta/lib/oeqa/runtime`` in the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. A test name maps +All test files reside in ``meta/lib/oeqa/runtime`` in the +:term:`Source Directory`. A test name maps directly to a Python module. Each test module may contain a number of individual tests. Tests are usually grouped together by the area tested (e.g tests for systemd reside in ``meta/lib/oeqa/runtime/systemd.py``). @@ -7934,8 +7931,8 @@ If your image is already built, make sure the following are set in your "IP-address-for-the-test-target" TEST_SERVER_IP = "IP-address-for-the-test-server" You can then export the tests with the following BitBake command form: $ bitbake image -c testexport Exporting -the tests places them in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in +the tests places them in the +:term:`Build Directory` in ``tmp/testexport/``\ image, which is controlled by the ``TEST_EXPORT_DIR`` variable. @@ -8158,8 +8155,8 @@ section: - "`Viewing Task Variable Dependencies <#dev-viewing-task-variable-dependencies>`__" describes how to use the ``bitbake-dumpsig`` command in conjunction with key - subdirectories in the `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ to determine + subdirectories in the + :term:`Build Directory` to determine variable dependencies. - "`Running Specific Tasks <#dev-debugging-taskrunning>`__" describes @@ -8313,7 +8310,7 @@ Following are a few of the available ``oe-pkgdata-util`` subcommands. If you want to inspect the ``${WORKDIR}/packages-split`` directory, make sure that - ```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ is not + :ref:`rm_work ` is not enabled when you build the recipe. - ``oe-pkgdata-util find-path ``\ path\ `` ...``: Lists the names of @@ -8704,8 +8701,7 @@ the names ``bbplain``, ``bbnote``, ``bbdebug``, ``bbwarn``, ``bberror``, and ``bbfatal``. The :ref:`logging ` class implements these functions. See that class in the ``meta/classes`` -folder of the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ for information. +folder of the :term:`Source Directory` for information. Logging With Python ~~~~~~~~~~~~~~~~~~~ @@ -8890,8 +8886,8 @@ to the file: tools/snep-send.$(OBJEXT): include/near/dbus.h Once you have edited the file, use the ``refresh`` command to create the patch: $ quilt refresh Refreshed patch patches/parallelmake.patch Once the patch file exists, you need to add it back to the originating recipe -folder. Here is an example assuming a top-level `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ named ``poky``: $ +folder. Here is an example assuming a top-level +:term:`Source Directory` named ``poky``: $ cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard The final thing you need to do to implement the fix in the build is to update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the @@ -9163,8 +9159,8 @@ Here are some other tips that you might find useful: virtual console (e.g. Fn+Left or Fn+Right on a Zaurus). - Removing :term:`TMPDIR` (usually - ``tmp/``, within the `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__) can often fix + ``tmp/``, within the + :term:`Build Directory`) can often fix temporary build issues. Removing ``TMPDIR`` is usually a relatively cheap operation, because task output will be cached in :term:`SSTATE_DIR` (usually @@ -9471,8 +9467,7 @@ repository: methods to find out: - *Maintenance File:* Examine the ``maintainers.inc`` file, which is - located in the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ at + located in the :term:`Source Directory` at ``meta/conf/distro/include``, to see who is responsible for code. - *Search by File:* Using `Git <&YOCTO_DOCS_OM_URL;#git>`__, you can @@ -9495,8 +9490,8 @@ repository: The Yocto Project provides two scripts that conveniently let you generate and send pull requests to the Yocto Project. These scripts are ``create-pull-request`` and ``send-pull-request``. You can find - these scripts in the ``scripts`` directory within the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. + these scripts in the ``scripts`` directory within the + :term:`Source Directory` (e.g. ``~/poky/scripts``). Using these scripts correctly formats the requests without @@ -9641,8 +9636,8 @@ As mentioned in the "`Licensing <&YOCTO_DOCS_OM_URL;#licensing>`__" section in the Yocto Project Overview and Concepts Manual, open source projects are open to the public and they consequently have different licensing structures in place. This section describes the mechanism by -which the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ tracks changes to +which the :term:`OpenEmbedded Build System` +tracks changes to licensing text and covers how to maintain open source license compliance during your project's lifecycle. The section also describes how to enable commercially licensed recipes, which by default are disabled. @@ -9947,8 +9942,8 @@ of compliance in mind. One way of doing this (but certainly not the only way) is to release just the source as a tarball. You can do this by adding the following to -the ``local.conf`` file found in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT += +the ``local.conf`` file found in the +:term:`Build Directory`: INHERIT += "archiver" ARCHIVER_MODE[src] = "original" During the creation of your image, the source from all recipes that deploy packages to the image is placed within subdirectories of ``DEPLOY_DIR/sources`` based on the @@ -10070,8 +10065,8 @@ The error reporting tool allows you to submit errors encountered during builds to a central database. Outside of the build environment, you can use a web interface to browse errors, view statistics, and query for errors. The tool works using a client-server system where the client -portion is integrated with the installed Yocto Project `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``). +portion is integrated with the installed Yocto Project +:term:`Source Directory` (e.g. ``poky``). The server receives the information collected and saves it in a database. @@ -10093,8 +10088,8 @@ By default, the error reporting tool is disabled. You can enable it by inheriting the :ref:`report-error ` class by adding the following statement to the end of your -``local.conf`` file in your `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. INHERIT += +``local.conf`` file in your +:term:`Build Directory`. INHERIT += "report-error" By default, the error reporting feature stores information in @@ -10155,8 +10150,8 @@ The Yocto Project provides the Wayland protocol libraries and the reference `Weston `__ compositor as part of its release. You can find the integrated packages -in the ``meta`` layer of the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Specifically, you +in the ``meta`` layer of the :term:`Source Directory`. +Specifically, you can find the recipes that build both Wayland and Weston at ``meta/recipes-graphics/wayland``. diff --git a/documentation/dev-manual/dev-manual-qemu.rst b/documentation/dev-manual/dev-manual-qemu.rst index 653f90573e..d695b90202 100644 --- a/documentation/dev-manual/dev-manual-qemu.rst +++ b/documentation/dev-manual/dev-manual-qemu.rst @@ -100,8 +100,8 @@ available. Follow these general steps to run QEMU: Here are some additional examples to help illustrate further QEMU: - This example starts QEMU with MACHINE set to "qemux86-64". - Assuming a standard `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, ``runqemu`` + Assuming a standard + :term:`Build Directory`, ``runqemu`` automatically finds the ``bzImage-qemux86-64.bin`` image file and the ``core-image-minimal-qemux86-64-20200218002850.rootfs.ext4`` (assuming the current build created a ``core-image-minimal`` @@ -232,8 +232,8 @@ be a problem when QEMU is running with KVM enabled. Specifically, software compiled with a certain CPU feature crashes when run on a CPU under KVM that does not support that feature. To work around this problem, you can override QEMU's runtime CPU setting by changing the -``QB_CPU_KVM`` variable in ``qemuboot.conf`` in the `Build -Directory's <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``deploy/image`` +``QB_CPU_KVM`` variable in ``qemuboot.conf`` in the +:term:`Build Directory` ``deploy/image`` directory. This setting specifies a ``-cpu`` option passed into QEMU in the ``runqemu`` script. Running ``qemu -cpu help`` returns a list of available supported CPU types. diff --git a/documentation/dev-manual/dev-manual-start.rst b/documentation/dev-manual/dev-manual-start.rst index fadc0bff3e..81fa7847e6 100644 --- a/documentation/dev-manual/dev-manual-start.rst +++ b/documentation/dev-manual/dev-manual-start.rst @@ -140,8 +140,7 @@ particular working environment and set of practices. Following are some best practices for setting up machines used for developing images: - - Have the `OpenEmbedded build - system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ available on + - Have the :term:`OpenEmbedded Build System` available on the developer workstations so developers can run their own builds and directly rebuild the software stack. @@ -740,8 +739,8 @@ Cloning and Checking Out Branches 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 <&YOCTO_DOCS_REF_URL;#source-directory>`__ in the Yocto +files is referred to as the :term:`Source Directory` + in the Yocto Project documentation. The preferred method of creating your Source Directory is by using diff --git a/documentation/kernel-dev/kernel-dev-common.rst b/documentation/kernel-dev/kernel-dev-common.rst index f264cea159..813f4047e2 100644 --- a/documentation/kernel-dev/kernel-dev-common.rst +++ b/documentation/kernel-dev/kernel-dev-common.rst @@ -24,8 +24,8 @@ host is set up to use the Yocto Project. For information on how to get set up, see the "`Preparing the Build Host <&YOCTO_DOCS_DEV_URL;#dev-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 `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (``poky``) on your +is creating a local Git repository of the +:term:`Source Directory` (``poky``) on your system. Follow the steps in the "`Cloning the ``poky`` Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" section in the Yocto Project Development Tasks Manual to set up your @@ -76,8 +76,8 @@ section: "qemux86-64", which is fine if you are building for the QEMU emulator in 64-bit mode. However, if you are not, you need to set the ``MACHINE`` variable appropriately in your ``conf/local.conf`` file - found in the `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (i.e. + found in the + :term:`Build Directory` (i.e. ``~/poky/build`` in this example). Also, since you are preparing to work on the kernel image, you need @@ -240,8 +240,8 @@ section: "qemux86-64", which is fine if you are building for the QEMU emulator in 64-bit mode. However, if you are not, you need to set the ``MACHINE`` variable appropriately in your ``conf/local.conf`` file - found in the `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (i.e. + found in the + :term:`Build Directory` (i.e. ``~/poky/build`` in this example). Also, since you are preparing to work on the kernel image, you need @@ -289,8 +289,8 @@ section: ` <&YOCTO_GIT_URL;>`__. For simplicity, it is recommended that you create your copy of the - kernel Git repository outside of the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__, which is + kernel Git repository outside of the + :term:`Source Directory`, which is usually named ``poky``. Also, be sure you are in the ``standard/base`` branch. @@ -317,8 +317,8 @@ section: 6. *Create a Local Copy of the Kernel Cache Git Repository:* For simplicity, it is recommended that you create your copy of the kernel - cache Git repository outside of the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__, which is + cache Git repository outside of the + :term:`Source Directory`, which is usually named ``poky``. Also, for this example, be sure you are in the ``yocto-4.12`` branch. @@ -483,8 +483,8 @@ ensure the build process uses the appropriate kernel branch. Although this particular example does not use it, the :term:`KERNEL_FEATURES` variable could be used to enable features specific to the kernel. The -append file points to specific commits in the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ Git repository and +append file points to specific commits in the +:term:`Source Directory` Git repository and the ``meta`` Git repository branches to identify the exact kernel needed to build the BSP. @@ -781,8 +781,8 @@ the "`Getting Ready to Develop Using 8. *Build the Image With Your Modified Kernel:* You can now build an image that includes your kernel patches. Execute the following - command from your `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in the terminal + command from your + :term:`Build Directory` in the terminal set up to run BitBake: $ cd ~/poky/build $ bitbake core-image-minimal Using Traditional Kernel Development to Patch the Kernel @@ -1134,8 +1134,7 @@ build system applies fragments on top of and after applying the existing defconfig file configurations. Syntactically, the configuration statement is identical to what would -appear in the ``.config`` file, which is in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. +appear in the ``.config`` file, which is in the :term:`Build Directory`. .. note:: diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.rst b/documentation/kernel-dev/kernel-dev-concepts-appx.rst index ed1486b65d..cf4c20aaeb 100644 --- a/documentation/kernel-dev/kernel-dev-concepts-appx.rst +++ b/documentation/kernel-dev/kernel-dev-concepts-appx.rst @@ -320,8 +320,8 @@ tree specific to your kernel from which to generate the new kernel image. The following figure shows the temporary file structure created on your -host system when you build the kernel using Bitbake. This `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ contains all the +host system when you build the kernel using Bitbake. This +:term:`Build Directory` contains all the source files used during the build. Again, for additional information on the Yocto Project kernel's diff --git a/documentation/kernel-dev/kernel-dev-maint-appx.rst b/documentation/kernel-dev/kernel-dev-maint-appx.rst index d76e789d56..c0c0bc260b 100644 --- a/documentation/kernel-dev/kernel-dev-maint-appx.rst +++ b/documentation/kernel-dev/kernel-dev-maint-appx.rst @@ -222,7 +222,7 @@ functionality. This behavior means that all the generated files for a particular machine or BSP are now in the build tree directory. The files include the final ``.config`` file, all the ``.o`` files, the ``.a`` files, and -so forth. Since each machine or BSP has its own separate `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in its own separate +so forth. Since each machine or BSP has its own separate +:term:`Build Directory` in its own separate branch of the Git repository, you can easily switch between different builds. diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst index 59096fbebf..9764b25b6d 100644 --- a/documentation/overview-manual/overview-manual-concepts.rst +++ b/documentation/overview-manual/overview-manual-concepts.rst @@ -6,8 +6,8 @@ Yocto Project Concepts This chapter provides explanations for Yocto Project concepts that go beyond the surface of "how-to" information and reference (or look-up) -material. Concepts such as components, the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ workflow, +material. Concepts such as components, the :term:`OpenEmbedded Build System` +workflow, cross-development toolchains, shared state cache, and so forth are explained. @@ -48,8 +48,8 @@ Concepts <#openembedded-build-system-build-concepts>`__" section. BitBake ------- -BitBake is the tool at the heart of the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ and is responsible +BitBake is the tool at the heart of the :term:`OpenEmbedded Build System` +and is responsible for parsing the :term:`Metadata`, generating a list of tasks from it, and then executing those tasks. @@ -109,7 +109,7 @@ Class files (``.bbclass``) contain information that is useful to share between recipes files. An example is the :ref:`autotools ` class, which contains common settings for any application that Autotools uses. -The "`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter in the +The ":ref:`ref-manual/ref-classes:Classes`" chapter in the Yocto Project Reference Manual provides details about classes and how to use them. @@ -123,8 +123,8 @@ variables that govern the OpenEmbedded build process. These files fall into several areas that define machine configuration options, distribution configuration options, compiler tuning options, general common configuration options, and user configuration options in -``conf/local.conf``, which is found in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. +``conf/local.conf``, which is found in the :term:`Build Directory`. + .. _overview-layers: @@ -164,8 +164,8 @@ OpenEmbedded Build System Concepts ================================== This section takes a more detailed look inside the build process used by -the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, which is the build +the :term:`OpenEmbedded Build System`, +which is the build system specific to the Yocto Project. At the heart of the build system is BitBake, the task executor. @@ -221,8 +221,8 @@ figure <#general-workflow-figure>`__: BitBake needs some basic configuration files in order to complete a build. These files are ``*.conf`` files. The minimally necessary ones -reside as example files in the ``build/conf`` directory of the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. For simplicity, +reside as example files in the ``build/conf`` directory of the +:term:`Source Directory`. For simplicity, this section refers to the Source Directory as the "Poky Directory." When you clone the `Poky <&YOCTO_DOCS_REF_URL;#poky>`__ Git repository @@ -241,8 +241,8 @@ for creating actual configuration files when you source ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__, which is the build environment script. -Sourcing the build environment script creates a `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ if one does not +Sourcing the build environment script creates a +:term:`Build Directory` if one does not already exist. BitBake uses the Build Directory for all its work during builds. The Build Directory has a ``conf`` directory that contains default versions of your ``local.conf`` and ``bblayers.conf`` @@ -357,8 +357,8 @@ Configuration Edits" box in the figure. When you launch your build with the ``bitbake target`` command, BitBake sorts out the configurations to ultimately define your build -environment. It is important to understand that the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ reads the +environment. It is important to understand that the +:term:`OpenEmbedded Build System` reads the configuration files in a specific order: ``site.conf``, ``auto.conf``, and ``local.conf``. And, the build system applies the normal assignment statement rules as described in the "`Syntax and @@ -460,7 +460,7 @@ typically find in the distribution layer: can be shared among recipes in the distribution. When your recipes inherit a class, they take on the settings and functions for that class. You can read more about class files in the - "`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter of the Yocto + ":ref:`ref-manual/ref-classes:Classes`" chapter of the Yocto Reference Manual. - *conf:* This area holds configuration files for the layer @@ -643,8 +643,8 @@ Package Feeds ------------- When the OpenEmbedded build system generates an image or an SDK, it gets -the packages from a package feed area located in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The `general +the packages from a package feed area located in the +:term:`Build Directory`. The `general workflow figure <#general-workflow-figure>`__ shows this package feeds area in the upper-right corner. @@ -687,7 +687,7 @@ package files are kept: for the i586 or qemux86 architectures. BitBake uses the -```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__ +:ref:`do_package_write_* ` tasks to generate packages and place them into the package holding area (e.g. ``do_package_write_ipk`` for IPK packages). See the ":ref:`ref-tasks-package_write_deb`", @@ -733,8 +733,8 @@ code: The :ref:`ref-tasks-fetch` and :ref:`ref-tasks-unpack` tasks fetch -the source files and unpack them into the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. +the source files and unpack them into the +:term:`Build Directory`. .. note:: @@ -984,7 +984,7 @@ details on how this is accomplished, you can look at ```package.bbclass`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`__. Depending on the type of packages being created (RPM, DEB, or IPK), the -```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__ +:ref:`do_package_write_* ` task creates the actual packages and places them in the Package Feed area, which is ``${TMPDIR}/deploy``. You can see the "`Package Feeds <#package-feeds-dev-environment>`__" section for more detail on @@ -1067,7 +1067,7 @@ processing includes creation of a manifest file and optimizations. The manifest file (``.manifest``) resides in the same directory as the root filesystem image. This file lists out, line-by-line, the installed packages. The manifest file is useful for the -```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ class, +:ref:`testimage ` class, for example, to determine whether or not to run specific tests. See the :term:`IMAGE_MANIFEST` variable for additional information. @@ -1102,7 +1102,7 @@ as specified by the ``IMAGE_FSTYPES`` were ``ext4``, the dynamically generated task would be as follows: do_image_ext4 The final task involved in image creation is the -```do_image_complete`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image-complete>`__ +:ref:`do_image_complete ` task. This task completes the image by applying any image post processing as defined through the :term:`IMAGE_POSTPROCESS_COMMAND` @@ -1242,7 +1242,7 @@ version of the task where instead of building something, BitBake can skip to the end result and simply place a set of files into specific locations as needed. In some cases, it makes sense to have a setscene task variant (e.g. generating package files in the -```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__ +:ref:`do_package_write_* ` task). In other cases, it does not make sense (e.g. a :ref:`ref-tasks-patch` task or a :ref:`ref-tasks-unpack` task) since @@ -1317,8 +1317,8 @@ this output: Images " chapter in the Yocto Project Reference Manual. -The build process writes images out to the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ inside the +The build process writes images out to the :term:`Build Directory` +inside the ``tmp/deploy/images/machine/`` folder as shown in the figure. This folder contains any files expected to be loaded on the target device. The :term:`DEPLOY_DIR` variable @@ -1775,8 +1775,8 @@ need to fix this situation. Thus far, this section has limited discussion to the direct inputs into a task. Information based on direct inputs is referred to as the "basehash" in the code. However, the question of a task's indirect -inputs still exits - items already built and present in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The checksum (or +inputs still exits - items already built and present in the +:term:`Build Directory`. The checksum (or signature) for a particular task needs to add the hashes of all the tasks on which the particular task depends. Choosing which dependencies to add is a policy decision. However, the effect is to generate a master @@ -2117,9 +2117,9 @@ Fakeroot and Pseudo Some tasks are easier to implement when allowed to perform certain operations that are normally reserved for the root user (e.g. :ref:`ref-tasks-install`, -```do_package_write*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__, +:ref:`do_package_write* `, :ref:`ref-tasks-rootfs`, and -```do_image*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image>`__). For example, +:ref:`do_image* `). For example, the ``do_install`` task benefits from being able to set the UID and GID of installed files to arbitrary values. @@ -2139,8 +2139,8 @@ The capability to run tasks in a fake root environment is known as the BitBake keyword/variable flag that requests a fake root environment for a task. -In the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, the program that +In the :term:`OpenEmbedded Build System`, +the program that implements fakeroot is known as `Pseudo `__. Pseudo overrides system calls by using the environment variable ``LD_PRELOAD``, diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst index 745d2ecf91..82562bf995 100644 --- a/documentation/overview-manual/overview-manual-development-environment.rst +++ b/documentation/overview-manual/overview-manual-development-environment.rst @@ -86,8 +86,8 @@ Once your development host is set up to use the Yocto Project, several methods exist for you to do work in the Yocto Project environment: - *Command Lines, BitBake, and Shells:* Traditional development in the - Yocto Project involves using the `OpenEmbedded build - system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, which uses + Yocto Project involves using the :term:`OpenEmbedded Build System`, + which uses BitBake, in a command-line environment from a shell on your development host. You can accomplish this from a host that is a native Linux machine or from a host that has been set up with CROPS. @@ -162,8 +162,8 @@ these tarballs gives you a snapshot of the released files. .. note:: - - The recommended method for setting up the Yocto Project `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ and the files + - The recommended method for setting up the Yocto Project + :term:`Source Directory` and the files for supported BSPs (e.g., ``meta-intel``) is to use `Git <#git>`__ to create a local copy of the upstream repositories. @@ -350,8 +350,8 @@ Book `__. software on which to develop. The Yocto Project has two scripts named ``create-pull-request`` and ``send-pull-request`` that ship with the release to facilitate this workflow. You can find these scripts in - the ``scripts`` folder of the `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. For information + the ``scripts`` folder of the + :term:`Source Directory`. For information on how to use these scripts, see the "`Using Scripts to Push a Change Upstream and Request a Pull <&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream>`__" section in @@ -638,8 +638,8 @@ When you build an image using the Yocto Project, the build process uses a known list of licenses to ensure compliance. You can find this list in the :term:`Source Directory` at ``meta/files/common-licenses``. Once the build completes, the list of -all licenses found and used during that build are kept in the `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ at +all licenses found and used during that build are kept in the +:term:`Build Directory` at ``tmp/deploy/licenses``. If a module requires a license that is not in the base list, the build diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst index b27412cb25..3f98fa939c 100644 --- a/documentation/overview-manual/overview-manual-yp-intro.rst +++ b/documentation/overview-manual/overview-manual-yp-intro.rst @@ -180,8 +180,8 @@ developing using the Yocto Project: changes on the development system within the BitBake environment and then deploying only the updated packages to the target. - The Yocto Project `OpenEmbedded build - system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ produces packages + The Yocto Project :term:`OpenEmbedded Build System` + produces packages in standard formats (i.e. RPM, DEB, IPK, and TAR). You can deploy these packages into the running system on the target by using utilities on the target such as ``rpm`` or ``ipk``. @@ -202,8 +202,8 @@ The Yocto Project's "Layer Model" is a development model for embedded and IoT Linux creation that distinguishes the Yocto Project from other simple build systems. The Layer Model simultaneously supports collaboration and customization. Layers are repositories that contain -related sets of instructions that tell the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to do. You can +related sets of instructions that tell the :term:`OpenEmbedded Build System` +what to do. You can collaborate, share, and reuse layers. Layers can contain changes to previous instructions or settings at any @@ -292,8 +292,8 @@ The Yocto Project employs a collection of components and tools used by the project itself, by project developers, and by those using the Yocto Project. These components and tools are open source projects and metadata that are separate from the reference distribution -(`Poky <&YOCTO_DOCS_REF_URL;#poky>`__) and the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. Most of the +(`Poky <&YOCTO_DOCS_REF_URL;#poky>`__) and the +:term:`OpenEmbedded Build System`. Most of the components and tools are downloaded separately. This section provides brief overviews of the components and tools @@ -367,8 +367,8 @@ The following list consists of tools that help production related activities using the Yocto Project: - *Auto Upgrade Helper:* This utility when used in conjunction with the - `OpenEmbedded build - system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ (BitBake and + :term:`OpenEmbedded Build System` + (BitBake and OE-Core) automatically generates upgrades for recipes that are based on new versions of the recipes published upstream. @@ -668,8 +668,8 @@ Project. - *Toaster:* Regardless of what your Build Host is running, you can use Toaster to develop software using the Yocto Project. Toaster is a web - interface to the Yocto Project's `Open-Embedded build - system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. The interface + interface to the Yocto Project's :term:`OpenEmbedded Build System`. + The interface enables you to configure and run your builds. Information about builds is collected and stored in a database. You can use Toaster to configure and start builds on multiple remote build servers. @@ -789,8 +789,7 @@ section in the BitBake User's Manual. The OpenEmbedded Build System Workflow ====================================== -The `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ uses a "workflow" to +The :term:`OpenEmbedded Build System` uses a "workflow" to accomplish image and SDK generation. The following figure overviews that workflow: @@ -836,8 +835,8 @@ helpful for getting started: - *Configuration Files:* Files that hold global definitions of variables, user-defined variables, and hardware configuration - information. These files tell the `Open-Embedded build - system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to build and + information. These files tell the :term:`OpenEmbedded Build System` + what to build and what to put into the image to support a particular platform. - *Extensible Software Development Kit (eSDK):* A custom SDK for diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst index 07244a0311..3e8127b927 100644 --- a/documentation/ref-manual/faq.rst +++ b/documentation/ref-manual/faq.rst @@ -256,8 +256,7 @@ situation changes, the team will not support spaces in pathnames. **A:** The toolchain configuration is very flexible and customizable. It is primarily controlled with the ``TCMODE`` variable. This variable controls which ``tcmode-*.inc`` file to include from the -``meta/conf/distro/include`` directory within the `Source -Directory <#source-directory>`__. +``meta/conf/distro/include`` directory within the :term:`Source Directory`. The default value of ``TCMODE`` is "default", which tells the OpenEmbedded build system to use its internally built toolchain (i.e. @@ -342,8 +341,8 @@ redirect requests through proxy servers. **A:** Yes - you can easily do this. When you use BitBake to build an image, all the build output goes into the directory created when you run the build environment setup script (i.e. -````` <#structure-core-script>`__). By default, this `Build -Directory <#build-directory>`__ is named ``build`` but can be named +````` <#structure-core-script>`__). By default, this :term:`Build Directory` +is named ``build`` but can be named anything you want. Within the Build Directory, is the ``tmp`` directory. To remove all the @@ -379,8 +378,8 @@ system of that image. Thus, the build system provides a value of "/usr/bin" for ``bindir``, a value of "/usr/lib" for ``libdir``, and so forth. -Meanwhile, ``DESTDIR`` is a path within the `Build -Directory <#build-directory>`__. However, when the recipe builds a +Meanwhile, ``DESTDIR`` is a path within the :term:`Build Directory`. +However, when the recipe builds a native program (i.e. one that is intended to run on the build machine), that program is never installed directly to the build machine's root file system. Consequently, the build system uses paths within the Build diff --git a/documentation/ref-manual/migration.rst b/documentation/ref-manual/migration.rst index 1d4d53647f..31959b2845 100644 --- a/documentation/ref-manual/migration.rst +++ b/documentation/ref-manual/migration.rst @@ -731,7 +731,7 @@ Automated Image Testing ----------------------- A new automated image testing framework has been added through the -```testimage.bbclass`` <#ref-classes-testimage*>`__ class. This +:ref:`testimage.bbclass ` class. This framework replaces the older ``imagetest-qemu`` framework. You can learn more about performing automated image tests in the @@ -1077,7 +1077,7 @@ future releases the :ref:`autotools ` class will enable a separate build directory by default as well. Recipes building Autotools-based software that fails to build with a separate build directory should be changed to inherit from the -```autotools-brokensep`` <#ref-classes-autotools>`__ class instead of +:ref:`autotools-brokensep ` class instead of the ``autotools`` or ``autotools_stage``\ classes. .. _migration-1.6-building-qemu-native: @@ -1305,7 +1305,7 @@ occurred: However, if the software is not capable of being built in this manner, you will need to either patch the software so that it can build separately, or you will need to change the recipe to inherit - the ```autotools-brokensep`` <#ref-classes-autotools>`__ class + the :ref:`autotools-brokensep ` class instead of the ``autotools`` or ``autotools_stage`` classes. - *The ``--foreign`` option is no longer passed to ``automake`` when @@ -2048,7 +2048,7 @@ time. A minor part of this restructuring is that the post-processing definitions and functions have been moved from the :ref:`image ` class to the -```rootfs-postcommands`` <#ref-classes-rootfs*>`__ class. Functionally, +:ref:`rootfs-postcommands ` class. Functionally, however, they remain unchanged. .. _migration-2.1-removed-recipes: @@ -3973,7 +3973,7 @@ For names of recipes removed because of this repository change, see the Previously, it was possible for Python recipes that inherited the :ref:`distutils ` and -```distutils3`` <#ref-classes-distutils3>`__ classes to fetch code +:ref:`distutils3 ` classes to fetch code during the :ref:`ref-tasks-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 @@ -4183,7 +4183,7 @@ This section provides information about automatic testing changes: practices now dictate that you use the :term:`IMAGE_CLASSES` variable rather than the :term:`INHERIT` variable when you inherit the - ```testimage`` <#ref-classes-testimage*>`__ and + :ref:`testimage ` and :ref:`testsdk ` classes used for automatic testing. diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst index 6449b49cd4..4b4f3bac5a 100644 --- a/documentation/ref-manual/ref-classes.rst +++ b/documentation/ref-manual/ref-classes.rst @@ -14,8 +14,8 @@ some default behavior. Any :term:`Metadata` usually found in a recipe can also be placed in a class file. Class files are identified by the extension ``.bbclass`` and are usually placed in a ``classes/`` directory beneath -the ``meta*/`` directory found in the `Source -Directory <#source-directory>`__. Class files can also be pointed to by +the ``meta*/`` directory found in the :term:`Source Directory`. +Class files can also be pointed to by :term:`BUILDDIR` (e.g. ``build/``) in the same way as ``.conf`` files in the ``conf`` directory. Class files are searched for in :term:`BBPATH` using the same method by which ``.conf`` @@ -555,7 +555,7 @@ used. ``distutils`` class in their recipes. - Extensions that use build systems based on ``setuptools3`` require - the ```setuptools3`` <#ref-classes-setuptools>`__ class in their + the :ref:`setuptools3 ` class in their recipes. The ``distutils3*`` classes either inherit their corresponding @@ -592,8 +592,8 @@ ${WORKDIR}/${BPN}/{PV}/ See these variables for more information: :term:`PV`, For more information on the ``externalsrc`` class, see the comments in -``meta/classes/externalsrc.bbclass`` in the `Source -Directory <#source-directory>`__. For information on how to use the +``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`. +For information on how to use the ``externalsrc`` class, see the "`Building Software from an External Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__" section in the Yocto Project Development Tasks Manual. @@ -1733,8 +1733,8 @@ package-specific classes: You can control the list of resulting package formats by using the ``PACKAGE_CLASSES`` variable defined in your ``conf/local.conf`` -configuration file, which is located in the `Build -Directory <#build-directory>`__. When defining the variable, you can +configuration file, which is located in the :term:`Build Directory`. +When defining the variable, you can specify one or more package types. Since images are generated from packages, a packaging class is needed to enable image generation. The first class listed in this variable is used for image generation. @@ -2181,8 +2181,8 @@ recipe are no longer needed. However, by default, the build system preserves these files for inspection and possible debugging purposes. If you would rather have these files deleted to save disk space as the build progresses, you can enable ``rm_work`` by adding the following to -your ``local.conf`` file, which is found in the `Build -Directory <#build-directory>`__. INHERIT += "rm_work" If you are +your ``local.conf`` file, which is found in the :term:`Build Directory`. +INHERIT += "rm_work" If you are modifying and building source code out of the work directory for a recipe, enabling ``rm_work`` will potentially result in your changes to the source being lost. To exclude some recipes from having their work @@ -2565,7 +2565,7 @@ Other classes use the ``terminal`` class anywhere a separate terminal session needs to be started. For example, the :ref:`patch ` class assuming :term:`PATCHRESOLVE` is set to "user", the -```cml1`` <#ref-classes-cml1>`__ class, and the +:ref:`cml1 ` class, and the :ref:`devshell ` class all use the ``terminal`` class. diff --git a/documentation/ref-manual/ref-images.rst b/documentation/ref-manual/ref-images.rst index 5aeaa43833..4eba5cdf16 100644 --- a/documentation/ref-manual/ref-images.rst +++ b/documentation/ref-manual/ref-images.rst @@ -27,8 +27,8 @@ image you want. From within the ``poky`` Git repository, you can use the following -command to display the list of directories within the `Source -Directory <#source-directory>`__ that contain image recipe files: $ ls +command to display the list of directories within the :term:`Source Directory` +that contain image recipe files: $ ls meta*/recipes*/images/*.bb Following is a list of supported recipes: diff --git a/documentation/ref-manual/ref-release-process.rst b/documentation/ref-manual/ref-release-process.rst index 95ec686a13..832f011918 100644 --- a/documentation/ref-manual/ref-release-process.rst +++ b/documentation/ref-manual/ref-release-process.rst @@ -117,7 +117,7 @@ consists of the following pieces: an ARM target, did the build produce ARM binaries. If, for example, the build produced PPC binaries then there is a problem. -- ```testimage.bbclass`` <#ref-classes-testimage*>`__: This class +- :ref:`testimage.bbclass `: This class performs runtime testing of images after they are built. The tests are usually used with `QEMU <&YOCTO_DOCS_DEV_URL;#dev-manual-qemu>`__ to boot the images and check the combined runtime result boot diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst index c63900e604..a21c0bdd52 100644 --- a/documentation/ref-manual/ref-structure.rst +++ b/documentation/ref-manual/ref-structure.rst @@ -26,8 +26,7 @@ section in the Yocto Project Development Tasks Manual. Top-Level Core Components ========================= -This section describes the top-level components of the `Source -Directory <#source-directory>`__. +This section describes the top-level components of the :term:`Source Directory`. .. _structure-core-bitbake: @@ -57,8 +56,8 @@ Manual <&YOCTO_DOCS_BB_URL;>`__. This directory contains user configuration files and the output generated by the OpenEmbedded build system in its standard configuration -where the source tree is combined with the output. The `Build -Directory <#build-directory>`__ is created initially when you ``source`` +where the source tree is combined with the output. The :term:`Build Directory` +is created initially when you ``source`` the OpenEmbedded build environment setup script (i.e. ````` <#structure-core-script>`__). @@ -175,8 +174,8 @@ creates the ``build/`` directory in your current working directory. If you provide a Build Directory argument when you ``source`` the script, you direct the OpenEmbedded build system to create a Build Directory of your choice. For example, the following command creates a Build -Directory named ``mybuilds/`` that is outside of the `Source -Directory <#source-directory>`__: $ source OE_INIT_FILE ~/mybuilds The +Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`: +$ source OE_INIT_FILE ~/mybuilds The OpenEmbedded build system uses the template configuration files, which are found by default in the ``meta-poky/conf/`` directory in the Source Directory. See the "`Creating a Custom Template Configuration @@ -206,8 +205,8 @@ These files are standard top-level files. The Build Directory - ``build/`` ================================ -The OpenEmbedded build system creates the `Build -Directory <#build-directory>`__ when you run the build environment setup +The OpenEmbedded build system creates the :term:`Build Directory` +when you run the build environment setup script ````` <#structure-core-script>`__. If you do not give the Build Directory a specific name when you run the setup script, the name defaults to ``build/``. diff --git a/documentation/ref-manual/ref-system-requirements.rst b/documentation/ref-manual/ref-system-requirements.rst index 9358a168f1..3144d303f8 100644 --- a/documentation/ref-manual/ref-system-requirements.rst +++ b/documentation/ref-manual/ref-system-requirements.rst @@ -348,8 +348,8 @@ installer: system. Once the build completes, you can find the ``.sh`` file that installs - the tools in the ``tmp/deploy/sdk`` subdirectory of the `Build - Directory <#build-directory>`__. The installer file has the string + the tools in the ``tmp/deploy/sdk`` subdirectory of the + :term:`Build Directory`. The installer file has the string "buildtools" (or "buildtools-extended") in the name. 3. Transfer the ``.sh`` file from the build host to the machine that diff --git a/documentation/ref-manual/ref-tasks.rst b/documentation/ref-manual/ref-tasks.rst index f3c698ba98..4bcd0a2d00 100644 --- a/documentation/ref-manual/ref-tasks.rst +++ b/documentation/ref-manual/ref-tasks.rst @@ -409,7 +409,7 @@ dependencies specified by :term:`DEPENDS`). See the Removes work files after the OpenEmbedded build system has finished with them. You can learn more by looking at the -"```rm_work.bbclass`` <#ref-classes-rm-work>`__" section. +":ref:`rm_work.bbclass `" section. .. _ref-tasks-unpack: diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst index 4298e04965..eacc49fc3d 100644 --- a/documentation/ref-manual/ref-terms.rst +++ b/documentation/ref-manual/ref-terms.rst @@ -378,8 +378,8 @@ universal, the list includes them just in case: :ref:`ref-tasks-patch`, and so forth). Toaster - A web interface to the Yocto Project's `OpenEmbedded Build - System <#build-system-term>`__. The interface enables you to + A web interface to the Yocto Project's :term:`OpenEmbedded Build System`. + The interface enables you to configure and run your builds. Information about builds is collected and stored in a database. For information on Toaster, see the `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__. diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst index 473b672b76..aa7f59f602 100644 --- a/documentation/ref-manual/ref-variables.rst +++ b/documentation/ref-manual/ref-variables.rst @@ -144,8 +144,7 @@ system and gives an overview of their function and contents. = "1" # Uses environment data. ARCHIVER_MODE[recipe] = "1" # Uses recipe and include files. ARCHIVER_MODE[srpm] = "1" # Uses RPM package files. For information on how the variable works, see the - ``meta/classes/archiver.bbclass`` file in the `Source - Directory <#source-directory>`__. + ``meta/classes/archiver.bbclass`` file in the :term:`Source Directory`. AS Minimal command and arguments needed to run the assembler. @@ -583,8 +582,8 @@ system and gives an overview of their function and contents. BBLAYERS Lists the layers to enable during the build. This variable is defined - in the ``bblayers.conf`` configuration file in the `Build - Directory <#build-directory>`__. Here is an example: BBLAYERS = " \\ + in the ``bblayers.conf`` configuration file in the :term:`Build Directory`. + Here is an example: BBLAYERS = " \\ /home/scottrif/poky/meta \\ /home/scottrif/poky/meta-poky \\ /home/scottrif/poky/meta-yocto-bsp \\ /home/scottrif/poky/meta-mykernel \\ " @@ -705,8 +704,8 @@ system and gives an overview of their function and contents. . For more information on how this variable works, see - ``meta/classes/binconfig.bbclass`` in the `Source - Directory <#source-directory>`__. You can also find general + ``meta/classes/binconfig.bbclass`` in the :term:`Source Directory`. + You can also find general information on the class in the ":ref:`binconfig.bbclass `" section. @@ -1042,8 +1041,8 @@ system and gives an overview of their function and contents. Bluetooth but you do not ever intend to use it. COMMON_LICENSE_DIR - Points to ``meta/files/common-licenses`` in the `Source - Directory <#source-directory>`__, which is where generic license + Points to ``meta/files/common-licenses`` in the + :term:`Source Directory`, which is where generic license files reside. COMPATIBLE_HOST @@ -1391,8 +1390,8 @@ system and gives an overview of their function and contents. for an SDK (i.e. ``nativesdk-``) D - The destination directory. The location in the `Build - Directory <#build-directory>`__ where components are installed by the + The destination directory. The location in the :term:`Build Directory` + where components are installed by the :ref:`ref-tasks-install` task. This location defaults to: ${WORKDIR}/image @@ -1664,8 +1663,8 @@ system and gives an overview of their function and contents. file whose root name is the same as the variable's argument and whose filename extension is ``.conf``. For example, the distribution configuration file for the Poky distribution is named ``poky.conf`` - and resides in the ``meta-poky/conf/distro`` directory of the `Source - Directory <#source-directory>`__. + and resides in the ``meta-poky/conf/distro`` directory of the + :term:`Source Directory`. Within that ``poky.conf`` file, the ``DISTRO`` variable is set as follows: DISTRO = "poky" @@ -2296,8 +2295,8 @@ system and gives an overview of their function and contents. :term:`SRC_URI` statements. The default value for the ``FILESPATH`` variable is defined in the - ``base.bbclass`` class found in ``meta/classes`` in the `Source - Directory <#source-directory>`__: FILESPATH = + ``base.bbclass`` class found in ``meta/classes`` in the + :term:`Source Directory`: FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \\ "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" The ``FILESPATH`` variable is automatically extended using the overrides @@ -2344,14 +2343,14 @@ system and gives an overview of their function and contents. packages themselves but this is not always possible. By default, the OpenEmbedded build system uses the ``fs-perms.txt``, - which is located in the ``meta/files`` folder in the `Source - Directory <#source-directory>`__. If you create your own file + which is located in the ``meta/files`` folder in the :term:`Source Directory`. + If you create your own file permissions setting table, you should place it in your layer or the distro's layer. You define the ``FILESYSTEM_PERMS_TABLES`` variable in the - ``conf/local.conf`` file, which is found in the `Build - Directory <#build-directory>`__, to point to your custom + ``conf/local.conf`` file, which is found in the :term:`Build Directory`, + to point to your custom ``fs-perms.txt``. You can specify more than a single file permissions setting table. The paths you specify to these files must be defined within the :term:`BBPATH` variable. @@ -2717,8 +2716,8 @@ system and gives an overview of their function and contents. IMAGE_FEATURES The primary list of features to include in an image. Typically, you configure this variable in an image recipe. Although you can use this - variable from your ``local.conf`` file, which is found in the `Build - Directory <#build-directory>`__, best practices dictate that you do + variable from your ``local.conf`` file, which is found in the + :term:`Build Directory`, best practices dictate that you do not. .. note:: @@ -2886,13 +2885,13 @@ system and gives an overview of their function and contents. class is broken and is not supported. It is recommended that you do not use it. - The ```populate_sdk_*`` <#ref-classes-populate-sdk-*>`__ and + The :ref:`populate_sdk_* ` and :ref:`image ` classes use the ``IMAGE_PKGTYPE`` for packaging up images and SDKs. You should not set the ``IMAGE_PKGTYPE`` manually. Rather, the variable is set indirectly through the appropriate - ```package_*`` <#ref-classes-package>`__ class using the + :ref:`package_* ` class using the :term:`PACKAGE_CLASSES` variable. The OpenEmbedded build system uses the first package type (e.g. DEB, RPM, or IPK) that appears with the variable @@ -2995,8 +2994,7 @@ system and gives an overview of their function and contents. wic.bz2 wic.gz wic.lzma For more information about these types of images, see - ``meta/classes/image_types*.bbclass`` in the `Source - Directory <#source-directory>`__. + ``meta/classes/image_types*.bbclass`` in the :term:`Source Directory`. INC_PR Helps define the recipe revision for recipes that share a common @@ -3156,8 +3154,8 @@ system and gives an overview of their function and contents. :term:`IMAGE_FSTYPES` variable. The default value of this variable, which is set in the - ``meta/conf/bitbake.conf`` configuration file in the `Source - Directory <#source-directory>`__, is "cpio.gz". The Linux kernel's + ``meta/conf/bitbake.conf`` configuration file in the + :term:`Source Directory`, is "cpio.gz". The Linux kernel's initramfs mechanism, as opposed to the initial RAM filesystem `initrd `__ mechanism, expects an optionally compressed cpio archive. @@ -3945,8 +3943,8 @@ system and gives an overview of their function and contents. MACHINE Specifies the target device for which the image is built. You define - ``MACHINE`` in the ``local.conf`` file found in the `Build - Directory <#build-directory>`__. By default, ``MACHINE`` is set to + ``MACHINE`` in the ``local.conf`` file found in the + :term:`Build Directory`. By default, ``MACHINE`` is set to "qemux86", which is an x86-based architecture machine to be emulated using QEMU: MACHINE ?= "qemux86" @@ -4353,8 +4351,8 @@ system and gives an overview of their function and contents. ``sysroots/`` directory so that all builds that use the script will use the correct directories for the cross compiling layout. - See the ``meta/classes/binconfig.bbclass`` in the `Source - Directory <#source-directory>`__ for details on how this class + See the ``meta/classes/binconfig.bbclass`` in the + :term:`Source Directory` for details on how this class applies these additional sed command arguments. For general information on the ``binconfig`` class, see the ":ref:`binconfig.bbclass `" section. @@ -4499,8 +4497,8 @@ system and gives an overview of their function and contents. PACKAGE_CLASSES This variable, which is set in the ``local.conf`` configuration file - found in the ``conf`` folder of the `Build - Directory <#build-directory>`__, specifies the package manager the + found in the ``conf`` folder of the + :term:`Build Directory`, specifies the package manager the OpenEmbedded build system uses when packaging data. You can provide one or more of the following arguments for the @@ -5234,8 +5232,8 @@ system and gives an overview of their function and contents. Typically, you could add a specific server for the build system to attempt before any others by adding something like the following to - the ``local.conf`` configuration file in the `Build - Directory <#build-directory>`__: PREMIRRORS_prepend = "\\ + the ``local.conf`` configuration file in the + :term:`Build Directory`: PREMIRRORS_prepend = "\\ git://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ ftp://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ http://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\* @@ -5364,8 +5362,8 @@ system and gives an overview of their function and contents. PYTHON_ABI When used by recipes that inherit the - ```distutils3`` <#ref-classes-distutils3>`__, - ```setuptools3`` <#ref-classes-setuptools3>`__, + :ref:`distutils3 `, + :ref:`setuptools3 `, :ref:`distutils `, or :ref:`setuptools ` classes, denotes the Application Binary Interface (ABI) currently in use for Python. By @@ -5382,8 +5380,8 @@ system and gives an overview of their function and contents. PYTHON_PN When used by recipes that inherit the - ```distutils3`` <#ref-classes-distutils3>`__, - ```setuptools3`` <#ref-classes-setuptools3>`__, + `distutils3 `, + :ref:`setuptools3 `, :ref:`distutils `, or :ref:`setuptools ` classes, specifies the major Python version being built. For Python 3.x, ``PYTHON_PN`` would @@ -5522,7 +5520,7 @@ system and gives an overview of their function and contents. RM_WORK_EXCLUDE With ``rm_work`` enabled, this variable specifies a list of recipes whose work directories should not be removed. See the - "```rm_work.bbclass`` <#ref-classes-rm-work>`__" section for more + ":ref:`rm_work.bbclass `" section for more details. ROOT_HOME @@ -5731,14 +5729,14 @@ system and gives an overview of their function and contents. SDK_DEPLOY The directory set up and used by the - ```populate_sdk_base`` <#ref-classes-populate-sdk>`__ class to which + :ref:`populate_sdk_base ` class to which the SDK is deployed. The ``populate_sdk_base`` class defines ``SDK_DEPLOY`` as follows: SDK_DEPLOY = "${TMPDIR}/deploy/sdk" SDK_DIR The parent directory used by the OpenEmbedded build system when creating SDK output. The - ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class defines + :ref:`populate_sdk_base ` class defines the variable as follows: SDK_DIR = "${WORKDIR}/sdk" .. note:: @@ -5770,7 +5768,7 @@ system and gives an overview of their function and contents. file contains package information on a line-per-package basis as follows: packagename packagearch version - The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class + The :ref:`populate_sdk_base ` class defines the manifest file as follows: SDK_HOST_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest" The location is derived using the :term:`SDK_DEPLOY` and @@ -5807,7 +5805,7 @@ system and gives an overview of their function and contents. SDK_INHERIT_BLACKLIST A list of classes to remove from the :term:`INHERIT` value globally within the extensible SDK configuration. The - ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class sets the + :ref:`populate-sdk-ext ` class sets the default value: SDK_INHERIT_BLACKLIST ?= "buildhistory icecc" Some classes are not generally applicable within the extensible SDK @@ -5827,7 +5825,7 @@ system and gives an overview of their function and contents. within the extensible SDK. By default, ``SDK_LOCAL_CONF_BLACKLIST`` is set in the - ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class and + :ref:`populate-sdk-ext ` class and excludes the following variables: :term:`CONF_VERSION` :term:`BB_NUMBER_THREADS` @@ -5848,7 +5846,7 @@ system and gives an overview of their function and contents. A list of variables allowed through from the OpenEmbedded build system configuration into the extensible SDK configuration. By default, the list of variables is empty and is set in the - ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class. + :ref:`populate-sdk-ext ` class. This list overrides the variables specified using the :term:`SDK_LOCAL_CONF_BLACKLIST` @@ -5877,7 +5875,7 @@ system and gives an overview of their function and contents. SDK_OUTPUT The location used by the OpenEmbedded build system when creating SDK - output. The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ + output. The :ref:`populate_sdk_base ` class defines the variable as follows: SDK_DIR = "${WORKDIR}/sdk" SDK_OUTPUT = "${SDK_DIR}/image" SDK_DEPLOY = "${DEPLOY_DIR}/sdk" @@ -5942,7 +5940,7 @@ system and gives an overview of their function and contents. file contains package information on a line-per-package basis as follows: packagename packagearch version - The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class + The :ref:`populate_sdk_base ` class defines the manifest file as follows: SDK_TARGET_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest" The location is derived using the :term:`SDK_DEPLOY` and @@ -5960,7 +5958,7 @@ system and gives an overview of their function and contents. The title to be printed when running the SDK installer. By default, this title is based on the :term:`DISTRO_NAME` or :term:`DISTRO` variable and is set in the - ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as + :ref:`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)". @@ -5993,7 +5991,7 @@ system and gives an overview of their function and contents. The default installation directory for the Extensible SDK. By default, this directory is based on the :term:`DISTRO` variable and is set in the - ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as + :ref:`populate_sdk_base ` class as follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" For the default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk". @@ -6135,8 +6133,8 @@ system and gives an overview of their function and contents. prebuilt binaries and libraries such as ``libstdc++`` and ``glibc``. To enable file removal, set the variable to "1" in your - ``conf/local.conf`` configuration file in your: `Build - Directory <#build-directory>`__. SKIP_FILEDEPS = "1" + ``conf/local.conf`` configuration file in your: + :term:`Build Directory`. SKIP_FILEDEPS = "1" SOC_FAMILY Groups together machines based upon the same family of SOC (System On @@ -7289,8 +7287,8 @@ system and gives an overview of their function and contents. If you want to establish this directory in a location other than the default, you can uncomment and edit the following statement in the - ``conf/local.conf`` file in the `Source - Directory <#source-directory>`__: #TMPDIR = "${TOPDIR}/tmp" An + ``conf/local.conf`` file in the :term:`Source Directory`: + #TMPDIR = "${TOPDIR}/tmp" An example use for this scenario is to set ``TMPDIR`` to a local disk, which does not use NFS, while having the Build Directory use NFS. @@ -7325,7 +7323,7 @@ system and gives an overview of their function and contents. TOOLCHAIN_OUTPUTNAME This variable defines the name used for the toolchain output. The - ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class sets + :ref:`populate_sdk_base ` class sets the ``TOOLCHAIN_OUTPUTNAME`` variable as follows: TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" See the :term:`SDK_NAME` and @@ -7374,8 +7372,8 @@ system and gives an overview of their function and contents. definitions can be a single static definition, or can be dynamically adjusted. You can see details for a given CPU family by looking at the architecture's ``README`` file. For example, the - ``meta/conf/machine/include/mips/README`` file in the `Source - Directory <#source-directory>`__ provides information for + ``meta/conf/machine/include/mips/README`` file in the + :term:`Source Directory` provides information for ``TUNE_ARCH`` specific to the ``mips`` architecture. ``TUNE_ARCH`` is tied closely to @@ -7510,8 +7508,8 @@ system and gives an overview of their function and contents. ``meta/conf/machine/include/arm/arch-arm.inc``). Here is an example from that file: TUNEVALID[bigendian] = "Enable big-endian mode." - See the machine include files in the `Source - Directory <#source-directory>`__ for these features. + See the machine include files in the :term:`Source Directory` + for these features. UBOOT_CONFIG Configures the :term:`UBOOT_MACHINE` and can @@ -7696,8 +7694,7 @@ system and gives an overview of their function and contents. The default list is set in your ``local.conf`` file: USER_CLASSES ?= "buildstats image-mklibs image-prelink" For more information, see - ``meta-poky/conf/local.conf.sample`` in the `Source - Directory <#source-directory>`__. + ``meta-poky/conf/local.conf.sample`` in the :term:`Source Directory`. USERADD_ERROR_DYNAMIC If set to ``error``, forces the OpenEmbedded build system to produce diff --git a/documentation/sdk-manual/sdk-appendix-customizing.rst b/documentation/sdk-manual/sdk-appendix-customizing.rst index 8169f2bed8..3bb6ef3a19 100644 --- a/documentation/sdk-manual/sdk-appendix-customizing.rst +++ b/documentation/sdk-manual/sdk-appendix-customizing.rst @@ -150,7 +150,7 @@ set. If the ``DISTRO_NAME`` variable is not set, the title is derived from the :term:`DISTRO` variable. The -```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__ +:ref:`populate_sdk_base ` class defines the default value of the ``SDK_TITLE`` variable as follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" @@ -212,7 +212,7 @@ installation directory for the SDK is based on the :term:`DISTRO` and :term:`SDKEXTPATH` variables from within the -```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__ +:ref:`populate_sdk_base ` class as follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" You can change this default installation directory by specifically setting the ``SDKEXTPATH`` variable. @@ -276,8 +276,8 @@ source, you need to do a number of things: - Alternatively, if you just want to set the ``SSTATE_MIRRORS`` variable's value for the SDK alone, create a - ``conf/sdk-extra.conf`` file either in your `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ or within any + ``conf/sdk-extra.conf`` file either in your + :term:`Build Directory` or within any layer and put your ``SSTATE_MIRRORS`` setting within that file. .. note:: diff --git a/documentation/sdk-manual/sdk-appendix-obtain.rst b/documentation/sdk-manual/sdk-appendix-obtain.rst index c6efdf674c..015506de01 100644 --- a/documentation/sdk-manual/sdk-appendix-obtain.rst +++ b/documentation/sdk-manual/sdk-appendix-obtain.rst @@ -70,8 +70,8 @@ build the SDK installer. Follow these steps: machine that uses CROPS. 2. *Clone the ``poky`` Repository:* You need to have a local copy of the - Yocto Project `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (i.e. a local + Yocto Project :term:`Source Directory` + (i.e. a local ``poky`` repository). See the "`Cloning the ``poky`` Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" and possibly the "`Checking Out by Branch in @@ -87,8 +87,8 @@ build the SDK installer. Follow these steps: ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ environment setup script to define the OpenEmbedded build environment on your build host. $ source OE_INIT_FILE Among other things, the script - creates the `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is + creates the :term:`Build Directory`, + which is ``build`` in this case and is located in the Source Directory. After the script runs, your current working directory is set to the ``build`` directory. diff --git a/documentation/sdk-manual/sdk-extensible.rst b/documentation/sdk-manual/sdk-extensible.rst index 17cd08a25c..3df2174fd9 100644 --- a/documentation/sdk-manual/sdk-extensible.rst +++ b/documentation/sdk-manual/sdk-extensible.rst @@ -9,8 +9,8 @@ Information covers the pieces of the SDK, how to install it, and presents a look at using the ``devtool`` functionality. The extensible SDK makes it easy to add new applications and libraries to an image, modify the source for an existing component, test changes on the target -hardware, and ease integration into the rest of the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. +hardware, and ease integration into the rest of the +:term:`OpenEmbedded Build System`. .. note:: diff --git a/documentation/sdk-manual/sdk-intro.rst b/documentation/sdk-manual/sdk-intro.rst index fcb15a8592..88238d7dd4 100644 --- a/documentation/sdk-manual/sdk-intro.rst +++ b/documentation/sdk-manual/sdk-intro.rst @@ -39,8 +39,7 @@ All SDKs consist of the following: Additionally, an extensible SDK has tools that allow you to easily add new applications and libraries to an image, modify the source of an existing component, test changes on the target hardware, and easily -integrate an application into the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. +integrate an application into the :term:`OpenEmbedded Build System`. You can use an SDK to independently develop and test code that is destined to run on some target machine. SDKs are completely @@ -126,8 +125,7 @@ of a cross-compiler, cross-linker, and cross-debugger that are used to develop user-space applications for targeted hardware. Additionally, for an extensible SDK, the toolchain also has built-in ``devtool`` functionality. This toolchain is created by running a SDK installer -script or through a `Build -Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ that is based on +script or through a :term:`Build Directory` that is based on your metadata configuration or extension for your targeted device. The cross-toolchain works with a matching target sysroot. @@ -149,8 +147,8 @@ The QEMU emulator allows you to simulate your hardware while running your application or image. QEMU is not part of the SDK but is made available a number of different ways: -- If you have cloned the ``poky`` Git repository to create a `Source - Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ and you have +- If you have cloned the ``poky`` Git repository to create a + :term:`Source Directory` and you have sourced the environment setup script, QEMU is installed and automatically available. diff --git a/documentation/sdk-manual/sdk-working-projects.rst b/documentation/sdk-manual/sdk-working-projects.rst index 63f61de66d..d18568d60a 100644 --- a/documentation/sdk-manual/sdk-working-projects.rst +++ b/documentation/sdk-manual/sdk-working-projects.rst @@ -14,8 +14,7 @@ Once you have a suitable `cross-development toolchain <&YOCTO_DOCS_REF_URL;#cross-development-toolchain>`__ installed, it is very easy to develop a project using the `GNU Autotools-based `__ -workflow, which is outside of the `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. +workflow, which is outside of the :term:`OpenEmbedded Build System`. The following figure presents a simple Autotools workflow. diff --git a/documentation/toaster-manual/toaster-manual-intro.rst b/documentation/toaster-manual/toaster-manual-intro.rst index ec50be5a91..bc4298dfce 100644 --- a/documentation/toaster-manual/toaster-manual-intro.rst +++ b/documentation/toaster-manual/toaster-manual-intro.rst @@ -4,8 +4,8 @@ Introduction ************ -Toaster is a web interface to the Yocto Project's `OpenEmbedded build -system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. The interface +Toaster is a web interface to the Yocto Project's +:term:`OpenEmbedded Build System`. The interface enables you to configure and run your builds. Information about builds is collected and stored in a database. You can use Toaster to configure and start builds on multiple remote build servers. diff --git a/documentation/toaster-manual/toaster-manual-reference.rst b/documentation/toaster-manual/toaster-manual-reference.rst index c98a27eeb8..d799b4b99b 100644 --- a/documentation/toaster-manual/toaster-manual-reference.rst +++ b/documentation/toaster-manual/toaster-manual-reference.rst @@ -422,15 +422,15 @@ at the `Django `__ site. However, several ``manage.py`` commands have been created that are specific to Toaster and are used to control configuration and back-end -tasks. You can locate these commands in the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``) at +tasks. You can locate these commands in the +:term:`Source Directory` (e.g. ``poky``) at ``bitbake/lib/manage.py``. This section documents those commands. .. note:: - When using ``manage.py`` commands given a default configuration, - you must be sure that your working directory is set to the `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. Using + you must be sure that your working directory is set to the + :term:`Build Directory`. Using ``manage.py`` commands from the Build Directory allows Toaster to find the ``toaster.sqlite`` file, which is located in the Build Directory. diff --git a/documentation/toaster-manual/toaster-manual-setup-and-use.rst b/documentation/toaster-manual/toaster-manual-setup-and-use.rst index 7e715403d0..360270afbf 100644 --- a/documentation/toaster-manual/toaster-manual-setup-and-use.rst +++ b/documentation/toaster-manual/toaster-manual-setup-and-use.rst @@ -12,8 +12,8 @@ dependencies as described in the "`Preparing to Use Toaster <#toaster-manual-start>`__" chapter, you are ready to start Toaster. -Navigate to the root of your `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``): $ +Navigate to the root of your +:term:`Source Directory` (e.g. ``poky``): $ cd poky Once in that directory, source the build environment script: $ source oe-init-build-env Next, from the build directory (e.g. ``poky/build``), start Toaster using this command: $ source toaster @@ -267,8 +267,8 @@ Perform the following steps to install Toaster: the "`Configuring Toaster <#configuring-toaster>`__" section. This line also runs the ``checksettings`` command, which configures - the location of the Toaster `Build - Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The Toaster + the location of the Toaster :term:`Build Directory`. + The Toaster root directory ``TOASTER_DIR`` determines where the Toaster build directory is created on the file system. In the example above, ``TOASTER_DIR`` is set as follows: /var/www/toaster/poky This diff --git a/documentation/toaster-manual/toaster-manual-start.rst b/documentation/toaster-manual/toaster-manual-start.rst index 439952e15e..1114c04eab 100644 --- a/documentation/toaster-manual/toaster-manual-start.rst +++ b/documentation/toaster-manual/toaster-manual-start.rst @@ -28,8 +28,8 @@ Establishing Toaster System Dependencies Toaster requires extra Python dependencies in order to run. A Toaster requirements file named ``toaster-requirements.txt`` defines the Python dependencies. The requirements file is located in the ``bitbake`` -directory, which is located in the root directory of the `Source -Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. +directory, which is located in the root directory of the +:term:`Source Directory` (e.g. ``poky/bitbake/toaster-requirements.txt``). The dependencies appear in a ``pip``, install-compatible format. -- cgit v1.2.3-54-g00ecf