From b44fbe5b1b425b8a8c23e4f0ba80583944ab303a Mon Sep 17 00:00:00 2001 From: Michael Opdenacker Date: Thu, 27 Oct 2022 15:09:08 +0200 Subject: manuals: use references to the "Build Directory" term Replace instances of "Build Directory" and "build directory" (when applicable) by :term:`Build Directory` as already done in most places. Doing this, fix the indentation of the paragraphs with this term. (From yocto-docs rev: dce50679242d39f133e0cde5c8483b5e69f3eb54) Signed-off-by: Michael Opdenacker Signed-off-by: Richard Purdie --- documentation/overview-manual/concepts.rst | 74 ++++++++++------------ .../overview-manual/development-environment.rst | 8 +-- 2 files changed, 36 insertions(+), 46 deletions(-) (limited to 'documentation/overview-manual') diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst index 931bec79e8..b323a6fdf4 100644 --- a/documentation/overview-manual/concepts.rst +++ b/documentation/overview-manual/concepts.rst @@ -233,13 +233,12 @@ for creating actual configuration files when you source :ref:`structure-core-script`, which is the build environment script. -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`` +Sourcing the build environment script creates a :term:`Build Directory` +if one does not already exist. BitBake uses the :term:`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`` configuration files. These default configuration files are created only -if versions do not already exist in the Build Directory at the time you +if versions do not already exist in the :term:`Build Directory` at the time you source the build environment setup script. Because the Poky repository is fundamentally an aggregation of existing @@ -251,9 +250,9 @@ assumes the script is executed from within a cloned or unpacked version of Poky. Depending on where the script is sourced, different sub-scripts are -called to set up the Build Directory (Yocto or OpenEmbedded). +called to set up the :term:`Build Directory` (Yocto or OpenEmbedded). Specifically, the script ``scripts/oe-setup-builddir`` inside the poky -directory sets up the Build Directory and seeds the directory (if +directory sets up the :term:`Build Directory` and seeds the directory (if necessary) with configuration files appropriate for the Yocto Project development environment. @@ -428,7 +427,7 @@ The distribution layer provides policy configurations for your distribution. Best practices dictate that you isolate these types of configurations into their own layer. Settings you provide in ``conf/distro/distro.conf`` override similar settings that BitBake finds -in your ``conf/local.conf`` file in the Build Directory. +in your ``conf/local.conf`` file in the :term:`Build Directory`. The following list provides some explanation and references for what you typically find in the distribution layer: @@ -531,10 +530,11 @@ repositories, which is not the default behavior, and store them in the variable. Judicious use of a :term:`DL_DIR` directory can save the build system a trip -across the Internet when looking for files. A good method for using a -download directory is to have :term:`DL_DIR` point to an area outside of -your Build Directory. Doing so allows you to safely delete the Build -Directory if needed without fear of removing any downloaded source file. +across the Internet when looking for files. A good method for using a download +directory is to have :term:`DL_DIR` point to an area outside of your +:term:`Build Directory`. Doing so allows you to safely delete the +:term:`Build Directory` if needed without fear of removing any downloaded +source file. The remainder of this section provides a deeper look into the source files and the mirrors. Here is a more detailed look at the source file @@ -632,15 +632,14 @@ process validates them with generated output quality assurance checks through the :ref:`insane ` class. -The package feed area resides in the Build Directory. The directory the +The package feed area resides in the :term:`Build Directory`. The directory the build system uses to temporarily store packages is determined by a combination of variables and the particular package manager in use. See the "Package Feeds" box in the illustration and note the information to the right of that area. In particular, the following defines where package files are kept: -- :term:`DEPLOY_DIR`: Defined as - ``tmp/deploy`` in the Build Directory. +- :term:`DEPLOY_DIR`: Defined as ``tmp/deploy`` in the :term:`Build Directory`. - ``DEPLOY_DIR_*``: Depending on the package manager used, the package type sub-folder. Given RPM, IPK, or DEB packaging and tarball @@ -696,10 +695,8 @@ code: .. image:: figures/source-fetching.png :width: 100% -The :ref:`ref-tasks-fetch` and -:ref:`ref-tasks-unpack` tasks fetch -the source files and unpack them into the -:term:`Build Directory`. +The :ref:`ref-tasks-fetch` and :ref:`ref-tasks-unpack` tasks fetch +the source files and unpack them into the :term:`Build Directory`. .. note:: @@ -710,17 +707,16 @@ the source files and unpack them into the file has been modified, the :ref:`ref-tasks-fetch` task and all tasks that depend on it are re-executed. -By default, everything is accomplished in the Build Directory, which has -a defined structure. For additional general information on the Build -Directory, see the ":ref:`structure-core-build`" section in +By default, everything is accomplished in the :term:`Build Directory`, which has +a defined structure. For additional general information on the +:term:`Build Directory`, see the ":ref:`structure-core-build`" section in the Yocto Project Reference Manual. -Each recipe has an area in the Build Directory where the unpacked source -code resides. The :term:`S` variable points -to this area for a recipe's unpacked source code. The name of that -directory for any given recipe is defined from several different -variables. The preceding figure and the following list describe the -Build Directory's hierarchy: +Each recipe has an area in the :term:`Build Directory` where the unpacked +source code resides. The :term:`S` variable points to this area for a recipe's +unpacked source code. The name of that directory for any given recipe is +defined from several different variables. The preceding figure and the +following list describe the :term:`Build Directory`'s hierarchy: - :term:`TMPDIR`: The base directory where the OpenEmbedded build system performs all its work during the @@ -1258,15 +1254,12 @@ this output: ":doc:`/ref-manual/images`" chapter in the Yocto Project Reference Manual. -The build process writes images out to the :term:`Build Directory` -inside the -``tmp/deploy/images/machine/`` folder as shown in the figure. This +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 -points to the ``deploy`` directory, while the -:term:`DEPLOY_DIR_IMAGE` -variable points to the appropriate directory containing images for the -current configuration. +The :term:`DEPLOY_DIR` variable points to the ``deploy`` directory, while the +:term:`DEPLOY_DIR_IMAGE` variable points to the appropriate directory +containing images for the current configuration. - kernel-image: A kernel binary file. The :term:`KERNEL_IMAGETYPE` @@ -1340,10 +1333,9 @@ can initialize the environment before using the tools. the :doc:`/sdk-manual/index` manual. All the output files for an SDK are written to the ``deploy/sdk`` folder -inside the :term:`Build Directory` as -shown in the previous figure. Depending on the type of SDK, there are -several variables to configure these files. Here are the variables -associated with an extensible SDK: +inside the :term:`Build Directory` as shown in the previous figure. Depending +on the type of SDK, there are several variables to configure these files. +Here are the variables associated with an extensible SDK: - :term:`DEPLOY_DIR`: Points to the ``deploy`` directory. diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst index 43a6f1b480..04aea1373c 100644 --- a/documentation/overview-manual/development-environment.rst +++ b/documentation/overview-manual/development-environment.rst @@ -623,11 +623,9 @@ MIT license `here `__. 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 -:term:`Build Directory` at -``tmp/deploy/licenses``. +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 :term:`Build Directory` at ``tmp/deploy/licenses``. If a module requires a license that is not in the base list, the build process generates a warning during the build. These tools make it easier -- cgit v1.2.3-54-g00ecf