From afde290655c47bbd20bedcbc971fcf59302ecd83 Mon Sep 17 00:00:00 2001 From: Nicolas Dechesne Date: Tue, 28 Apr 2020 23:36:21 +0200 Subject: sphinx: overview-manual: add figures The automatic conversion with pandoc skipped the figures. Add them manually. (From yocto-docs rev: 1c2d071b7963490e8126a0b81792bda7a7c0bc8c) Signed-off-by: Nicolas Dechesne Signed-off-by: Richard Purdie --- .../overview-manual/overview-manual-concepts.rst | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) (limited to 'documentation/overview-manual/overview-manual-concepts.rst') diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst index b37adbbba6..11614d0e6c 100644 --- a/documentation/overview-manual/overview-manual-concepts.rst +++ b/documentation/overview-manual/overview-manual-concepts.rst @@ -171,6 +171,9 @@ The following diagram represents the high-level workflow of a build. The remainder of this section expands on the fundamental input, output, process, and metadata logical blocks that make up the workflow. +.. image:: figures/YP-flow-diagram.png + :align: center + In general, the build's workflow consists of several functional areas: - *User Configuration:* metadata you can use to control the build @@ -211,6 +214,9 @@ The following figure shows an expanded representation of the "User Configuration" box of the `general workflow figure <#general-workflow-figure>`__: +.. image:: figures/user-configuration.png + :align: center + 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 @@ -405,6 +411,9 @@ figure <#general-workflow-figure>`__: The following figure shows an expanded representation of these three layers from the `general workflow figure <#general-workflow-figure>`__: +.. image:: figures/layer-input.png + :align: center + In general, all layers have a similar structure. They all contain a licensing file (e.g. ``COPYING.MIT``) if the layer is to be distributed, a ``README`` file as good practice and especially if the layer is to be @@ -556,6 +565,9 @@ 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 area of the `general workflow figure <#general-workflow-figure>`__: +.. image:: figures/source-input.png + :align: center + Upstream Project Releases ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -637,6 +649,9 @@ area in the upper-right corner. This section looks a little closer into the package feeds area used by the build system. Here is a more detailed look at the area: +.. image:: figures/package-feeds.png + :align: center + Package feeds are an intermediary step in the build process. The OpenEmbedded build system provides classes to generate different package types, and you specify which classes to enable through the @@ -711,6 +726,9 @@ Source Fetching The first stages of building a recipe are to fetch and unpack the source code: +.. image:: figures/source-fetching.png + :align: center + The ```do_fetch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-fetch>`__ and ```do_unpack`` <&YOCTO_DOCS_REF_URL;#ref-tasks-unpack>`__ tasks fetch the source files and unpack them into the `Build @@ -802,6 +820,9 @@ Patching Once source code is fetched and unpacked, BitBake locates patch files and applies them to the source files: +.. image:: figures/patching.png + :align: center + The ```do_patch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-patch>`__ task uses a recipe's ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statements and the ```FILESPATH`` <&YOCTO_DOCS_REF_URL;#var-FILESPATH>`__ variable @@ -843,6 +864,9 @@ After source code is patched, BitBake executes tasks that configure and compile the source code. Once compilation occurs, the files are copied to a holding area (staged) in preparation for packaging: +.. image:: figures/configuration-compile-autoreconf.png + :align: center + This step in the build process consists of the following tasks: - ```do_prepare_recipe_sysroot`` <&YOCTO_DOCS_REF_URL;#ref-tasks-prepare_recipe_sysroot>`__: @@ -900,6 +924,9 @@ Package Splitting After source code is configured, compiled, and staged, the build system analyzes the results and splits the output into packages: +.. image:: figures/analysis-for-package-splitting.png + :align: center + The ```do_package`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package>`__ and ```do_packagedata`` <&YOCTO_DOCS_REF_URL;#ref-tasks-packagedata>`__ tasks combine to analyze the files found in the @@ -979,6 +1006,9 @@ Image Generation Once packages are split and stored in the Package Feeds area, the build system uses BitBake to generate the root filesystem image: +.. image:: figures/image-generation.png + :align: center + The image generation process consists of several stages and depends on several tasks and variables. The ```do_rootfs`` <&YOCTO_DOCS_REF_URL;#ref-tasks-rootfs>`__ task creates @@ -1093,6 +1123,9 @@ The OpenEmbedded build system uses BitBake to generate the Software Development Kit (SDK) installer scripts for both the standard SDK and the extensible SDK (eSDK): +.. image:: figures/sdk-generation.png + :align: center + .. note:: For more information on the cross-development toolchain generation, @@ -1272,6 +1305,9 @@ the `general workflow figure <#general-workflow-figure>`__ that BitBake output, in part, consists of images. This section takes a closer look at this output: +.. image:: figures/images.png + :align: center + .. note:: For a list of example images that the Yocto Project provides, see the @@ -1331,6 +1367,9 @@ SDK (e.g. ``bitbake -c populate_sdk_ext`` imagename) or a standard SDK (e.g. ``bitbake -c populate_sdk`` imagename). This section takes a closer look at this output: +.. image:: figures/sdk.png + :align: center + The specific form of this output is a set of files that includes a self-extracting SDK installer (``*.sh``), host and target manifest files, and files used for SDK testing. When the SDK installer file is @@ -1450,6 +1489,9 @@ creates these necessary toolchains for you. The following figure shows a high-level build environment regarding toolchain construction and use. +.. image:: figures/cross-development-toolchains.png + :align: center + Most of the work occurs on the Build Host. This is the machine used to build images and generally work within the the Yocto Project environment. When you run -- cgit v1.2.3-54-g00ecf