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 ++++++++++++++++++++++ .../overview-manual-development-environment.rst | 12 +++++++ .../overview-manual/overview-manual-yp-intro.rst | 13 ++++++- 3 files changed, 66 insertions(+), 1 deletion(-) (limited to 'documentation') 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 diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst index 4e6770c4f4..abd775be84 100644 --- a/documentation/overview-manual/overview-manual-development-environment.rst +++ b/documentation/overview-manual/overview-manual-development-environment.rst @@ -179,6 +179,9 @@ development: Yocto Metadata Layers. You can create local copies of Git repositories for each of these areas. + .. image:: figures/source-repos.png + :align: center + For steps on how to view and access these upstream Git repositories, see the "`Accessing Source Repositories <&YOCTO_DOCS_DEV_URL;#accessing-source-repositories>`__" @@ -191,6 +194,9 @@ development: these files does not produce a local copy of the Git repository but rather a snapshot of a particular release or image. + .. image:: figures/index-downloads.png + :align: center + For steps on how to view and access these files, see the "`Accessing Index of Releases <&YOCTO_DOCS_DEV_URL;#accessing-index-of-releases>`__" @@ -205,6 +211,9 @@ development: form. The tarballs are similar to those found in the `Index of /releases: <&YOCTO_DL_URL;/releases/>`__ area. + .. image:: figures/yp-download.png + :align: center + For steps on how to use the "DOWNLOADS" page, see the "`Using the Downloads Page <&YOCTO_DOCS_DEV_URL;#using-the-downloads-page>`__" section in the Yocto Project Development Tasks Manual. @@ -285,6 +294,9 @@ develop, test, and submit changes to "contrib" areas for the maintainer to examine. The maintainer then chooses which changes are going to become a permanent part of the project. +.. image:: figures/git-workflow.png + :align: center + While each development environment is unique, there are some best practices or methods that help development run smoothly. The following list describes some of these practices. For more information about Git diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst index 62257c26b9..06eeed5cb5 100644 --- a/documentation/overview-manual/overview-manual-yp-intro.rst +++ b/documentation/overview-manual/overview-manual-yp-intro.rst @@ -21,6 +21,9 @@ comes to delivering embedded software stacks. The project allows software customizations and build interchange for multiple hardware platforms as well as software stacks that can be maintained and scaled. +.. image:: figures/key-dev-elements.png + :align: center + For further introductory information on the Yocto Project, you might be interested in this `article `__ @@ -704,6 +707,9 @@ Repositories <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/>`__. The following figure illustrates what generally comprises Poky: +.. image:: figures/poky-reference-distribution.png + :align: center + - BitBake is a task executor and scheduler that is the heart of the OpenEmbedded build system. @@ -784,7 +790,12 @@ The OpenEmbedded Build System Workflow The `OpenEmbedded build system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ uses a "workflow" to accomplish image and SDK generation. The following figure overviews that -workflow: Following is a brief summary of the "workflow": +workflow: + +.. image:: figures/YP-flow-diagram.png + :align: center + +Following is a brief summary of the "workflow": 1. Developers specify architecture, policies, patches and configuration details. -- cgit v1.2.3-54-g00ecf